kernel wrong on boot

HELP, AGAIN!!

 ls -l /boot/vmlinuz*
lrwxrwxrwx 1 root root      35 Jun 16 20:05 /boot/vmlinuz -> vmlinuz-5.3.18-150300.59.71-default  **<<<< Todays update**
-rw-r--r-- 1 root root 9079040 May  5 10:15 /boot/vmlinuz-5.3.18-150300.59.68-default    **<<<<<<<< Booting this!**
-rw-r--r-- 1 root root 9083136 Jun  8 12:27 /boot/vmlinuz-5.3.18-150300.59.71-default  ***<<<< No idea what this is!!***

**uname -r**
**5.3.18-150300.59.68-default**
This after a reboot, one of which went through a long 'purge kernels' in boot process.

Tried "purge-kernels’ as root, but just gt the CNF message,
using systemctl purge kernels give a different 'error **<<<<<<< Unknown command verb purge-kernel

**Looks like the latest kernel did update. But it won’t boot. **It is On /dev/sda disk(see below)
**

lsblk -f
NAME   FSTYPE FSVER LABEL             UUID                                 FSAVAIL FSUSE% MOUNTPOINT
**sda                                                                                        
├─sda1 swap   1                       3cb7ceb0-f1a8-4aa8-921e-0cec9d4f39e1                [SWAP]
├─sda2 ext4   1.0   PATA-root         34b30e42-2c86-45b9-b27e-cfe1aa7c7868   27.5G    21% /
└─sda3 ext4   1.0   PATA-home         997de06e-983c-40e0-9297-296e72284acf   66.9G    27% /home**
sdb                                                                                        
├─sdb1 ntfs         System Reserved   1A0CB3280CB2FE37                                     
├─sdb2 ext2   1.0                     01ec6f47-8821-4f0d-82f2-0400640472db                 
├─sdb3 ntfs         Windows 7 64 Home ACB2B4EEB2B4BDE0                                     
└─sdb4 ext4   1.0                     f7cc156d-84b4-4443-8375-c29496cbbac6                 
sdc                                                                                        
├─sdc1 swap   1                       effdd0f4-9789-4254-8550-7708d9eb0d31                 
├─sdc2 ext4   1.0   Root-SATA160      60d428c6-d739-45b2-b544-c2c797195af3                 
└─sdc3 ext4   1.0   Home-SATA160      079bb985-d65a-41dd-bcb9-e1c19e8e31e

zypper purge-kernels

(run as root) would have worked, though it would probably just say that there is nothing to purge.

The most common reason for booting the wrong kernel, is that the grub boot menu was not updated. If, for example, you have both Leap and Tumbleweed installed on the same computer, and Tumbleweed happens to be controlling the boot menu, then the boot entry for 15.3 would not have been update (unless you updated it yourself).

I’ll try

zypper purge-kernels

, but it will likely not do anything. I did try to do another update, but it just came back with ‘Nothing to do’ message.

I don’t have Leap and TW, but I have the three disks with Leap 15.3
I’ve been down this road before, but long ago and far from my mind, so I don’t remember which one is controlling the boot processes. Nor how to determine that.

I have set YaST Boot loader the same for each disk. No luck with that.

I know I can make it start with the latest kernel and initrd by pressing the ‘e’ key and editing them. Of course that only helps for that boot only.

You mentioned ‘update it myself’. How can I do that and is it even possible?

Yep nothing to do message

zypper purge-kernels
Reading installed packages...

Preparing to purge obsolete kernels...
Configuration: latest,latest-1,running
Running kernel release: 5.3.18-150300.59.68-default   <<<<< 
Running kernel arch: x86_64

Resolving package dependencies...
Nothing to do.

Login to each, and update the grub menu on each:

grub2-mkconfig -o /boot/grub2/grub.cfg

[QUOTE=nrickert;3134888]Login to each, and update the grub menu on each:

grub2-mkconfig -o /boot/grub2/grub.cfg

/QUOTE
OK, thanks, I think I have done that, but this old mind plays tricks on me.

OK, it worked this time. Don’t know why it didn’t earlier except the user must have got confused(easily done these days).

Thanks for your time and help.

If you wish no interference among multiple same name distros (e.g. Leap and Tumbleweed, or two Leap 15.4s), a unique value should be set for each for GRUB_DISTRIBUTOR= in its /etc/default/grub. It’s more important if using UEFI, but it should be helpful to do the same with legacy/MBR booting, as it should cause the stanza labels among the different distros to differ, making it easier to be sure what Grub you’re looking at.Are these three 15.3s booting via UEFI? If yes, and you wish no interference among them, a unique value should be set for each for GRUB_DISTRIBUTOR= in its /etc/default/grub. If not UEFI, it should be helpful to do the same, as it should cause the stanza labels among the three to differ.

All my PCs are multiboot with multiple openSUSE installations of various versions. I don’t exactly boot from grub.cfg on any of them. On UEFI, only one installation has the ESP mounted, so that one has full boot control, but I don’t stop there. I build a custom.cfg menu from scratch that uses the kernel and initrd symlinks, so only needs updates when a distro is added or removed. The grub.cfg of the distro that has the ESP mounted incorporates custom.cfg as its first entries. The reason it does that is I copy /etc/grub.d/40_custom to /etc/grub.d/06_custom. On legacy/MBR booters, I do what amounts to the same thing by putting Grub Legacy with GFXboot on an EXT2 filesystem, which has a menu.lst that is a corollary to custom.cfg on UEFI, except it lacks any direct ties to any Grub on any other of the PC’s filesystems.