Hash: SHA512

Am Fri, 13 Jul 2018 14:26:51 +0300
Toomas Soome <tso...@me.com> schrieb:

> > On 13 Jul 2018, at 14:00, O. Hartmann <ohartm...@walstatt.org> 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? 
> >   
> The first thing to check is if the secure boot is disabled. We do not support 
> secure
> boot at all at this time.

Secure boot is in every scenario disabled!
> If you have efi or bios version running - you can check from either console 
> variable
> value (it can have efi or vidconsole or comconsole) or better yet, see if 
> efi-version
> is set (show efi-version) - if efi-version is not set, it is BIOS loader 
> running.
> Another indirect way is to see lsdev -v, with device paths present, it is 
> uefi:)

What are you talking about?
What is the point of entry - running system, loader?

sysct machdep.bootmethod: BIOS

This makes me quite sure that the system has booted via BIOS - as I'm sure 
since I've
checked that many times. UEFI doesn't work on those systems with FreeBSD. I'm 
not sure
antmore, but I tried also Windows 7 on those mainboards booting via UEFI - and 
I might
recall that they failed also. I also recall that there were issues with earlier 
versions regarding booting only Windows 8/8.1 - and nothing else, but the fact 
that Linux
worked confuses me a bit.

If this ASRock crap (never ever again this brand!) doesn't work at all - who 
cares, I
intend to purchase new server grade hardware. But the more puzzling issue is 
with the
Fujitsu, which I consider serious and from the behaviour the Fujitsu failure 
exactly like the ASRock - Windows 7 works, RedHat 7.5 works (I assume I can 
trust the
Firmware settings when I disable CSM support, that the Firmware will only 
capable loader? Or is there a ghosty override somwhere to be expected?). Also 
on ASRock
disabling CSM should ensure not booting a dual-bootstrap-capable system. This 
said, on
the recent Fujitsu, it seems to boil down to a FreeBSD UEFI-firmware interaction
problem, while the ASRock is still under suspicion to be broken by design.  

> GPT partitions can never start from disk absolute sector 1; this is because 
> at sector 0
> there is MBR (for compatibility), sector 1 is GPT table and then sectors 2-33 
> have GPT
> partition table entries, so the first possible data sector is 34 (absolute 
> 34). Thats
> assuming 512B sectors.  For details see UEFI 2.7 Chapter 5.3.1 page 131.

Thanks for the explanation. That implies the installer did right, gpart did 
also right
and therefore there must be an issue with the stuff located within the EFI 

> rgds,
> toomas

Thank you very much and kind regards,


> _______________________________________________
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to