On 2022-04-02 07:58, Johannes Schauer Marin Rodrigues wrote: > Quoting Christian Kastner (2022-03-23 21:36:59) >> 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.
Well, that's cool to hear! > Big downside: running qemu (from guestfish) inside qemu (from > qemu-user-static) is *reeeeaaaaalllyyyyyy sloooooooooow*. XD How slow? On my end, IIRC sbuild-qemu-create takes 2mins to build a native image, and 12-13mins to build a foreign one. However, that's wall-time, for a process that can run unattended. Having a one-time, slow, non-interactive process might not be that bad, compared to needing root. > 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 Sounds good. >> 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. Indeed, I just checked and autopkgtest-virt-qemu just calls .split() on the string. The file workaround should be fine, though. > 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. Full ACK. Hence the focus on extending vmdb2 if possible, or using guestfish or debos, but I myself don't favor any particular tool. My first choice would simply be the tool that accomplishes it. > 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. Indeed, I have asked myself the same question a number of times. It's tempting to make this as flexible as possible, but in the end, it's main use cases are build and test environments. From experience, this means that one frequently needs to configure hardware (e.g. number of CPUs), or modify the build environment (configure external repos, pre-install packages, copy files e.g. SSH keys). So it can be helpful to facilitate a few common uses, but it's probably overkill to allow for all, and it's probably also not needed: after all, one can always boot the image, and modify interactively. > And lastly, the name is also still an open question. The hardest part :D > Alas, I'll probably not get to working on this much in the next two weeks. Best of luck! I wish I could do more to help, but still swamped at the moment, with little time for Debian. Best, Christian
