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"