> 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
256MB:)
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,
toomas
_______________________________________________
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"
