When upgrading a F17 system to F18 using fedup (latest from git or packaged versions), the grub installation on the system isn't upgraded to the same version that it would be at for a fresh install of F18 I haven't noticed any problems in the upgraded system that I can directly attribute to the old grub2 version but the installed grub probably should be upgraded on the target system. Workaround: grub2-install <target_device> grub2-mkconfig -o /boot/grub2/grub.cfg
Ah! Here is a perfect example of something that should be handled by a system-upgrade dracut module provided by the relevant package. Basically, any dracut module named 'system-upgrade-*' will be pulled into the upgrade image when they get built. The upgrade image provides the normal dracut hooks, plus "upgrade-pre", "upgrade", and "upgrade-post". During all of those hooks, the target system is mounted at $NEWROOT. Using these hooks, developers should be able to perform any migration tasks that might be necessary during an upgrade. In this particular case, grub2 would probably want to run a script during "upgrade-post", which did something like: 1) check the existing grub installation to see if it needs upgrading 2) figure out what options are needed for grub2-install and grub2-mkconfig 3) run the needed commands It should probably also honor a commandline flag or other signal from the user to leave the the bootloader alone. Any output from the script ends up in the journal, so logging is handled automatically. And that's about it! I'm happy to help with the dracut-specific bits. The rest is, generally, up to the relevant package maintainers or anyone else with the necessary expertise.
I think the right thing to do here (on BIOS systems and other places that the bootloader isn't just a file in the FS) is actually to let grubby do the normal updates in kernel's %post and let the user upgrade their bootloader if they have a reason to. The installed bootloader is known to be working. This is the approach we already take e.g. for bootloader updates via yum.
Does this still hold true for the grub1 to grub2 transition for F18? There are some side-effects of upgrading without changing the bootloader installed on the system. The one I'm aware of ATM is the removal of the grub splash (see https://bugzilla.redhat.com/show_bug.cgi?id=857523) which isn't that bad on the grand scheme of things. How did we handle the grub1 -> grub2 transition for BIOS systems during upgrade?
(In reply to comment #1) > 1) check the existing grub installation to see if it needs upgrading grub2 is much more complex and much less mature than grub1. It is thus in my opinion a very good idea to "upgrade" the grub installation regularly. Doing it at each OS upgrade seems to be a good approximation. There is a lot of known issues in grub2. Some of them will be solved by the f18 grub2, and we can hope others will be solved in f19. All systems thus always "needs" upgrading. One reason is that users expect "getting" the fixes in the new release. Another and more important reason is that it is impossible to "support" grub2 in a scenario where we don't know which grub2 version fXX users are using. > 2) figure out what options are needed for grub2-install and grub2-mkconfig What options to use - and where to install grub - can not be known for sure. That is essentially Bug 740953 "RFE: Provide command to easily update grub.cfg". That is why anaconda asked/informed the user about where to install the boot loader so the user could be blamed if it did the wrong thing. Doing the boot loader upgrade/installation in dracut requires more input than just a skip flag. (In reply to comment #2) > I think the right thing to do here (on BIOS systems and other places that > the bootloader isn't just a file in the FS) What is implied here is that the active grub2 efi is updated immediately when a new grub2-efi.rpm is installed. Regressions will render the system unbootable. There will only be one bootloader and it is not _known_ to be working. New dependencies to /boot/grub2 content (usually installed by grub2-install) or grub.cfg (usually created by grub2-mkconfig) will not be resolved. For the record and for what it's worth: I think it is very unfortunate that the architectures are treated differently. I consider the BIOS approach much better and more reliable than the EFI approach. If we have to ship prebuilt and signed .efi's then they should be shipped under /usr and installed to the right location by grub2-install. (In reply to comment #3) > How did we handle the grub1 -> grub2 transition for BIOS systems during > upgrade? anaconda made boot loader installation mandatory.
*** Bug 882534 has been marked as a duplicate of this bug. ***
As a very minor sequel to this bug report, a fresh install gets a prettified grub menu, while an upgrade via fedup gets the old one.
The maintainers of grub/grub2 have decided to not make it automatically upgrade systems to grub2 during updates, so fedup is working as intended here.