(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).
, 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?
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.