Closed lilmike closed 3 years ago
vathpela
commented
4 years ago That sure looks correct. Is it possible your firmware simply doesn't support booting from that device, or you need the full device path for it (that'd be a firmware bug, but... those happen.)? If it's the latter, adding '-e 3' to the command line /might/ fix it, if we know how to create all the device path entries.
lilmike
commented
4 years ago I believe we solved this issue. It was a problem of us including the pmbr_boot flag in parted, which I later found out was a violation of the EFI specification that would cause it to ignore and/or remove that boot entry. Feel free to close this. -Michael.
On Mon, Jan 13, 2020 at 08:00:56AM -0800, Peter Jones wrote:
That sure looks correct. Is it possible your firmware simply doesn't support booting from that device, or you need the full device path for it (that'd be a firmware bug, but... those happen.)? If it's the latter, adding '-e 3' to the command line /might/ fix it, if we know how to create all the device path entries.
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/rhboot/efibootmgr/issues/116#issuecomment-573735739
martinezjavier
commented
3 years ago Closing this according to @lilmike's comment.
I'm using grub to install in EFI mode on a spirit book, and it seems that efibootmgr isn't creating the device path of the hard drive properly. As far as I can tell, the boot entry contains hard drive 1, and the proper gpt partitian id. Output of efibootmgr -v is
Boot0000* GRUB HD(1,GPT,5381edc5-d04c-4b4b-a962-65bc1a0c49b4,0x1800,0x1c0801)/File(\EFI\GRUB\grubx64.efi)
Am I understanding this output correctly? If not, can anyone think of why it would fail to boot the boot entry, in fact when booting back up, it even deletes the boot entry (and provides only efi shell and "invalid"). Thanks! -Michael.