Changing the ID to boot from an older Kernel by default | grubby

I would like to know how dnf treats the default Index when I do the following changes. Will the older default kernel still be available after an update or do I have two newer kernels?
I do use installonly_limit=2 in my /etc/dnf/dnf.conf.

Before I test it on my selves I try to find out if somebody already made experience with it.

grubby

List all installed kernels

To get the index number of all the installed kernels:

sudo grubby --info=ALL | grep -E "^kernel|^index"

The output should be something like this:

 index=0
 kernel="/boot/vmlinuz-5.15.10-200.fc35.x86_64"
 index=1
 kernel="/boot/vmlinuz-5.15.10-lqx1.0.fc35.x86_64"
 index=2
 kernel="/boot/vmlinuz-5.15.8-200.fc35.x86_64"
 index=3
 kernel="/boot/vmlinuz-5.15.8-lqx1.0.fc35.x86_64"

Change the default kernel using index

Now we can change the default kernel by using the index number:

sudo grubby --set-default-index=1

Verify the default kernel

Verify that the right kernel has been set as default:

sudo grubby --default-title

The output will be the default kernel title:

Fedora Linux (5.15.10-lqx1.0.fc35.x86_64) 35 (Workstation Edition)

That will retain 2 kernels. By default it will keep the two most recent kernels.

Are you trying to retain a kernel older than that?

1 Like

Yes, I just ask because of hardware where is not recognized with the 6.0.x series of kernels yet by default. Or where have to be installed additional drivers not ready yet.

p.s.
The example above is with the same kernel series.
I’m asking between 6.0.x and 5.19.x drivers to be sure of it.

I had that problem in the past. I think I was using dnf versionlock to hold it in place.

Eventually I just decided it was easier to install the LTS kernel and not have to worry about it. If the main kernel stopped working for me, I just switched to LTS until it was fixed.

1 Like

I guess with Fedora this is not an option ?! Or did i miss something?

Ok. I do update with dnf and never use -y option. Always reading before apply an update. Just for new users I would not expect working the same way.

There is a well maintained copr for that kwizart/kernel-longterm-5.15 Copr

One slight alteration to the above posts.

Dnf will not remove the currently running kernel.
When you have the installonly_limit=2 option set that means a kernel upgrade will result in having only the currently booted kernel and the newly installed one remaining after the upgrade.

For example, if you are booted to the 5.19.16 kernel and you also have the 6.0.5 kernel installed, but a kernel upgrade installs the 6.0.6 kernel, the end result is you will now have the 5.19.6 kernel and the 6.0.6 kernels as the only 2 kernels installed.

Dnf does not remove the booted kernel no matter how far back it is in the install sequence. It instead keeps the currently booted kernel and the newest one being installed, but removes those older than the newest except the one booted to meet the installonly_limit value. It keeps the booted kernel and enough of the newest to meet that limit.

As a feedback, the 5.19.x kernel not got removed when I made an update on 6.x.x. I had to remove it manually.

This is the reason that the default setting is installonly-limit=3 and that the settings are that the newest kernel is the default kernel for booting. It ensures you have 2 older ‘tested and functional’ kernels installed in case something prevents the newest kernel from booting, but does not retain an extremely old kernel.

For most systems that 3rd kernel is insignificant in space occupied on the storage. Since most kernels use about the same amount of space, once the system has been updated and has the three kernels saved then newer updates do not use additional space for kernel storage.

On my system I have a 350 MB /boot partition and only 200 MB of that is in use with the 3 kernels stored.