Re: [UEFI] Boot issues on some UEFI implementations

On Tue, 24 Jul 2018 02:20:00 -0400
Allan Jude <allanjude_at_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_at_freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_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)

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 format
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?

From 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 newly
created FAT32 formatted EFI partition, I struggle then with a quick
installation of FreeBSD using "bsdinstall". Having created according to a pure
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 structure
on ZFS for the installation without destroying the initial layout :-( 

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. 

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.

>