Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
Hi,
Quoting Benjamin Drung (2026-05-06 14:11:13)
> > I would like to add another "me too" to what ch and mika said. I am
> > maintaining quite a few "image builders" and just ran into this problem
> > with one of them. This used to work automatically before dracut came
> > along. It can thus evidently be solved automatically. It is an anti-feature
> > to now make all image builders set another environment variable just so
> > that dracut is happy. As ch pointed out, this means that I also have to
> > backport such a change to earlier versions of Debian so that Debian stable
> > or oldstable is able to create a dracut image for testing and unstable.
> > Please fix this problem in one place (in dracut) instead of forcing a lot
> > of maintainers to do busy-work.
>
> Can you give me psaudo-code or logic how to determine when dracut should
> default to build a generic initrd and when it can build a host-only initrd?
you could use the ischroot command, no?
Usually, chroot checks use something similar to this:
ischroot() {
if [ "$(stat -c "%d/%i" "/")" != "$(stat -Lc "%d/%i" "/proc/1/root"
2>/dev/null)" ]; then
return 0 # in a chroot
fi
return 1 # not in a chroot
}
This checks whether the devicenumber/inode pair of what the process sees as the
root of the filesystem is the same as the one that the process which is
currently
PID 1 (init) sees.
The above shell snippet is similar to what used to be used by initramfs-tools
before they switched to using the ischroot tool in 2016 (commit b0a5f26a).
The origin of the snippet might've been the udev postinst where it lived until
2023 when it got switched out in favour of dh_installsystemd.
Thanks!
cheers, josch
signature.asc
Description: signature
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
On Wed, 2026-05-06 at 12:26 +0200, Johannes Schauer Marin Rodrigues wrote: > Hi, > > On Mon, 13 Apr 2026 07:27:33 +0200 Michael Prokop wrote: > > * Christian Kastner [Sat Apr 11, 2026 at 09:41:55AM +0200]: > > > 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: > > > > > > > > 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. > > > > > > 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. > > > > (Speaking with my hat as author of grml-debootstrap (which exists > > since 2006) and project lead of the Grml rescue live system, and > > being a previous contributor and maintainer of initramfs-tools. > > Please don't think about autopkgtest + vmdb2 only, there are *many* image > > builder tools around.) > > I would like to add another "me too" to what ch and mika said. I am > maintaining > quite a few "image builders" and just ran into this problem with one of them. > This used to work automatically before dracut came along. It can thus > evidently > be solved automatically. It is an anti-feature to now make all image builders > set another environment variable just so that dracut is happy. As ch pointed > out, this means that I also have to backport such a change to earlier versions > of Debian so that Debian stable or oldstable is able to create a dracut image > for testing and unstable. Please fix this problem in one place (in dracut) > instead of forcing a lot of maintainers to do busy-work. Can you give me psaudo-code or logic how to determine when dracut should default to build a generic initrd and when it can build a host-only initrd? -- Benjamin Drung Debian & Ubuntu Developer
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
Hi, On Mon, 13 Apr 2026 07:27:33 +0200 Michael Prokop wrote: > * Christian Kastner [Sat Apr 11, 2026 at 09:41:55AM +0200]: > > 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: > > > >>> 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. > > > > 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. > > (Speaking with my hat as author of grml-debootstrap (which exists > since 2006) and project lead of the Grml rescue live system, and > being a previous contributor and maintainer of initramfs-tools. > Please don't think about autopkgtest + vmdb2 only, there are *many* image > builder tools around.) I would like to add another "me too" to what ch and mika said. I am maintaining quite a few "image builders" and just ran into this problem with one of them. This used to work automatically before dracut came along. It can thus evidently be solved automatically. It is an anti-feature to now make all image builders set another environment variable just so that dracut is happy. As ch pointed out, this means that I also have to backport such a change to earlier versions of Debian so that Debian stable or oldstable is able to create a dracut image for testing and unstable. Please fix this problem in one place (in dracut) instead of forcing a lot of maintainers to do busy-work. Thanks! cheers, josch signature.asc Description: signature
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
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
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
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
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
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
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
Hi, * Christian Kastner [Sat Apr 11, 2026 at 09:41:55AM +0200]: > 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: > >>> 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. [...] > >> 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. 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. (Speaking with my hat as author of grml-debootstrap (which exists since 2006) and project lead of the Grml rescue live system, and being a previous contributor and maintainer of initramfs-tools. Please don't think about autopkgtest + vmdb2 only, there are *many* image builder tools around.) regards -mika- signature.asc Description: PGP signature
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
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
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
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: > > [..] > > > ``` > > > $ sudo autopkgtest-build-qemu --boot=efi unstable /tmp/unstable-amd64.img > > > [...] > > > Exec: ['chroot', '/tmp/tmpyajn1s9p', 'eatmydata', 'apt-get', '-y', > > > '--no-show-progress', '', 'install', 'linux-image-amd64'] > > > [...] > > > Processing triggers for dracut (110-9) ... > > > update-initramfs: Generating /boot/initrd.img-6.19.11+deb14-amd64 > > > dracut[W]: Turning off host-only mode: /dev is not mounted! > > > [...] > > > Exec: ['mount', '--bind', '/dev', '/tmp/tmpyajn1s9p/dev'] > > > Exec: ['mount', '--bind', '/sys', '/tmp/tmpyajn1s9p/sys'] > > > Exec: ['mount', '--bind', '/proc', '/tmp/tmpyajn1s9p/proc'] > > > Exec: ['parted', '-s', '/dev/loop15', 'set', '1', 'esp', 'on'] > > > Exec: ['chroot', '/tmp/tmpyajn1s9p', 'apt-get', 'update'] > > > Hit:1 http://deb.debian.org/debian unstable InRelease > > > Reading package lists... > > > Exec: ['chroot', '/tmp/tmpyajn1s9p', 'apt-get', '-y', > > > '--no-show-progress', 'install', 'grub-efi-amd64'] > > > [...] > > > Processing triggers for dracut (110-9) ... > > > update-initramfs: Generating /boot/initrd.img-6.19.11+deb14-amd64 > > > [...] > > > ``` > > > > > > Then converting the resulting image to raw, mount it and run `lsinitrd` > > > on /boot/initrd.img-6.19.11+deb14-amd64 gives: > > > > > > ``` > > > dracut cmdline: > > > root=/dev/mapper/loop15p2 rootfstype=ext4 rootflags=rw,relatime > > > ``` > > > > > > 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 -- Benjamin Drung Debian & Ubuntu Developer
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
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: > [..] > > ``` > > $ sudo autopkgtest-build-qemu --boot=efi unstable /tmp/unstable-amd64.img > > [...] > > Exec: ['chroot', '/tmp/tmpyajn1s9p', 'eatmydata', 'apt-get', '-y', > > '--no-show-progress', '', 'install', 'linux-image-amd64'] > > [...] > > Processing triggers for dracut (110-9) ... > > update-initramfs: Generating /boot/initrd.img-6.19.11+deb14-amd64 > > dracut[W]: Turning off host-only mode: /dev is not mounted! > > [...] > > Exec: ['mount', '--bind', '/dev', '/tmp/tmpyajn1s9p/dev'] > > Exec: ['mount', '--bind', '/sys', '/tmp/tmpyajn1s9p/sys'] > > Exec: ['mount', '--bind', '/proc', '/tmp/tmpyajn1s9p/proc'] > > Exec: ['parted', '-s', '/dev/loop15', 'set', '1', 'esp', 'on'] > > Exec: ['chroot', '/tmp/tmpyajn1s9p', 'apt-get', 'update'] > > Hit:1 http://deb.debian.org/debian unstable InRelease > > Reading package lists... > > Exec: ['chroot', '/tmp/tmpyajn1s9p', 'apt-get', '-y', '--no-show-progress', > > 'install', 'grub-efi-amd64'] > > [...] > > Processing triggers for dracut (110-9) ... > > update-initramfs: Generating /boot/initrd.img-6.19.11+deb14-amd64 > > [...] > > ``` > > > > Then converting the resulting image to raw, mount it and run `lsinitrd` > > on /boot/initrd.img-6.19.11+deb14-amd64 gives: > > > > ``` > > dracut cmdline: > > root=/dev/mapper/loop15p2 rootfstype=ext4 rootflags=rw,relatime > > ``` > > > > 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 -- Benjamin Drung Debian & Ubuntu Developer
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
On Wed, Apr 08, 2026 at 11:39:18AM +0200, Benjamin Drung wrote: [..] > ``` > $ sudo autopkgtest-build-qemu --boot=efi unstable /tmp/unstable-amd64.img > [...] > Exec: ['chroot', '/tmp/tmpyajn1s9p', 'eatmydata', 'apt-get', '-y', > '--no-show-progress', '', 'install', 'linux-image-amd64'] > [...] > Processing triggers for dracut (110-9) ... > update-initramfs: Generating /boot/initrd.img-6.19.11+deb14-amd64 > dracut[W]: Turning off host-only mode: /dev is not mounted! > [...] > Exec: ['mount', '--bind', '/dev', '/tmp/tmpyajn1s9p/dev'] > Exec: ['mount', '--bind', '/sys', '/tmp/tmpyajn1s9p/sys'] > Exec: ['mount', '--bind', '/proc', '/tmp/tmpyajn1s9p/proc'] > Exec: ['parted', '-s', '/dev/loop15', 'set', '1', 'esp', 'on'] > Exec: ['chroot', '/tmp/tmpyajn1s9p', 'apt-get', 'update'] > Hit:1 http://deb.debian.org/debian unstable InRelease > Reading package lists... > Exec: ['chroot', '/tmp/tmpyajn1s9p', 'apt-get', '-y', '--no-show-progress', > 'install', 'grub-efi-amd64'] > [...] > Processing triggers for dracut (110-9) ... > update-initramfs: Generating /boot/initrd.img-6.19.11+deb14-amd64 > [...] > ``` > > Then converting the resulting image to raw, mount it and run `lsinitrd` > on /boot/initrd.img-6.19.11+deb14-amd64 gives: > > ``` > dracut cmdline: > root=/dev/mapper/loop15p2 rootfstype=ext4 rootflags=rw,relatime > ``` > > 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. Chris
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
On Wed, 2026-04-08 at 08:13 +0200, Christian Kastner wrote: > Control: reopen -1 > > On 2026-04-07 13:37, Christian Kastner wrote: > > On 2026-04-07 13:26, Benjamin Drung wrote: > > > Okay. Found it: dracut in installed and generates the initrd. Some time > > > later /dev is mounted: > > > > > > Exec: ['mount', '--bind', '/dev', '/tmp/tmp8sopd0qw/dev'] > > > Exec: ['mount', '--bind', '/sys', '/tmp/tmp8sopd0qw/sys'] > > > Exec: ['mount', '--bind', '/proc', '/tmp/tmp8sopd0qw/proc'] > > > > > > Then your modscript.sh is executed: > > > > > > Processing triggers for dracut (110-9) ... > > > update-initramfs: Generating /boot/initrd.img-6.19.11+deb14-amd64 > > > > > > This time hostonly mode is not disabled, because /dev is mounted. > > > If you are confident enough with the change, that's more than good > > enough for me. And a -9 upload will enable a regular test. > > I tested 110-9, and I'm afraid the problem is still present. A boot with > qemu-system-x86 shows it's again hangs at > > (1 of 2) Job dev-mapper-loop0p1.device/start running (3s / no limit) > (2 of 2) Job dracut-initqueue.service/start running (8s / no limit) I could reproduce the issue: ``` $ sudo autopkgtest-build-qemu --boot=efi unstable /tmp/unstable-amd64.img [...] Exec: ['chroot', '/tmp/tmpyajn1s9p', 'eatmydata', 'apt-get', '-y', '--no-show-progress', '', 'install', 'linux-image-amd64'] [...] Processing triggers for dracut (110-9) ... update-initramfs: Generating /boot/initrd.img-6.19.11+deb14-amd64 dracut[W]: Turning off host-only mode: /dev is not mounted! [...] Exec: ['mount', '--bind', '/dev', '/tmp/tmpyajn1s9p/dev'] Exec: ['mount', '--bind', '/sys', '/tmp/tmpyajn1s9p/sys'] Exec: ['mount', '--bind', '/proc', '/tmp/tmpyajn1s9p/proc'] Exec: ['parted', '-s', '/dev/loop15', 'set', '1', 'esp', 'on'] Exec: ['chroot', '/tmp/tmpyajn1s9p', 'apt-get', 'update'] Hit:1 http://deb.debian.org/debian unstable InRelease Reading package lists... Exec: ['chroot', '/tmp/tmpyajn1s9p', 'apt-get', '-y', '--no-show-progress', 'install', 'grub-efi-amd64'] [...] Processing triggers for dracut (110-9) ... update-initramfs: Generating /boot/initrd.img-6.19.11+deb14-amd64 [...] ``` Then converting the resulting image to raw, mount it and run `lsinitrd` on /boot/initrd.img-6.19.11+deb14-amd64 gives: ``` dracut cmdline: root=/dev/mapper/loop15p2 rootfstype=ext4 rootflags=rw,relatime ``` 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? 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" -- Benjamin Drung Debian & Ubuntu Developer
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
Control: reopen -1 On 2026-04-07 13:37, Christian Kastner wrote: > On 2026-04-07 13:26, Benjamin Drung wrote: >> Okay. Found it: dracut in installed and generates the initrd. Some time >> later /dev is mounted: >> >> Exec: ['mount', '--bind', '/dev', '/tmp/tmp8sopd0qw/dev'] >> Exec: ['mount', '--bind', '/sys', '/tmp/tmp8sopd0qw/sys'] >> Exec: ['mount', '--bind', '/proc', '/tmp/tmp8sopd0qw/proc'] >> >> Then your modscript.sh is executed: >> >> Processing triggers for dracut (110-9) ... >> update-initramfs: Generating /boot/initrd.img-6.19.11+deb14-amd64 >> >> This time hostonly mode is not disabled, because /dev is mounted. > If you are confident enough with the change, that's more than good > enough for me. And a -9 upload will enable a regular test. I tested 110-9, and I'm afraid the problem is still present. A boot with qemu-system-x86 shows it's again hangs at (1 of 2) Job dev-mapper-loop0p1.device/start running (3s / no limit) (2 of 2) Job dracut-initqueue.service/start running (8s / no limit) I'm very much embarrassed, but I now see that for the autopkgtest *running*, I repeatedly blind-typed the wrong command. Muscle memory, I guess... Of course, the runner also needs the EFI option: $ autopkgtest -B -U dracut -- qemu --boot=efi /tmp/unstable-amd64.img However: the qemu-system-x86_64 command I shared earlier was correct, and the way I reproduced the two messages from boot above. Best, Christian
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
On Tue, 2026-04-07 at 13:16 +0200, Benjamin Drung wrote: > On Tue, 2026-04-07 at 12:34 +0200, Christian Kastner wrote: > > On 2026-04-07 12:07, Benjamin Drung wrote: > > > On Tue, 2026-04-07 at 11:44 +0200, Benjamin Drung wrote: > > > > Those two reports gave me a clue. I assume the opposite. You want > > > > hostonly disabled. The patch fix-dracut-enable-hostonly_cmdline-in- > > > > hostonly-mode-again.patch enables hostonly-cmdline by default again, but > > > > this: > > > > > > > > dracut[W]: Turning off host-only mode: /dev is not mounted! > > > > > > > > does not turn off hostonly-cmdline which causes the host config to leak > > > > into the initrd. I'll prepare a fix for dracut. > > > > > > Here comes the fix: https://github.com/dracut-ng/dracut-ng/pull/2351 > > > > > > Can you test that this fix solves your issue? > > > > It seems not, I'm afraid. > > > > I tested this by first rebuilding -8 with your newest change. > > > > Then telling autopkgtest-build-qemu to install these rebuilt packages > > with the following post-creation script: > > > > modscript.sh > > > > #!/bin/sh > > > > # autopkgtest-build-qemu passes the chroot as $1 > > [ -n "$1" ] || exit 1 > > > > cp /tmp/rebuild/*.deb "$1"/ > > chroot "$1" dpkg -i dracut_110-8_all.deb dracut-core_110-8_amd64.deb > > dracut-install_110-8_amd64.deb > > > > > > $ autopkgtest-build-qemu --script=modscript.sh --boot=efi unstable > > /tmp/unstable-amd64.img > > > > And finally booting with the qemu-system-x86_64 command string that I > > shared earlier. It still hangs at the same spot, referencing loop0p1. > > > > > > I tested this exact same procedure above with the -7 from snapshot.d.o, > > and that worked fine, so the procedure itself seems correct. > > > > I can also confirm that the warning printed is not relevant, as it also > > appears in the -7 as I just noticed. It must have been an added after > > trixie, as extra information. > > I could reproduce your results with a patched dracut: > > ``` > $ lsinitrd /boot/initrd.img-6.19.11+deb14-amd64 > [...] > dracut cmdline: > root=/dev/mapper/loop77p2 rootfstype=ext4 rootflags=rw,relatime > ``` > > But I verified in a chroot that the patch works as intended > (hostonly_cmdline is enabled before but disabled with the patch). > > We need to further investigate what went wrong in your example. At least > I see "Version: dracut-110-9" in the lsinitrd output. So the initrd was > regenerated after the package update. Okay. Found it: dracut in installed and generates the initrd. Some time later /dev is mounted: Exec: ['mount', '--bind', '/dev', '/tmp/tmp8sopd0qw/dev'] Exec: ['mount', '--bind', '/sys', '/tmp/tmp8sopd0qw/sys'] Exec: ['mount', '--bind', '/proc', '/tmp/tmp8sopd0qw/proc'] Then your modscript.sh is executed: Processing triggers for dracut (110-9) ... update-initramfs: Generating /boot/initrd.img-6.19.11+deb14-amd64 This time hostonly mode is not disabled, because /dev is mounted. -- Benjamin Drung Debian & Ubuntu Developer
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
Apologies, I forgot to turn off wrapping. Correct copy-pastable versions below. modscript.sh #!/bin/sh # autopkgtest-build-qemu passes the chroot as $1 [ -n "$1" ] || exit 1 cp /tmp/rebuild/*.deb "$1"/ chroot "$1" dpkg -i dracut_110-8_all.deb dracut-core_110-8_amd64.deb dracut-install_110-8_amd64.deb $ autopkgtest-build-qemu --script=modscript.sh --boot=efi unstable /tmp/unstable-amd64.img
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
On 2026-04-07 13:26, Benjamin Drung wrote: > On Tue, 2026-04-07 at 13:16 +0200, Benjamin Drung wrote:>> I could reproduce > your results with a patched dracut: >> >> ``` >> $ lsinitrd /boot/initrd.img-6.19.11+deb14-amd64 >> [...] >> dracut cmdline: >> root=/dev/mapper/loop77p2 rootfstype=ext4 rootflags=rw,relatime >> ``` >> >> But I verified in a chroot that the patch works as intended >> (hostonly_cmdline is enabled before but disabled with the patch). >> >> We need to further investigate what went wrong in your example. At least >> I see "Version: dracut-110-9" in the lsinitrd output. So the initrd was >> regenerated after the package update. > > Okay. Found it: dracut in installed and generates the initrd. Some time > later /dev is mounted: > > Exec: ['mount', '--bind', '/dev', '/tmp/tmp8sopd0qw/dev'] > Exec: ['mount', '--bind', '/sys', '/tmp/tmp8sopd0qw/sys'] > Exec: ['mount', '--bind', '/proc', '/tmp/tmp8sopd0qw/proc'] > > Then your modscript.sh is executed: > > Processing triggers for dracut (110-9) ... > update-initramfs: Generating /boot/initrd.img-6.19.11+deb14-amd64 > > This time hostonly mode is not disabled, because /dev is mounted. Thank you for figuring this one out. So my testing methodology was flawed. Unfortunately, I don't know any other way that autopkgtest-build-qemu could be tested, at least not easily (I supposed some --mirror could be hacked). If you are confident enough with the change, that's more than good enough for me. And a -9 upload will enable a regular test. Best, Christian
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
On Tue, 2026-04-07 at 12:34 +0200, Christian Kastner wrote: > On 2026-04-07 12:07, Benjamin Drung wrote: > > On Tue, 2026-04-07 at 11:44 +0200, Benjamin Drung wrote: > > > Those two reports gave me a clue. I assume the opposite. You want > > > hostonly disabled. The patch fix-dracut-enable-hostonly_cmdline-in- > > > hostonly-mode-again.patch enables hostonly-cmdline by default again, but > > > this: > > > > > > dracut[W]: Turning off host-only mode: /dev is not mounted! > > > > > > does not turn off hostonly-cmdline which causes the host config to leak > > > into the initrd. I'll prepare a fix for dracut. > > > > Here comes the fix: https://github.com/dracut-ng/dracut-ng/pull/2351 > > > > Can you test that this fix solves your issue? > > It seems not, I'm afraid. > > I tested this by first rebuilding -8 with your newest change. > > Then telling autopkgtest-build-qemu to install these rebuilt packages > with the following post-creation script: > > modscript.sh > > #!/bin/sh > > # autopkgtest-build-qemu passes the chroot as $1 > [ -n "$1" ] || exit 1 > > cp /tmp/rebuild/*.deb "$1"/ > chroot "$1" dpkg -i dracut_110-8_all.deb dracut-core_110-8_amd64.deb > dracut-install_110-8_amd64.deb > > > $ autopkgtest-build-qemu --script=modscript.sh --boot=efi unstable > /tmp/unstable-amd64.img > > And finally booting with the qemu-system-x86_64 command string that I > shared earlier. It still hangs at the same spot, referencing loop0p1. > > > I tested this exact same procedure above with the -7 from snapshot.d.o, > and that worked fine, so the procedure itself seems correct. > > I can also confirm that the warning printed is not relevant, as it also > appears in the -7 as I just noticed. It must have been an added after > trixie, as extra information. I could reproduce your results with a patched dracut: ``` $ lsinitrd /boot/initrd.img-6.19.11+deb14-amd64 [...] dracut cmdline: root=/dev/mapper/loop77p2 rootfstype=ext4 rootflags=rw,relatime ``` But I verified in a chroot that the patch works as intended (hostonly_cmdline is enabled before but disabled with the patch). We need to further investigate what went wrong in your example. At least I see "Version: dracut-110-9" in the lsinitrd output. So the initrd was regenerated after the package update. -- Benjamin Drung Debian & Ubuntu Developer
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
On 2026-04-07 12:07, Benjamin Drung wrote: > On Tue, 2026-04-07 at 11:44 +0200, Benjamin Drung wrote: >> Those two reports gave me a clue. I assume the opposite. You want >> hostonly disabled. The patch fix-dracut-enable-hostonly_cmdline-in- >> hostonly-mode-again.patch enables hostonly-cmdline by default again, but >> this: >> >> dracut[W]: Turning off host-only mode: /dev is not mounted! >> >> does not turn off hostonly-cmdline which causes the host config to leak >> into the initrd. I'll prepare a fix for dracut. > > Here comes the fix: https://github.com/dracut-ng/dracut-ng/pull/2351 > > Can you test that this fix solves your issue? It seems not, I'm afraid. I tested this by first rebuilding -8 with your newest change. Then telling autopkgtest-build-qemu to install these rebuilt packages with the following post-creation script: modscript.sh #!/bin/sh # autopkgtest-build-qemu passes the chroot as $1 [ -n "$1" ] || exit 1 cp /tmp/rebuild/*.deb "$1"/ chroot "$1" dpkg -i dracut_110-8_all.deb dracut-core_110-8_amd64.deb dracut-install_110-8_amd64.deb $ autopkgtest-build-qemu --script=modscript.sh --boot=efi unstable /tmp/unstable-amd64.img And finally booting with the qemu-system-x86_64 command string that I shared earlier. It still hangs at the same spot, referencing loop0p1. I tested this exact same procedure above with the -7 from snapshot.d.o, and that worked fine, so the procedure itself seems correct. I can also confirm that the warning printed is not relevant, as it also appears in the -7 as I just noticed. It must have been an added after trixie, as extra information. Best, Christian
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
On Tue, 2026-04-07 at 11:44 +0200, Benjamin Drung wrote: > On Tue, 2026-04-07 at 09:38 +0200, Christian Kastner wrote: > > On 2026-04-06 10:50, Christian Kastner wrote: > > > I can now confirm that it was the dracut 110-8 upload that triggered > > > this new boot failure. Specifically, it was commit bebb2681, which > > > added: > > > > > > fix-dracut-enable-hostonly_cmdline-in-hostonly-mode-again.patch > > > > > > Disabling this patch fixes the issue for me again [...] > > > > So I compared the output of a trixie image build (which continues to > > successfully EFI boot) and an unstable image build (which exhibits the > > problem). > > > > There is one key difference in the image build log when the kernel gets > > installed. Here is a snippet from the unstable build: > > > > Setting up linux-image-6.19.11+deb14-amd64 (6.19.11-1) ... > > I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.19.11+deb14-amd64 > > I: /initrd.img.old is now a symlink to boot/initrd.img-6.19.11+deb14-amd64 > > I: /vmlinuz is now a symlink to boot/vmlinuz-6.19.11+deb14-amd64 > > I: /initrd.img is now a symlink to boot/initrd.img-6.19.11+deb14-amd64 > > /etc/kernel/postinst.d/dracut: > > dracut[W]: Turning off host-only mode: /dev is not mounted! > > ... > > > > The trixie build lacks this dracut warning. > > > > So it would appear that in image builds, this problem stems from > > host-only mode previously being on, and now being turned off. > > Those two reports gave me a clue. I assume the opposite. You want > hostonly disabled. The patch fix-dracut-enable-hostonly_cmdline-in- > hostonly-mode-again.patch enables hostonly-cmdline by default again, but > this: > > dracut[W]: Turning off host-only mode: /dev is not mounted! > > does not turn off hostonly-cmdline which causes the host config to leak > into the initrd. I'll prepare a fix for dracut. Here comes the fix: https://github.com/dracut-ng/dracut-ng/pull/2351 Can you test that this fix solves your issue? -- Benjamin Drung Debian & Ubuntu Developer
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
On Tue, 2026-04-07 at 09:38 +0200, Christian Kastner wrote: > On 2026-04-06 10:50, Christian Kastner wrote: > > I can now confirm that it was the dracut 110-8 upload that triggered > > this new boot failure. Specifically, it was commit bebb2681, which > > added: > > > > fix-dracut-enable-hostonly_cmdline-in-hostonly-mode-again.patch > > > > Disabling this patch fixes the issue for me again [...] > > So I compared the output of a trixie image build (which continues to > successfully EFI boot) and an unstable image build (which exhibits the > problem). > > There is one key difference in the image build log when the kernel gets > installed. Here is a snippet from the unstable build: > > Setting up linux-image-6.19.11+deb14-amd64 (6.19.11-1) ... > I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.19.11+deb14-amd64 > I: /initrd.img.old is now a symlink to boot/initrd.img-6.19.11+deb14-amd64 > I: /vmlinuz is now a symlink to boot/vmlinuz-6.19.11+deb14-amd64 > I: /initrd.img is now a symlink to boot/initrd.img-6.19.11+deb14-amd64 > /etc/kernel/postinst.d/dracut: > dracut[W]: Turning off host-only mode: /dev is not mounted! > ... > > The trixie build lacks this dracut warning. > > So it would appear that in image builds, this problem stems from > host-only mode previously being on, and now being turned off. Those two reports gave me a clue. I assume the opposite. You want hostonly disabled. The patch fix-dracut-enable-hostonly_cmdline-in- hostonly-mode-again.patch enables hostonly-cmdline by default again, but this: dracut[W]: Turning off host-only mode: /dev is not mounted! does not turn off hostonly-cmdline which causes the host config to leak into the initrd. I'll prepare a fix for dracut. -- Benjamin Drung Debian & Ubuntu Developer
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
On Tue, Apr 07, 2026 at 09:38:11AM +0200, Christian Kastner wrote: > On 2026-04-06 10:50, Christian Kastner wrote: > > I can now confirm that it was the dracut 110-8 upload that triggered > > this new boot failure. Specifically, it was commit bebb2681, which > > added: > > > > fix-dracut-enable-hostonly_cmdline-in-hostonly-mode-again.patch > > > > Disabling this patch fixes the issue for me again [...] > > So I compared the output of a trixie image build (which continues to > successfully EFI boot) and an unstable image build (which exhibits the > problem). > > There is one key difference in the image build log when the kernel gets > installed. Here is a snippet from the unstable build: > > Setting up linux-image-6.19.11+deb14-amd64 (6.19.11-1) ... > I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.19.11+deb14-amd64 > I: /initrd.img.old is now a symlink to boot/initrd.img-6.19.11+deb14-amd64 > I: /vmlinuz is now a symlink to boot/vmlinuz-6.19.11+deb14-amd64 > I: /initrd.img is now a symlink to boot/initrd.img-6.19.11+deb14-amd64 > /etc/kernel/postinst.d/dracut: > dracut[W]: Turning off host-only mode: /dev is not mounted! > ... > > The trixie build lacks this dracut warning. > > So it would appear that in image builds, this problem stems from > host-only mode previously being on, and now being turned off. > > Is this something that can or should be forced/overridden by the image > build tool (here, vmdb2 upon which autopkgtest relies)? Please don't make this something that the image builders have to override. Everytime such a thing gets added, _ALL_ image builders have to re-learn such a thing, and it takes for a long time to update all tools across all platforms where they can possibly run. Think of an image builder running on bookworm, or one running on Fedora, or elsewhere. Please have dracut (or whatever) figure this out automatically. After all it also worked with initramfs-tools. Best, Chris
Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images
On 2026-04-06 10:50, Christian Kastner wrote: > I can now confirm that it was the dracut 110-8 upload that triggered > this new boot failure. Specifically, it was commit bebb2681, which > added: > > fix-dracut-enable-hostonly_cmdline-in-hostonly-mode-again.patch > > Disabling this patch fixes the issue for me again [...] So I compared the output of a trixie image build (which continues to successfully EFI boot) and an unstable image build (which exhibits the problem). There is one key difference in the image build log when the kernel gets installed. Here is a snippet from the unstable build: Setting up linux-image-6.19.11+deb14-amd64 (6.19.11-1) ... I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.19.11+deb14-amd64 I: /initrd.img.old is now a symlink to boot/initrd.img-6.19.11+deb14-amd64 I: /vmlinuz is now a symlink to boot/vmlinuz-6.19.11+deb14-amd64 I: /initrd.img is now a symlink to boot/initrd.img-6.19.11+deb14-amd64 /etc/kernel/postinst.d/dracut: dracut[W]: Turning off host-only mode: /dev is not mounted! ... The trixie build lacks this dracut warning. So it would appear that in image builds, this problem stems from host-only mode previously being on, and now being turned off. Is this something that can or should be forced/overridden by the image build tool (here, vmdb2 upon which autopkgtest relies)? Best, Christian
