On Mon, 2026-04-13 at 22:39 +0200, Christian Kastner wrote:
> Control: reopen -1
>
> On 2026-04-13 07:27, Michael Prokop wrote:
> > * Christian Kastner [Sat Apr 11, 2026 at 09:41:55AM +0200]:
> > > On 2026-04-10 23:59, Benjamin Drung wrote:
> > > > 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.
> >
> > I'd like to highlight and echo Chris' (Hofstaedtler) comment:
> >
> > > 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.
> >
> > *Please* let's avoid a solution for which every single image
> > builder tool needs to special case things.
>
> I'm afraid this either didn't fix the issue and/or Chris & Michael are
> right, in that it works but is non-ideal.
>
> I tried adding DRACUT_EXTRA_ARGS=--no-hostonly to various parts of
> autopkgtest, but did not succeed; the boot still fails at the same spot.
Can you show me your patch so that I can reproduce it?
> I count at least three occurrences of dracut invocation during an image
> build:
> (1) when the kernel is installed, a vmdb2 step
> (2) when GRUB is installed, a vmdb2 step
> (3) somewhere in autopkgtest's post-installation script
> ("setup-testbed"), where some systemd change seems to fire a
> trigger
>
> It's possible that I overlooked something. But in that case, I believe
> the above is a good example for how injecting this envvar is a
> sub-optimal solution, especially in light of the many other image build
> tools out there that might be affected.
>
> I was thinking: perhaps there is a way to restore most of the old
> behaviour for the typical image builder use case, while otherwise
> enabling the new one.
>
> Specifically, if the root device in question is /dev/loop*, then
> automatically use --no-hostonly. and users for which this would be wrong
> could set DRACUT_EXTRA_ARGS=--hostonly. So the logic is turned around.
The current logic is:
* --hostonly is the default
* if /dev is not mounted, disable hostonly (thus --no-hostonly)
* the hostonly setting influences the default for --hostonly-cmdline
This --hostonly-cmdline causes the VM to fail to boot.
> Unless I'm mistaken, this would
> (a) "fix" all image builders again
> (b) at the cost of doing the wrong thing by default on systems where
> /dev/loop* is intentional, but with an option to go around
> this.
>
> I'm probably biased, but I'd wager that the (a) use case is much more
> likely than the (b) one.
The big question to me is: is that proposal really the best default
behaviour? Can we discuss this upstream in
https://github.com/dracut-ng/dracut-ng/issues/2355
--
Benjamin Drung
Debian & Ubuntu Developer
