Bug 1492145
| Summary: | F27AH UEFI installs drop into shim key management | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Colin Walters <walters> |
| Component: | grub2 | Assignee: | Peter Jones <pjones> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 27 | CC: | bcl, dustymabe, gen.work, lkundrak, pjones, tgvita, vidar.akselsen, walters |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-09-21 00:35:53 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Colin Walters
2017-09-15 15:18:26 UTC
(This could obviously be a bug anywhere in the anaconda/ostree/grub/shim/etc. stack, sticking here since I don't know yet) 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 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.
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. or rather since this particular tree is targeting 64 bit we should just name grub2-efi-x64 Thanks for debugging this Peter and Dusty! Indeed the fix is simple: https://pagure.io/fedora-atomic/pull-request/84 we should move this bug to a more appropriate component 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) 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. @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. (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. 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. Note this bug was filed against an atomic host. Please open a new bug to report a problem occurring on non atomic hosts. |