Grub menu not updating on kernel change

Hi,

I have been having a lot of problems attempting to upgrade to Fed30 form Fed29.

One thing which maybe a blocking issue is that it seems that grub2 is not updating when there is a change to the kernel. Specifically, I had the last 3 fc29 kernels and removed the oldest one with dnf. When I reboot I still see the third line with the old, now removed kernel.

Obviously, if the new fc30 kernel does not appear as the new default in grub menu the update will not be able to go ahead. This is what I’m seeing, so I think I need to resolve this issue directly since it is orders of magnitude quicker to test a kernel change than to run through upgrade process yet again only to find I still boot the Fed29.

Until last week I have not had problem with kernel updates and grub. Since I started trying to upgrade I have been having problems, though I do not know at exactly what stage this grub issue started, I have attempted the upgrade process a dozen times in the last week.

I need to focus here on getting grub to update the grub menu correctly. I’m suspecting it’s BLS related issue. Since this whole thing has become invisible and arcane since BLS was forced on us it is very hard to know what is happening or even where to look.

Any suggestions on how to pin this down?
Thanks.

if you are removing kernels by hand your always need to tell that grub too with “grub2-mkconfig”!

this command is your friend:

[ -d /sys/firmware/efi/efivars ] && sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg || sudo grub2-mkconfig -o /boot/grub2/grub.cfg

it first looks if you’re booting with EFI, according to the output it writes/updates the related grub.cfg.

the above line is a short form [1] of this:

 if [ -d /sys/firmware/efi/efivars ]; then
     sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg;
 else
    sudo grub2-mkconfig -o /boot/grub2/grub.cfg;
fi

if my above command doesn’t fix the problem please look if your /etc/default/grub

has either
GRUB_DEFAULT=saved
or
GRUB_DEFAULT=0

HINT:
everytime you change something in /etc/default/grub you need to run grub2-mkconfig to get your changes active !

[1]
laziness is the art to rest before getting tired !
:slight_smile:

thanks,
installing a kernel must run grub2-mkconfig so I assumed removing one would for similar reasons ( not much point in having a grub option pointing to a missing image! ).

A few days back it did have GRUB_DEFAULT=saved ( don’t know who changed that ! ) and for some reason it had moved itself to boot off the fifth line which was memtest86+ !! Great idea. I had not even run that myself so I don’t know why is “saved” that choice.

I changed it back to GRUB_DEFAULT=0 and ran grub2-mkconfig by hand to get sensible booting restored.

I still have the old kernel present in grub menu.

EDIT: dnf install kernel reports just two kernels yet I see I still have the older 3rd one in /boot. So in that respect grub2-mkconfig seems to be correct. dnf has lost track !!

Ok this is more of a mess that I thought.

  1. dnf lost track of what kernels were installed. ( I used dnf to remove the 3rd kernel yet is was still in /boot )

  2. I then manually removed the four files associated with that kernel by hand and reran grub2-mkconfig, I see the timestamp of /boot/grub2/grub.cfg got updated but I STILL see three kernels in grub boot menu.

    cd /boot
    rm 5.1.21-200
    grub2-mkconfig -o /boot/grub2/grub.cfg

This is getting really schizophrenic, Fedora is totally loosing it now.

there is NO need to run grub2-mkconfig after dnf upgrades the kernels !
It’s done automatically.

“saved” is the default -AFAIK-
there is a write-up in the internet what it is for/ it does.

for your left over kernels/grub-entries you maybe need a look in
/boot/loader/entries if the entries there fits with the kernels installed.

I usually do

rpm -qa | grep kernel-core

sudo dnf remove <copy-paste the kernel-core from the above output I want to remove>

sudo grub2-mkconfig …

if you’re running kernel modules (nvida, etc) you need to also remove kernel-devel and kmod-something.

If you’re removing kernels by hand under /boot with rm … you might clean under /lib/modules/ the left overs too

OK, that is what I thought was the case, except that it doesn’t work like that now.

Saved may be the default now, but I used to have =0. That does not explain why it got changed to “saved” and decided to set that to 5 during an attempt to upgrade to Fed30.
rpm -qa | grep kernel-core
thanks, kernel-core was still the in three versions, despite kernel being removed. I removed the old one:
dnf remove kernel-core-5.1.21-200.fc29
This removed things like VirtualBox too but did NOT touch /boot/grub2/grub.cfg
.

