On 2026-04-10 23:59, Benjamin Drung wrote: > On Wed, 2026-04-08 at 12:45 +0200, Benjamin Drung wrote: >> On Wed, 2026-04-08 at 12:06 +0200, Chris Hofstaedtler wrote: >>> On Wed, Apr 08, 2026 at 11:39:18AM +0200, Benjamin Drung wrote: >>>> Explanation: When installing linux-image-amd64, /dev is not mounted and >>>> dracut turns off host-only mode. That's what we want for this image. But >>>> then /dev gets mounted and the initrd is regenerated (when installing >>>> grub-efi-amd6). This time the initrd is build in host-only mode. >>>> >>>> The big question: How to solve that? Should dracut become smarter and >>>> detect either the chroot run or that a loop mount is probably not what >>>> is wanted? >>> >>> IMO detection of the chroot is a good approach. We already have >>> various software pieces that behave differently when they detect a >>> chroot (systemctl, glibc postinst, etc). >>> >>> I think this would also help users that run in a rescue environment, >>> as (per my limited understanding), hostonly would also likely >>> produce something that won't boot. >>> >>>> Or should autopkgtest-build-qemu add a dracut config to >>>> disable host-only? >>>> This could be done by placing a file in /etc/dracut.conf.d/*.conf with: >>>> hostonly="no" >>> >>> As I wrote earlier, I believe this is non-ideal. Each image builder >>> will have to learn it, and each image builder will do something >>> different. You'll end up with various configurations in the wild >>> that you don't know that they exist. >>> >>> Also it seems to me that, once the built installation actually >>> booted, users no longer want the override. >> >> I forwarded this issue to upstream: >> https://github.com/dracut-ng/dracut-ng/issues/2355 > > The discussed solution in dracut: > https://github.com/dracut-ng/dracut-ng/pull/2369 > > In case this patch is applied in dracut, autopkgtest-build-qemu should > set this environment variable during the build: > > DRACUT_EXTRA_ARGS=--no-hostonly
While an option, I'm not entirely sure if autopkgtest is the correct place to do this. The actual image build happens through the lower-level vmdb2, so fixing the problem generally would probably require fixing it in vmdb2. Looping the autopkgtest and vmdb2 maintainers in, in case they see this differently. Best, Christian
