Bug 1474861
Summary: | 32 bit UEFI Support | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jan Kurik <jkurik> |
Component: | Changes Tracking | Assignee: | Peter Jones <pjones> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 28 | CC: | 8ru2u4gz, klember, mikhail.v.gavrilov, mirh, pjones, randy, rfarmer84, rharwood, samuel-rhbugs |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | ChangeAcceptedF27, SystemWideChange | ||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-04-24 14:10:22 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jan Kurik
2017-07-25 14:03:22 UTC
On 2017-Aug-01, we have reached the Fedora 27 Change Checkpoint: Completion deadline (testable). At this point, all accepted changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be enabled at Change Completion deadline as well. Change tracking bug should be set to the MODIFIED state to indicate it achieved completeness. Incomplete and non testable Changes will be reported to FESCo for 2017-Aug-11 meeting. Please set this bug to the MODIFIED state to indicate it is already in the testable state, or provide an update describing the current state of implementation for this Change. Thank you, Jan Deferring. Please resubmit the Change proposal for review to Change wrangler once this is ready. For more info check https://pagure.io/fesco/issue/1760#comment-457211 This is testable on non-secure-boot machines with this copr: https://copr.fedorainfracloud.org/coprs/pjones/efi32cpu64/builds/ And I'll be able to merge it as soon as https://bugzilla.redhat.com/show_bug.cgi?id=1483014 is done. We discussed it in the FESCo meeting yesterday and agreed to allow this as a late exception: * AGREED: Include 32bit UEFI Support in F27 (+1:5, 0:0, -1:0) (kalev, 16:19:16) https://meetbot.fedoraproject.org/fedora-meeting/2017-08-18/fesco.2017-08-18-16.00.log.html This is mostly done: gnu-efi is done shim-unsigned-x64 is done shim-unsigned-aarch64 is done (wish I had named this aa64 but oh well) lorax is done anaconda is done shim-signed is in the works - right now it has the shim-0.8 /boot/efi/EFI/fedora/shimx64.efi that's signed by MS, and I'll swap out the new one once signing happens. At that point I'm also going to deadpkg this package and move it into the "shim" package, fixing our ages old naming goof. On 2017-Sep-05 we reached the "Change Checkpoint: 100% Code Complete Deadline" milestone for Fedora 27 release. At this point all the Changes not at least in "ON_QA" state should be brought to FESCo for review. Please update the state of this bug to "ON_QA" if it is already 100% completed. Please let me know in case you have any trouble with the implementation and the Change needs any help or review. Thanks, Jan (In reply to Peter Jones from comment #5) > This is mostly done: > > gnu-efi is done > shim-unsigned-x64 is done > shim-unsigned-aarch64 is done (wish I had named this aa64 but oh well) > lorax is done > anaconda is done > shim-signed is in the works - right now it has the shim-0.8 > /boot/efi/EFI/fedora/shimx64.efi that's signed by MS, and I'll swap out the > new one once signing happens. At that point I'm also going to deadpkg this > package and move it into the "shim" package, fixing our ages old naming goof. Just to be clear, is this the reason why in Fedora 27, I have two entries that say "Fedora", and I end up getting this when I ask efibootmgr what's going on? $ efibootmgr -v BootCurrent: 0001 Timeout: 0 seconds BootOrder: 0001,0000,2001,2002,2003 Boot0000* Fedora HD(1,GPT,7f5ff969-0902-4306-8441-cc26c5282b55,0x800,0x64000)/File(\EFI\fedora\shim.efi)RC Boot0001* Fedora HD(1,GPT,7f5ff969-0902-4306-8441-cc26c5282b55,0x800,0x64000)/File(\EFI\fedora\shimx64.efi) Boot2001* EFI USB Device RC Boot2002* EFI DVD/CDROM RC Boot2003* EFI Network RC I thought I was losing my mind or that my firmware was doing something bogus. Thanks! (In reply to Ryan Farmer from comment #7) > (In reply to Peter Jones from comment #5) > > This is mostly done: > > > > gnu-efi is done > > shim-unsigned-x64 is done > > shim-unsigned-aarch64 is done (wish I had named this aa64 but oh well) > > lorax is done > > anaconda is done > > shim-signed is in the works - right now it has the shim-0.8 > > /boot/efi/EFI/fedora/shimx64.efi that's signed by MS, and I'll swap out the > > new one once signing happens. At that point I'm also going to deadpkg this > > package and move it into the "shim" package, fixing our ages old naming goof. > > Just to be clear, is this the reason why in Fedora 27, I have two entries > that say "Fedora", and I end up getting this when I ask efibootmgr what's > going on? Yes, though this aspect should be fixed in https://bodhi.fedoraproject.org/updates/FEDORA-2017-249267e56b (shim-signed-13-0.5). Everything is done here except signing; that'll be shim-signed-13-1 , which should happen within the next week or so. If there's any delay in that, we can ship as-is for f27 and issue the new version as an update, and all that will mean is that the install image still doesn't work on ia32. This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'. I see signed ia32 shim finally was released in 15.2 And for as much not being in F28, I see latest rawhide has it. Can the issue be closed then? Is this operational currently? Forwarding the needinfo request to author of the Change. I never got a response, so I've just asked at https://discussion.fedoraproject.org/t/how-to-install-onto-32-bit-efi/85941 instead. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days |