Why am I running an old oem kernel?

[reitsmar]

Hi, I hope someone here can help me diagnose (and possibly) solve a kernel load problem I seem to be having:

I like to believe that I am running Ubuntu 24.10. Every few days I run an 'apt update / upgrade'. Below is the content of my /boot folder. Notice how initrd.img and vmlinuz point to the 6.11 kernel.

ls -ls /boot

rw-r--r-- 1 root root 259368 Aug 25 2022 config-5.14.0-1051-oem
-rw-r--r-- 1 root root 292033 Feb 24 07:23 config-6.11.0-21-generic
-rw-r--r-- 1 root root 287562 Mar 14 10:48 config-6.8.0-57-generic
drwx------ 5 root root 4096 Dec 31 1969 efi
drwxr-xr-x 5 root root 4096 Mar 31 16:38 grub
lrwxrwxrwx 1 root root 28 Mar 31 16:29 initrd.img -> initrd.img-6.11.0-21-generic
-rw-r--r-- 1 root root 68099625 Mar 22 16:05 initrd.img-5.14.0-1051-oem
-rw-r--r-- 1 root root 74757550 Mar 31 16:30 initrd.img-6.11.0-21-generic
-rw-r--r-- 1 root root 73741181 Mar 31 16:29 initrd.img-6.8.0-57-generic
lrwxrwxrwx 1 root root 27 Mar 31 16:37 initrd.img.old -> initrd.img-6.8.0-57-generic
-rw-r--r-- 1 root root 142796 Apr 8 2024 memtest86+ia32.bin
-rw-r--r-- 1 root root 143872 Apr 8 2024 memtest86+ia32.efi
-rw-r--r-- 1 root root 147744 Apr 8 2024 memtest86+x64.bin
-rw-r--r-- 1 root root 148992 Apr 8 2024 memtest86+x64.efi
-rw------- 1 root root 5972498 Aug 25 2022 System.map-5.14.0-1051-oem
-rw------- 1 root root 9427299 Feb 24 07:23 System.map-6.11.0-21-generic
-rw------- 1 root root 9081735 Mar 14 10:48 System.map-6.8.0-57-generic
lrwxrwxrwx 1 root root 25 Mar 31 16:29 vmlinuz -> vmlinuz-6.11.0-21-generic
-rw------- 1 root root 8933856 Aug 25 2022 vmlinuz-5.14.0-1051-oem
-rw------- 1 root root 15350152 Mar 6 03:04 vmlinuz-6.11.0-21-generic
-rw------- 1 root root 14989704 Mar 15 05:43 vmlinuz-6.8.0-57-generic
lrwxrwxrwx 1 root root 24 Mar 31 16:29 vmlinuz.old -> vmlinuz-6.8.0-57-generic

Also note that /boot also contains a vmlinuz-5.14.0-1051-oem kernel. I think that this is the kernel that my machine originally came with.

Now look at the results of the following two commands:

uname -a

linux rr-home 5.14.0-1051-oem #58-Ubuntu SMP Fri Aug 26 05:50:00 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

more /proc/version

Linux version 5.14.0-1051-oem (buildd@lcy02-amd64-080) (gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils f
or Ubuntu) 2.34) #58-Ubuntu SMP Fri Aug 26 05:50:00 UTC 2022

So despite /boot/initrd.img and /boot/vmlinuz pointing to the 6.11 kernel, and with every 'apt update/upgrade' nicely updating things to the latest, my machine, when booting, stubbornly keeps running that 2022 5.14.0-1051-oem kernel.

My questions:
--What causes my system to 'revert' to the 5.14.0-1051-oem kernel even if /boot/initrd.img and /boot/vmlinuz point to the 6.11 kernel?
--How can I fix this? (or should I even fix this?)

Thanks for helping!!

Rene

 

[GatorsFan]

