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
