old kernel references are "stuck" in /etc/grub2.cfg and /etc/grub2-efi.cfg

asked 2018-07-20 03:22:14 -0600

erickj
41 ●2 ●3

After my last upgrade to F28 I noticed there are multiple kernel menu options listed on the grub boot loader that are no longer installed. I'm guessing these are leftovers from old Fedora major releases that aren't cleaned up after system upgrades (dnf system-upgrade)

Here are the kernels that I have actually installed:

$ rpm -q kernel
kernel-4.17.2-200.fc28.x86_64
kernel-4.17.3-200.fc28.x86_64
kernel-4.17.4-200.fc28.x86_64

However, here I can see the kernels listed in /etc/grub2.cfg and /etc/grub2-efi.cfg:

$ sudo grep Fedora /etc/grub2.cfg | ruby -e 'STDIN.readlines.each do |l| puts l.match(/Fedora\s[^\)]+\)/) end'
Fedora (4.17.4-200.fc28.x86_64)
Fedora (4.17.3-200.fc28.x86_64)
Fedora (4.17.2-200.fc28.x86_64)
Fedora (4.16.9-300.fc28.x86_64)
Fedora (4.16.7-100.fc26.x86_64)
Fedora (4.14.16-200.fc26.x86_64)

09:54:55 [erick@lenobot:~] 
$ sudo grep Fedora /etc/grub2-efi.cfg | ruby -e 'STDIN.readlines.each do |l| puts l.match(/Fedora\s[^\)]+\)/) end'
Fedora (4.17.4-200.fc28.x86_64)
Fedora (4.17.3-200.fc28.x86_64)
Fedora (4.17.2-200.fc28.x86_64)
Fedora (4.16.9-300.fc28.x86_64)
Fedora (4.16.7-100.fc26.x86_64)
Fedora (4.14.16-200.fc26.x86_64)
Fedora (0-rescue-2df438ba327a49f7ad5fd2367ebe5581)
Fedora (4.11.7-200.fc25.x86_64)

Looking in /boot I see these kernels (which matches the output of rpm -q kernel):

$ ls /boot/ | grep '^vm'
vmlinuz-0-rescue-2df438ba327a49f7ad5fd2367ebe5581
vmlinuz-4.17.2-200.fc28.x86_64
vmlinuz-4.17.3-200.fc28.x86_64
vmlinuz-4.17.4-200.fc28.x86_64

I'm aware that grub2.cfg is generated from the scripts inside of /etc/grub.d/*, but being someone who changes grub configs only when necessary with a healthy fear/respect for fucking up my boot loader, how do I go about cleaning up these old references to the 4.16.x, 4.14.x, and 4.11.x kernels?

edit retag flag offensive close merge delete

Comments

My system is the same way. Should we do something manually to fix this?

tim8723 ( 2018-07-20 06:40:10 -0600 )edit

add a comment

answered 2018-07-23 06:34:29 -0600

FeRDNYC

206 ●9 ●7

The new-kernel-pkg script is responsible for managing boot entries in /boot/grub2/grub.cfg (or, actually, in /etc/grub2.cfg which should be a symlink to /boot/grub2/grub.cfg). It's the script that kernel-$(uname -r).rpm packages are supposed to run on installation / removal to update the boot config.

You can clean out each of the old entries by running, for each unnecessary line:

new-kernel-pkg --remove <kernel-version>

So you'd want:

new-kernel-pkg --remove 4.16.9-300.fc28.x86_64
new-kernel-pkg --remove 4.16.7-100.fc26.x86_64
new-kernel-pkg --remove 4.14.16-200.fc26.x86_64
new-kernel-pkg --remove 4.11.7-200.fc25.x86_64

It's not super clear to me why you'd have both /etc/grub2.cfg and /etc/grub2-efi.cfg being actively updated (perhaps that's normal with EFI systems, I don't have any experience with them), but it looks like new-kernel-pkg will act on both files in a single run if they're both detected. So, a single set of new-kernel-pkg runs should cover everything.

Comments

This worked perfectly, for my system. Thank you.

tim8723 ( 2018-08-18 08:20:19 -0600 )edit

add a comment

old kernel references are "stuck" in /etc/grub2.cfg and /etc/grub2-efi.cfg

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

old kernel references are "stuck" in /etc/grub2.cfg and /etc/grub2-efi.cfg edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

old kernel references are "stuck" in /etc/grub2.cfg and /etc/grub2-efi.cfg