Control: reassign -1 dracut
Control: retitle -1 dracut 110-8 breaks autopkgtest EFI boot images
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.
Reproducing the relevant part from my original report:
> Booting the VM manually, systemd hangs and times out waiting for the
> following services to start up:
>
> (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 not familiar with early boot initrd environments but the 'loop0p1'
> seems suspiciously like something that might have bled in from the host
> environment, because vmdb2 uses that during image creation.
Steps to reproduce the autopkgtest failure (should work with any recent
autopkgtest, eg: from trixie):
$ sudo autopkgtest-build-qemu --boot=efi unstable /tmp/unstable-amd64.img
...
$ autopkgtest -B -U dracut -- qemu /tmp/unstable-amd64.img
Interactive image boot:
$ qemu-system-x86_64 \
-enable-kvm \
-drive
if=pflash,format=raw,unit=0,read-only=on,file=/usr/share/OVMF/OVMF_CODE_4M.fd \
-device virtio-serial \
-nic user,model=virtio \
-m 2048 \
-smp 2 \
-nographic \
-drive file=/tmp/unstable-amd64.img,discard=unmap,if=virtio
Best,
Christian
