Cannot boot 6.5.4-1 or 6.5.3-1 - have to use 6.4.11-1

Booting to either of the 6.5 kernels I get a kernel panic:

Currently there is still a 6.4 kernel which still works - so I’m using that for now:

To pre-empt an expected question - yes I have an Nvidia graphics card (GeForce GTX 1070 Ti).

These are the kernels currently listed - with the working one highlighted.

Be sure to not let purge-kernels service remove your working kernel before you have another that works. You could reconfigure via /etc/zypp.conf to keep oldest:

# grep oldest,latest zypp.conf
multiversion.kernels = oldest,latest,latest-1,latest-2,latest-3,running

This way 6.4.11 will remain installed until you either reconfigure multiversion.kernels, or manually remove it with rpm, zypper or YaST. Alternatively, you can lock it:

# sudo zypper al kernel-default-6.4.11-1

Or just lockdown all kernel-default changes until you know a good one is available:

# sudo zypper al kernel-defaul*

Using the “*” instead of the “t” will cause zypper to ignore the lock’s existence when it claims it will remove it in a zypper installation or removal transaction in which it requires an answer to a conflict.

2 Likes

Be sure to not let purge-kernels service remove your working kernel before you have another that works

Thank you @mrmazda. That was my biggest worry, so I shall use the solutions you’ve highlighted to keep the working kernel.

Edit: although I believe the file is /etc/zypp/zypp.confwhich is slightly different from the path you gave. :slight_smile:

Correct. Sorry for being sloppy. :stuck_out_tongue:

1 Like

This is still a problem with kernel 6.6.1.

Perhaps there is there something I should be updating in Grub to allow booting the latest Kernel?

The Kernel panic says VFS: Unable to mount root fs on unknown-block(0,0).
I’m booting from an NVMe.

nvme0n1     259:0    0   1.8T  0 disk 
├─nvme0n1p1 259:2    0   512M  0 part /boot/efi
├─nvme0n1p2 259:3    0    32G  0 part [SWAP]
└─nvme0n1p3 259:4    0   1.8T  0 part /var
                                      /usr/local
                                      /srv
                                      /root
                                      /opt
                                      /boot/grub2/x86_64-efi
                                      /boot/grub2/i386-pc
                                      /.snapshots
                                      /

Usual reason for this is missing, corrupted or incomplete initrd. One possible reason - drivers needed to mount root device changed between 6.4 and 6.5 (e.g. changed from built-in to loadable module), so under 6.4 dracut fails to detect needed modules.

Maybe he can compare the initrd from the two different kernels. Just a guess, maybe someone can
read what the difference is and can advice the op.
The command is:
lsinitrd | less

I think the problem might have been ZFS.

I have an external backup drive, which I’ve used with previous OSs, and it’s formatted ZFS.

I think, if I have the ZFS drivers installed then the kernel install cannot create the initrd, and therefore the kernel cannot boot. Just before the 6.6.2 kernel was about to be installed I removed all traces of ZFS, and the system rebooted into 6.6.2 correctly. So, not 100% scientific because two things changed at once, but it’s a good correlation.

I guess the previous 6.4.11 kernel which did boot had its initrd created before ZFS was installed, so managed to continue working.

I don’t need ZFS when booting, it’s just a backup drive. Assuming the above is correct, I need to discover if there is a way to have the XFS drivers installed but excluded from being included in the initrd creation process.

Assuming “XFS” actually means “ZFS”, and a bit of search …

Assuming “XFS” actually means “ZFS”, and a bit of search …

You are right - I meant to type Z not X.

Thank you for your search skils. I shall try that.

Seems to have worked.
Thank you.