Date: Tue, 24 Jul 2018 08:53:36 +0300 From: Toomas Soome <tsoome@me.com> To: "O. Hartmann" <ohartmann@walstatt.org> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <16439773-3E9A-40FF-99A1-32E97CCEE2C3@me.com> In-Reply-To: <20180724071514.6cb9d111@freyja.zeit4.iv.bundesimmobilien.de> References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> <68505F98-E840-4148-9E48-BDB350F7431A@me.com> <20180713164447.42430301@thor.intern.walstatt.dynvpn.de> <680FBB42-75BF-427F-AA3B-6D864E83ED1F@me.com> <20180723092735.12a5d2a8@freyja.zeit4.iv.bundesimmobilien.de> <80523BE6-C035-482D-B134-23812183DE83@me.com> <20180724071514.6cb9d111@freyja.zeit4.iv.bundesimmobilien.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 24 Jul 2018, at 08:16, O. Hartmann <ohartmann@walstatt.org> wrote:
>=20
> On Mon, 23 Jul 2018 10:56:04 +0300
> Toomas Soome <tsoome@me.com> wrote:
>=20
>>> On 23 Jul 2018, at 10:27, O. Hartmann <ohartmann@walstatt.org> =
wrote:
>>>=20
>>> On Fri, 13 Jul 2018 18:44:23 +0300
>>> Toomas Soome <tsoome@me.com <mailto:tsoome@me.com>> wrote:
>>>=20
>>>>> On 13 Jul 2018, at 17:44, O. Hartmann <o.hartmann@walstatt.org
>>>>> <mailto:o.hartmann@walstatt.org>> wrote:
>>>>>=20
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA512
>>>>>=20
>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300
>>>>> Toomas Soome <tsoome@me.com <mailto:tsoome@me.com> =
<mailto:tsoome@me.com
>>>>> <mailto:tsoome@me.com>>> schrieb:=20
>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann <ohartmann@walstatt.org> =
wrote:
>>>>>>>=20
>>>>>>> The problem is some kind of weird. I face UEFI boot problems on =
GPT
>>>>>>> drives where the first partition begins at block 40 of the =
hdd/ssd.
>>>>>>>=20
>>>>>>> I have two host in private use based on an
>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, =
Socket
>>>>>>> LGA1155). Both boards are equipted with the lates official =
available AMI
>>>>>>> firmware revision, dating to 2013. This is for the Z77-Pro4-M =
revision
>>>>>>> 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 (2013/7/17). =
For both
>>>>>>> boards a BETA revision for the Spectre/Meltdown mitigation is =
available,
>>>>>>> but I didn't test that. But please read.
>>>>>>>=20
>>>>>>> The third box I realised this problem is a brand new Fujitsu =
Esprimo
>>>>>>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, =
date
>>>>>>> 05/25/2018 (or 20180525).
>>>>>>>=20
>>>>>>> Installing on any kind of HDD or SSD manually or via bsdinstall =
the OS
>>>>>>> using UEFI-only boot method on a GPT partitioned device fails. =
The
>>>>>>> ASRock boards jump immediately into the firmware, the Fujitsu =
offers
>>>>>>> some kind of CPU/Memory/HDD test facility.
>>>>>>>=20
>>>>>>> If on both type of vendor/boards CSM is disabled and UEFI boot =
only is
>>>>>>> implied, the MBR partitioned FreeBSD installation USB flash =
device does
>>>>>>> boot in UEFI! I guess I can assume this when the well known =
clumsy 80x25
>>>>>>> char console suddenly gets bright and shiny with a much higher =
resoltion
>>>>>>> as long the GPU supports EFI GOP. Looking with gpart at the USB =
flash
>>>>>>> drives reveals that the EFI partition starts at block 1 of the =
device
>>>>>>> and the device has a MBR layout. I haven't found a way to force =
the GPT
>>>>>>> scheme, when initialised via gpart, to let the partitions start =
at block
>>>>>>> 1. This might be a naiv thinking, so please be patient with me.
>>>>>>>=20
>>>>>>> I do not know whether this is a well-known issue. On the ASRock =
boards,
>>>>>>> I tried years ago some LinuxRed Hat and Suse with UEFI and that =
worked -
>>>>>>> FreeBSD not. I gave up on that that time. Now, having the very =
same
>>>>>>> issues with a new Fujitsu system, leaves me with the impression =
that
>>>>>>> FreeBSD's UEFI implementation might have problems I'm not aware =
of.
>>>>>>>=20
>>>>>>> Can someone shed some light onto this?=20
>>>>>>>=20
>>>>>>=20
>>>>>> The first thing to check is if the secure boot is disabled. We do =
not
>>>>>> support secure boot at all at this time. =20
>>>>>=20
>>>>> Secure boot is in every scenario disabled!
>>>>>=20
>>>>>>=20
>>>>>> If you have efi or bios version running - you can check from =
either
>>>>>> console variable value (it can have efi or vidconsole or =
comconsole) or
>>>>>> better yet, see if efi-version is set (show efi-version) - if =
efi-version
>>>>>> is not set, it is BIOS loader running. Another indirect way is to =
see
>>>>>> lsdev -v, with device paths present, it is uefi:) =20
>>>>>=20
>>>>> What are you talking about?
>>>>> What is the point of entry - running system, loader?
>>>>>=20
>>>>> sysct machdep.bootmethod: BIOS
>>>>>=20
>>>>> This makes me quite sure that the system has booted via BIOS - as =
I'm sure
>>>>> since I've checked that many times. UEFI doesn't work on those =
systems
>>>>> with FreeBSD. I'm not sure antmore, but I tried also Windows 7 on =
those
>>>>> mainboards booting via UEFI - and I might recall that they failed =
also. I
>>>>> also recall that there were issues with earlier UEFI versions =
regarding
>>>>> booting only Windows 8/8.1 - and nothing else, but the fact that =
Linux
>>>>> worked confuses me a bit.
>>>>>=20
>>>>> If this ASRock crap (never ever again this brand!) doesn't work at =
all -
>>>>> who cares, I intend to purchase new server grade hardware. But the =
more
>>>>> puzzling issue is with the Fujitsu, which I consider serious and =
from the
>>>>> behaviour the Fujitsu failure looks exactly like the ASRock - =
Windows 7
>>>>> works, RedHat 7.5 works (I assume I can trust the Firmware =
settings when I
>>>>> disable CSM support, that the Firmware will only EFI/UEFI capable =
loader?
>>>>> Or is there a ghosty override somwhere to be expected?). Also on =
ASRock
>>>>> disabling CSM should ensure not booting a dual-bootstrap-capable =
system.
>>>>> This said, on the recent Fujitsu, it seems to boil down to a =
FreeBSD
>>>>> UEFI-firmware interaction problem, while the ASRock is still under
>>>>> suspicion to be broken by design. =20
>>>>>>=20
>>>>>> GPT partitions can never start from disk absolute sector 1; this =
is
>>>>>> because at sector 0 there is MBR (for compatibility), sector 1 is =
GPT
>>>>>> table and then sectors 2-33 have GPT partition table entries, so =
the
>>>>>> first possible data sector is 34 (absolute 34). Thats assuming =
512B
>>>>>> sectors. For details see UEFI 2.7 Chapter 5.3.1 page 131. =20
>>>>>=20
>>>>> Thanks for the explanation. That implies the installer did right, =
gpart
>>>>> did also right and therefore there must be an issue with the stuff =
located
>>>>> within the EFI partition? =20
>>>>=20
>>>> Ok, so, it is not about UEFI bootcode but BIOS, and if we reach =
BIOS loader
>>>> at all or not - that is, if the BIOS bootstrap is actually caring =
to read
>>>> the MBR code and start it, since once the MBR code is started, it =
is all
>>>> about our code. =20
>>>=20
>>> I'm getting confused a bit here. Do you mean by "BIOS" the CSM? or =
do you
>>> mean that specific portion of the UEFI firmware, which looks for the =
proper
>>> UEFI partition?
>>>=20
>>=20
>> BIOS as either native or CSM. Note that from boot code point of view =
the CSM
>> boot *is* BIOS boot, we have no access to UEFI features.
>>=20
>>>=20
>>> The boxes in question, most notably the more recent Fujitsu Esprimo =
Q956,
>>> refuse booting UEFI, even if properly setup (in terms of what =
FreeBSD
>>> provides on recent CURRENT) is applied and CSM is switched off in =
the
>>> firmware. Again: GPT partition scheme.
>>>=20
>>> The system boots properly if a second partition of type =
"freebsd-boot" is
>>> applied and bootcode is properly applied via "gpart bootcode -b =
/boot/pmbr
>>> -p /boot/gptboot -i 2 ada0" (ada0 is the device). =20
>>>>=20
>>>> btw, you can try to validate the installed boot blocks by using =
recent
>>>> enough loader (usb or iso) and then you can use from OK prompt: =20
>>>=20
>>> lsdev provides me with the follwoing informations (CSM enabled):
>>>=20
>>> OK lsdev
>>> disk devices:
>>> disk0: BIOS DRIVE C ...
>>>=20
>>> disk0p1: EFI
>>> disk0p2: FreeBSD BOOT
>>> disk0p3: FreeBSD SWAP
>>> disk0p4: FreeBSD ZFS
>>> zfs devices:
>>> zfs:zroot
>>>=20
>>> OK chain disk0
>>> open failed (so for disk0p{1-4}.
>>>=20
>>> OK chain zroot
>>> failed to read disk (just for completeness) =20
>>=20
>>=20
>> chain command does use only device name (such as disk0: or disk0p2: =
), but
>> not zfs pool as device. I just found I haven=E2=80=99t ported the =
code to read the
>> file.
>=20
> ??
>=20
>>=20
>> the point for chain command test is to see if the normal read and =
execute
>> would work, so in your case please try:
>>=20
>> chain disk0:
>=20
> As stated above, I did so, and the result is also mentioned above, I =
always get=20
> "open failed".
> This is the same for=20
>=20
> chain disk0
> chain disk0p1
> chain disk0p2
> chain disk0p3
> chain disk0p4
>=20
> as already said. CSM is enabled in this case.
sigh=E2=80=A6 chain command does take device as argument, device must =
always end with colon=E2=80=A6. in this case, the devil is in details:) =
as I wrote above, the command should be:
chain disk0:
The disk0p1: etc will only work when partition boot code was installed =
(which you most likely do not have - the only possible candidate could =
be FreeBSD ZFS partition).
>=20
>>=20
>> to read pmbr (512B) and execute it. The expected outcome would be =
that pmbr
>> boot code would browse the GPT, read stage1 from disk0p2: and execute =
it;
>> stage1 would detect FreeBSD ZFS from disk0p4: and load and
>> execute /boot/loader. If that will happen, it means the boot code in =
our
>> stages is just fine, but the bios (CSM) does not load pmbr=E2=80=A6. =
if thats true,
>> it would mean that you either need to use UEFI boot or need to have =
some hack
>> to fool the BIOS or just not use GPT on that machine with CSM.
>=20
> To make it clear here: The only way to boot this box is using CSM (as =
it is the
> same with the ASRock boards mentioned earlier). But my intention is to =
disable
> CSM and use a GPT/UEFI environment only! And GPT/UEFI doesn't work =
with
> FreeBSD, neither with 12-CURRENT, nor 11.2-RELENG.
>=20
> It would be nice if this could be fixed. I'm more interested in the =
fix on the
> recent Fujitsu device than the outdated ASRock crap, but if the fix =
for the
> Fujitsu Firmware could fix older issues as a byproduct, I'd appreciate =
that.
>=20
> Kind regards,
>=20
ok, somehow I have lost that part of the discussion. Well, you wrote =
that the UEFI boot fails when the first partition starts from sector 40 =
- does it mean you have boot when the partition will start from some =
other sector? I think, there is something else going on.
What you can do is to see if that firmware will offer you EFI shell =
option, from there you can try to start the bootx64.efi manually and see =
what error you will get. However, the number 1 cause for failing to =
start the bootloader in UEFI is secure boot - we do not support it and =
secure boot must be switched off.=20
However, they seem to claim "The Secure Boot option is available in the =
UEFI/BIOS of most if not all ASRock boards. It is disabled by =
default.=E2=80=9D=20
Still suggest to double check if thats really the case. Also, if the =
bootx64.efi start will fail and no messages are appearing on screen, =
then either there is something in firmware logs or you could get them =
from trying to start bootx64.efi from UEFI shell.
thds,
toomas
>=20
>>=20
>> rgds,
>> toomas
>>=20
>>>>=20
>>>> OK chain diskX:
>>>>=20
>>>> (replace X by correct disk number from lsdev) to read and start the =
MBR
>>>> code. If that is working, then its really about BIOS refusing to =
read the
>>>> MBR and execute it. =20
>>>=20
>>> See above.
>>>=20
>>> I do not get that far to the loader if CSM is disabled (pure UEFI). =
The
>>> same on the ASROCK boards.=20
>>>=20
>>> The ASRock systems boot off of an SSD with GPT partition scheme and =
UFS
>>> filesystem only (running recent 12-CURRENT), while the Esprimo box =
is also
>>> an SSD, but GPT/ZFS (11.2-RELENG).
>>>=20
>>> I do not doubt the principle here, since a bunch of Fujitsu servers =
around
>>> here boot off 12-CURRENT and 11.2-RELENG from GPT/UFS SSDs as well =
as
>>> GPT/ZFS SSDs. Not problem so far.
>>>=20
>>> I checked out for the most recent Firmware for the ASRock boards and =
applied
>>> the may, 2018 Spectre/Meltdown mitigation images found in the BETA =
section.
>>> No changes for boot at all.
>>>=20
>>> Can I do something to help?
>>>=20
>>>>=20
>>>> rgds,
>>>> toomas
>>>>=20
>>>=20
>>> Kind regards,
>>> oh
>>> _______________________________________________
>>> freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> =
mailing
>>> list https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> <https://lists.freebsd.org/mailman/listinfo/freebsd-current>; To
>>> unsubscribe, send any mail to =
"freebsd-current-unsubscribe@freebsd.org
>>> <mailto:freebsd-current-unsubscribe@freebsd.org>" =20
>>=20
>=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16439773-3E9A-40FF-99A1-32E97CCEE2C3>