From owner-freebsd-current@freebsd.org Mon Jul 23 07:33:00 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 0E2151041E16 for ; Mon, 23 Jul 2018 07:33:00 +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 6DD47700D1 for ; Mon, 23 Jul 2018 07:32:59 +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 0LpPg1-1gAoGX06AH-00fDuf; Mon, 23 Jul 2018 09:27:40 +0200 Date: Mon, 23 Jul 2018 09:27:38 +0200 From: "O. Hartmann" To: Toomas Soome Cc: freebsd-current Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180723092735.12a5d2a8@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <680FBB42-75BF-427F-AA3B-6D864E83ED1F@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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:FwH7604Bdkg7+LeRZyqI5sZPYvPdQ9n93QN75WS1RBxIrmgevl1 BePDmIC+tZbCn3jLX1idzhf0lKUlmFxjzsBDJCI89yc9bMjgLiCk5hu7AmfEnDmA0RyVnwD Cl2902cx7XkVIMK8LA5sORR7pOtv8d/K/lmWNV3LqwLTIU5dTeZyzwm3mNn6K67stRa87B9 u7ZzCTAyCRKoXV+qW447Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:5Hj+822oEuY=:+K0A32isDgl1R7kzVG8GuM TPFfXEb0wZyjiohdO63FToKWQexl30onI7h32LObfikYgHdUYdQMB/uWiU0SQPPjDYPOPGTP7 23KjMhk11HFndCrzyHzImpsllzP1Z2fiP8OJHXqaEtJfkWTQ5+sHt1BvUlu3+R4Tf3/jiqfJJ PFPVdTwVZcrYPoV+Uz5OQinlrvfTkcvyGPkuQifWb/9FNM2OnRmQUrHWICHXC1oILSqZ46ypt 6ahusAZScF5MWFL/xdW8Bd7+vRsTUc7wU/5RJWtPIGwep7p+zjdmJzZxQhTqg9vtSDX0H97pM ztaeJL+CJixEVaLHal7dyr0Aj+/nUPBnsem9io/yVaRhTmUfKtA0fQutOIu36sGV6A9fbGp9z Ddj44vKO+gh0T3o9My8uJWTDtdpmBGTZ/jEc+On5yUykoF2UzSkCL+XKMm4BdjiCPW0nNfg5a 89zb7mMgaU4hCFA0LcaUdgFK3pEYGfIU0R4FCmKfthaElZdQHiDYTIfNMius1YPWBh7C4iDhk UwxkXjjbTaEZEBgFWVP4hb/LYiMAc4ilQZtzqcnMgFxjV3eUsyekf7cmXnIL1ZPXw9UK11JfD BNZfJ9tnF3rUSfFbaNYGu3zlHMnA8K50UOk1WtcT4nM1008vfNRK7lFpEsXfOd32n6VctdtbQ 4tyUsrWyVpnl5aMXT1hPe5IDhWIEgs3jMa1CmYSbvtPw0CyXZIhh1Rm/gSMeiRsce2bWVkc/A 7sOIrCxPvuDsfZsMDVCFAwUUqusE9emvJrDZL3TYP8rAWerENHZmrvZhTCEQ62N8o5waccxsu dMOxZo8 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: Mon, 23 Jul 2018 07:33:00 -0000 On Fri, 13 Jul 2018 18:44:23 +0300 Toomas Soome wrote: > > On 13 Jul 2018, at 17:44, O. Hartmann wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Am Fri, 13 Jul 2018 14:26:51 +0300 > > Toomas Soome > schrieb: > > > >>> On 13 Jul 2018, at 14:00, O. Hartmann wrote: > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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). > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> Can someone shed some light onto this? > >>> > >> > >> The first thing to check is if the secure boot is disabled. We do not > >> support secure boot at all at this time. > > > > Secure boot is in every scenario disabled! > > > >> > >> 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:) > > > > What are you talking about? > > What is the point of entry - running system, loader? > > > > sysct machdep.bootmethod: BIOS > > > > 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. > > > > 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. > >> > >> 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. > > > > 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? > > 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. 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? 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. 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). > > 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: lsdev provides me with the follwoing informations (CSM enabled): OK lsdev disk devices: disk0: BIOS DRIVE C ... disk0p1: EFI disk0p2: FreeBSD BOOT disk0p3: FreeBSD SWAP disk0p4: FreeBSD ZFS zfs devices: zfs:zroot OK chain disk0 open failed (so for disk0p{1-4}. OK chain zroot failed to read disk (just for completeness) > > 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. See above. I do not get that far to the loader if CSM is disabled (pure UEFI). The same on the ASROCK boards. 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). 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. 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. Can I do something to help? > > rgds, > toomas > Kind regards, oh