4 ms·

Using QEMU to produce Debian filesystems for multiple architectures

69 points by headmelted 8y ago

elboulangero 8y ago
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
- headmelted 8y ago
  I actually really like how debos handles this - unfortunately when I went down the road of trying to get it working for my setup I couldn't get it to complete the debootstrap process (I admittedly didn't spend too much time trying to get this working - my suspicion was that it had to do with kernel support on my build agent). I hit the same roadblock with qemu-debootstrap, which is a great wrapper for this use case, but makes (to be fair, reasonable) assumptions about permissions you do and do not have that might not apply in a build agent where you don't have control of the kernel. Separating the process out into two stages helped with this as I was manually able to perform only the mounts needed to get a minimal filesystem produced. Not to plug but I wrote another article that explains the context in which I'm producing the builds and goes into more details about the constraints (https://headmelted.com/continuous-delivery-with-azure-pipelines-and-github-releases-20a0155360d8 https://headmelted.com/continuous-delivery-with-azure-pipeli...). All that said, debos is a great tool if it fits your situation (as is qemu-debootstrap!)
- eeZah7Ux 8y ago
  I'd rather use debootstrap, it's been the standard for decades.
  - ausjke 8y ago
    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.
Spock1979 8y ago
Awesome article Jay.. impressive stuff - looking forward to the next article!
Walkman 8y ago
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 8y ago
  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)
jschwartzi 8y ago
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 8y ago
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?

69 points by headmelted 8y ago

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

headmelted 8y ago
I actually really like how debos handles this - unfortunately when I went down the road of trying to get it working for my setup I couldn't get it to complete the debootstrap process (I admittedly didn't spend too much time trying to get this working - my suspicion was that it had to do with kernel support on my build agent). I hit the same roadblock with qemu-debootstrap, which is a great wrapper for this use case, but makes (to be fair, reasonable) assumptions about permissions you do and do not have that might not apply in a build agent where you don't have control of the kernel. Separating the process out into two stages helped with this as I was manually able to perform only the mounts needed to get a minimal filesystem produced. Not to plug but I wrote another article that explains the context in which I'm producing the builds and goes into more details about the constraints (https://headmelted.com/continuous-delivery-with-azure-pipelines-and-github-releases-20a0155360d8 https://headmelted.com/continuous-delivery-with-azure-pipeli...). All that said, debos is a great tool if it fits your situation (as is qemu-debootstrap!)
eeZah7Ux 8y ago
I'd rather use debootstrap, it's been the standard for decades.
- ausjke 8y ago
  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.

Spock1979 8y ago

Awesome article Jay.. impressive stuff - looking forward to the next article!

Walkman 8y ago

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 8y ago
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)

jschwartzi 8y ago

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 8y ago

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?