
Using QEMU to produce Debian filesystems for multiple architectures - headmelted
https://headmelted.com/using-qemu-to-produce-debian-filesystems-for-multiple-architectures-280df41d28eb
======
elboulangero
You might want to check debos [1], which I think allows something similar.

[1] [https://github.com/go-debos/debos](https://github.com/go-debos/debos)

~~~
eeZah7Ux
I'd rather use debootstrap, it's been the standard for decades.

~~~
ausjke
it's good for a "bootstrap" root filesystem, a starting point that is, but
might be difficult to build a full blown distro. With a basic rootfs, you need
a virtual machine like qemu or kvm to make a full release.

------
jschwartzi
Note that Multistrap from the emdebian project is intended to do at a higher
level when this article uses debootstrap for.

[https://wiki.debian.org/Multistrap](https://wiki.debian.org/Multistrap)

You still need either an embedded system or a QEMU emulator to finish
installing the packages but you can build a complete root filesystem with a
simple configuration file.

------
sneak
What bothers me is that this requires a running linux kernel and root to
eventually produce a single regular file. Why is this not refactored in such a
way that it can be done conveniently from userspace?

------
Walkman
You probably don't want to use this the same way you don't want to use random
Docker images from the docker hub. I don't see the use case for this.

~~~
headmelted
I'm currently working on a cross-compilation solution that needed these root
filesystems, and knew they would be of use to others.

If it helps with piece of mind, the images are built in the open (the Azure
Pipelines YAML file in the repo handles this).

There are a bunch of scenarios in which you may find yourself unable to
_create_ these with debootstrap yourself (e.g. restricted permissions, a
kernel without binfmt_misc suppport), but _are_ able to use them (using proot
to avoid needing admin, or Resin's patched version of QEMU that reworks
execve() to operate without binfmt)