seems to me if you have 5.14 you are not running Ubuntu 24.10 - 24.10 ships with 6.11 kernel - 24.04 ships with 6.8 kernel - the 5.14 kernel ships with version 20.04.5

What is the output of

lsb_release -a

you can use your Synaptic Package Manager and remove all the old kernels

 

[reitsmar]

seems to me if you have 5.14 you are not running Ubuntu 24.10 - 24.10 ships with 6.11 kernel - 24.04 ships with 6.8 kernel - the 5.14 kernel ships with version 20.04.5

What is the output of

you can use your Synaptic Package Manager and remove all the old kernels

 

[reitsmar]

Thanks for the quick reaction.

lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04.2 LTS
Release: 24.04
Codename: noble

OK, so 24.04 LTS; still,,, why is that old 5.14 oem kernel running? Or conversely, if 5.14 is what should be running, why do /boot/initrd.img and /boot/vmlinuz point to the 6.11 kernel?

 

[osprey]

So despite /boot/initrd.img and /boot/vmlinuz pointing to the 6.11 kernel, and with every 'apt update/upgrade' nicely updating things to the latest, my machine, when booting, stubbornly keeps running that 2022 5.14.0-1051-oem kernel.

My questions:
--What causes my system to 'revert' to the 5.14.0-1051-oem kernel even if /boot/initrd.img and /boot/vmlinuz point to the 6.11 kernel?
--How can I fix this? (or should I even fix this?)

Thanks for helping!!

Rene

It's possible that the grub bootloader thinks that the earlier kernel is the default, so it keeps using it. Perhaps paste a copy the file /etc/default/grub, here using code tags so that it's an exact copy, and then readers may be able to see if this is the problem.

 

[MikeWalsh]

Y'know, this is one of the things I love about 'our Pup'. Its modular build system.....and the way you can chop & change things; mix'n'match to achieve the results you want.

I have a build of Xenialpup64 - based on Ubuntu 16.04 'Xenial Xerus', from nine years ago - running a 6-series kernel (k6.6.79). I also have a build of Noblepup32 (from last year) running a 3-series kernel (k3.14.56) from 2014, simply because it supports an ancient plotter I very occasionally fire-up for certain situations. This is a minimal, stripped-back 'bare-bones' build, not connected to the internet, running in basic 'standalone' mode just to control this one piece of ancient hardware...

I'm assuming that in the case of mainstream distros, it's only possible to access/use whatever kernel builds were made available for a given release's particular repos..? I could of course be wrong, and am happy to be corrected on this point.

In Puppy's case, you can run literally ANY Puppy you want with any KERNEL you want. The Linux kernel is pretty flexible and forgiving. More so, perhaps, than many might imagine...

(shrug...)


Mike.

 

[Aristarchus]

Y'know, this is one of the things I love about 'our Pup'. Its modular build system.....and the way you can chop & change things; mix'n'match to achieve the results you want.

I have a build of Xenialpup64 - based on Ubuntu 16.04 'Xenial Xerus', from nine years ago - running a 6-series kernel (k6.6.79). I also have a build of Noblepup32 (from last year) running a 3-series kernel (k3.14.56) from 2014, simply because it supports an ancient plotter I very occasionally fire-up for certain situations. This is a minimal, stripped-back 'bare-bones' build, not connected to the internet, running in basic 'standalone' mode just to control this one piece of ancient hardware...

I'm assuming that in the case of mainstream distros, it's only possible to access/use whatever kernel builds were made available for a given release's particular repos..? I could of course be wrong, and am happy to be corrected on this point.

In Puppy's case, you can run literally ANY Puppy you want with any KERNEL you want. The Linux kernel is pretty flexible and forgiving. More so, perhaps, than many might imagine...

(shrug...)


Mike.

Shrug,
Nothing difficult,
Just check kernel compatibility.
The only issues are caused by some kernel modules requiring specific gcc version. Not that many.
However if you install new gcc on old distro release then does not matter how you label it it is system upgrade.

 

