Date: Fri, 13 Jul 2018 14:26:51 +0300 From: Toomas Soome <tsoome@me.com> To: "O. Hartmann" <ohartmann@walstatt.org> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <68505F98-E840-4148-9E48-BDB350F7431A@me.com> In-Reply-To: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 13 Jul 2018, at 14:00, O. Hartmann <ohartmann@walstatt.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?68505F98-E840-4148-9E48-BDB350F7431A>