Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1251600

Summary: BOOTAA64.EFI fails to PXE boot on AMD Seattle systems
Product: [Fedora] Fedora Reporter: D. Marlin <dmarlin>
Component: grub2Assignee: Peter Jones <pjones>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 23CC: bcl, lkundrak, mads, msalter, paul, pbrobinson, pjones, pwhalen, rsalveti
Target Milestone: ---   
Target Release: ---   
Hardware: aarch64   
OS: Linux   
Whiteboard:
Fixed In Version: grub2-2.02-0.30.fc24 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-04-12 09:38:58 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: 922257, 1301166    

Description D. Marlin 2015-08-07 21:05:11 UTC
Description of problem:

When attempting to PXE boot a Seattle system using F23_RC1, the grub menu is never displayed, and it drops to a grub prompt.  If BOOTAA64.EFI is replaced with the F22 version, the boot completes and installation proceeds as expected.


Version-Release number of selected component (if applicable):

grub2-efi-2.02-0.21.fc23.aarch64


How reproducible:

consistently


Steps to Reproduce:
1.  Set up PXE/tftp server for F23_RC1
  http://arm.koji.fedoraproject.org/compose/23_Alpha_RC1/23/Server/aarch64/os/
2.  PXE boot the system
3.


Actual results:

Boot firmware (version  built at 13:11:53 on Apr  2 2015)
Trust Zone Configuration is disabled
Status Code Available
DXE Status Code Available


>>Checking Media Presence......
>>Start PXE over IPv4.
  Station IP address is 10.15.5.9

  Server IP address is 10.15.4.12
  NBP filename is aarch64-fedora/BOOTAA64.EFI
  NBP filesize is 885736 Bytes

>>Checking Media Presence......
 Downloading NBP file...

  Succeed to download NBP file.
Fetching Netboot Image


(wait a few minutes to timeout)


      Minimal BASH-like line editing is supported. For the first word,    
      TAB lists possible command completions. Anywhere else TAB lists     
      possible device or file completions.                                


grub> 



Expected results:

Boots to grub menu, and proceeds with install.


Additional info:

This is only reproducible on AMD Seattle systems.  APM Mustang systems boot and install as expected.

The Seattle host was an A0 system with the latest firmware (ROD0074E 0.10).

Comment 1 Mark Salter 2015-08-18 20:40:10 UTC
https://savannah.gnu.org/bugs/index.php?45794

Comment 2 Mark Salter 2015-08-19 13:53:15 UTC
As Andrei pointed out in the upstream bug report, the problem was not upstream. Fedora is still carrying and old fix. Fedora needs to drop 0050-reopen-SNP-protocol-for-exclusive-use-by-grub.patch from grub2.

Comment 3 D. Marlin 2015-11-02 22:12:20 UTC
This is still an issue in F23_Beta.  Any ETA for a fix?

Comment 4 paul 2016-01-19 08:48:31 UTC
FYI, I've been trying to PXE boot bootx64.efi for a week on F23 fully updated, and the above solution of removing 0050-reopen-SNP-protocol-for-exclusive-use-by-grub.patch finally got it working. Not sure if there's an X86_64 bug for this issue too somewhere.

Comment 5 Peter Robinson 2016-01-19 08:55:51 UTC
(In reply to paul from comment #4)
> FYI, I've been trying to PXE boot bootx64.efi for a week on F23 fully
> updated, and the above solution of removing
> 0050-reopen-SNP-protocol-for-exclusive-use-by-grub.patch finally got it
> working. Not sure if there's an X86_64 bug for this issue too somewhere.

This is completely unrelated to X86_64

Comment 6 paul 2016-01-19 09:29:31 UTC
Sorry. I know that. However, this bug was how I found the resolution to my issue with X86_64. I just wanted to provide a data point the 0050 patch seems to be a generic problem rather than architecture specific.

Comment 8 Peter Jones 2016-04-07 15:12:53 UTC
So, I'm pretty sure that the confusion here is that msalter had originally provided a patch that added the _OPEN_EXCLUSIVE bits to fix some Aarch64 platform, but then they were discovered not to be correct.  But that discovery was only ever reflected in the patch that eventually got merged upstream.  So when we rebased to upstream, we kept that patch (now abbreviated because git rebase collapsed the duplicate bits), and the two do not work together.

msalter then apparently was confused about this and filed https://savannah.gnu.org/bugs/index.php?45794 in response?

I've pushed a revert for the original patch, and we now rely solely upon the upstream code.  If that's not the right thing, I'm going to need more information about whatever debugging has gone on.

Builds are here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13583703 (f24)
http://koji.fedoraproject.org/koji/taskinfo?taskID=13583699 (master)

Comment 9 Fedora Update System 2016-04-07 15:30:46 UTC
grub2-2.02-0.30.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-e8aec1d3a5

Comment 10 Fedora Update System 2016-04-08 16:52:54 UTC
grub2-2.02-0.30.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-e8aec1d3a5

Comment 11 Fedora Update System 2016-04-12 09:38:50 UTC
grub2-2.02-0.30.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.