[Aristarchus]

Y'know, this is one of the things I love about 'our Pup'. Its modular build system.....and the way you can chop & change things; mix'n'match to achieve the results you want.

I have a build of Xenialpup64 - based on Ubuntu 16.04 'Xenial Xerus', from nine years ago - running a 6-series kernel (k6.6.79). I also have a build of Noblepup32 (from last year) running a 3-series kernel (k3.14.56) from 2014, simply because it supports an ancient plotter I very occasionally fire-up for certain situations. This is a minimal, stripped-back 'bare-bones' build, not connected to the internet, running in basic 'standalone' mode just to control this one piece of ancient hardware...

I'm assuming that in the case of mainstream distros, it's only possible to access/use whatever kernel builds were made available for a given release's particular repos..? I could of course be wrong, and am happy to be corrected on this point.

In Puppy's case, you can run literally ANY Puppy you want with any KERNEL you want. The Linux kernel is pretty flexible and forgiving. More so, perhaps, than many might imagine...

(shrug...)


Mike.

Shrug,
Nothing difficult,
Just check kernel compatibility.
The only issues are caused by some kernel modules requiring specific gcc version. Not that many.
However if you install new gcc on old distro release then does not matter how you label it is system upgrade.

Aside being pointless PR for some distro it does not solve OP problem and he is rightly concerned about running old kernel with security issues.

Looks like @osprey provided best possible answer.

 

[reitsmar]

It's possible that the grub bootloader thinks that the earlier kernel is the default, so it keeps using it. Perhaps paste a copy the file /etc/default/grub, here using code tags so that it's an exact copy, and then readers may be able to see if this is the problem.

