Bug 1547818

Created attachment 1399096 [details]
uefi1

This is the first 7.5 build. 

RHVH had no code changes.

Is this reproducible over PXE? If not, the ISO distill root may need some tweaking. Aviv, can you check?

Created attachment 1399097 [details]
uefi2

No such issue on iscsi machine and VM. It only occurs on UEFI machine.

Can reproduce this issue with redhat-virtualization-host-4.2-20180218.0.

I built a new ISO, can you try it?

http://download-node-02.eng.bos.redhat.com/devel/candidate-trees/RHVH-4.1-20180222.15/compose/RHVH/x86_64/iso/RHVH-4.1-20180222.15-RHVH-x86_64-dvd1.iso

(In reply to Aviv Sabadra from comment #6)
> I built a new ISO, can you try it?
> 
> http://download-node-02.eng.bos.redhat.com/devel/candidate-trees/RHVH-4.1-
> 20180222.15/compose/RHVH/x86_64/iso/RHVH-4.1-20180222.15-RHVH-x86_64-dvd1.iso

Still met the same issue.
Failed to install RHVH-4.1-20180222.15-RHVH-x86_64-dvd1.iso on UEFI machine.
No such issue on VM.

Can you test with SecureBoot off?

Samantha, any guesses here?

This is built with a pungi distill from snapshot 5

(In reply to Ryan Barry from comment #8)
> Can you test with SecureBoot off?

Install RHVH-4.1-20180222.15-RHVH-x86_64-dvd1.iso & RHVH-4.1-20180218.0-RHVH-x86_64-dvd1.iso on UEFI machine both can successful after change SecureBoot off.
But so strange, no such issue on previous build RHVH-4.1-20180128.0-RHVH-x86_64-dvd1.iso even with SecureBoot enabled.

So is this a problem? It not, I will close this bug.

I'm suspecting this is somehow connected to package signing... Can you please try this one: http://download-node-02.eng.bos.redhat.com/devel/candidate-trees/RHVH-4.1-20180225.0/compose/RHVH/x86_64/iso/RHVH-4.1-20180225.0-RHVH-x86_64-dvd1.iso ?

(In reply to Aviv Sabadra from comment #11)
> I'm suspecting this is somehow connected to package signing... Can you
> please try this one:
> http://download-node-02.eng.bos.redhat.com/devel/candidate-trees/RHVH-4.1-
> 20180225.0/compose/RHVH/x86_64/iso/RHVH-4.1-20180225.0-RHVH-x86_64-dvd1.iso ?


1. Set SecureBoot off in UEFI machine
Install RHVH-4.1-20180225.0-RHVH-x86_64-dvd1.iso - Pass

2. Set SecureBoot on in UEFI machine
Install RHVH-4.1-20180225.0-RHVH-x86_64-dvd1.iso - Failed(Met the same issue like the bug's description)

Created attachment 1401216 [details]
RHEL75_Beta_UEFI_Fail

(In reply to cshao from comment #16)
> Created attachment 1401216 [details]
> RHEL75_Beta_UEFI_Fail

Makes sense, it's either a grub2 or kernel packaging mismatch error, or as designed for beta releases, need to ask the RHEL team.

(In reply to Yuval Turgeman from comment #19)
> (In reply to cshao from comment #16)
> > Created attachment 1401216 [details]
> > RHEL75_Beta_UEFI_Fail
> 
> Makes sense, it's either a grub2 or kernel packaging mismatch error, or as
> designed for beta releases, need to ask the RHEL team.

You've got the gist of it. It's somewhat as designed; the kernel is signed with test keys for beta, so you have to enroll that key if you want to enable secure boot for beta.

I think this should function as a workaround: https://access.redhat.com/solutions/2573221

(In reply to Samantha N. Bueno from comment #20)
> (In reply to Yuval Turgeman from comment #19)
> > (In reply to cshao from comment #16)
> > > Created attachment 1401216 [details]
> > > RHEL75_Beta_UEFI_Fail
> > 
> > Makes sense, it's either a grub2 or kernel packaging mismatch error, or as
> > designed for beta releases, need to ask the RHEL team.
> 
> You've got the gist of it. It's somewhat as designed; the kernel is signed
> with test keys for beta, so you have to enroll that key if you want to
> enable secure boot for beta.
> 
> I think this should function as a workaround:
> https://access.redhat.com/solutions/2573221

Nice, thanks for the link - perhaps it's a stupid question, but is there a reason that shim isn't shipped with the beta key pre enrolled somehow in beta releases ?

(In reply to Yuval Turgeman from comment #21)
> (In reply to Samantha N. Bueno from comment #20)
> > (In reply to Yuval Turgeman from comment #19)
> > > (In reply to cshao from comment #16)
> > > > Created attachment 1401216 [details]
> > > > RHEL75_Beta_UEFI_Fail
> > > 
> > > Makes sense, it's either a grub2 or kernel packaging mismatch error, or as
> > > designed for beta releases, need to ask the RHEL team.
> > 
> > You've got the gist of it. It's somewhat as designed; the kernel is signed
> > with test keys for beta, so you have to enroll that key if you want to
> > enable secure boot for beta.
> > 
> > I think this should function as a workaround:
> > https://access.redhat.com/solutions/2573221
> 
> Nice, thanks for the link - perhaps it's a stupid question, but is there a
> reason that shim isn't shipped with the beta key pre enrolled somehow in
> beta releases ?

Np, I hope that helps to alleviate some of your current pain.

That's a good question actually, and I'm not really sure why it isn't shipped with the key enrolled. My initial reaction/guess is since it's a test key, it's not something we can call official. I can try and ask around to find a more definite answer.

As a follow-up to my previous comment, it seems that the test keys are not enrolled because there is no easy way of automatically enrolling them. I don't know if that helps to explain things any further -- I wish I had a better understanding of SecureBoot myself.

(In reply to Samantha N. Bueno from comment #23)
> As a follow-up to my previous comment, it seems that the test keys are not
> enrolled because there is no easy way of automatically enrolling them. I
> don't know if that helps to explain things any further -- I wish I had a
> better understanding of SecureBoot myself.

Thanks for the update :)

Can you please retest this now that 7.5 is GA?

Test version:
redhat-virtualization-host-4.1-20180420.0
redhat-virtualization-host-4.2-20180420.0

Test result:
1. Set SecureBoot off in UEFI machine - Install - Pass
2. Set SecureBoot on in UEFI machine - Install - Pass

So the bug is fixed, change bug status to VERIFIED.

*** Bug 1631153 has been marked as a duplicate of this bug. ***

BZ<2>Jira Resync