Using QEMU to produce Debian filesystems for multiple architectures | Hacker News Reader

Using QEMU to produce Debian filesystems for multiple architectures

headmelted.com

69 pointsheadmelted8 comments

You might want to check debos [1], which I think allows something similar.

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-pipeli...).

All that said, debos is a great tool if it fits your situation (as is qemu-debootstrap!)

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

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.

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

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.

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?

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.

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)

Reply on news.ycombinator.com