Hmm, everything (all lines) in my /etc/default/grub are commented out (#) except for the following:

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`( . /etc/os-release; echo ${NAME:-Ubuntu} ) 2>/dev/null || echo Ubuntu`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

There is a /etc/default/grub.d/oem-flavour.cfg file with the following lines:

# This file is automatically generated by oem-somerville-onix-adl-meta, and changes will be overriden
GRUB_FLAVOUR_ORDER=oem

I'm (of course) not sure if this is related to what's going on, but I figured I might as well mention it.

R.

 

[osprey]

Hmm, everything (all lines) in my /etc/default/grub are commented out (#) except for the following:

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`( . /etc/os-release; echo ${NAME:-Ubuntu} ) 2>/dev/null || echo Ubuntu`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

There is a /etc/default/grub.d/oem-flavour.cfg file with the following lines:

# This file is automatically generated by oem-somerville-onix-adl-meta, and changes will be overriden
GRUB_FLAVOUR_ORDER=oem

I'm (of course) not sure if this is related to what's going on, but I figured I might as well mention it.

R.

Thanks for the details.

GRUB_DEFAULT=0 means that the grub is loading the first kernel that is mentioned in the grub.cfg file which is the main configuration file for grub.

One can check the order of kernels that grub will load by looking in the grub.cfg file which is usually located at: /boot/grub/grub.cfg. One usually needs to be root to access the file. Each kernel's version appears on the line beginning with "linux".

One does not directly alter that file!

If there is a difference between the kernel that is being loaded on the machine, the 5.14 oem kernel, and the first one mentioned in the grub.cfg file, then I would speculate that the config from your output in post #9: GRUB_FLAVOUR_ORDER=oem
is the controlling config. In that case, I would comment out that config with the pound sign #, like so: # GRUB_FLAVOUR_ORDER=oem, and update grub. Reboot and see if that helps.

If, on the other hand, the 5.14 oem kernel is the first to appear in the grub.cfg file, then this can be altered in the next boot up by getting a grub menu on screen as the machine boots, and selecting the "Advanced Options" menu item using the down arrow key. The available kernels for the machine should appear and you can select the later kernel to boot with the arrow keys.

With the machine now booted to the later kernel, you can configure grub to boot it in future from then by entering the following configs to /etc/default/grub:
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
and then updating grub.

 

[KGIII]

My hunch is that you did the "OEM install" when you installed Ubuntu. That's where that kernel comes from.

See:

Kernel/OEMKernel - Ubuntu Wiki

It's similar, but not exactly alike, to the HWE stack.

Back up your data and remove the OEM kernel. When that's done, reboot. It should boot to your backup kernel at this point. You can then go ahead and update and no longer be using the OEM kernel.

Or, you can just use the OEM kernel. It's harmless and not something to be alarmed with if you're not having issues.

 

[reitsmar]

Thank you all for helping!! Much appreciated!!

KGill, indeed, the machine came from Dell with Linux (Ubuntu/oem) preloaded.

I hesitate to follow your advice and 'remove the OEM kernel' (or rename it to something else) hoping that after that it boots /boot/vmlinuz -> vmlinuz-6.11.0-21-generic instead. Reason is that I do not want to risk the system not booting up anymore (it is my main machine). I can of course always reinstall Ubuntu, but I'd very much like to avoid that, especially since I'd also have to reinstall lots of additional software, libs, etc.

You write "you can just use the OEM kernel. It's harmless and not something to be alarmed with if you're not having issues".
Indeed, that is what I have been doing so far. But if I do that, am I not missing out on security fixes that have been wrapped up in newer kernels?

 

[KGIII]

but I'd very much like to avoid that, especially since I'd also have to reinstall lots of additional software, libs, etc.

That's why you make backups. I actually only backup /home/kgiii (generally). If things break and I can't fix them, I just do a fresh installation and copy that data back. Then, when I install my applications (as I need them), they all have the same settings they had before. Browsers will even have the same open tabs when you open them. You do really want to do it in that order.

And, yeah, you have an OEM install done by Dell. There's nothing wrong with that, so long as everything works as expected. There's no need to change.

The OEM kernel gets all the security fixes, the same fixes the mainline kernel gets. You don't need to worry there.

But, yeah, it's important to have backups - even if you don't change to a different kernel. They'll come in handy and it'll suck if you do need them and don't have them. These days, with a modern NVMe M.2 SSD, it's a very quick process to reinstall and move data around.

I'll digress a bit here... I'm a bit curious, so I'll share what I find.

I just looked and TeamGroup has 1 TB USB thumbdrives for about 60 USD and 512 GB thumbdrives are just about half of that. If you know what data you want to preserve (just regarding the OS and its backups) that's plenty of space for all sorts of data.

https://www.newegg.com/p/pl?d=teamgroup+usb+thumbdrive&N=601113575%20601113577%20100007960

As an aside, it's amazing to me to see how much the prices for storage have come down. That amazes me for RAM, as well.

That and the storage has become so small. They now working on (selling?) SD cards in the 4 TB region. Can you imagine how much data you could then fit into a shoebox?!?

I had to check that out...

Some rough math says you can fit about 5000 SD cards (not even MicroSD cards) into a size 10 (US) shoebox. So, we're looking at a bit over 19 pitabyes of storage. Now that's a lot of data!

 

[theLegionWithin]

prepare for the worst - hope for the best

 

[GatorsFan]

just make sure you have booted to that latest kernel first
to boot to a different kernel
Modify the GRUB_DEFAULT=0 value as per your need.
In your case GRUB_DEFAULT=6.11.0-21-generic
save the file and now run

sudo update-grub

now reboot - now your machine should have booted to kernel 6.11 once you have verified that kernel is running you can now safely remove those old kernels - personally I use the Synaptic Package Manager for this - now that all the old kernels are remove you can change GRUB_DEFAULT= to it's original state and run sudo update-grub again

as @osprey has stated in #10 GRUB_DEFAULT=0 means that the grub is loading the first kernel that is mentioned in the grub.cfg file