Le Sat, 21 Mar 2026 10:44:46 +0100, Benjamin Drung <[email protected]> a écrit :
>Hi Pascal, > Hi Benjamin >Maybe the patch causes this failure as well. I am surprised that the >autopkgtest did not catch it. To ensure that there is no other reason >for the failure: Can you provide debug logs and describe your setup? > > The boot failure occurred before the root fs was mounted. Therefore no logs were saved. At the moment, I am quite reluctant booting again with an initramfs generated by dracut 110-6 because yesterday I spent a lot of time retrieving a functional boot. However, I quite convinced it is related to the systemd-gpt-auto-generator since I pass 'root=gpt-auto' as booting parameter and all fs partitions are discoverable (/, /boot as efi partition, encryted /home) I remember that the boot process stalled with something related to the some systemd generator process (sorry I do not remember exactly). To retrieve a functional boot, I had to : - boot in SystemRescueCd, - run Debian in a chroot, - reinstall dracut-* pakage in 110-5 version, but it was not enough: - change the boot parameters 'root=UUID=....', - recreate the fstab file, - rebuild the initramfs with 110-5 version Without cancelling the discoverable part I could not boot again. Once I could boot again into Debian, I could revert back to 'root=gpt-auto' and the system can now boot normally with dracut 110-5 and systemd-gpt-auto-generator with discoverable partitions. If I did not provide enough clues, I can still try to boot with dracut 110-6 to get some logs if you insist (now that I know the recipe to retrieve a functional boot). Best regards Pascal D
