Failure to boot after upgrading to Fedora 41

Ask Fedora
1

Hi,

I’ve just updated to fedora 41, tried to boot with this (new default)

6.12.11-200.fc41.x86_64

and got chubby failure like:

VFS: Unable to mount root fs on unknown-block(0,0)

Booting with older kernel:

6.12.11-100.fc40.x86_64

works…for now.

I found some recommendations online like regenerating initramfs. Done that. Did not help. One thing I noticed is this:

cat /boot/grub2/grub.cfg

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Fedora Linux (6.12.11-200.fc41.x86_64) 41 (Workstation Edition)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-6.12.11-200.fc41.x86_64-advanced-a46d7a14-2792-4069-b558-02c963f76b18' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root 2733a5a5-7ddb-4daf-a792-c963f2bc8efa
        echo    'Loading Linux 6.12.11-200.fc41.x86_64 ...'
        linux   /vmlinuz-6.12.11-200.fc41.x86_64 root=/dev/mapper/luks-4f583464-8166-4a4e-800c-fa2749ce33e4 ro rd.luks.uuid=luks-4f583464-8166-4a4e-800c-fa2749ce33e4 rhgb quiet 
}
menuentry 'Fedora Linux (6.12.11-100.fc40.x86_64) 41 (Workstation Edition)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-6.12.11-100.fc40.x86_64-advanced-a46d7a14-2792-4069-b558-02c963f76b18' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root 2733a5a5-7ddb-4daf-a792-c963f2bc8efa
        echo    'Loading Linux 6.12.11-100.fc40.x86_64 ...'
        linux   /vmlinuz-6.12.11-100.fc40.x86_64 root=UUID=a46d7a14-2792-4069-b558-02c963f76b18 ro rd.luks.uuid=luks-4f583464-8166-4a4e-800c-fa2749ce33e4 rhgb quiet 
        echo    'Loading initial ramdisk ...'
        initrd  /initramfs-6.12.11-100.fc40.x86_64.img
}
menuentry 'Fedora Linux (6.12.10-100.fc40.x86_64) 41 (Workstation Edition)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-6.12.10-100.fc40.x86_64-advanced-a46d7a14-2792-4069-b558-02c963f76b18' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root 2733a5a5-7ddb-4daf-a792-c963f2bc8efa
        echo    'Loading Linux 6.12.10-100.fc40.x86_64 ...'
        linux   /vmlinuz-6.12.10-100.fc40.x86_64 root=UUID=a46d7a14-2792-4069-b558-02c963f76b18 ro rd.luks.uuid=luks-4f583464-8166-4a4e-800c-fa2749ce33e4 rhgb quiet 
        echo    'Loading initial ramdisk ...'
        initrd  /initramfs-6.12.10-100.fc40.x86_64.img

As we can see the 1st entry has different line:

linux   /vmlinuz-6.12.11-200.fc41.x86_64 root=/dev/mapper/luks-4f58

from the others and completely missing initramfs configuration if I am not blind. Not sure whether this is expected or not. I have not found any bugs regarding this.

Note: I use LUKS to encrypt my drives. They get decrypted during boot.

I have not tried regenerating GRUB cfg file.

If required, I can provide any other info on request.

Please advice. Thank you very much.

2

Right,

so I tried generating GRUB config to /tmp and check the contents and it seems it generated well this time. After that I updated the real deal grub config and shit got working again.

So it is an update bug?..my wild guess.

1 Like