Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1492145 - F27AH UEFI installs drop into shim key management
Summary: F27AH UEFI installs drop into shim key management
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-15 15:18 UTC by Colin Walters
Modified: 2018-03-09 14:04 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-21 00:35:53 UTC
Type: Bug


Attachments (Terms of Use)

Description Colin Walters 2017-09-15 15:18:26 UTC
BIOS installs of Fedora 27 Atomic Host are fine, but UEFI installs drop into "Shim UEFI key management", there's a screen shot here:

https://openqa.fedoraproject.org/tests/142198#step/_console_wait_login/3

Comment 1 Colin Walters 2017-09-15 15:19:03 UTC
(This could obviously be a bug anywhere in the anaconda/ostree/grub/shim/etc. stack, sticking here since I don't know yet)

Comment 2 Dusty Mabe 2017-09-17 21:38:59 UTC
I can confirm I can reproduce this with an Atomic Host iso. This is the one I used: https://kojipkgs.fedoraproject.org/compose/branched/Fedora-27-20170915.n.0/compose/Atomic/x86_64/iso/Fedora-Atomic-ostree-x86_64-27-20170915.n.0.iso

Comment 3 Peter Jones 2017-09-18 19:03:27 UTC
I think this means you've got some Mok variables set in UEFI that shouldn't be?  Boot the machine to linux and check /sys/firmware/efi/efivars/ for any variables starting with: "Mok" ; if they're there, do:

chattr -i ${MOK_VAR_NAME}
rm ${MOK_VAR_NAME}

And see if you still get this upon reboot.

Comment 4 Dusty Mabe 2017-09-18 21:06:57 UTC
got with pjones this afternoon and he helped narrow down the problem. You can see from the log https://openqa.fedoraproject.org/tests/142198/file/serial0.txt

```
Failed to load image \EFI\fedora\grubx64.efi: Not Found
```

It turns out we have the grub2-efi-ia32 rpm installed when we should have the grub2-efi-x64 rpm installed. According to peter jones anaconda would detect and install the right one but since we are using ostree we probably just need to install both of them in the tree.

Comment 5 Dusty Mabe 2017-09-18 21:22:17 UTC
or rather since this particular tree is targeting 64 bit we should just name grub2-efi-x64

Comment 6 Colin Walters 2017-09-19 21:32:09 UTC
Thanks for debugging this Peter and Dusty!  Indeed the fix is simple:

https://pagure.io/fedora-atomic/pull-request/84

Comment 7 Dusty Mabe 2017-09-19 22:04:05 UTC
we should move this bug to a more appropriate component

Comment 8 Dusty Mabe 2017-09-21 00:35:53 UTC
ok with the following commits:

- https://pagure.io/fedora-atomic/pull-request/84 (rawhide)
- https://pagure.io/fedora-atomic/pull-request/85 (f27)

We have fixed this issue. Passing openqa tests for last nights run:

- https://openqa.fedoraproject.org/tests/144987 (rawhide)
- https://openqa.fedoraproject.org/tests/145178 (f27)

Comment 9 Vidar Akselsen 2017-11-16 18:30:08 UTC
I was also dropped into shim key management on two distinct systems after doing a "dnf upgrade" followed by "dnf autoremove" and a reboot. Both systems where upgraded from F26. I believe both systems where using UEFI boot and gpt. The first system AMD Athlon 5350 based PC and the other a Lenovo t440p laptop (Intel) with secureboot disabled.

Comment 10 Eugene Leonovich 2018-01-09 16:06:16 UTC
@Vidar Akselsen I run into the same issue after doing "dnf autoremove". After reading the comments above I fixed it by installing the "grub2-efi-x64" package.

Comment 11 Vidar Akselsen 2018-01-09 20:14:33 UTC
(In reply to Eugene Leonovich from comment #10)
> @Vidar Akselsen I run into the same issue after doing "dnf autoremove".
> After reading the comments above I fixed it by installing the
> "grub2-efi-x64" package.

Thank you for the reply. Since I couldn't boot and reinstall any packages I ended up booting a live DVD, mounting the boot partition and copied most contents of the live DVD efi boot files to the hard disk.

Comment 12 tgvita 2018-03-09 06:41:04 UTC
Met this problem too, very same symptoms, I'm sure this is caused by 'dnf autoremove' command, I suspect that it removed some important package like shim unintendedly.

Comment 13 Dusty Mabe 2018-03-09 14:04:00 UTC
Note this bug was filed against an atomic host. Please open a new bug to report a problem occurring on non atomic hosts.


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