Date: Wed, 22 Aug 2018 19:08:50 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Warner Losh <imp@bsdimp.com>, "O. Hartmann" <ohartmann@walstatt.org> Cc: Roman Bogorodskiy <novel@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, Toomas Soome <tsoome@me.com>, "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net>, Allan Jude <allanjude@freebsd.org> Subject: Re: EFI issues Message-ID: <eadf5d63-a65a-338e-a3e0-f91b410052fa@FreeBSD.org> In-Reply-To: <CANCZdfoiAC03G1MhFZYoAL9B-f-ktpP8JXFiCT50wPfa2npD8Q@mail.gmail.com> References: <20180728072938.GA28778@kloomba> <20180729094502.180dabc0@thor.intern.walstatt.dynvpn.de> <20180729080957.GB2216@kloomba> <20180729105550.4ac8711a@thor.intern.walstatt.dynvpn.de> <20180729111751.GC2216@kloomba> <20180729143529.16bad01a@thor.intern.walstatt.dynvpn.de> <CANCZdfoiAC03G1MhFZYoAL9B-f-ktpP8JXFiCT50wPfa2npD8Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--IM5KIsqwgmx41lsnpLxyiKbh9eiwrVozU
Content-Type: multipart/mixed; boundary="aVeG81pqBcdaTRNuZhjvrC3qRO5KZPFuV";
protected-headers="v1"
From: Jung-uk Kim <jkim@FreeBSD.org>
To: Warner Losh <imp@bsdimp.com>, "O. Hartmann" <ohartmann@walstatt.org>
Cc: Roman Bogorodskiy <novel@freebsd.org>,
FreeBSD Current <freebsd-current@freebsd.org>, Toomas Soome <tsoome@me.com>,
"Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net>,
Allan Jude <allanjude@freebsd.org>
Message-ID: <eadf5d63-a65a-338e-a3e0-f91b410052fa@FreeBSD.org>
Subject: Re: EFI issues
References: <20180728072938.GA28778@kloomba>
<20180729094502.180dabc0@thor.intern.walstatt.dynvpn.de>
<20180729080957.GB2216@kloomba>
<20180729105550.4ac8711a@thor.intern.walstatt.dynvpn.de>
<20180729111751.GC2216@kloomba>
<20180729143529.16bad01a@thor.intern.walstatt.dynvpn.de>
<CANCZdfoiAC03G1MhFZYoAL9B-f-ktpP8JXFiCT50wPfa2npD8Q@mail.gmail.com>
In-Reply-To: <CANCZdfoiAC03G1MhFZYoAL9B-f-ktpP8JXFiCT50wPfa2npD8Q@mail.gmail.com>
--aVeG81pqBcdaTRNuZhjvrC3qRO5KZPFuV
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
On 18. 8. 3., Warner Losh wrote:
> On Sun, Jul 29, 2018 at 6:35 AM, O. Hartmann <ohartmann@walstatt.org> w=
rote:
>>>>> '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)
>>
> ...
>=20
>>> 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 h=
as
>>> 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 sin=
ce
>> this portion of
>> FreeBSD is under heavy development or has been under such ...
>>
>> Ypu shpuld consider contacting Warner Losh or Toomas Soome (on the cur=
rent@
>> 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 hi=
nt
>> 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 t=
he
>> default for
>> changeable media (like USB flash drives) and not necessaryly the defau=
lt
>> for SATA/SAS
>> devices.
>=20
>=20
> Case shouldn't matter. If it does, I've done something wrong. Internall=
y,
> we convert to lower case and the filesystem is case insensitive in this=
> case.
>=20
> 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
--aVeG81pqBcdaTRNuZhjvrC3qRO5KZPFuV--
--IM5KIsqwgmx41lsnpLxyiKbh9eiwrVozU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAlt97QcACgkQfJ+WJvzb
8UYyeQf/XIlVJu6nnnvLtndk3qQy4rRi6HGva0KPGtpBk4x9mkdH4FeamevRgkDj
4vcxuJBHg0GvKVXPg/vae8RoPFgsZ44/8T7qjJBOHOhz3XqQdN9hd8nMQFI6AHFp
gFYFzzfA/2K8S3IhehoRDejhZog/3FoSB6V8tBftmYVY/AtGhpjJHzpDP4am9rZy
fvI+SwGHeotz040hlabwkjKvu6xxTxyV99/XdSFsDTMJyU0k2xLd663olS7Sc89i
rmPBVQYreOEasZ+SZ17x/LH26mb8c/ophNLlZvQZDpS4TWH6ujqQ5fy//e3yWpKm
Dcn/dcfMz8dmXzPrNp68F6Sx9KLsdA==
=zeRv
-----END PGP SIGNATURE-----
--IM5KIsqwgmx41lsnpLxyiKbh9eiwrVozU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?eadf5d63-a65a-338e-a3e0-f91b410052fa>