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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:17 UTC