“Saved may be the default now, but I used to have =0”

it could have been changed through an update of grub2-tools
see

rpm -qf /etc/default/grub

“This removed things like VirtualBox too but did NOT touch /boot/grub2/grub.cfg”

you need to read carefully what I wrote !
an dnf upgrade does touch /boot/grub2/grub.cfg.
an dnf remove does NOT touch /boot/grub2/grub.cfg.

at least on my box

Then you are not reading what I wrote !

I said I removed a kernel and you posted some comment about upgrading, I presumed you thought that was relevant , not just some random bit of knowledge.

it could have been changed through an update of grub2-tools
I thought there was the rpmsaved mechanism to stop us getting screwed around by silent changes to config files. Clearly something has been poking around changing stuff and it is a little academic once it wasted you a couple of days chasing odd behaviour and you finally work out what got changed.

I suspect grubby ( whoever gave it that silly name is unlikely to be rigorous about anything ) and BLS.

ls /boot/loader/entries seems to just have the remaining two kernels plus the fallback.

you need to read following sentence too, to pick the sense:

esp for you:

an dnf upgrade does touch /boot/grub2/grub.cfg.
an dnf remove does NOT touch /boot/grub2/grub.cfg.

Clarification:

the above statement IS WRONG !
Sorry !!!

I mixed it, cause I usually run vanilla kernels since a long time.
Removing these kernels goes exclusively via rm … .
Only in the case of removing kernels (distro kernels too !) via rm the run of “sudo grub2-mkconfig” is needed.

Normally “dnf remove kernel-core” updates the entries under grub automatically too.

1 Like

LOL, thanks for the help.

Now where was I ?

cit.:
“LOL, thanks for the help.
Now where was I ?”

obviously in a “state” where you’re stxxid (and arrogant) enough trying (!!!) to piss guys which want to help you on their legs, when you’re dissatisfied with their answers !

You need a fix for that “state” first - a sort of therapy I guess -, before one provide you with further info’s to fix your box.

you see, I exactly know where you are !!!
:slight_smile:

until that: good luck and good night !

Now why would I be dissatisfied with answers which are incorrect, tell me I’m wrong when I’m right with lots of bold and exclamation marks which frankly come over as being a bit condescending !!!

arrogant :
1. Having or displaying a sense of overbearing self-worth or self-importance.

2. Marked by or arising from a feeling or assumption of one’s superiority toward others:

That would seem to better characterise your own attitude rather than someone asking for help and following suggestions made.

dnf remove does NOT touch /boot/grub2/grub.cfg.

You did fess up and post a correction when you realised, which is commendable. Shame it took so long realise the difference between rm and dnf remove.

rpm -qa | grep kernel-core

That was a useful pointer, which at least cleared up one issue. Thanks.

I don’t have time to do a full psychoanalysis based on forum posts, as you do, you will have to examine your own motivations and the attitude you display to others when giving “help”. Imagining you can suggest someone needs “therapy” is another sign of arrogance you may need to look at.

Thanks again.

To summarise the cause of the problem here for future reference, since it was not at all evident so far.

To update the kernel you need dnf update kernel, this will pull in deps such as kernel-core and kernel-modules. It will also result in changes to the grub boot menu but will not ( or may not ) touch /boot/grub2/grub.cfg , if you do dnf install kernel-core you will get only that package, not the kernel and modules and subsequent dnf install kernel will not report that there is another kernel version installed.

To remove and old kernel you need to do dnf remove kernel-core.xx.xxx.xx.fcxx , this will remove deps such as kernel and kernel-mods. If you do dnf remove kernel, it will to only that and not remove the kernel-core and kernel-mod packages.

There may be a good, logical reason for this arcane, special behaviour but it not at all obvious to the user.

1 Like

Nice what you did find the way, I would like only add that to delete a old kernel maybe the best way is the following command:

sudo dnf remove kernel*x.xx.x-xxx.fcxx.x86_64

Here you can see an exempel
https://forums.fedoraforum.org/showthread.php?318051-How-to-delete-older-kernels-Fedora-28

