Bug 1650707

Created attachment 1506568 [details]
anaconda log

Created attachment 1506569 [details]
dnf.librepo.log

Created attachment 1506570 [details]
hawkey.log

Created attachment 1506571 [details]
packaging.log

Created attachment 1506572 [details]
program.log

Javier: your changes on November 12th (grubby-8.40-20) has broken ARMv7

I thought the whole point, or at least one of them, of BLS is that grubby isn't needed at all, so I wonder why these changes were even necessary?

Hello Peter,

(In reply to Peter Robinson from comment #6)
> Javier: your changes on November 12th (grubby-8.40-20) has broken ARMv7

I thought that on F29 ARMv7 already migrated to grub2 by chain-loading from u-boot as mentioned in https://fedoraproject.org/wiki/Changes/uEFIforARMv7.

Since in Rawhide / F30 we now default to BLS, the latest changes in the grubby package move the old grubby tool and the new-kernel-pkg script to the grubby-deprecated package.

But if the plan is to keep using u-boot / extlinux for ARMv7 in F30, then we should make the grubby-deprecated package to be installed for this platform.

(In reply to Peter Robinson from comment #7)
> I thought the whole point, or at least one of them, of BLS is that grubby
> isn't needed at all, so I wonder why these changes were even necessary?

That's correct. As mentioned the change was to move the old grubby binary and the new-kernel-pkg script to a grubby-deprecated package. The grubby package now contains a grubby wrapper (grubby-bls) script that implements all the old grubby options but instead of modifying bootloader config files, it modifies the BLS snippets.

We did this for backward compatibility reasons, to support grubby users.

Created attachment 1506789 [details]
PATCH] Install grubby-deprecated when using the extlinux bootloader

I think we need the attached patch for Anaconda so the grubby-deprecated package is installed when using the extlinux bootloader.

I couldn't test it because don't have an ARMv7 board now, but I can test it next week.

Created attachment 1506801 [details]
[PATCH] Install grubby-deprecated package for ARMv7

As pointed out by Peter Robinson, the Anaconda changes are not enough and Lorax also needs to know that the grubby-deprecated package is needed for ARMv7.

Attached patch for Lorax as well.

Also proposed upstream pull-request for lorax and anaconda:

https://github.com/weldr/lorax/pull/527

https://github.com/rhinstaller/anaconda/pull/1693

Broadcom Emulex team is also seeing this bug.  When can we expect a fix?

Laurie

(In reply to Laurie Barry from comment #13)
> Broadcom Emulex team is also seeing this bug.  When can we expect a fix?
> 
> Laurie

What architecture?  Was this on ARM?  And is this on Fedora, or RHEL8, or both?

(In reply to Ewan D. Milne from comment #14)
> (In reply to Laurie Barry from comment #13)
> > Broadcom Emulex team is also seeing this bug.  When can we expect a fix?
> > 
> > Laurie
> 
> What architecture?  Was this on ARM?  And is this on Fedora, or RHEL8, or
> both?

This was on an earlier Snapshot of RHEL 8 on x86_64. I have not retested using Snapshot 4.

(In reply to ricky.armas from comment #15)
> (In reply to Ewan D. Milne from comment #14)
> > (In reply to Laurie Barry from comment #13)
> > > Broadcom Emulex team is also seeing this bug.  When can we expect a fix?
> > > 
> > > Laurie
> > 
> > What architecture?  Was this on ARM?  And is this on Fedora, or RHEL8, or
> > both?
> 
> This was on an earlier Snapshot of RHEL 8 on x86_64. I have not retested
> using Snapshot 4.

OK, thank you, please reply the kernel version you used and I will clone this for RHEL8.

(In reply to Ewan D. Milne from comment #16)
> (In reply to ricky.armas from comment #15)
> > (In reply to Ewan D. Milne from comment #14)
> > > (In reply to Laurie Barry from comment #13)
> > > > Broadcom Emulex team is also seeing this bug.  When can we expect a fix?
> > > > 
> > > > Laurie
> > > 
> > > What architecture?  Was this on ARM?  And is this on Fedora, or RHEL8, or
> > > both?
> > 
> > This was on an earlier Snapshot of RHEL 8 on x86_64. I have not retested
> > using Snapshot 4.
> 
> OK, thank you, please reply the kernel version you used and I will clone
> this for RHEL8.

Please don't clone this for RHEL8. The fact that they are getting the same "DNF error: Error in POSTTRANS scriptlet in rpm package kernel-core" error message, doesn't mean that it's the same bug. That just tells that some scriptlet failed but doesn't say much about the actual cause of the failure.

This particular bug is about the grubby tool not being installed by default on Fedora and ARMv7 requiring grubby to add new kernel entries to the extlinux.conf file. That's not the case for RHEL8 since ARMv7 is not a supported architecture. So this definitely bug is not related to neither RHEL8 nor x86_64.

Also, if the scriptlet is failing probably is due kernel-install scripts that are installed by grub2-common. There were many bugs fixed on the grub2 package on recent snapshots, so I would first check if the issue is still reproduced with the latest snapshot.

(In reply to Paul Whalen from comment #0)
> Description of problem:
> 
> armhfp rawhide installation currently fail with:
> 
> ..
> Configuring authselect-compat.armv7hl
> Configuring kernel-core.armv7hl
> =============================================================================
> ===
> =============================================================================
> ===
> Error
> 
>    The following error occurred while installing.  This is a fatal error and
>    installation will be aborted.
>    
>    DNF error: Error in POSTTRANS scriptlet in rpm package kernel-core
> 
> 
> Version-Release number of selected component (if applicable):
> grubby-8.40-20.fc30.armv7hl.rpm
> 
> How reproducible:
> Everytime

Is this problem still happening? I think that it should had been fixed by Anaconda installing grubby-deprecated when using the extlinux bootloader:

https://github.com/rhinstaller/anaconda/commit/da7c834a83b

This was fixed before the end of 2018 with the referenced commit, thanks Javier!

fyi Broadcom Emulex is no longer seeing this as of Snapshot 4.  

thx
Laurie

On Thu, Jan 31, 2019 at 4:01 PM Ricky Armas <ricky.armas> wrote:
I tested on RHEL 8 SS4. Whatever was causing the issue, it is now fixed.

-Ricky

(In reply to Laurie Barry from comment #20)
> fyi Broadcom Emulex is no longer seeing this as of Snapshot 4.  
> 
> thx
> Laurie
> 
> On Thu, Jan 31, 2019 at 4:01 PM Ricky Armas <ricky.armas> wrote:
> I tested on RHEL 8 SS4. Whatever was causing the issue, it is now fixed.
> 
> -Ricky

OK, thank you for retesting.