On 2026-04-13 22:50, Benjamin Drung wrote:
> On Mon, 2026-04-13 at 22:39 +0200, Christian Kastner wrote:
>> 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'm sorry, but when re-creating the two changes, things now worked. I
suspect that I might have had a typo that escaped even repeated checks.
>> 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
In this case, the solution was to change (3), specifically by adding
export DRACUT_EXTRA_ARGS=--no-hostonly
to the top of:
/usr/share/autopkgtest/setup-commands/setup-testbed
>> 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.
Even though this could be resolved for the autopkgtest case after all,
as per your instructions, I still have the feeling that this would
remain a challenge for other image builders that could be better
addressed (though again, I'm probably biased).
>> 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
> 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
If you are open to this, sure, though my next opportunity to contribute
will be on Wednesday.
Best,
Christian
