Bug 1251600 - BOOTAA64.EFI fails to PXE boot on AMD Seattle systems
Summary: BOOTAA64.EFI fails to PXE boot on AMD Seattle systems
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 23
Hardware: aarch64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARM64, F-ExcludeArch-aarch64 1301166
TreeView+ depends on / blocked
 
Reported: 2015-08-07 21:05 UTC by D. Marlin
Modified: 2016-04-12 09:38 UTC (History)
9 users (show)

Fixed In Version: grub2-2.02-0.30.fc24
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-12 09:38:58 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.