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>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 24 Jul 2018, at 09:20, Allan Jude <allanjude@freebsd.org> wrote: >=20 > 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. >>=20 >> 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. >>=20 >> 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). >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> Can someone shed some light onto this?=20 >>=20 >> Thanks in advance, >>=20 >> Oliver=20 >> _______________________________________________ >> 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" >>=20 >=20 > 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 >=20 > Although both of these should only impact BIOS boot, not UEFI, you = never > know. >=20 > The other option is to try an ESP (EFI System Partition) that is > formatted FAT32 instead of FAT12/FAT16) >=20 >=20 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5BE9BA38-4B13-4BC8-A0CE-EEE4F34CFF08>