Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Jul 2018 13:00:01 +0200
From:      "O. Hartmann" <ohartmann@walstatt.org>
To:        freebsd-current <freebsd-current@freebsd.org>
Subject:   [UEFI] Boot issues on some UEFI implementations
Message-ID:  <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de>

next in thread | raw e-mail | index | archive | help
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 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180713130001.219a0a84>