Loaded image device handle not set
Bug #1308009 reported by
Leif Lindholm
This bug report is a duplicate of:
Bug #1304442: Partial device paths not properly handled by Bds.
Edit
Remove
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linaro UEFI |
New
|
Undecided
|
Unassigned |
Bug Description
Identified as a failure to boot a GRUB image that has been installed into the ARM Bds as a boot entry using grub-install from within Linux.
The same image correctly determines its boot device, and so locates its loadable modules and config file, when executed from the EFI shell.
In the error case, when GRUB retreives the LoadedImage information, the DeviceHandle field is set to 0. Passing this handle on to OpenProtocol with DEVICE_PATH_GUID, causes that call to return INVALID_PARAMETER.
description: | updated |
To post a comment you must log in.
Investigating further, and comparing to x86 (via Ovmf), it seems the problem is actually really late in the chain:
- The boot menu entry created by grub-install looks correct compared to x86.
- Booting via this entry fails, through the symptoms added above.
- Manually adding an entry for the same image in the boot manager creates an entry that can boot successfully.
The difference between the entries are as follows on my platform: 0xD66FFE00, 0x3F,0x19FC0) /\EFI\grub\ grubaa64. efi 1B67-4C24- B346-73DB42E873 E5)/HD( 1,MBR,0xD66FFE0 0,0x3F, 0x19FC0) /\EFI\grub\ grubaa64. efi
- The entry created by grub-install (not working):
[1] grub
- HD(1,MBR,
- The entry created manually in the boot manager (working):
[3] manual grub
- VenHw(FE61BB5F-
- Arguments:
So, the VenHw string seems to enable what is necessary for this to function - but on x86 no such thing is required. 6D86A651- EBFF-4D0E- 9C22-436A93138D C2,0x2000, 0x80000) /\EFI\grub\ grubx64. efi
My working boot entry there (generated by grub-install, built from the same source) looks like:
HD(1,GPT,