Date: Tue, 24 Jul 2018 14:22:59 +0200 From: "O. Hartmann" <o.hartmann@walstatt.org> To: Allan Jude <allanjude@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <20180724142255.23e120c6@freyja.zeit4.iv.bundesimmobilien.de> 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 Tue, 24 Jul 2018 02:20:00 -0400 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 dri= ves > > 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 boa= rds > > 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 Q9= 56, > > 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 boa= rds > > 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 resoltio= n as > > long the GPU supports EFI GOP. Looking with gpart at the USB flash driv= es > > 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 iss= ues > > 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.o= rg" > > =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) How can I detect the format of the EFI partition? Suppose I create the EFI partition via gpart, 12-CURRENT installer or 11.2-RELENG installer, what fo= rmat would that EFI partition be (the partition scheme I use is always GPT so far and as far as I know)? What format is the result, if I would dd /boot/boot1.efifat to the EFI partition? =46rom a first glimpse I guess its FAT12/16, since creating an EFI partition = via gpart myself of 500m and try to newfs_msdos -F 32, I receive an error about insufficient clusters with no further parameters. I tried to create a 512m partition fiddling around with the blocksize option -b of newfs_msdos When created manually /dev/gpt/efiboot0, formatted FAT32 (with -b 512 or -b 1024, I forgot) and preparing/copying the content of /boot/boot1.efifat (mdconfig mounted ...) with proper folder structure to efi/boot/ on the new= ly created FAT32 formatted EFI partition, I struggle then with a quick installation of FreeBSD using "bsdinstall". Having created according to a p= ure ZFS disk swap, gptboot (to be on the secure side if UEFI fails again) and a zroot ZFS pool, the dumb installer doesn't let me create a filesystem struc= ture on ZFS for the installation without destroying the initial layout :-(=20 So I stopped at that point and tried booting the box with only the FAT32 EFI/ESP partition with the loader copied from boot1.efifat as described.=20 The result is annoying, the ESPRIMO Q956 firmware shows up with some kind of testing tool/shell as reported in the initial posting of mine. I'd have expected some signs from the FreeBSD UEFI bootloader so far at this point, = but I might be mislead here. I also have applied the "gpart set -a" commands, without any effect. >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180724142255.23e120c6>