On Tue, 24 Jul 2018 02:20:00 -0400 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 V22.214.171.124 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 > > _______________________________________________ > > firstname.lastname@example.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) 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. > _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"