From owner-freebsd-current@freebsd.org Fri Jul 13 16:44:35 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 73E351043927 for ; Fri, 13 Jul 2018 16:44:35 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A9308E645 for ; Fri, 13 Jul 2018 16:44:35 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PBT00700AAAZD00@st13p35im-asmtp001.me.com> for freebsd-current@freebsd.org; Fri, 13 Jul 2018 15:44:28 +0000 (GMT) Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PBT00KZ4AE0RL00@st13p35im-asmtp001.me.com>; Fri, 13 Jul 2018 15:44:27 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-07-13_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1807130135 From: Toomas Soome Message-id: <680FBB42-75BF-427F-AA3B-6D864E83ED1F@me.com> MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [UEFI] Boot issues on some UEFI implementations Date: Fri, 13 Jul 2018 18:44:23 +0300 In-reply-to: <20180713164447.42430301@thor.intern.walstatt.dynvpn.de> Cc: freebsd-current To: "O. Hartmann" References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> <68505F98-E840-4148-9E48-BDB350F7431A@me.com> <20180713164447.42430301@thor.intern.walstatt.dynvpn.de> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 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: Fri, 13 Jul 2018 16:44:35 -0000 > 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 = 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