From owner-freebsd-current@freebsd.org Tue Jul 24 05:17:07 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19DE410407BB for ; Tue, 24 Jul 2018 05:17:07 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CA557FB80 for ; Tue, 24 Jul 2018 05:17:06 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LyB6P-1g2spE3YEX-015W93; Tue, 24 Jul 2018 07:16:54 +0200 Date: Tue, 24 Jul 2018 07:16:45 +0200 From: "O. Hartmann" To: Toomas Soome Cc: freebsd-current 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:kaldUXvoNbvSJiQgZs0oudw04hQJ8TXGk8BteXYtUdpS30A/5P3 ILx/szbRdULvy2HtdGivh/UWfwpg05BCEk8Z3bNFnu5GgLgiqU/w4VOXrmImlhEaF0ux2XF JwR3bMuGNpW1Yj3Jf4Udiil7JBj+5zWU14S2oaNkz85xWeee2zDKxXTrU2JYEkNVvbPBtQQ FdkMz3gQVdrP44b7H2k0g== X-UI-Out-Filterresults: notjunk:1;V01:K0:XofDm7xAoQM=:TpGe8/xlwtImGlRPOo83qF SAufpTDbK7etPp+fJKuuKSq1vndXKfL4MJc/8HSXGzy9KLZR9hPonLIvroKxKLASd2yUA33dr /+/loRrJY8R4YTZ338PUMI92bS6C7utIaOeMfLuZsVGPjcSu8mCgAqW8yO6oizzGDu3aQCwkx 8fymEj+NAHzKdUOxuxvoWDLsXklwCL8cJAXUvu/i7dHZNaXEZNnvRHxpRSyRtUEbKXdXGJNaN 3vjd6A5VRwZgiU5gMWQ9Q/aOstQE+XP3b8w1mXf4Ko8fkLMnBbMTGL87Pb23HMwM/ZWazaNGf DWS6vUVw+KLZjLDsyUIGYbZVxNgzhNUArIf/v7BNT/TunZ5oe/v/Bu7x93iCLMUTBrwcITnXC +8zsYcqWvvlQ81AH/fUQGM5mleLz02ZSjU5WSuvi8AEI4wKSs7Fd+4vuK7t+k9g4boGd+LHPc Ri5cCPVpNsYxySLVxpBz3vKBczZn9AScv8ogoTm4CqJ9sisBfcCYbpeWq+tvB4kYCtR+aVRMz 8bHlw5U85on/F1sPCYdlgDvv/ECVUPS6mWllbPWXHsOXWaLJbBotg8MNsABloJZsEUOa4wvJV wzf0v/q8u7EOF+N3G1pHhiFilH3U1jpiPKAAQyH+FC75Qps/Ocj2MFMdaTZp0UIchkEvA7iLb NfLrZoLThqDqUK3uNpdbp1OHoXeyLKDWn0ArX3Cocn2ilmIDYmvdpCqcbmLnEZ80BVBBJN9C7 ii2Vc8gP11IXOLFXsofv/A1b2PgVTxwJz3HyMPWsx97q1yagui9l+96Ur9uvgQYpNYvjzPFFb TXOIZsh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 05:17:07 -0000 On Mon, 23 Jul 2018 10:56:04 +0300 Toomas Soome wrote: > > On 23 Jul 2018, at 10:27, O. Hartmann wrote: > >=20 > > On Fri, 13 Jul 2018 18:44:23 +0300 > > Toomas Soome > wrote: > > =20 > >>> On 13 Jul 2018, at 17:44, O. Hartmann >>> > wrote: > >>>=20 > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA512 > >>>=20 > >>> Am Fri, 13 Jul 2018 14:26:51 +0300 > >>> Toomas Soome >>> >> schrieb:=20 > >>>>> On 13 Jul 2018, at 14:00, O. Hartmann 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 mailing > > list https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To > > unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > > " =20 >=20