Date: Tue, 24 Jul 2018 07:16:45 +0200 From: "O. Hartmann" <ohartmann@walstatt.org> To: Toomas Soome <tsoome@me.com> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180724071514.6cb9d111@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <80523BE6-C035-482D-B134-23812183DE83@me.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 23 Jul 2018 10:56:04 +0300
Toomas Soome <tsoome@me.com> wrote:
> > 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> wrot=
e:
> >>>>>=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 availabl=
e AMI
> >>>>> firmware revision, dating to 2013. This is for the Z77-Pro4-M revis=
ion
> >>>>> 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 avail=
able,
> >>>>> 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 reso=
ltion
> >>>>> as long the GPU supports EFI GOP. Looking with gpart at the USB fla=
sh
> >>>>> drives reveals that the EFI partition starts at block 1 of the devi=
ce
> >>>>> 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 boa=
rds,
> >>>>> I tried years ago some LinuxRed Hat and Suse with UEFI and that wor=
ked -
> >>>>> 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-ve=
rsion
> >>>> 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 tho=
se
> >>> mainboards booting via UEFI - and I might recall that they failed als=
o. I
> >>> also recall that there were issues with earlier UEFI versions regardi=
ng
> >>> 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 al=
l -
> >>> who cares, I intend to purchase new server grade hardware. But the mo=
re
> >>> 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 w=
hen I
> >>> disable CSM support, that the Firmware will only EFI/UEFI capable loa=
der?
> >>> Or is there a ghosty override somwhere to be expected?). Also on ASRo=
ck
> >>> disabling CSM should ensure not booting a dual-bootstrap-capable syst=
em.
> >>> 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, gpa=
rt
> >>> did also right and therefore there must be an issue with the stuff lo=
cated
> >>> within the EFI partition? =20
> >>=20
> >> Ok, so, it is not about UEFI bootcode but BIOS, and if we reach BIOS l=
oader
> >> at all or not - that is, if the BIOS bootstrap is actually caring to r=
ead
> >> the MBR code and start it, since once the MBR code is started, it is a=
ll
> >> about our code. =20
> >=20
> > I'm getting confused a bit here. Do you mean by "BIOS" the CSM? or do y=
ou
> > mean that specific portion of the UEFI firmware, which looks for the pr=
oper
> > 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 Q95=
6,
> > 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/p=
mbr
> > -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 t=
o read the
> file.
??
>=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:
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
chain disk0
chain disk0p1
chain disk0p2
chain disk0p3
chain disk0p4
as already said. CSM is enabled in this case.
>=20
> to read pmbr (512B) and execute it. The expected outcome would be that pm=
br
> 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.
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 disa=
ble
CSM and use a GPT/UEFI environment only! And GPT/UEFI doesn't work with
FreeBSD, neither with 12-CURRENT, nor 11.2-RELENG.
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.
Kind regards,
oh
>=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 a=
lso
> > an SSD, but GPT/ZFS (11.2-RELENG).
> >=20
> > I do not doubt the principle here, since a bunch of Fujitsu servers aro=
und
> > 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 ap=
plied
> > the may, 2018 Spectre/Meltdown mitigation images found in the BETA sect=
ion.
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180724071514.6cb9d111>