Red Hat Bugzilla – Bug 827238
After the first kernel update on F17 final, the new kernel not appear on advanced options of menu grub
Last modified: 2013-08-01 04:54:27 EDT
Description of problem:
After the 1st kernel update, the new kernel no apper on advanced options (recovery mode etc) of grub
Version-Release number of selected component (if applicable):
F17 Final Release
yum update -y
Steps to Reproduce:
executing grub2-mkconfig -o /boot/grub2/grub.cfg is fixed, but, no all users know this
Yes, that is how it is and how grubby works - and I doubt that is considered a bug.
(In reply to comment #1)
> Yes, that is how it is and how grubby works - and I doubt that is considered
> a bug.
But that's inconsistent - I reinstalled the f17 kernel with rpm -i --force (because the first one seems failed and seems to give a bad initramfs or something) - and was rather surprised that the re-installed kernel appears as a new top level entry - rather than it continuing what appears to be the trend after upgrading to f17, hiding everything under the sub-menus. In my case since I was re-installing an existing entry by force, I would not have noticed if/whether it got added to the advanced menu, but both entry works.
Any progress on this bug report. I agree with Hin-Tak Leung that this is inconsistent.
1) It should use the "old" system, were each kernel is listed + its recovery mode.
2) The "new" method should be always used (whenever you install a new kernel, or install the system), where the title should be "Fedora linux" with the latest kernel + "Fedora Linux Rescue modes" were old kernels + the rescue modes are listed.
Obviously I prefer the new method were the grub menu won't be cluttered + it is always the same number of clicks to go to windows.
Agree with Hin-Tak Leung, and... what is the logic used for kernel updates?, if a new kernel is installed, why is not listed and booted for default?.
And, if installing it with rpm -i --force the result is other, so, is inconsistent.
Is a feature or a bug?, a think that a bug, because after a bug report for F18 Alpha and a new version of grubby, now, after update the kernel, works normally (new kernel is booted and show in grub menu entry for advanced options), refer: https://bugzilla.redhat.com/show_bug.cgi?id=858571
(In reply to comment #4)
> Agree with Hin-Tak Leung, and... what is the logic used for kernel updates?,
Please let this report stay on topic.
(In reply to comment #5)
> (In reply to comment #4)
> > Agree with Hin-Tak Leung, and... what is the logic used for kernel updates?,
> Please let this report stay on topic.
Is a bug or is normal?, rpm -ivh and yum update no same result after reboot.
Mads Kiilerich you say that is the normal function of grubby, is right or not?
(In reply to comment #6)
Installing with rpm and yum do give the same result. rpm --force might give something else when the kernel already partly exists. That is however not at all relevant for this report. Please discuss or file it elsewhere.
I have exactly the same problem with Fedora 18.
Why don't add 'grub2-mkconfig -o /boot/grub2/grub.cfg' in the post-install scipt for each kernel packages?
(In reply to comment #9)
> Why don't add 'grub2-mkconfig -o /boot/grub2/grub.cfg' in the post-install
> scipt for each kernel packages?
Because that is a different way of doing it, with different advantages and disadvantages.
One disadvantage is that it would do the slow and complex and error-prone probing for other OS's every time and it could be considered more likely to break the configuration.
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. 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 WONTFIX if it remains open with a Fedora
'version' of '17'.
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 prior to Fedora 17's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 17 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 to Fedora 17's end of life.
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.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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.
Thank you for reporting this bug and we are sorry it could not be fixed.