Hello.
I'm trying to use a newer version of GRUB2 (grub2-efi-2.02-0.34.fc24.x86_64) for UEFI PXE booting Linux (Clonezilla) and also a custom UEFI application (custom shell) that needs access to the TCP4 UEFI stack in firmware (depends of the scenario). Using older versions of GRUB2 it is working, but with newer versions, when it chainloads the custom UEFI application all the UEFI Network Protocols are gone (error 14 when calling gBS->LocateProtocol(&gEfiPxeBaseCodeProtocolGuid, ...).
I need the newer version because the new netboot capabilities that looks for a cfg file using the MAC Address as grub.cfg-01-AA-BB-CC-DD-EE-FF. Is newer versions of grub2 unloading UEFI protocols (maybe calling UEFI's Boot Services ExitBootServices) before chainloading UEFI applications?
PS: Is this the correct forum for this matter?
My best regards,
Leandro Becker.
On Tue, Jul 12, 2016 at 12:52 PM, Leandro Gustavo Biss Becker lbecker@fedoraproject.org wrote:
Hello.
I'm trying to use a newer version of GRUB2 (grub2-efi-2.02-0.34.fc24.x86_64) for UEFI PXE booting Linux (Clonezilla) and also a custom UEFI application (custom shell) that needs access to the TCP4 UEFI stack in firmware (depends of the scenario). Using older versions of GRUB2 it is working, but with newer versions, when it chainloads the custom UEFI application all the UEFI Network Protocols are gone (error 14 when calling gBS->LocateProtocol(&gEfiPxeBaseCodeProtocolGuid, ...).
I need the newer version because the new netboot capabilities that looks for a cfg file using the MAC Address as grub.cfg-01-AA-BB-CC-DD-EE-FF. Is newer versions of grub2 unloading UEFI protocols (maybe calling UEFI's Boot Services ExitBootServices) before chainloading UEFI applications?
PS: Is this the correct forum for this matter?
Sure. But maybe not too many people have done UEFI PXE booting. I've done PXE and know enough about UEFI to stop now and forever hold my peace, but I've never done UEFI PXE.
My understanding is that PXE is booting is going to talk to a DHCP server which should be configured to recognize UEFI specifically, so it can hand over the proper kind of bootloader, in this case an EFI version of GRUB2. What I don't know is how that works exactly. Does the PXE client-server connection permit the transfer of multiple files? For example....
Fedora builds a grubx64.efi (the boot.img and core.img) within their build system and then signs it in order to support UEFI Secure Boot. But this signed binary doesn't contain all of GRUB's modules. Those are in a separate package that isn't installed by default, in grub2-efi-modules. So maybe the server doesn't have those modules installed with the new version of GRUB? Or maybe they're not baked into the Fedora built grubx64.efi?
So I'd figure out what's different between the old GRUB and new GRUB verions, and see if what's missing is a regression, or if it's that those modules were pulled out into grub2-efi-modules on purpose. And then if there's some way between PXE client-server and GRUB for GRUB to get any of those modules, or if they must be baked into the grubx64.efi (the actual EFI OSLoader, or bootloader). If it does, then it might be that you have to build your own grubx64.efi using grub2-install or one of the other script commands for this purpose, and explicitly add in the modules that you need baked into that grubx64.efi.
The next thing is whether or not you need Secure Boot support. If you do, then there's a kind of chainloading that has to happen, where the first thing loaded is shim.efi, then mokutil.efi so that your own key can be registered with the firmware, and then your own signed grubx64.efi.
Maybe that's enough for now to start looking.
On Tue, Jul 12, 2016 at 5:25 PM, Chris Murphy lists@colorremedies.com wrote:
My understanding is that PXE is booting is going to talk to a DHCP server which should be configured to recognize UEFI specifically, so it can hand over the proper kind of bootloader, in this case an EFI version of GRUB2. What I don't know is how that works exactly.
With ISC's dhcpd, you make "architecture-type" a condition:
option architecture-type code 93 = unsigned integer 16; if option architecture-type = 00:07 { filename "shim.efi"; } else { filename "pxelinux.0"; }
At least, I think that's what you mean.
On Tue, Jul 12, 2016 at 11:52 AM, Leandro Gustavo Biss Becker lbecker@fedoraproject.org wrote:
Using older versions of GRUB2 it is working, but with newer versions, ...
Just so that we're clear, if you boot this computer using an older version of GRUB2 from tftp, your custom application works, but if you then use the newer version, it doesn't work? You can reproduce both the working and not-working conditions?
If so, what version was previously working? It'll be easier to look at differences in the build process if we have something specific to look at.
I need the newer version because the new netboot capabilities that looks for a cfg file using the MAC Address as grub.cfg-01-AA-BB-CC-DD-EE-FF.
I'm using grub2-efi-2.02-0.16.el7.centos, and it loads configuration files with that style naming. I was under the impression that it always had. Can you clarify what changed, and in what version?
Thank you all for the replies and sorry my late reply.
Gordon, I downgraded a little bit, from f24 (grub2-efi-2.02-0.34.fc24.x86_64.rpm) to f22 (grub2-efi-2.02-0.18.fc22.x86_64.rpm) and everything is working for my needs. Chris, thank you for you tips, all the used modules are builtin.
Analyzing the source code for both versions, I found an interesting change on grub-core\loader\efi\chainloader.c:382 ( I do not know if this change is broking what I need). In the newer version of grub, there is a call to grub_device_close(dev), so I'm wondering if this is causing the custom application to fail opening UEFI Network Protocols.
Here is a link to a picture of the code difference: https://1drv.ms/i/s!AsJQCGQT6-QYnymMc77WIQntDizy
My best regards, Leandro!
On 07/14/2016 12:49 PM, Leandro Gustavo Biss Becker wrote:
Analyzing the source code for both versions, I found an interesting change on grub-core\loader\efi\chainloader.c:382 ( I do not know if this change is broking what I need). In the newer version of grub, there is a call to grub_device_close(dev), so I'm wondering if this is causing the custom application to fail opening UEFI Network Protocols.
I'm not a grub developer, so I'm not familiar with the code, but you probably want to look at pxechainloader.c and the pxe.c file in the drivers directory. don't see the change that broke things, but it looks to me like grub_pxe_shutdown needs to be called with the GRUB_LOADER_FLAG_PXE_NOT_UNLOAD flag, and nothing is setting that. In pxechainloader.c, the grub_pxechain_unload is registered with that flag.
I don't have enough time to chase this down further, but if you want to, maybe start there.
-
Chris Murphy -
Gordon Messmer -
Leandro Gustavo Biss Becker