How to get my kinetic install to select newer kernel?


Been playing around with kinetic for a tad bit . . . running it in a multi-boot '12 Mac Pro as one of the first linux installs to go into the machine and then upgrading via editing /apt/sources.list . . . .

Last week or the week before I noticed that uname -r is showing as 5.13 xxx . . . and, when booted in Lubuntu I can’t seem to get Discourse to show up, so I posted a question on the list-serve about what kernel should be running and got a couple replies that it should be 5.19 . . . ???

Couldn’t get too much bounce on how to get the newer kernel selected, should be that when I update the grub bootloader the newer kernels in all of the systems should be picked. In Lubuntu I now have 5.13. 5.19.0 and now 5.19.5 “installed” but it still is selecting to run 5.13 . . . .

I have mainline installed and I can add and subtract kernels, but it doesn’t show a selection to select a kernel to run . . .?? Updating the master grub list doesn’t seem to get Lubuntu moved up . . . .

One of the suggestions from the list-serve was to try to run a new install, to get that to update grub . . . had to do a fresh install of another OS, did that . . . Lubuntu is still booting 5.13. Seemed like there was an error somewhere in Lubuntu where it was saying “resume from UUID=xxxxx” which was a swap partition UUID . . . and it wasn’t reviving from suspend.

I changed that in /etc/fstab to an /boot/efi partition and got the system to revive from suspend, but it’s still running 5.13 kernel?? Not sure if I messed up by editing /etc/fstab in Lubuntu, but still question would be how to get the 5.19 kernel selected in grub?? I had a similar issue in my Pop_OS! system where it wasn’t moving the kernel up, but I think that was because they load the kernel in the /boot/efi directory and it was over-filled??

I don’t think Lubuntu does that, but, then there doesn’t seem to be a way to click, “choose newer kernel on reboot”??? and then that data makes it into the master grub file???

I would likely check that you don’t have multiple grub’s installed on your box. If you’re using a real old kernel such as 5.13 from Ubuntu 21.10, I’d be suspicious this is the cause.

Whenever your current system runs update-grub, it’ll correctly update the system, but if that updated grub isn’t the one being used on booting your system, the effects will be ignored, with whatever system controls the boot not having been updated (an old 21.10 system possible; or 20.04 using HWE at 20.04.4, pre-5.15 upgrades that formed 20.04.5)

If you use Pop OS, as they are happy to use testing grade kernels what I see as a 21.10 (20.04.4 kernel) could be even earlier since they QA using only hardware they sell (understandably) thus are far quicker. Pop OS does boot differently for recent releases of Ubuntu, but we don’t support Pop OS here sorry.


I would likely check that you don’t have multiple grub’s installed on your box. If you’re using a real old kernel such as 5.13 from Ubuntu 21.10, I’d be suspicious this is the cause.


Thanks for the reply . . . I think there are more than one grub, and I tried to remove grub from systems other than the controller grub, in this case SUSE TW . . . but I’ve had problems with ubuntu based systems over the years with their handling of grub, like they seem to want to be the only system on grub, making it difficult to multi-boot. There have been bug reports filed with numerous others joining in.

I believe in Lubuntu I tried to use synaptic to remove grub, but it keeps re-appearing, apparently . . . seemed like in LM I have to use their package manager to update the system, but I might have gone back to “dist-upgrade” with Lubuntu . . . .

Seems like you are saying that only one system can have grub installed, perhaps I’ll try to remove it from Lubuntu again and see if it will then let the newer kernels flow into play.

I’m not using Pop! on the desktop, so that isn’t involved in this case; Pop! is on the Sys76 laptop . . . I was just using that as an example of another system that wasn’t upgrading the kernel . . . .

This sounds like a very scrambled setup, so it will be hard to say what exactly will and won’t help, and any suggestions on what to do may be risky.

At this point, it would be a good idea to back up all your data from all operating systems and all internal drives, including any passwords stored in browsers or password managers. That way, even if things go really wrong, you won’t lose access to your data. Also make sure you have at least one live USB that you know works, so that you can boot your computer even if you aren’t able to boot any installed operating system.

Once that’s done, I’d make sure I had live USB flash drives for all of the operating systems on the computer, then wipe all the internal drives. Then it should be a matter of reinstalling the operating systems and restoring the data. I’d install Lubuntu last so that it (hopefully?) takes control of GRUB and allows you to boot the 5.19 kernel.

If that sounds like too much hassle, you might try getting into your UEFI boot menu and see if there’s a “Boot from File” option in there. Poke around and see if there’s multiple bootloaders in your EFI partition. Perhaps the multiple Linux distros is causing some confusion there.

Another thing you might try is running sudo grub-install from within Lubuntu to see if that lets it take control of the bootloader.


Alrighty, thanks for the thoughts . . . that would be “the long way” to wipe all of the drives and so forth. I’m not trying to get Lubuntu to “take control” of grub, I believe the problem is that it tried to do that . . . and that created some problems . . . for itself???

But, when you say, “try getting into your UEFI boot menu” . . . not sure if I have, but how would I rifle into that menu?? Is that a console command kind of thing??

After I posted this thread I tried to remove grub from Lubuntu and I adjusted the /etc/fstab UUID for the /boot/efi to the efi partition that Lubuntu is installed in . . . haven’t had time to get back to see if any of that will allow Lubuntu to find and use the newer kernels just yet . . . .

