Bug 849389
Summary: | uefi boot fails on Asus motherboards | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | John Reiser <jreiser> | ||||||
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | rawhide | CC: | awilliam, clydekunkel7734, dennis, gansalmon, g.kaviyarasu, itamar, jfeeney, jonathan, kernel-maint, kparal, madhu.chinakonda, mads, pjones, robatino, vanmeeuwen+fedora | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | AcceptedNTH | ||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2012-09-04 20:36:31 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: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 752662 | ||||||||
Attachments: |
|
Description
John Reiser
2012-08-19 02:11:39 UTC
I see the same behavior (hanging boot) on ASUS M5A97 PRO [1]. See attachment. How do I check whether it has or has not TCM? Standard (non-UEFI) boot works OK. I have tried the same media on two other UEFI-enabled machines (Thinkpad X220 and Thinkpad T420s) and both boot OK even when using UEFI boot. [1] http://www.asus.com/Motherboards/AMD_AM3Plus/M5A97_PRO/#specifications Created attachment 606806 [details]
frozen boot
Created attachment 606807 [details]
M5A97 lspci
My machine hardware: http://www.smolts.org/client/show/pub_e0775e72-9150-4dad-a11d-63552306941a I also have to say I used a USB stick (after working around bug 851220), because it doesn't have an optical drive. I also used F18 Alpha TC3 x86_64 netinst. Proposing as F18 Alpha blocker: " The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods " https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria "Boot a command list" might come from grub2. "Secure boot not enabled" do not come from grub2. It must come from the kernel. AFAIK "secure boot" is all about also checking the next step if the current step was checked. Not initiating the "secure" chain should never be a problem. It looks like a kernel bug to me ... but it is probably mjg stuff anyway. (In reply to comment #0) > Description: Booting Fedora 18-Alpha-TC3 netinst.iso x86_64 DVD in UEFI mode > on a system which lacks TCM hardware (Trusted Computing Module) and thus > does not support secure mode, fails with "Secure boot not enabled" and > requires hard reset. Secure boot doesn't require TCM. (In reply to comment #5) > "Boot a command list" might come from grub2. > > "Secure boot not enabled" do not come from grub2. It must come from the > kernel. > > AFAIK "secure boot" is all about also checking the next step if the current > step was checked. Not initiating the "secure" chain should never be a > problem. It looks like a kernel bug to me ... but it is probably mjg stuff > anyway. This isn't being printed from the kernel. It seems _much_ too early for the kernel to be printing anything at that point. The kernel does print "Secure boot enabled" on UEFI machines with SecureBoot (or a parameter passed), however we print nothing in the non-SB case. (In reply to comment #6) > This isn't being printed from the kernel. That leaves one option. And indeed, shim.c: status = get_variable(L"SecureBoot", global_var, &charsize, (void *)&sb); /* FIXME - more paranoia here? */ if (status != EFI_SUCCESS || sb != 1) { Print(L"Secure boot not enabled\n"); return FALSE; } I would expect that shim only was installed on "secure boot" systems ... but also that it would work as usual if "secure boot" isn't enabled. The message comes from grub, however it's merely the last thing that grub prints. The failure is almost certainly in the kernel. Reassigning. Probably because x86-64/efi: Use EFI to deal with platform wall clock hasn't been reverted from F18 yet. (In reply to comment #9) > Probably because x86-64/efi: Use EFI to deal with platform wall clock hasn't > been reverted from F18 yet. Right. The Alpha TC3 is using 3.6.0-0.rc1.git6.1.fc18.x86_64 which does not have the relevant commit reverted. That commit happens to hit these machines early enough in the kernel boot that you won't actually see the oops. kernel-3.6.0-0.rc2.git2.1.fc18 went into the f18 tag last night/this morning and does have the revert included. I'd suggest waiting for the next Alpha TC to be spun and test that. We can mark this as ON_QA then, as those builds have been pushed stable, and test and close (if appropriate) with TC4 when we can build it. Discussed at 2012-08-27 QA meeting, functioning as a blocker review meeting. As we understand it, this affects many Asus systems when installing native UEFI. It was very close to being accepted as a blocker, but we decided simply to take it as NTH as the fix is already in a kernel build we'll be pulling for TC4 anyway, and it's simpler to approve as NTH rather than blocker. We can re-evaluate if there turns out to be some kind of issue down the road. This is fixed with F18 Alpha TC5 on ASUS M5A97 PRO (I used USB to boot). update is pushed stable, so let's close it. |