I have been a Linux user (Ubuntu, Mint, Debian) for a few years and recently installed Neon on a spare partition and am getting comfy with it.
I noticed something peculiar that is not a problem but makes me curious.
Usually, Neon kernels follow the rest of the Ubuntu updates. Last June, though, Discover updated it to 5.19 while Ubuntu was still at 5.15. Fine, no problem, and it worked well. Then, booting another day and the updates rolled the kernel back to 5.15.
Now, just a couple of weeks ago, Discover updated to 6.2 and kept it there for two weeks. Today, the update process AGAIN rolled it back to 5.15.
Again, I do not see any change in any programâs behavior, so there is no problem, other than being curious.
Are you certain that the other kernels arenât still installed? On my Mint VM, I have the 5.15 and 6.2 (which started as 5.19) kernels; in fact, the 5.15 branch was updated today, but it left the 6.2 branch alone.
Are you running Grub or systemd-boot? Do you have a boot menu or is it hidden?
I am using legacy BIOS and grub. In the grub menu, there is the âAdvanced optionsâ and a long list of other choices. But running the edit command does not tell me the kernel. I tried that when I first noticed this issue, but could not find the kernel in those listings.
So if the kernels are still there, how would I choose from among 10 entries under âAdvanced optionâ?
BTW, my memory fails me, but I THINK that I removed the headers when I ran autoremove. I wonât do that again.
It is a simplified version of the grub menu:
Mint
Ubuntu, with Linux 5.15.0-79-generic
Ubuntu, with Linux 5.15.0-79-generic (recovery mode)
Ubuntu, with Linux 5.15.0-78-generic
Ubuntu, with Linux 5.15.0-78-generic (recovery mode)
Ubuntu, with Linux 5.15.0-41-generic
Ubuntu, with Linux 5.15.0-41-generic (recovery mode)
KDE neon 5.27 (22.04) (on /dev/sda3)
Ubuntu 22.04.3 LTS (22.04) (on /dev/sdb1)
Windows 10 (on /dev/sdb2)
Those entries for âUbuntu, with Linuxâ all refer to Mint, sda1
That Ubuntu on sdb1 is Ubuntu Mate
Neon will keep a version of 5.15, 5.19, and a version of 6.2 and rotate out older ones. You will see updates for the older kernel in Discover on a regular basis, even though you are not using it. It is there should you need to.
Type âuname -râ in a terminal to display the running kernel version. It should be 6.2 in the current Neon.
Well, you named the "kernel " of my question. I use neofetch or uname -a. In May, it was 5.15. In June it was 5.19. In July it was back to 5.15. In early August it was 6.2, and now it is back to 5.15
What the ???
I would guess Mint is rotating it, not Neon. You may need to check your grub.conf file in Mint to see if is booting the right kernel. I suspect its pointing to 5.15. You should be able to find the menuentry about halfway down the file.
menuentry NeonâŚ
âŚ
linux /boot/vmlinuz-5.15.0-79-generic
i know there is a setting in grub where it will pick an entry from the list and other where it will pick last saved and these two features could be walking on each other.
Well, great tips here and I can report some info but no solution yet. And a reminder, I am OK with the older kernel, just curious whatâs going on.
Yes, I have grub_customizer, and I found the grub entry with kernel 6.2
The main entry reads:
insmod part_msdos
insmod ext2
set root=âhd0,msdos3â
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3 257f0255-786a-4160-ac57-b953d367efde
else
search --no-floppy --fs-uuid --set=root 257f0255-786a-4160-ac57-b953d367efde
fi
linux /boot/vmlinuz root=/dev/sda3
initrd /boot/initrd.img
The entry with 6.2 reads:
insmod part_msdos
insmod ext2
set root=âhd0,msdos3â
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3 257f0255-786a-4160-ac57-b953d367efde
else
search --no-floppy --fs-uuid --set=root 257f0255-786a-4160-ac57-b953d367efde
fi
linux /boot/vmlinuz root=/dev/sda3
initrd /boot/initrd.img-6.2.0-26-generic
Only the last line is different.
When I tried booting to it, the bootup failed at the USB mouse and reported that device /dev had failed. (Sorry, it was a huge list of messages, that is the only one I could see as relevant.)
When I went to the /boot menu (in the 3rd partition but navigated there from Mint, 1st partition), the icon for the 6.2 kernel had a big X through it.
So I STRONGLY suspect that when I ran autoremove after updating in KDE, it did something to the newer kernels that made the system revert to 5.15
Curiouser and curiouser
grub customizer takes your entire grub structure and archives it, replacing it with itâs own structure (based on what is is unclear)⌠so now when you have a kernel update your grub cannot adjust properly to the new kernel, nor can it prune properly the older kernels.
i suspect the normal grub behavior when a new kernel shows up is trying to operate on a mangled version grub put in place by grub customizer and thatâs why you are getting weird results.
unfortunately there does not seem to be any easy way uninstall grub customizer short of reinstalling grub.
Am I correct, then, in understanding @skyfishgoo to be saying that the fault lies with grub_customizer, that a solution now would be more difficult than it is worth? Thus, I am best off waiting for an updated 6.2 kernel, which will supersede 5.15?
Iâm cool with that. Is this a âsolutionâ?
if you want to be sure which kernel you are booting into you can select an item from the grub menu and hit E, it will show you the command you are about to execute and you can read the kernel version in the text.
if that version doesnât match what is showing on the grub screen then, that is the fault of grub customizer, yes.
Those should be booting to symbolic links in /boot. To see what is used, run ls -l /boot
The links are supposed to be maintained by the software updater, f.ex. APT. Using them means a grub entry doesnât have to change for every new kernel. (IMO the update-grub machinery is awfully complex and very fragile. I donât let it touch the boot directly on my systems, preferring to maintain by hand a vastly simpler grub.cfg; I can go for years without having to touch it.)
If I rename initrd.img as old and initrd.img.old as initrd.img, and then the same thing to vmlinuz, would that remove the âback and forthâ issue? Can I redirect grub to the more updated kernel symlink?
Vanilla grub doesnât use the symlinks. I have little idea what has pointed yours at 5.15. On my Ubuntu when thereâs a new kernel APT updates the links. The .old links are pointed at the previous kernel.
If you want to make changes to the links, you delete and recreate them; for example:
rm vmlinuz
ln -s vmlinuz-6.2.0-26-generic vmlinuz
You could use the file /boot/grub/custom.cfg to add an entry or entries that you have control over. The vanilla grub sources that if itâs present.