Regards

1 Like

thanks xtym but that is not consistent with what I have just shown. that is exactly what I thought I needed to do but dnf remove kernel*x.xx.x-xxx.fcxx.x86_64 only removes kernel, not kernel-core and kernel-modules. Please try it and post back what you find after looking in /boot and /boot/loader/entries.

in #2 I reported:

EDIT: dnf install kernel reports just two kernels yet I see I still have the older 3rd one in /boot. So in that respect grub2-mkconfig seems to be correct. dnf has lost track !!

The link you show is just forum post and may well be wrong. There’s a lot of it about.

Someone there suggests running update-grub to update grub menu on Fedora when that does not exist ( it is a *buntu command ).

It did work for me, yesterday i deleted a kernel fromtesting repo what did be obsolete. You can see it in my dnf.log
Regards.

2019-10-21T16:39:12Z DDEBUG Command: dnf remove kernel*5.3.5-300.fc31.x86_64 
2019-10-21T16:39:12Z DDEBUG Installroot: /
2019-10-21T16:39:12Z DDEBUG Releasever: 31
2019-10-21T16:39:12Z DEBUG cachedir: /var/cache/dnf
2019-10-21T16:39:12Z DDEBUG Base command: remove
2019-10-21T16:39:12Z DDEBUG Extra commands: ['remove', 'kernel*5.3.5-300.fc31.x86_64']
2019-10-21T16:39:12Z DEBUG Okänt konfigurationsvärde: failovermethod=priority i /etc/yum.repos.d/fedora-updates-modular.repo; Konfiguration: OptionBinding med id ”failovermethod” finns inte
2019-10-21T16:39:12Z DEBUG Okänt konfigurationsvärde: failovermethod=priority i /etc/yum.repos.d/fedora-updates-modular.repo; Konfiguration: OptionBinding med id ”failovermethod” finns inte
2019-10-21T16:39:12Z DEBUG Okänt konfigurationsvärde: failovermethod=priority i /etc/yum.repos.d/fedora-updates-modular.repo; Konfiguration: OptionBinding med id ”failovermethod” finns inte
2019-10-21T16:39:12Z DEBUG No module defaults found
2019-10-21T16:39:12Z DDEBUG timer: sack setup: 299 ms
2019-10-21T16:39:12Z DEBUG --> Börjar beroendeupplösning
2019-10-21T16:39:12Z DEBUG --> Finding unneeded leftover dependencies
2019-10-21T16:39:12Z DEBUG ---> Paketet kernel.x86_64 5.3.5-300.fc31 kommer att tas bort
2019-10-21T16:39:12Z DEBUG ---> Paketet kernel-core.x86_64 5.3.5-300.fc31 kommer att tas bort
2019-10-21T16:39:12Z DEBUG ---> Paketet kernel-modules.x86_64 5.3.5-300.fc31 kommer att tas bort
2019-10-21T16:39:12Z DEBUG ---> Paketet kernel-modules-extra.x86_64 5.3.5-300.fc31 kommer att tas bort
2019-10-21T16:39:12Z DEBUG --> Avslutade beroendeupplösning
2019-10-21T16:39:12Z DDEBUG timer: depsolve: 117 ms
2019-10-21T16:39:12Z INFO Beroenden upplösta.
2019-10-21T16:39:12Z INFO ================================================================================
 Paket                   Ark       Version            Förråd               Strl
================================================================================
Tar bort:
 kernel                  x86_64    5.3.5-300.fc31     @updates-testing      0  
 kernel-core             x86_64    5.3.5-300.fc31     @updates-testing     67 M
 kernel-modules          x86_64    5.3.5-300.fc31     @updates-testing     28 M
 kernel-modules-extra    x86_64    5.3.5-300.fc31     @updates-testing    1.9 M

Transaktionssammanfattning
================================================================================
Ta bort  4 Paket

