Date: Tue, 24 Jul 2018 09:30:08 +0300 From: Toomas Soome <tsoome@me.com> To: Allan Jude <allanjude@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <5BE9BA38-4B13-4BC8-A0CE-EEE4F34CFF08@me.com> In-Reply-To: <fd135b65-bc86-0e73-a6a4-c420304b8d30@freebsd.org> References: <20180713130001.219a0a84@freyja.zeit4.iv.bundesimmobilien.de> <fd135b65-bc86-0e73-a6a4-c420304b8d30@freebsd.org>
index | next in thread | previous in thread | raw e-mail
> On 24 Jul 2018, at 09:20, Allan Jude <allanjude@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-unsubscribe@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, toomashome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5BE9BA38-4B13-4BC8-A0CE-EEE4F34CFF08>