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):
Steps to Reproduce:
1. Set up PXE/tftp server for F23_RC1
2. PXE boot the system
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.
Boots to grub menu, and proceeds with install.
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).
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.
This is still an issue in F23_Beta. Any ETA for a fix?
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.
(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
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.
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:
grub2-2.02-0.30.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-e8aec1d3a5
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
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.