2019-10-21T16:39:12Z INFO Frigjort utrymme:  97 M
2019-10-21T16:39:38Z INFO Kör transaktionskontroll
2019-10-21T16:39:38Z INFO Transaktionskontrollen lyckades.
2019-10-21T16:39:38Z INFO Kör transaktionstest
2019-10-21T16:39:38Z INFO Transaktionstesten lyckades.
2019-10-21T16:39:38Z DDEBUG timer: transaction test: 308 ms
2019-10-21T16:39:38Z INFO Kör transaktionen
2019-10-21T16:39:38Z DDEBUG RPM transaction start.
2019-10-21T16:39:47Z DDEBUG RPM transaction over.
2019-10-21T16:39:47Z DDEBUG timer: verify transaction: 317 ms
2019-10-21T16:39:47Z DDEBUG timer: transaction: 9045 ms
2019-10-21T16:39:47Z DEBUG Completion plugin: Generating completion cache...
2019-10-21T16:39:47Z INFO 
Borttagna:
  kernel-5.3.5-300.fc31.x86_64                                                  
  kernel-core-5.3.5-300.fc31.x86_64                                             
  kernel-modules-5.3.5-300.fc31.x86_64                                          
  kernel-modules-extra-5.3.5-300.fc31.x86_64                                    

2019-10-21T16:39:47Z INFO Klart!
2019-10-21T16:39:47Z DDEBUG Cleaning up.
1 Like

thanks xtym, that is interesting. I note that you are running Fed31 , not Fed29.

Here is what happens when I remove a version of kernel package on Fed29. Unless I’m misreading this we have two very different things happening here. What do you make of it?

bash-4.4#dnf install kernel
Last metadata expiration check: 0:26:30 ago on Tue 22 Oct 2019 11:21:21 BST.
Package kernel-5.2.17-100.fc29.x86_64 is already installed.
Package kernel-5.2.18-100.fc29.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
bash-4.4#uname -a
Linux fedbox 5.2.18-100.fc29.x86_64 #1 SMP Tue Oct 1 13:32:05 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
bash-4.4#dnf install kernel-core
Last metadata expiration check: 0:27:10 ago on Tue 22 Oct 2019 11:21:21 BST.
Package kernel-core-5.2.17-100.fc29.x86_64 is already installed.
Package kernel-core-5.2.18-100.fc29.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
bash-4.4#dnf remove kernel-5.2.17-100.fc29
Dependencies resolved.
=========================================================================================================================
 Package                  Architecture             Version                              Repository                  Size
=========================================================================================================================
Removing:
 kernel                   x86_64                   5.2.17-100.fc29                      @updates                     0  

Transaction Summary
=========================================================================================================================
Remove  1 Package

Freed space: 0  
Is this ok [y/N]: y
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                 1/1 
  Erasing          : kernel-5.2.17-100.fc29.x86_64                                                                   1/1 
  Running scriptlet: kernel-5.2.17-100.fc29.x86_64                                                                   1/1 
  Verifying        : kernel-5.2.17-100.fc29.x86_64                                                                   1/1 

Removed:
  kernel-5.2.17-100.fc29.x86_64                                                                                          

Complete!
bash-4.4#dnf install kernel-core
Last metadata expiration check: 0:28:38 ago on Tue 22 Oct 2019 11:21:21 BST.
Package kernel-core-5.2.17-100.fc29.x86_64 is already installed.
Package kernel-core-5.2.18-100.fc29.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
bash-4.4#
bash-4.4#dnf install kernel
Last metadata expiration check: 0:00:15 ago on Tue 22 Oct 2019 13:17:15 BST.
Package kernel-5.2.18-100.fc29.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

bash-4.4#ls /boot/loader/entries
87ebc272236b419da0c6cab75da6ddad-0-rescue.conf
87ebc272236b419da0c6cab75da6ddad-5.2.17-100.fc29.x86_64.conf
87ebc272236b419da0c6cab75da6ddad-5.2.18-100.fc29.x86_64.conf

what if you do sudo dnf remove kernel*5.2.17-100.fc29 in place of sudo dnf remove kernel-5.2.17-100.fc29 If you use a “*” in place of “-” it will take all to remove becouse the own behaivor of * (this caracter can take every value or string mellan values).

Regards.

1 Like

ah many thanks, I overlooked the * among all the x’s . Obviously that will catch the other pkgs.

For some reason kernel acts as a meta when installing or upgrading but does not act as a meta when removing. Does that make any sense to you?