Bug 849389

Summary: uefi boot fails on Asus motherboards
Product: [Fedora] Fedora Reporter: John Reiser <jreiser>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: 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 Flags
frozen boot
none
M5A97 lspci none

Description John Reiser 2012-08-19 02:11:39 UTC
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.


Version-Release number of selected component (if applicable):
anaconda-18.6   Fedora 18-Alpha-TC3

How reproducible: every time (6 for 6 so far)


Steps to Reproduce:
1. boot Fedora 18-Alpha-TC3 x86_64 netinst.iso DVD in UEFI mode on Asus P8Z68 board which lacks TCM.
2. wait for Grub menu; boot either option (Fedora ...; Test this media & install/upgrade Fedora)
3.
  
Actual results: screen clears, displays "Secure boot not enabled", and box requires hardware reset to proceed (no response to Ctrl-Alt-DEL, for instance)


Expected results: successful boot


Additional info: Fedora 17 install DVD boots successfully on this box in this non-secure UEFI mode, and in regular (non-UEFI) mode.  Fedora 18-Alpha-TC3 netinst.iso boots successfully in regular (non-UEFI) mode.

Comment 1 Kamil Páral 2012-08-24 09:17:11 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

Comment 2 Kamil Páral 2012-08-24 09:17:30 UTC
Created attachment 606806 [details]
frozen boot

Comment 3 Kamil Páral 2012-08-24 09:18:58 UTC
Created attachment 606807 [details]
M5A97 lspci

Comment 4 Kamil Páral 2012-08-24 09:22:18 UTC
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

Comment 5 Mads Kiilerich 2012-08-24 09:33:10 UTC
"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.

Comment 6 Josh Boyer 2012-08-24 12:30:48 UTC
(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.

Comment 7 Mads Kiilerich 2012-08-24 12:43:50 UTC
(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.

Comment 8 Matthew Garrett 2012-08-24 15:15:46 UTC
The message comes from grub, however it's merely the last thing that grub prints. The failure is almost certainly in the kernel. Reassigning.

Comment 9 Matthew Garrett 2012-08-24 15:17:19 UTC
Probably because x86-64/efi: Use EFI to deal with platform wall clock hasn't been reverted from F18 yet.

Comment 10 Josh Boyer 2012-08-24 15:22:21 UTC
(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.

Comment 11 Adam Williamson 2012-08-24 19:40:09 UTC
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.

Comment 12 Adam Williamson 2012-08-27 17:00:35 UTC
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.

Comment 13 Kamil Páral 2012-09-04 11:16:30 UTC
This is fixed with F18 Alpha TC5 on ASUS M5A97 PRO (I used USB to boot).

Comment 14 Adam Williamson 2012-09-04 20:36:31 UTC
update is pushed stable, so let's close it.