From owner-freebsd-current@freebsd.org Fri Jul 13 12:27:17 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 A013F103A714 for ; Fri, 13 Jul 2018 12:27:17 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (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 489E383971 for ; Fri, 13 Jul 2018 12:27:17 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PBS00400XWS0600@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Fri, 13 Jul 2018 11:26:56 +0000 (GMT) Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PBS002V6YGSRF40@st13p35im-asmtp002.me.com>; Fri, 13 Jul 2018 11:26:56 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-07-13_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1807130089 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [UEFI] Boot issues on some UEFI implementations From: Toomas Soome In-reply-to: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> Date: Fri, 13 Jul 2018 14:26:51 +0300 Cc: freebsd-current Content-transfer-encoding: quoted-printable Message-id: <68505F98-E840-4148-9E48-BDB350F7431A@me.com> References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.3445.9.1) 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 12:27:18 -0000 > 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 The first thing to check is if the secure boot is disabled. We do not = support secure boot at all at this time.=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:) 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. rgds, toomas