That would be the basic goal in this thread, getting Lubuntu to find and use 5.19 kernels . . . that are “installed” but system is not accessing them.

You should be able to press a key or key sequence during very early boot to get into the UEFI boot menu. The exact key to press will vary depending on your hardware. You might see it displayed on the screen when the system first turns on. Google something like “Dell Inspiron 7000 uefi boot menu” and you should find it. (Obviously replace “Dell Inspiron 15 7000” with the actual manufacturer and model of your system.)

On my dell optiplex 780; I have the following installed

  • Lubuntu kinetic (21.10)
  • Lubuntu 22.04 LTS (jammy)
  • Lubuntu 20.04 LTS (focal)
  • Debian testing

Each has grub installed; with it found in /boot/grub/ on all systems, but as the machine boots in legacy (BIOS or CSM) mode, the only one active is the one that is written to the MBR, or first sector of the internal drive the BIOS setting tells the machine to boot from.

This machine I use for QA-test installs (install using existing partition), meaning I don’t upgrade the installed OSes at all, but re-install using existing partition which is non-destructive meaning my music etc is untouched… As 20.04.5 was the last (expected) ISO we’ll have for focal or 20.04, that partition is likely to become stale (no new dailies to refresh it), but the kinetic & 22.04/jammy will get re-freshed ~weekly.

When I perform these re-installs; whatever OS I (re-)install will take over ownership of the MBR & it’s grub will control boot; the others ignored. On that box, I just assess (post-install QA checks) checking Debian last, and let it run a update-grub; grub-install manually so it retakes ownership of the boot. I consider that my Debian workstation (why it controls boot).

Another box; hp 8200 uses uEFI but the effect is the same. It contained

  • Lubuntu 20.04 LTS
  • Fedora (whatever latest is)
  • OpenSuSE (tumbleweed)

I used that box for re-install tests of Lubuntu… and had a few failures… :frowning: As long as I can get the box to grub rescue; I’ll boot another OS (openSuSE tumbleweed my usual fallback) & have it take ownership of boot; meaning it’s grub version is what I use. For years, Lubuntu 20.04 LTS has been the grub I used, but recent failures have had me switch to using openSuSE’s instead.

Personally I’d not remove other GRUB packages; I sure don’t. My point is only one will be used by the system.

(here I’ll skip uEFI as it can be a little more complex; and some boxes aren’t 100% compliant with uEFI standards anyway so boxes can be unique)

The standard of 1982 set by IBM says each drive has a MBR (they used their earlier standard for floppies of the 1981 IBM PC); it’s the first sector of the drive; so if you have three physical drives you can have three systems with an active grub on them. The BIOS settings themselves will control which of those drives MBR (first sector of drive) is actually loaded into RAM & executed - ie. controls boot. If you were using PCs in the 80s, you may even recall it was jumpers on the drive we first used to control boot… but then cable standards & BIOS configuration took over from that.

I’d not remove other grubs, just remember a re-install, or the last OS installed usually takes ownership of the boot, and if you’re not happy with that (as I’m often not), just give it back to the OS you prefer controlling boot of your box.

I have had other OSes perform a grub-install type command during normal package upgrades when a new patched kernel appears; however most don’t instead running the Ubuntu equivalent of update-grub, meaning no boot ownership should occur (only a re-scan & update of grub configuration file occurs), but it’s possible & OS specific.

As for boxes not detecting an OpenSuSE install; that’s likely related to BTRFS, as a normal Ubuntu/Debian (and many others too) don’t handle BTRFS well in the update-grub search & thus that file-system is ignored (meaning any OS on a BTRFS system won’t likely appear in grub listing). The issue is BTRFS related, not the OS on it; but I bet that’s your issue, as BTRFS is a liked default of OpenSuSE. It’s somewhat easily (but messily) dealt with, but yeah it can be a little annoying (I suspect my 8200 install doesn’t use BTRFS as I didn’t want to fight with that issue again)

1 Like

OK . . . right. You mean essentially the grub menu . . . ??? It might be “tab”??? I have done that at some point in the distant past . . . . I’m away from that machine now, but I’ll check it tomorrow . . . .


Thanks for the detailed response . . . in your first grouping, as they are mostly lubuntu & debian that is “inter-compatible” . . . . But, in the second grouping, yes, now there is conflict between the individual grubs . . . . It’s not until you get to in my case 8 linux distros where having grubs in each one will cause a problem . . . . There is some kind of issue with ubuntu and grub, where ubuntu takes over . . . . One of the reasons why I do use TW as my master grub . . . only had a problem when I installed Debian recently, had to tidy up some UUIDs after that.

I don’t use BTRFS formatting BTW in my SUSE installs . . . I use ext4 for all of my installs . . . .

We’ll see how this plays out and I’ll post back on it . . . . All of my other distros are able to upgrade the kernel . . . progressively . . . .



So, I did get into the grub menu and there Lubuntu was still listed as “19.10” and showing the 5.13 kernel as the boot option . . . . So I did figure out how to edit the kernel into a number involving 5.19 that grub accepted and then figured out how to get that to boot.

Seems to have made the change to 5.19 . . . !!! So, thanks for that hint. I’ll have to try to reboot and see if the changes are intact. the “advanced options” I left with 5.13 to have another option.

Still having an issue where when booted in Lubuntu the Discourse site isn’t working. Now I’m over in TW and able to post here???

1 Like

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.