Re: [UEFI] Boot issues on some UEFI implementations

> 
> 
> > On 13 Jul 2018, at 14:00, O. Hartmann <ohartmann_at_walstatt.org> 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.

This sounds like a tool showing you the protective MBR which
is part of GPT.

> > 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. 
> 
> 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.
> 

One must be carefull when looking at a GPT scheme device,
as it still has a "protective MBR" at sector 0 which
covers sectors 1 to N of the device.  Legacy (mbr only)
tools well see this and show it as type 0xEE covering
the whole device.

Some modern tools still show this as an MBR, but
then also show the GPT's inside it.

Some tools never show you the protective MBR.


-- 
Rod Grimes                                                 rgrimes_at_freebsd.org