As things currently stand in Rawhide, the way https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault has been implemented assumes existing systems are converted to BLS on upgrade. There is a grubby %post to do this: %post if [ "$1" = 2 ]; then arch=$(uname -m) if [[ $arch == "s390x" ]]; then command=zipl-switch-to-blscfg else command=grub2-switch-to-blscfg fi $command --backup-suffix=.rpmsave &>/dev/null || : fi and after upgrade, the old, non-BLS compatible bits of grubby will not be present on the system, as they are in grubby-deprecated and that package will not be installed on upgrade. However, this will break 32-bit ARM systems on upgrade, AIUI. These use extlinux, which has not been made BLS-compatible. There is a proposed Change to switch to UEFI for new 32-bit ARM installs: https://fedoraproject.org/wiki/Changes/uEFIforARMv7 however, that does not propose to 'convert' existing installs: "Upgrades from prior versions of Fedora will continue to work as they do currently. Devices booting with extlinux will continue to upgrade and work as planned." So on upgrade to F30, 32-bit ARM systems will still be set up with extlinux, which will not be BLS-compatible...but grubby-deprecated will not be installed. So kernel updates will not work. One way to handle this, I guess, would be to have grubby-deprecated Obsolete grubby < 8.40-18 "%ifarch %{arm}" in the spec. That should ensure it gets installed on upgrade. If we do later make extlinux BLS-compatible, or in some other way render existing 32-bit ARM installs BLS-compatible on upgrade, we can have a later version of grubby Obsolete grubby-deprecated, or something. Proposing as a Beta blocker per the upgrade criteria and the update criteria - an upgraded 32-bit ARM system will not handle subsequent kernel updates correctly.
(In reply to Adam Williamson from comment #0) > As things currently stand in Rawhide, the way > https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault has been > implemented assumes existing systems are converted to BLS on upgrade. There > is a grubby %post to do this: > > %post > if [ "$1" = 2 ]; then > arch=$(uname -m) > if [[ $arch == "s390x" ]]; then > command=zipl-switch-to-blscfg > else > command=grub2-switch-to-blscfg > fi > > $command --backup-suffix=.rpmsave &>/dev/null || : > fi > > and after upgrade, the old, non-BLS compatible bits of grubby will not be > present on the system, as they are in grubby-deprecated and that package > will not be installed on upgrade. > Note that this will only be the case for architectures that either have grub2-tools (for grub2-switch-to-blscfg) or s390utils (for zipl-switch-to-blscfg) installed. On armhfp no conversion will happen and the %post scriptlet will be a no-op. > However, this will break 32-bit ARM systems on upgrade, AIUI. These use > extlinux, which has not been made BLS-compatible. There is a proposed Change > to switch to UEFI for new 32-bit ARM installs: > > https://fedoraproject.org/wiki/Changes/uEFIforARMv7 > > however, that does not propose to 'convert' existing installs: > > "Upgrades from prior versions of Fedora will continue to work as they do > currently. Devices booting with extlinux will continue to upgrade and work > as planned." > > So on upgrade to F30, 32-bit ARM systems will still be set up with extlinux, > which will not be BLS-compatible...but grubby-deprecated will not be > installed. So kernel updates will not work. > > One way to handle this, I guess, would be to have grubby-deprecated Obsolete > grubby < 8.40-18 "%ifarch %{arm}" in the spec. That should ensure it gets Another option is to make syslinux-extlinux depend on grubby-deprecated, which seems to be the correct think to do since it relies on new-kernel-pkg and the old grubby to update the boot entries in the extlinux.conf file. I see there isn't a dependency on grubby now, but I think that's a bug since without grubby the boot entries won't be updated. > installed on upgrade. If we do later make extlinux BLS-compatible, or in > some other way render existing 32-bit ARM installs BLS-compatible on > upgrade, we can have a later version of grubby Obsolete grubby-deprecated, > or something. > By making syslinux-extlinux to depend on grubby-deprecated, if we later switch existing armhfp installations to grub2 or something then the syslinux-extlinux cold be removed by making grub2-efi to Obsolete syslinux-extlinux. This will also make grubby-deprecated to be uninstalled due the unused dependencies. > Proposing as a Beta blocker per the upgrade criteria and the update criteria > - an upgraded 32-bit ARM system will not handle subsequent kernel updates > correctly. Agreed.
Created a pull-request to extlinux-bootloader package to add the dependency: https://src.fedoraproject.org/rpms/extlinux-bootloader/pull-request/2
Aha, yes, that makes perfect sense. Good idea.
1.2-7.fc30 is built now, so let's go ahead and close this, it ought to be fixed.