Re: EFI issues

From: Jung-uk Kim <jkim_at_FreeBSD.org>
Date: Wed, 22 Aug 2018 19:08:50 -0400
On 18. 8. 3., Warner Losh wrote:
> On Sun, Jul 29, 2018 at 6:35 AM, O. Hartmann <ohartmann_at_walstatt.org> wrote:
>>>>> 'efibootmgr -v' output:
>>>>>
>>>>> BootCurrent: 0004
>>>>> Timeout    : 1 seconds
>>>>> BootOrder  : 0001, 0002, 0003, 0004
>>>>>  Boot0001* Hard Drive  BBS(HD,,0x0)
>>>>>  Boot0002* Network Card  BBS(Network,,0x0)
>>>>>  Boot0003* UEFI OS
>>>>> HD(1,GPT,78459ec0-9303-11e8-97e6-98ded0009b1c,0x28,
>> 0x64000)/File(\EFI\BOOT\BOOTX64.EFI)
>>>>> ada0p1:/EFI/BOOT/BOOTX64.EFI (null)
>>>>> Path(0,0,ae84b11df581724e85442bab0c2cac5c020000020000) +Boot0004*
>> UEFI: SanDisk
>>>>> PciRoot(0x0)/Pci(0x1d,0x0)/USB(0x1,0x0)/USB(0x4,0x0)/HD(
>> 1,MBR,0x90909090,0x1,0x640)
>>>>> VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,
>> 530061006e004400690073006b000000)
>>
> ...
> 
>>> I've updated BIOS (which alone didn't change anything) and executed
>>> commands you suggested, and it helped! Thanks!
>>>
>>> Now 'efibootmgr -v' output looks like this:
>>>
>>> BootCurrent: 0000
>>> Timeout    : 1 seconds
>>> BootOrder  : 0000, 0004, 0006, 0003, 0007
>>> +Boot0000* FreeBSD
>>> HD(1,GPT,78459ec0-9303-11e8-97e6-98ded0009b1c,0x28,
>> 0x64000)/File(\efi\boot\BOOTx64.efi)
>>> ada0p1:/efi/boot/BOOTx64.efi (null) Boot0004* Hard Drive  BBS(HD,,0x0)
>>>  Boot0006* Network Card  BBS(Network,,0x0)
>>>  Boot0003* UEFI OS
>>> HD(1,GPT,78459ec0-9303-11e8-97e6-98ded0009b1c,0x28,
>> 0x64000)/File(\EFI\BOOT\BOOTX64.EFI)
>>> ada0p1:/EFI/BOOT/BOOTX64.EFI (null)
>>> Path(0,0,ef47642dc93ba041ac194d51d01b4ce65200650061006c00740065006b00
>> 200042006f006f00740020004100670065006e0074000000)
>>> Boot0007* UEFI: SanDisk
>>> PciRoot(0x0)/Pci(0x14,0x0)/USB(0x9,0x0)/HD(1,MBR,0x90909090,0x1,0x640)
>>> VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,
>> 340043003500330031003000300031003500340031003000310035003100
>> 300039003000390035000000)
>>>
>>>
>>> Unreferenced Variables:
>>>
>>> This is strange, because the only difference I see is that Boot0000 has
>>> lowercase filenames ('/efi/boot/BOOTx64.efi' vs
>>> '/EFI/BOOT/BOOTX64.EFI'). I'm wondering if that's the only reason it
>>> wasn't working before?
>>>
>>>> - --
>>>> O. Hartmann
>> [...]
>>
>>>
>>> Roman Bogorodskiy
>>
>> I'm glad to be of help. But it was a "wild guess", not experience or
>> decend knowledge.
>> Maybe there is an issue with recent UEFI/boot/stand implementation since
>> this portion of
>> FreeBSD is under heavy development or has been under such ...
>>
>> Ypu shpuld consider contacting Warner Losh or Toomas Soome (on the current_at_
>> list, there
>> is a thread entitelt "[UEFI] Boot issues on some UEFI implementations"
>> started by myself
>> targetting some weird FreeBSD/UEFI issues. Toomas Soome gave me the hint
>> with
>> efibootmgr(8) and I figured out by learning from the definitions, that on
>> specific UEFI
>> implementations, the boot path "/efi/boot/bootx64.efi" is considered the
>> default for
>> changeable media (like USB flash drives) and not necessaryly the default
>> for SATA/SAS
>> devices.
> 
> 
> Case shouldn't matter. If it does, I've done something wrong. Internally,
> we convert to lower case and the filesystem is case insensitive in this
> case.
> 
> The whole default file thing is something I thought I understood really,
> really well, but it's becoming clear that there's issues that are clear as
> mud. We should be coping with this junk in the installer...

I had a similar problem with one of my boxes and the workaround, i.e.,
adding a duplicate entry with efibootmgr(8), fixed it for me, too.

It seems the BIOS adds bogus data at the end.

Bad variable added by BIOS:
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0009
0000: 01 00 00 00 62 00 55 00 45 00 46 00 49 00 20 00
0010: 4f 00 53 00 00 00 04 01 2a 00 02 00 00 00 00 68
0020: 09 00 00 00 00 00 00 18 03 00 00 00 00 00 d9 29
0030: 2b 57 b4 37 24 48 b0 a1 0a d8 23 6b 38 db 02 02
0040: 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00
0050: 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00
0060: 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00
0070: 7f ff 04 00 aa 55 00 00

Good variable added by efibootmgr:
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0003
0000: 01 00 00 00 5e 00 55 00 45 00 46 00 49 00 20 00
0010: 4f 00 53 00 00 00 04 01 2a 00 02 00 00 00 00 68
0020: 09 00 00 00 00 00 00 18 03 00 00 00 00 00 d9 29
0030: 2b 57 b4 37 24 48 b0 a1 0a d8 23 6b 38 db 02 02
0040: 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00
0050: 6f 00 6f 00 74 00 5c 00 62 00 6f 00 6f 00 74 00
0060: 78 00 36 00 34 00 2e 00 65 00 66 00 69 00 00 00
0070: 7f ff 04 00

Actually, "efibootmgr -v" hangs or crashes depending on current boot
order.  My guess is device path printing is not robust enough to ignore
the bogus data.

Jung-uk Kim


Received on Wed Aug 22 2018 - 21:08:57 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:17 UTC