From owner-freebsd-current@freebsd.org Fri Jul 13 11:00:11 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 DFD881033D91 for ; Fri, 13 Jul 2018 11:00:10 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 4B89C80223 for ; Fri, 13 Jul 2018 11:00:10 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LtIZH-1g2vdJ23nH-012sEy for ; Fri, 13 Jul 2018 13:00:02 +0200 Date: Fri, 13 Jul 2018 13:00:01 +0200 From: "O. Hartmann" To: freebsd-current Subject: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:r1ivH10fWqe+xZnUId6MtXowSRrTOx4eOG3TEa78rbE7ranJoWE d9HhUJPQkaGn6qGr6H2iYQdTOd+u48egNX07WpwSClCxSz13fZgy0sn22HCm7bPRK6Asgnp ftuUpPIQXOiOSy9qet9MvfUf3rCqPSlk0I61bMKwuYmd4P1QbAj8uGzdUa98RreOg1SoyUp ZQeKfASvUL+u2vqUfsItg== X-UI-Out-Filterresults: notjunk:1;V01:K0:VJlegpgL9is=:JnwGe4JAkbLtz2v5Vs9nzC ujrERmwmYCa5e96MKQfUmI0rGli6DCf9FC7DJUkNvpBcwaXElV5g3f4DJhsg2QvFiM5XiSrcS xV5zQSyeNubzVg/QntUcUha32ePQESzXowjbu2yuNgnQZxevFKATcUhkMq2/o5R4UbEJgw0Fz dJiqJs5nwN/eedpJRYQkhdqwQ7WFrNS0zoKa27dkJ4DpfgAOBvfN5c2UicI9ujq+vyL3Q2kvu HD61SYavTgZBXX8A1PFui80aNpiFLGGJwTtMxFqkq5HZaAxrxrqu/L7oQGVzpbT8BVaGXE7f/ tYJ5orl1QqXSHD2hu7Kucm0DAtRSOp08D2UOqEObOl+48eXUE8+LvdIIGZwGpQzwl89izAa5l zeNISRuPKq6jskIlIyXe01/YyCDcGC3mSWvoRvQtxCg2C0Vo7lDmCVwRndXaCURzGWWgJSPY6 GH1/GRALKC91KTNTJZRlZqEY7/rqnsEtEaBud1EKo5PRhjfLUQsQIuHm5PsrgGyYz3fgbD9Zq 8D2f55ZbXJ4BOtbK9S0GnEL+Tvz84OkuM7XwIb5vTOSBq3yABPNYOITkk2Kl1Irm/zXK1pn2+ luhh39c7DHF0zQmhYuf6kVrU6ifE/6qA7VrgJ9mLBKnOoZwdUbSK5PGocig1f/XYrNkKAX7+b OYxRepuMQ7p5M0PAwuERZ4gbVvaNBXkIEyh5x5/Qm2rCdhjQx4tPdSBXq20k6+Q350HmZlml8 Vf9arHFlr6SiTiB2+S1wVUvl9hYHFp1vweS7mx7fSwi1e0pcvrhu1G4Odrb9Pe7p9thQGIHMj rfKA4ec 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 11:00:11 -0000 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? Thanks in advance, Oliver