Description of problem: After installation of a new kernel I have and entry in grub.cfg menuentry 'Fedora (3.1.1-2.fc16.x86_64)' --class gnu-linux --class gnu --class os { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='(hd0,msdos1)' search --no-floppy --fs-uuid --set=root a5af04f3-89b1-471c-b883-9e481614f986 echo 'Loading Fedora (3.1.1-2.fc16.x86_64)' linux /vmlinuz-3.1.1-2.fc16.x86_64 root=UUID=4389faaa-68e7-40cf-cd19-fa55c1b49531 ro SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 K EYTABLE=us echo 'Loading initial ramdisk ...' initrd /initramfs-3.1.1-2.fc16.x86_64.img } When I regenerate the config with grub2-mkconfig I have. menuentry 'Linux, with Linux 3.1.1-2.fc16.x86_64' --class gnu-linux --class gnu --class os { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='(hd0,msdos1)' search --no-floppy --fs-uuid --set=root a5af04f3-89b1-471c-b883-9e481614f986 echo 'Loading Linux 3.1.1-2.fc16.x86_64 ...' linux /vmlinuz-3.1.1-2.fc16.x86_64 root=UUID=4389faaa-68e7-40cf-cd19-fa55c1b49531 ro echo 'Loading initial ramdisk ...' initrd /initramfs-3.1.1-2.fc16.x86_64.img } Also on a kernel removal, there are removed all the section below /etc/grub.d/10_linux section like a xen, custom, persistent... BTW: grub2-mkconfig ignores GRUB_DISABLE_LINUX_RECOVERY=true in /etc/default/grub. I am getting somewhat lost what is broken here.. Version-Release number of selected component (if applicable): grub2-1.99-12.fc16.x86_64 How reproducible: Always. Steps to Reproduce: Install and remove kernel package, compare to grub.cfg generated by grub2-mkconfig.
In my case everything was correct except the message "Loading ..." still said 3.1.1-1 rather than 3.1.1-2 although the actual image was 3.1.1-2.
Try GRUB_DISABLE_RECOVERY="true" The problem with the "Loading" message is bug 732654.
It is not just the message (beside the menu entry name), also options for the kernel are different. GRUB_DISABLE_RECOVERY compared to GRUB_DISABLE_LINUX_RECOVERY works, but it is somehow not according to doc flying around.
GRUB_DISABLE_LINUX_RECOVERY was dropped upstream a year ago: 2010-10-12 Robert Millan <rmh> * util/grub-mkconfig.in: Merge `GRUB_DISABLE_LINUX_RECOVERY' and `GRUB_DISABLE_NETBSD_RECOVERY' into a single `GRUB_DISABLE_RECOVERY' variable. All references updated. Please keep one issue in each bug report. If you see other issues not already reported ( https://admin.fedoraproject.org/pkgdb/acls/bugs/grub2 ) then please file separate bug reports.
Thanks for the point about option being dropped. This was however just a side note, please focus on the subject - grub2-mkconfig and kernel install/remove generate a different menuentry. This has nothing to do with recovery.
You are referring to the menuentry title?
Comment 3: "also options for the kernel are different."
The options for new kernels are cloned from the "best" existing kernel entry. The origin for the options like SYSFONT is that your /etc/default/grub contained a GRUB_CMDLINE_LINUX setting with these values, created by anaconda. It called grub2-mkconfig which put these values in your grub.cfg. If running grub2-mkconfig create different entries now then it is because your /etc/default/grub has changed.
I probably do not understand correctly. This is my $ more /etc/default/grub GRUB_CMDLINE_LINUX="" GRUB_DISABLE_RECOVERY="true" I did not used anaconda for several years... grub2-mkconfig does not create a menuentry with those missing options SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us The "Fedora" menuentry is created during kernel installation (by grubby?). The "Linux" menuentry is created with grub2-mkconfig. I do not know why the kernel installation takes them, but grub2-mkconfig does not. If you think the grub2-mkconfig is right, then this bug may belong to grubby.
(In reply to comment #9) > I did not used anaconda for several years... How was the system installed/upgraded? How was the initial grub2 configuration created? > grub2-mkconfig does not create a menuentry with those missing options > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us It will if you have GRUB_CMDLINE_LINUX="SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us" > If you think the grub2-mkconfig is right, then this bug may belong to grubby. No. Grubby just created a new entry by cloning another entry which also didn't have these extra options. I am sure grubby is innocent here. There is no indications of any bug. Everything you have described is expected and correct behaviour. The only source of confusion is that your /etc/default/grub has changed.
I am curious about this behavior as well. When I perform a kernel update (nearly weekly), I do not expect that even though I have edited /etc/default/grub to read as follows: GRUB_DEFAULT="Windows 7 (loader) (on /dev/sda1)" that yum/grubby/whatever will decide to make the new kernel the default boot target. It clearly doesn't use /etc/default/grub when (re)creating /boot/grub2/grub.cfg - which also seems wrong to me. It would be like selinux, or BIND, or anything else ignoring a system configuration. Now, perhaps there is a different configuration location I should be changing so that yum/grubby/whatever will not 'misbehave'; but, as yet, I have found no documentation to indicate that this is the case.
(In reply to comment #11) What you are describing is not the bug reported here - it might be more like Bug 768106 - grubby does not support grub2 set default="${saved_entry}" and replaces with "0"
I am having the Description-section problem in F17: installation of new kernel results in a /boot/grub2/grub.cfg that is very different from what grub2-mkconfig would generate: # grub2-mkconfig 2> /dev/null | diff -uw /boot/grub2/grub.cfg - | diffstat - | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 50 insertions(+), 13 deletions(-) I can post the diff, but it's a mix of #768106, single-to-double quotes, and more serious differences including something that results in a grub2.conf that requests a keystroke from the user before booting, which really sucks for my headless offsite server if I forget to run grub2-mkconfig before a reboot. I am not editing /boot/grub2/grub.cfg by hand (I'm using 40_custom and /etc/default/grub). Should I file another bug, request this bug be changed to apply to F17 (at least, possibly rawhide), or educate myself as to something I've missed? A bit more info in case it helps: # cat /etc/fedora-release ; rpm -q kernel grubby | tail -2 Fedora release 17 (Beefy Miracle) kernel-3.6.5-1.fc17.x86_64 grubby-8.12-1.fc17.x86_64
Several issues has been mentioned in this report. Some of them has been fixed in f17. To avoid a too confusing mess I will close this issue. Please file new separate issues (after checking for duplicates) for any issues you may have with f17. Keep in mind that if grubby patches grub.cfg incorrectly then it is most likely a grubby issue, not a grub2 issue.