Bug 1654841 - 32-bit ARM systems upgraded from <F30 to >=F30 will have non-BLS bootloader, but grubby-deprecated will not be installed
Summary: 32-bit ARM systems upgraded from <F30 to >=F30 will have non-BLS bootloader, ...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: grubby
Version: rawhide
Hardware: armv7hl
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F30BetaBlocker 1598523
TreeView+ depends on / blocked
 
Reported: 2018-11-29 19:43 UTC by Adam Williamson
Modified: 2018-12-17 17:42 UTC (History)
6 users (show)

Fixed In Version: extlinux-bootloader-1.2-7.fc30
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-12-17 17:42:53 UTC
Type: Bug


Attachments (Terms of Use)

Description Adam Williamson 2018-11-29 19:43:55 UTC
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.

Comment 1 Javier Martinez Canillas 2018-11-30 11:14:09 UTC
(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.

Comment 2 Javier Martinez Canillas 2018-11-30 14:34:49 UTC
Created a pull-request to extlinux-bootloader package to add the dependency:

https://src.fedoraproject.org/rpms/extlinux-bootloader/pull-request/2

Comment 3 Adam Williamson 2018-11-30 17:38:20 UTC
Aha, yes, that makes perfect sense. Good idea.

Comment 4 Adam Williamson 2018-12-17 17:42:53 UTC
1.2-7.fc30 is built now, so let's go ahead and close this, it ought to be fixed.


Note You need to log in before you can comment on or make changes to this bug.