Grub does not 'see'the latest kernels

[Teunis]

Kubuntu 20.04 on a Thinkpad W520.
I just noticed the system runs on kernel 5.11.0-42 but -43 and -44 are also installed.
Yet Grub does not offer them as a boot option.

sudo update-grub

Does see the kernels but they are not added to the grub boot menu.

Any ideas about what is happening?

[claydoh]

Are you booting multiple distros? If so, you may be booting from the grub for a different OS, maybe?
What does $ efibootmgr show?

here is mine, as a reference:

$ efibootmgr
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0003,0004,0001,0002,0005
Boot0000* neon
Boot0001* UEFI:CD/DVD Drive
Boot0002* UEFI:Removable Device
Boot0003* Windows Boot Manager
Boot0004* UEFI OS
Boot0005* UEFI:Network Device

[jlittle]

So, after a reboot, the running kernel is still 5.11.0-42 (as shown by uname -a), and "Advanced options for Ubuntu" on the grub menu does not show extra kernels?

I would check the boot chain. Being 2011ish, is it BIOS/MBR or UEFI? If BIOS/MBR, you might install boot-info-script and see what it says. If UEFI, use sudo efibootmgr -v to see what is being run from the ESP, then check the grub.cfg where the boot variable points to (by default that's /boot/efi/EFI/ubuntu/grub.cfg, and that just invokes /boot/grub/grub.cfg.) If the grub.cfg generated by update-grub is not the grub.cfg that grub presents to you, then the normal chain of events is not being followed.

I'd also check carefully the output of ls -l /boot, and in particular what the vmlinuz symlink points to.

[Teunis]

claydoh and jlittle, you are right, it is a multi boot system and by doing the grub-update from a recently installed neon the -44 kernel was properly set.
This ~10 y/o computer is still MBR based, no efi.

[jlittle]

IMO, a good way to do multiple installs is to decide which install should control the boot, and stop the grub automatic update machinery on the others. Either not install a boot loader at all, or remove it, or set it to non-updating. With grub one can use the grub-<arch>-bin meta-package, and remove the grub-<arch> one. Then grub is still in that install, and can be used if you need it, just not automatically.

With more than one grub instance automatically updating, you're asking for trouble.

(Please excuse the preachy tone; if someone had explained this obviousness to me when I first started doing multiple installs, it would have helped me, as it took me a long time to understand it.)

[Teunis]

I've been running multi-boot for many years and I believe this is the first time I run into this issue.
So I've probably not been 100% on the ball when doing this last installation.
I'll try to reset the existing grub to behave as wanted.

[TwoFistedJustice]

I had a similar problem on my Thinkpad X260 running 18.04. I could install any kernel I wanted, but I could only boot up to a certain one. I spent a lot of hours following this advice and that advice. All to no avail. Eventually I just decided to live with it until 20.04 LTS came out. Then I did an upgrade install and the problem persisted. At which point I wiped my system and started over from scratch. Now it works as expected.

Probably not the nifty solution you were hoping for. But it's what worked in the end for me.

[vinnywright]

claydoh and jlittle, you are right, it is a multi boot system and by doing the grub-update from a recently installed neon the -44 kernel was properly set.
This ~10 y/o computer is still MBR based, no efi.

,,,,,, sounds like you forgot to "not" install grub with the new neon install , or have it installed to the partition the new install is on . so it took over the booting of the box .

I have several installs on this box as well with a Neon one as the grub "controller" (now anyway) .
recently (well relatively) I installed a SSD and put a "hole disk" no partitions BTRFS file system on it and an install .
however Grubs osprober will not see it so I had to put something like this in /etc/grub.d/40_custom on the Neon install to boot it

menuentry 'Kubuntu-18.04' {
insmod btrfs
set root='(hd2)'
linux /@/boot/vmlinuz root=UUID=fe385e89-57a5-4632-9823-043a70b67c65 rootflags=subvol=@ ro quiet splash
initrd /@/boot/initrd.img
}

VINNY

[oshunluvr]

RE. Vinny's problem; the issue is actually with os-prober rather than grub as a boot loader. os-prober does not scan BTRFS whole-disk file systems nor (at least last time I tried it) BTRFS RAID file systems. So Vinny's solution is correct - just create the 40-custom entry.

A "normal" grub stanza might have lines like these instead:

linux /@/boot/vmlinuz-5.11.0-40-generic root=UUID=60834933-9999-4d5c-922c-9abbc373e172 ro rootflags=subvol=@ quiet
initrd /@/boot/initrd.img-5.11.0-40-generic

which point to a specific kernel version. This would require grub to properly update.

Note that Vinny's entry uses /boot/vmlinuz and /boot/initrd.img which are symlinks to the last installed kernel. Sometimes I've seen the installer not updating those links properly - but not often. In that case, you might end up booting to wrong kernel because it may link to the older kernel.

If Vinny wanted the option to boot the previous kernel instead of only the current one, he could re-write his 40-custom to read:

menuentry 'Kubuntu-18.04'
{ insmod btrfs
set root='(hd2)'
linux /@/boot/vmlinuz root=UUID=fe385e89-57a5-4632-9823-043a70b67c65 rootflags=subvol=@ ro quiet splash
initrd /@/boot/initrd.img }
menuentry 'Kubuntu-18.04 (previous kernel)'
{ insmod btrfs
set root='(hd2)'
linux /@/boot/vmlinuz.old root=UUID=fe385e89-57a5-4632-9823-043a70b67c65 rootflags=subvol=@ ro quiet splash
initrd /@/boot/initrd.imz.old
}

The symlinks a appended with .old to indicate they link to (or should) the previous kernel which update retains each time a new kernel is installed. I have seen the link updating fail, but rarely, and it easy to manually fix them.

To jlittle's comment about booting multiple installs: A very valid point - updating multiple grubs can be complicated and time consuming. Here, I boot half a dozen installs from a stand-alone grub installation. I have done this both from a separate EXT4 partition and from a BTRFS subvolume (as I do currently). What I do is to boot to the grub install and use stanzas like this to point to each separate install and read the grub file present within each of them, like this:

menuentry 'KDE Neon 18.04' {
insmod part_gpt
insmod btrfs
search --no-floppy --fs-uuid --set=root 60834933-9999-4d5c-922c-9abbc373e172
configfile /@KDEneon1804/boot/grub/grub.cfg
}

This works like a nested menu. I can choose KDE Neon 18.04 from the grub menu, change my mind with ESC and pick another without rebooting grub again. You could even use generic install names like "Install1", "Install 2" etc. and never have to mess with your stand alone grub at all.

The advantages to a stand-alone grub is you never have to worry about accidentally removing grub when wiping an old install and you don't have to update both grubs each time you install a new kernel.

[jlittle]

.... he could re-write his 40-custom to read...

A slightly easier alternative to editing 40_custom, which requires running update-grub to take effect, is to use the facility provided by 41_custom, and put a file called custom.cfg in the grub directory. If it exists it is sourced and menu entries added to the grub menu.

Changes to a custom.cfg are more easily made booting from a live USB or another install; after fixes to 40_custom, needed to boot the OS to then run update-grub, you have to go through hoops (use a chroot, or edit grub.cfg.as well...).

[Teunis]

A very late reply with my solution.
Grub Customiser offers the option to save (grub) to the MBR and that's what was needed.