Date: Mon, 23 Jul 2018 10:56:04 +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: <80523BE6-C035-482D-B134-23812183DE83@me.com> In-Reply-To: <20180723092735.12a5d2a8@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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
> 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
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
> 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
> 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)
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.
the point for chain command test is to see if the normal read and =
execute would work, so in your case please try:
chain disk0:
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.
rgds,
toomas
>>=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
> 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>"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?80523BE6-C035-482D-B134-23812183DE83>