Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #91939 > unrolled thread

Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images Benjamin Drung <bdrung@debian.org> - 2026-04-07 11:50 +0200
    Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images Benjamin Drung <bdrung@debian.org> - 2026-04-07 12:10 +0200
      Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images Benjamin Drung <bdrung@debian.org> - 2026-04-07 13:20 +0200
        Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images Benjamin Drung <bdrung@debian.org> - 2026-04-07 13:30 +0200
          Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images Benjamin Drung <bdrung@debian.org> - 2026-04-08 11:50 +0200
            Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images Chris Hofstaedtler <zeha@debian.org> - 2026-04-08 12:10 +0200
              Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images Benjamin Drung <bdrung@debian.org> - 2026-04-08 12:50 +0200
                Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images Benjamin Drung <bdrung@debian.org> - 2026-04-11 00:10 +0200
                  Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images Michael Prokop <mika@debian.org> - 2026-04-13 07:30 +0200
                    Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images Benjamin Drung <bdrung@debian.org> - 2026-04-13 23:00 +0200
                    Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images Johannes Schauer Marin Rodrigues <josch@debian.org> - 2026-05-06 12:30 +0200
                      Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images Benjamin Drung <bdrung@debian.org> - 2026-05-06 14:20 +0200
                        Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images Johannes Schauer Marin Rodrigues <josch@debian.org> - 2026-05-06 16:10 +0200
                      Bug#1132794: dracut 110-8 breaks autopkgtest EFI boot images Benjamin Drung <bdrung@debian.org> - 2026-06-29 14:20 +0200

#91939 — 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

[toc] | [next] | [standalone]

#91940

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

[toc] | [prev] | [next] | [standalone]

#91941

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

[toc] | [prev] | [next] | [standalone]

#91942

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

[toc] | [prev] | [next] | [standalone]

#91951

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

[toc] | [prev] | [next] | [standalone]

#91952

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

[toc] | [prev] | [next] | [standalone]

#91953

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

[toc] | [prev] | [next] | [standalone]

#91975

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

[toc] | [prev] | [next] | [standalone]

#91989

[Multipart message — attachments visible in raw view] — view raw

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-

[toc] | [prev] | [next] | [standalone]

#92003

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

[toc] | [prev] | [next] | [standalone]

#92326

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Mon, 13 Apr 2026 07:27:33 +0200 Michael Prokop <mika@debian.org> 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

[toc] | [prev] | [next] | [standalone]

#92331

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 <mika@debian.org> 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

[toc] | [prev] | [next] | [standalone]

#92332

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#93151

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 <mika@debian.org> 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.

I submitted this change upstream:

fix(dracut): default to hostonly=no in chroot
https://github.com/dracut-ng/dracut/pull/2480

-- 
Benjamin Drung
Debian & Ubuntu Developer

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web