Date: Fri, 13 Jul 2018 18:44:23 +0300 From: Toomas Soome <tsoome@me.com> To: "O. Hartmann" <o.hartmann@walstatt.org> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <680FBB42-75BF-427F-AA3B-6D864E83ED1F@me.com> In-Reply-To: <20180713164447.42430301@thor.intern.walstatt.dynvpn.de> References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> <68505F98-E840-4148-9E48-BDB350F7431A@me.com> <20180713164447.42430301@thor.intern.walstatt.dynvpn.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 13 Jul 2018, at 17:44, O. Hartmann <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>> 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 > 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 > 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 >>=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 > 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 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. 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: OK chain diskX: (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. rgds, toomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?680FBB42-75BF-427F-AA3B-6D864E83ED1F>