Description of problem: When using grub2-mkconfig, it produces a grub.cfg that does not save the most recently user selected menu entry. Instead it uses a previously saved entry which cannot be changed unless manually running grub2-set-default or grub2-reboot. Version-Release number of selected component (if applicable): Fedora 17 Alpha LiveCD Also affects all of Fedora 16. How reproducible: Always Steps to Reproduce: 1. Boot to GRUB menu. 2. Choose an entry that is not a recovery entry. 3. Reboot to GRUB. Actual results: Chosen kernel entry is not the default. Even after a kernel update, and running grub2-mkconfig to write out a new grub.cfg, the new kernel entry is not chosen by default and won't ever be the default, even after choosing it in the GRUB menu. A prior grubenv menu entry is chosen instead due to /etc/default/grub: GRUB_DEFAULT=saved Expected results: I expect a new grub.cfg produced by grub2-mkconfig to save the most recent user selected menu entry as the default for next boot. Additional info: This can be solved by adding a line to /etc/default/grub: GRUB_SAVEDEFAULT=true
I think this is obviated by new behavior in GRUB 1.99-19.fc17 a.k.a 2.00~beta2. Plus grub devs told me that Recovery entries are exempt from being saved default.
Why do you want / expect the GRUB_SAVEDEFAULT behaviour? Fedora never worked that way, AFAIK. The /etc/default/grub in f17 grub2 do include GRUB_SAVEDEFAULT=true. It is however usually overwritten by anaconda. I do however tend to consider it a bug that it is set in the grub2 package. It will only work correctly if /boot is on a plain disk without LVM/RAID and it can thus not be considered a reliable feature. (Fedora should "normally" (whatever that means) select a new kernel version as default when it is installed. That seems to be slightly broken - but that is a different issue, right?)
This bug should be closed, I think. I was basing this on GRUB 1.99 behavior, not 2.00 beta 2 behavior, which I vastly, vasty prefer. In fact I now consider grubby's behavior to be the "bug" as it litters the GRUB menu with independent entries, and makes things sloppy. Instead I think grubby should call grub2-mkconfig and have it write out a new grub.cfg after kernel is updated.
Ok - then we close it. The bug that grubby exists at all will be a separate issue ;-) FWIW I agree that new-kernel-pkg invoking grub2-mkconfig probably would be a lesser evil, but I am also no big fan of having tighter dependency on the monstrous grub shell scripts and do file system probing as a side effect of package installation.
Well in that case we need a different bootloader, if GRUB2 is seen as just too unwieldy and complex - a characterization I'd probably agree with.