> On 24 Jul 2018, at 09:20, Allan Jude <allanj...@freebsd.org> wrote:
> 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.
>> 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 
>> _______________________________________________
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 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
> Although both of these should only impact BIOS boot, not UEFI, you never
> know.
> The other option is to try an ESP (EFI System Partition) that is
> formatted FAT32 instead of FAT12/FAT16)

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 

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,

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to