Quoting Christian Kastner (2022-03-23 21:36:59) > On 2022-03-23 12:43, Johannes Schauer Marin Rodrigues wrote: > > Quoting Francesco Poli (2022-03-23 00:09:21) > > Full: the problem with the current version of > > mmdebstrap-autopkgtest-build-qemu > > is, that it can only build qemu images for the native architecture. This is > > because it relies on guestfish. Guestfish will never be able to operate on > > foreign architecture qemu guests. This is because: > > > > - guestfish sets architecture specific options at compile time. This means > > that every guestfish binary can only be used for qemu guests of the same > > architecture as that binary and this cannot be changed at runtime > > > > - guestfish relies on another program called supermin. Essentially, > > supermin > > assembles a minimal chroot which is then loaded as qemu boots and then > > carries out the guestfish operations. Since supermin just copies binaries > > from the host, it cannot create foreign chroots either. > > This is unfortunate, as otherwise guestfish would be universal, but it's > understandable. > > I initially wondered whether foreign architecture guestfish/supermin > binaries couldn't be run through qemu-user-static, but that solution > would be just far too hacky I think.
I think how "hacky" it is depends on how you look at it. The advantage is, that
then you only have to maintain the "native" codepath which you run under
emulation if you want a foreign arch binary. I just tried it out and it seems
to work as expected. Big downside: running qemu (from guestfish) inside qemu
(from qemu-user-static) is *reeeeaaaaalllyyyyyy sloooooooooow*. XD
But I think it's a good idea to have for the sake of symmetry. We'd then have:
- guestfish
- fastest method when creating a native image
- slowest method when creating a foreign image
- initramfs
- medium speed for both native and foreign images
Then the new tool could have a --method switch with possible values:
- "auto" choose guestfish if installed for native images and initramfs
otherwise
- "guestfish" forces guestfish for native and foreign
- "initramfs" forces initramfs for native and foreign
> > A disadvantage is, that this only works for architectures for which qemu
> > knows
> > how to boot them without kernel and initrd from the outside. This means that
> > mips* and s390x are not supported and neither are most of the Debian ports
> > architectures. I don't know how to solve this other than by teaching
> > autopkgtest-virt-qemu that now it needs three input files: the kernel, the
> > initrd and the rootfs.
>
> Since these are QEMU options, I think autopkgtest-virt-qemu's existing
> --qemu-options could be used to supply kernel/initrd/rootfs?
Yes, that might work. Though from reading the autopkgtest-virt-qemu man page I
think this will not support paths with spaces. On the other hand, the man page
also says that additional arguments can be supplied via a file that contains
one argument per line.
> > Another disadvantage is, that the output can never be bit-by-bit
> > reproducible because grub-install is unreproducible.
> >
> > I've worked on this in context with replacing vmdb2 in
> > autopkgtest-build-qemu
> > so that sbuild-qemu-create (maintained by Christian Kastner) can be run
> > without
> > superuser privileges. We've tried to approach the vmdb2 author but Lars is
> > reluctant to include such drastic changes:
> > https://gitlab.com/larswirzenius/vmdb2/-/issues/62
> >
> > So I'll probably release yet another
> > https://wiki.debian.org/SystemBuildTools
> > because the existing solutions don't do what I want. The closest is probably
> > debos which can be run without being root because everything is done inside
> > qemu. But it also doesn't solve the hard problem of installing a bootloader,
> > leaving it to the user: https://github.com/go-debos/debos/issues/137
>
> I think this is a fantastic idea, not just because sbuild-qemu would be
> a major beneficiary but because there is a general gap here: there
> currently is no tool that can easily create images (1) without root and
> (2) for arbitrary architectures.
>
> Having such a tool would enable many upstreams to easily test their
> software on other architectures, e.g. via GitHub Actions. PowerPC and
> RISC-V are interesting contenders but only the fewest projects test
> them. However, our buildds and debci discover issues all the time.
>
> Additionally, it's really useful to have an on-demand, throwaway
> porterbox when you need one. I probably use sbuild-qemu-boot more than
> sbuild-qemu, and the former is just a QEMU launcher. I use it even for
> native architectures because it's basically a container-like workspace
> where I can do Bad Stuff without fear of polluting or trashing my system.
>
> I've run out of ideas how to easily solve this, other than what
> Francesco suggested (e.g. create a base with FAI or preseed.cfg, then
> finalize by running commands in the VM just as sbuild-qemu-update does
> it). Really looking forward to what you are working on.
>
> If you need a test user, I'll happily volunteer!
I'm not so sure whether it's a fantastic idea. First I want to evaluate other
existing tools like debos and see if they can do the job or not. I want to
resist the NIH syndrome.
Another question that I'm still pondering is how much configuration this new
tool should allow. I'm tempted to make it just fit for the use-case of
autopkgtest backend or porterbox or sbuild-qemu backend just to keep it simple.
And lastly, the name is also still an open question.
Alas, I'll probably not get to working on this much in the next two weeks.
Lets see. :)
Thanks!
cheers, josch
signature.asc
Description: signature
