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.
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.
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.
Best,
Christian
