[This post was drafted on the day Fedora 27 released, about half a year ago, but was not published. The issue bit me again with Fedora 28, so documenting it for referring next time.]
UPDATE: The issue occurred in Fedora 28 because I had
/etc/dnf/dnf.conf which is the reason error “nothing provides grub2-tools” was coming up. Removing that previously added and then forgotten line fixes the issue with updating
fedup and subsequently
dnf improving the upgrade experience of Fedora for power users, last few system upgrades have been smooth, quiet, even unnoticeable. That actually speaks volumes of the maturity and user friendliness achieved by these tools.
Upgrading from Fedora 25 to 26 was so event-less and smooth (btw: I have installed and used every version of Fedora from its inception and the default wallpaper of Fedora 26 was the most elegant of them all!).
With that, on the release day I set out to upgrade the main workstation from Fedora 26 to 27 using
dnf system-upgrade as documented. Before downloading the packages, dnf warned that upgrade cannot be done because of package dependency issues with
Things go wrong!
I simply removed both the offending packages and their dependencies (assuming were probably installed for the
grub2-breeze-theme dependency, but
grub2-tools actually provides
grub2-mkconfig) and proceeded with
dnf upgrade --refresh and
dnf system-upgrade download --refresh --releasever=27. If you are attempting this, don’t remove the grub2 packages yet, but read on!
Once the download and check is completed, running
dnf system-upgrade reboot will cause the system reboot to upgrade target and actual upgrade happen.
Except, I was greeted with EFI MOK (Machine Owner Key) screen on reboot. Now that the grub2 bootloader is broken thanks to the removal of
grub2-efi-modules and other related packages, a recovery must be attempted.
It is important to have a (possibly EUFI enabled) live media where you can boot from. Boot into the live media and try to reinstall grub. Once booted in, mount the root filesystem under
/mnt/sysimage, and EFI boot partition at
chroot /mnt/sysimage and try to reinstall
shim packages. If there’s no network connectivity, don’t despair,
nmcli is to your rescue. Connect to wifi using
nmcli device wifi connect <ssid> password <wifi_password>. Generate the boot configuration using
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg followed by actual install
grub2-install --target=x86_64-efi /dev/sdX (the –target option ensures correct host installation even if the live media is booted via legacy BIOS). You may now reboot and proceed with the upgrade.
But this again failed at the upgrade stage because of
grub package clash that
dnf warned earlier about.
Once booted into old installation, take a backup of the
/boot/ directory, remove the conflicting
grub related packages, and copy over the backed up
/boot/ directory contents, especially
/boot/efi/EFI/fedora/grubx64.efi. Now rebooting (using
dnf system-upgrade reboot) had the grub contents intact and the upgrade worked smoothly.
For more details on the package conflict issue, follow this bug.