Description of problem: DNF fails to update grub.cfg when new kernel is installed Version-Release number of selected component (if applicable): 4.2.23-1 How reproducible: Every time a new kernel is installed Steps to Reproduce: 1.dnf upgrade kernel 2. 3. Actual results: /boot/efi/EFI/fedora/grub.cfg is unchanged Expected results: grub.cfg updated to reflect new kernel. Additional info: /etc/default/grub GRUB_TIMEOUT=10 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="gfxterm" GRUB_CMDLINE_LINUX=" rhgb quiet" GRUB_DISABLE_RECOVERY="true" GRUB_GFXPAYLOAD_LINUX=1280x800x32 GRUB_GFXMODE=1280x800 GRUB_FONT="/boot/grub2/fonts/DejaVuSansMono.pf2" GRUB_BACKGROUND="/boot/grub2/images/grublogo.png" GRUB_ENABLE_BLSCFG=false grub2-mkconfig is not run by dnf. If I run grub2-mkconfig manually the grub.cfg file is updated correctly. All the kernel pieces are installed in the correct places except grub,cfg The post install scriptlet seems to run /bin/kernel-install Removing a kernel also does not seem to update the grub.cfg file
This is unrelated to dnf, this is done in the scriptlets.
Yes The scriptlet runs "kernel-install add" which is run when one tries to install a new kernel with dnf upgrade and probably with "rpm -i"
kernel-install is actually part of systemd
grub has a plugin for kernel-install which handles the grub-specific bits.
Didn't know grub had plugins. I searched with dnf (dnf list grub2*) and no grub2 plugin packages were listed. Checking dnf plugins availability the package dnf-plugins-extras is missing except in the source repo.
This behaviour of not updating the grub menu has changed in recent months. I have been adding custom entries, so that process would have picked up new kernels when I ran grub2-mkconfig. So I didn't pick up on when this behaviour started. When I noticed, I added a debug line to the grub2-mkconfig script in case it was somthing I did to see if was being run by the dnf upgrade process. It was not being run so no menu change occurred. I was using grub2-emu to check my new menu entries and noticed that the kernel entries were missing which led me to the GRUB_ENABLE_BLSCFG in /etc/default/grub. I set this to false, ran grub2-mkconfig and the menus looked ok under grub2-emu and when I booted. I deleted the /boot/loader directory which is part of the BLS process, since I assumed they would no longer be needed. A quick look the what /bin/kernel-install add does appears that it really assumes one wants to use BLS. I am still trying to figure out what problem the BLS process is trying to solve. I can see system management problems if I wanted to clone a menu to other identical hardware. You might have to change the entries in /boot/loader/entries for each machine to match the MACHINEID instead of just copying the grub.cfg file. I just did a kernel update with dnf upgrade with no /boot/loader directory and it recreated the directory and an entry for the 5.10 kernel. So it ignored the fact that I set GRUB_ENABLE_BLSCFG=false .
I decided to take the plunge and do a kernel update. The kernel update removed the kernel modules for the oldest kernel but did NOT remove the entry in the grub.cfg file. It did NOT run grub2-mkconfig or any other utility to update that file. So my grub.cfg now has two entries for non-existent kernels. The next one will leave me with none. I can run grub2.mkconfig manually but I should not have to do this. The kernel-install add logic is flawed when GRUB_ENABLE_BLSCFG=false . Is there a documented version (read commented) of the kernel-install script?
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
(In reply to Brian Kaye from comment #7) > I decided to take the plunge and do a kernel update. The kernel update > removed the kernel modules for the oldest kernel but did NOT remove the > entry in the grub.cfg file. It did NOT run grub2-mkconfig or any other > utility to update that file. So my grub.cfg now has two entries for > non-existent kernels. The next one will leave me with none. I can run > grub2.mkconfig manually but I should not have to do this. The kernel-install > add logic is flawed when GRUB_ENABLE_BLSCFG=false . > > Is there a documented version (read commented) of the kernel-install script? You need to install the grubby-deprecated package if you want a menuentry command to be added to the grub.cfg file. But the default configuration in Fedora is to use the BLS snippets and the kernel-install grub2 plugin. Closing this bug since that is the expected behaviour.
The behaviour is correct if GRUB_ENABLE_BLSCFG=true is specified (or default) but is not the expected behaviour if GRUB_ENABLE_BLSCFG=false is specified or one wants to pick up changes made to the GRUB config files when a kernel is installed or deleted.