From owner-freebsd-current@freebsd.org Tue Jul 24 07:30:40 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 D65571043148 for ; Tue, 24 Jul 2018 07:30:39 +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 8393A834D9; Tue, 24 Jul 2018 07:30:39 +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 <0PCC00C00Y0I5200@st13p35im-asmtp001.me.com>; Tue, 24 Jul 2018 06:30:12 +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 <0PCC00PIIY283530@st13p35im-asmtp001.me.com>; Tue, 24 Jul 2018 06:30:11 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-24_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=8 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1807240069 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: Date: Tue, 24 Jul 2018 09:30:08 +0300 Cc: freebsd-current@freebsd.org Content-transfer-encoding: quoted-printable Message-id: <5BE9BA38-4B13-4BC8-A0CE-EEE4F34CFF08@me.com> References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> To: Allan Jude 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: Tue, 24 Jul 2018 07:30:40 -0000 > On 24 Jul 2018, at 09:20, Allan Jude wrote: >=20 > On 2018-07-13 07: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. >>=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 >> Thanks in advance, >>=20 >> Oliver=20 >> _______________________________________________ >> 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 > If you are up for experimenting, see if either of these results in = your > system booting: > gpart set -a active ada0 > gpart set -a lenovofix ada0 >=20 > Although both of these should only impact BIOS boot, not UEFI, you = never > know. >=20 > The other option is to try an ESP (EFI System Partition) that is > formatted FAT32 instead of FAT12/FAT16) >=20 >=20 oops, indeed, and not just FAT32, but rather large one; first, the = minimum size for FAT32 is ~32MB - it can not be smaller, and with 4kn = you can not get below 256MB:) but, I recall there were some reports about systems refusing to boot if = ESP was not FAT32. I can not remember if there was some size limit = involved too or not (the UEFI specification does not set requirements = for ESP size). my 2cents, toomas