Bug 1483183 - installing/removing new kernel should run grub2-mkconfig
Summary: installing/removing new kernel should run grub2-mkconfig
Alias: None
Product: Fedora
Classification: Fedora
Component: grubby
Version: 29
Hardware: Unspecified
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2017-08-19 02:15 UTC by Audrey Yeena Toskin
Modified: 2019-11-27 19:04 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-11-27 19:04:26 UTC
Type: Bug

Attachments (Terms of Use)

Description Audrey Yeena Toskin 2017-08-19 02:15:04 UTC
Description of problem:

I think package changes involving the kernel ought to run grub2-mkconfig, probably in the %posttrans section of the RPM spec. Indeed, I'd previously thought installing a new kernel already did this -- https://ask.fedoraproject.org/en/question/109802/installing-new-kernel-always-puts-new-fedora-entry-at-the-top-of-grub-menu-despite-my-custom-menu-entry/

Is there a reason why it doesn't?

Version-Release number of selected component (if applicable):

* Fedora 26 Workstation x86_64 with UEFI motherboard
* grub2-2.02-0.46.fc26
* latest kernel: 4.12.5

How reproducible: always

Steps to Reproduce:

1. I have a custom GRUB menu entry in /etc/grub.d/09_FIRST, which is supposed to appear at the top of the GRUB menu.
2. When I run system updates using dnf, the new Fedora entry with the new kernel version gets bumped to the top of the GRUB menu, unless or until I rerun grub2-mkconfig myself.

The "FIRST" menu entry *is* selected by default, because I have GRUB_DEFAULT="FIRST" in my /etc/default/grub file. But the periodic update of kernels in Fedora means that "FIRST" is not always at the *top* of the GRUB menu. My particular complaint is maybe a small issue, but the aesthetic inconsistency bugs me. The current update behavior could also be a bigger problem for users with deeper GRUB customizations.

Actual results:

New Fedora entry is always placed at the top of GRUB menu.

Expected results:

The GRUB menu created by grub2-mkconfig command should stay the same even after installing kernel updates -- unless or until I change the GRUB configuration again.

Comment 1 Audrey Yeena Toskin 2017-08-19 02:23:16 UTC
Seems like this is basically the same as Bug #1201954, except there the OP closed the issue without much detail about their issue or what their solution was.

My original post is also similar to Bug #598596, except there the issue was changing the default kernel (their issue) rather than changing the *order* of GRUB menu entries (my issue). Still, it's related in that another user was surprised to discover that kernel updates don't seem to respect the user's current GRUB configuration.

Comment 2 Laura Abbott 2018-02-28 03:50:47 UTC
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale. The kernel moves very fast so bugs may get fixed as part of a kernel update. Due to this, we are doing a mass bug update across all of the Fedora 26 kernel bugs.
Fedora 26 has now been rebased to 4.15.4-200.fc26.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
If you have moved on to Fedora 27, and are still experiencing this issue, please change the version to Fedora 27.
If you experience different issues, please open a new bug report for those.

Comment 3 Audrey Yeena Toskin 2018-03-01 01:10:26 UTC
My issue isn't about the kernel itself, but the way the kernel package is installed. I think it would be reasonable to expect the RPM spec to rerun grub2-mkconfig during %posttrans

Comment 4 Laura Abbott 2018-03-01 16:51:20 UTC
The updating of grub isn't handled by the kernel but several other packages. Moving to the appropriate package for discussion.

Comment 5 Jan Kurik 2018-08-14 10:18:26 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Comment 6 Ben Cotton 2019-10-31 20:52:15 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
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 '29'.

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 29 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.

Comment 7 Ben Cotton 2019-11-27 19:04:26 UTC
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.