Re: [UEFI] Boot issues on some UEFI implementations

[Warner Losh]

[[ context trimmed ]]

On Fri, Jul 27, 2018 at 12:03 PM, Warner Losh  wrote:

>
>
> On Fri, Jul 27, 2018 at 11:05 AM, O. Hartmann 
> wrote:
>
>>
>> Just to add another success on ASRock Z77-Pro4 (800k ESP, FAT12) and
>> ASRock Z77-Pro4M
>> (300mb ESP, FAT32).
>>
>> On this firmware, I did not have to define/copy the bootloader
>> within /efi/freebd/BOOTx64.efi. It was sufficient to add an EFI variable
>> as described in
>> the manpage efibootmgr(8).
>>
>> The only pitfall on this firmware (very old, last functional update 2013,
>> Spectre/Meltodown mitigation only May 2018) was that I wasn't able to
>> activate variable
>> ""! Creating
>>
>> efibootmgr -c -l /mnt/efi/boot/BOOTx64.efi -L FreeBSD-12
>>
>> which results in "Boot"
>>
>> and followed by
>>
>> efibootmgr -a 
>>
>> or
>>
>> efibootmgr -n 
>>
>> resulted in "No such variable" or similar.
>>
>
> Yes. that's a bogus sanity check in the code. I've removed it and will
> commit in a moment.
>

that should be fixed as of r336768.


> I had to perform the very same task again to gain variable 0001 and then I
>> was able to
>> "activate" variable . This might be due to the fact the only variable
>> defined at all
>> was Boot0005 pointing to the most recent USB flash device with 12-CURRENT
>> from 2018-07-26
>> I just prepared.
>>
>
That part is weird


> Now, also those boxes boot via UEFI (one, 800k ESP with the /efi/boot
>> folder, the other,
>> 300mb ESP, with a copy /efi/freebsd as I had to do on the Fujitsu ESPRIMO
>> Q956 firmware).
>
>
> OK.
>

Cool!...

Warner
___
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"

Re: [UEFI] Boot issues on some UEFI implementations

[Warner Losh]

On Fri, Jul 27, 2018 at 11:05 AM, O. Hartmann 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am Fri, 27 Jul 2018 13:59:44 +0300
> Toomas Soome  schrieb:
>
> > > On 27 Jul 2018, at 13:02, O. Hartmann  wrote:
> > >
> > > On Fri, 27 Jul 2018 08:54:48 +0300
> > > Toomas Soome  wrote:
> > >
> > >>> On 27 Jul 2018, at 08:46, O. Hartmann 
> wrote:
> > >>>
> > >>> On Thu, 26 Jul 2018 19:23:43 +0300
> > >>> Toomas Soome  wrote:
> > >>>
> > >>> (reply inline/at the end)
> > >>>
> > >>>
> > > On 26 Jul 2018, at 16:58, O. Hartmann 
> wrote:
> > >
> > > On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
> > > "Rodney W. Grimes"  > > > wrote:
> >  On 25 Jul 2018, at 12:10, O. Hartmann 
> wrote:
> > 
> >  On Wed, 25 Jul 2018 11:46:07 +0300
> >  Toomas Soome  wrote:
> > 
> > >> On 25 Jul 2018, at 10:59, O. Hartmann 
> wrote:
> > >>
> > >> On Tue, 24 Jul 2018 08:53:36 +0300
> > >> Toomas Soome  wrote:
> > >>
> > >>
> > >> Hello  Toomas Soome,
> > >>
> > >> I CC Allan Jude since I discovered something  weird today
> regarding
> > >> the UEFI boot capabilities of USB flash devices and SSDs. See
> below.
> > >>
> >  On 24 Jul 2018, at 08:16, O. Hartmann <
> ohartm...@walstatt.org>
> >  wrote:
> > 
> >  On Mon, 23 Jul 2018 10:56:04 +0300
> >  Toomas Soome  wrote:
> > 
> > >> On 23 Jul 2018, at 10:27, O. Hartmann <
> ohartm...@walstatt.org>
> > >> wrote:
> > >>
> > >> On Fri, 13 Jul 2018 18:44:23 +0300
> > >> Toomas Soome mailto:tso...@me.com>>
> wrote:
> > >>
> >  On 13 Jul 2018, at 17:44, O. Hartmann <
> o.hartm...@walstatt.org
> >  > wrote:
> > 
> >  -BEGIN PGP SIGNED MESSAGE-
> >  Hash: SHA512
> > 
> >  Am Fri, 13 Jul 2018 14:26:51 +0300
> >  Toomas Soome mailto:tso...@me.com>
> >  >>
> >  schrieb:
> > >> On 13 Jul 2018, at 14: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
> > 

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Fri, 27 Jul 2018 13:59:44 +0300
Toomas Soome  schrieb:

> > On 27 Jul 2018, at 13:02, O. Hartmann  wrote:
> > 
> > On Fri, 27 Jul 2018 08:54:48 +0300
> > Toomas Soome  wrote:
> >   
> >>> On 27 Jul 2018, at 08:46, O. Hartmann  wrote:
> >>> 
> >>> On Thu, 26 Jul 2018 19:23:43 +0300
> >>> Toomas Soome  wrote:
> >>> 
> >>> (reply inline/at the end)
> >>> 
> >>>   
> > On 26 Jul 2018, at 16:58, O. Hartmann  wrote:
> > 
> > On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
> > "Rodney W. Grimes"  > > wrote: 
>  On 25 Jul 2018, at 12:10, O. Hartmann  
>  wrote:
>  
>  On Wed, 25 Jul 2018 11:46:07 +0300
>  Toomas Soome  wrote:
>    
> >> On 25 Jul 2018, at 10:59, O. Hartmann  
> >> wrote:
> >> 
> >> On Tue, 24 Jul 2018 08:53:36 +0300
> >> Toomas Soome  wrote:
> >> 
> >> 
> >> Hello  Toomas Soome,
> >> 
> >> I CC Allan Jude since I discovered something  weird today regarding
> >> the UEFI boot capabilities of USB flash devices and SSDs. See 
> >> below.
> >>   
>  On 24 Jul 2018, at 08:16, O. Hartmann 
>  wrote:
>  
>  On Mon, 23 Jul 2018 10:56:04 +0300
>  Toomas Soome  wrote:
>    
> >> On 23 Jul 2018, at 10:27, O. Hartmann 
> >> wrote:
> >> 
> >> On Fri, 13 Jul 2018 18:44:23 +0300
> >> Toomas Soome mailto:tso...@me.com>> wrote:
> >>   
>  On 13 Jul 2018, at 17:44, O. Hartmann 
>    > wrote:
>  
>  -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA512
>  
>  Am Fri, 13 Jul 2018 14:26:51 +0300
>  Toomas Soome mailto:tso...@me.com>
>  >>
>  schrieb: 
> >> On 13 Jul 2018, at 14: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
> 

Re: [UEFI] Boot issues on some UEFI implementations

[Toomas Soome]

> On 27 Jul 2018, at 13:02, O. Hartmann  wrote:
> 
> On Fri, 27 Jul 2018 08:54:48 +0300
> Toomas Soome  wrote:
> 
>>> On 27 Jul 2018, at 08:46, O. Hartmann  wrote:
>>> 
>>> On Thu, 26 Jul 2018 19:23:43 +0300
>>> Toomas Soome  wrote:
>>> 
>>> (reply inline/at the end)
>>> 
>>> 
> On 26 Jul 2018, at 16:58, O. Hartmann  wrote:
> 
> On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
> "Rodney W. Grimes"  > wrote:   
 On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
 
 On Wed, 25 Jul 2018 11:46:07 +0300
 Toomas Soome  wrote:
 
>> On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
>> 
>> On Tue, 24 Jul 2018 08:53:36 +0300
>> Toomas Soome  wrote:
>> 
>> 
>> Hello  Toomas Soome,
>> 
>> I CC Allan Jude since I discovered something  weird today regarding
>> the UEFI boot capabilities of USB flash devices and SSDs. See below.
>> 
 On 24 Jul 2018, at 08:16, O. Hartmann 
 wrote:
 
 On Mon, 23 Jul 2018 10:56:04 +0300
 Toomas Soome  wrote:
 
>> On 23 Jul 2018, at 10:27, O. Hartmann 
>> wrote:
>> 
>> On Fri, 13 Jul 2018 18:44:23 +0300
>> Toomas Soome mailto:tso...@me.com>> wrote:
>> 
 On 13 Jul 2018, at 17:44, O. Hartmann >>> > wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 Am Fri, 13 Jul 2018 14:26:51 +0300
 Toomas Soome mailto:tso...@me.com>
 >>
 schrieb:   
>> On 13 Jul 2018, at 14: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? 
>> 
> 
> The first thing to check is if the secure boot is disabled. We
> do not support secure boot at all at this time.

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

On Fri, 27 Jul 2018 08:54:48 +0300
Toomas Soome  wrote:

> > On 27 Jul 2018, at 08:46, O. Hartmann  wrote:
> > 
> > On Thu, 26 Jul 2018 19:23:43 +0300
> > Toomas Soome  wrote:
> > 
> > (reply inline/at the end)
> > 
> >   
> >>> On 26 Jul 2018, at 16:58, O. Hartmann  wrote:
> >>> 
> >>> On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
> >>> "Rodney W. Grimes"  >>> > wrote:   
> >> On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
> >> 
> >> On Wed, 25 Jul 2018 11:46:07 +0300
> >> Toomas Soome  wrote:
> >>   
>  On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
>  
>  On Tue, 24 Jul 2018 08:53:36 +0300
>  Toomas Soome  wrote:
>  
>  
>  Hello  Toomas Soome,
>  
>  I CC Allan Jude since I discovered something  weird today regarding
>  the UEFI boot capabilities of USB flash devices and SSDs. See below.
>    
> >> On 24 Jul 2018, at 08:16, O. Hartmann 
> >> wrote:
> >> 
> >> On Mon, 23 Jul 2018 10:56:04 +0300
> >> Toomas Soome  wrote:
> >>   
>  On 23 Jul 2018, at 10:27, O. Hartmann 
>  wrote:
>  
>  On Fri, 13 Jul 2018 18:44:23 +0300
>  Toomas Soome mailto:tso...@me.com>> wrote:
>    
> >> On 13 Jul 2018, at 17:44, O. Hartmann  >> > wrote:
> >> 
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA512
> >> 
> >> Am Fri, 13 Jul 2018 14:26:51 +0300
> >> Toomas Soome mailto:tso...@me.com>
> >> >>
> >> schrieb:   
>  On 13 Jul 2018, at 14: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? 
>    
> >>> 
> >>> The first thing to check is if the secure boot is disabled. We
> >>> do not support secure boot at all at this time.  
> >> 
> >> Secure 

Re: [UEFI] Boot issues on some UEFI implementations

[Toomas Soome]

> On 27 Jul 2018, at 08:46, O. Hartmann  wrote:
> 
> On Thu, 26 Jul 2018 19:23:43 +0300
> Toomas Soome  wrote:
> 
> (reply inline/at the end)
> 
> 
>>> On 26 Jul 2018, at 16:58, O. Hartmann  wrote:
>>> 
>>> On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
>>> "Rodney W. Grimes" >> > wrote: 
>> On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
>> 
>> On Wed, 25 Jul 2018 11:46:07 +0300
>> Toomas Soome  wrote:
>> 
 On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
 
 On Tue, 24 Jul 2018 08:53:36 +0300
 Toomas Soome  wrote:
 
 
 Hello  Toomas Soome,
 
 I CC Allan Jude since I discovered something  weird today regarding the
 UEFI boot capabilities of USB flash devices and SSDs. See below.
 
>> On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
>> 
>> On Mon, 23 Jul 2018 10:56:04 +0300
>> Toomas Soome  wrote:
>> 
 On 23 Jul 2018, at 10:27, O. Hartmann 
 wrote:
 
 On Fri, 13 Jul 2018 18:44:23 +0300
 Toomas Soome mailto:tso...@me.com>> wrote:
 
>> On 13 Jul 2018, at 17:44, O. Hartmann > > wrote:
>> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>> 
>> Am Fri, 13 Jul 2018 14:26:51 +0300
>> Toomas Soome mailto:tso...@me.com>
>> >> schrieb: 
 On 13 Jul 2018, at 14: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? 
 
>>> 
>>> 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 

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

On Thu, 26 Jul 2018 19:23:43 +0300
Toomas Soome  wrote:

(reply inline/at the end)


> > On 26 Jul 2018, at 16:58, O. Hartmann  wrote:
> > 
> > On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
> > "Rodney W. Grimes"  > > wrote: 
>  On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
>  
>  On Wed, 25 Jul 2018 11:46:07 +0300
>  Toomas Soome  wrote:
>    
> >> On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
> >> 
> >> On Tue, 24 Jul 2018 08:53:36 +0300
> >> Toomas Soome  wrote:
> >> 
> >> 
> >> Hello  Toomas Soome,
> >> 
> >> I CC Allan Jude since I discovered something  weird today regarding the
> >> UEFI boot capabilities of USB flash devices and SSDs. See below.
> >>   
>  On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
>  
>  On Mon, 23 Jul 2018 10:56:04 +0300
>  Toomas Soome  wrote:
>    
> >> On 23 Jul 2018, at 10:27, O. Hartmann 
> >> wrote:
> >> 
> >> On Fri, 13 Jul 2018 18:44:23 +0300
> >> Toomas Soome mailto:tso...@me.com>> wrote:
> >>   
>  On 13 Jul 2018, at 17:44, O. Hartmann   > wrote:
>  
>  -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA512
>  
>  Am Fri, 13 Jul 2018 14:26:51 +0300
>  Toomas Soome mailto:tso...@me.com>
>  >> schrieb: 
> >> On 13 Jul 2018, at 14: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? 
> >>   
> > 
> > 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
> > 

Re: [UEFI] Boot issues on some UEFI implementations

[Toomas Soome]

> On 26 Jul 2018, at 16:58, O. Hartmann  wrote:
> 
> On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
> "Rodney W. Grimes"  > wrote:
> 
 On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
 
 On Wed, 25 Jul 2018 11:46:07 +0300
 Toomas Soome  wrote:
 
>> On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
>> 
>> On Tue, 24 Jul 2018 08:53:36 +0300
>> Toomas Soome  wrote:
>> 
>> 
>> Hello  Toomas Soome,
>> 
>> I CC Allan Jude since I discovered something  weird today regarding the
>> UEFI boot capabilities of USB flash devices and SSDs. See below.
>> 
 On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
 
 On Mon, 23 Jul 2018 10:56:04 +0300
 Toomas Soome  wrote:
 
>> On 23 Jul 2018, at 10:27, O. Hartmann 
>> wrote:
>> 
>> On Fri, 13 Jul 2018 18:44:23 +0300
>> Toomas Soome mailto:tso...@me.com>> wrote:
>> 
 On 13 Jul 2018, at 17:44, O. Hartmann >>> > wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 Am Fri, 13 Jul 2018 14:26:51 +0300
 Toomas Soome mailto:tso...@me.com>
 >> schrieb:   
>> On 13 Jul 2018, at 14: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? 
>> 
> 
> 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

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
"Rodney W. Grimes"  wrote:

> > > On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
> > > 
> > > On Wed, 25 Jul 2018 11:46:07 +0300
> > > Toomas Soome  wrote:
> > >   
> > >>> On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
> > >>> 
> > >>> On Tue, 24 Jul 2018 08:53:36 +0300
> > >>> Toomas Soome  wrote:
> > >>> 
> > >>> 
> > >>> Hello  Toomas Soome,
> > >>> 
> > >>> I CC Allan Jude since I discovered something  weird today regarding the
> > >>> UEFI boot capabilities of USB flash devices and SSDs. See below.
> > >>>   
> > > On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
> > > 
> > > On Mon, 23 Jul 2018 10:56:04 +0300
> > > Toomas Soome  wrote:
> > >   
> > >>> On 23 Jul 2018, at 10:27, O. Hartmann 
> > >>> wrote:
> > >>> 
> > >>> On Fri, 13 Jul 2018 18:44:23 +0300
> > >>> Toomas Soome mailto:tso...@me.com>> wrote:
> > >>>   
> > > On 13 Jul 2018, at 17:44, O. Hartmann  > > > wrote:
> > > 
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA512
> > > 
> > > Am Fri, 13 Jul 2018 14:26:51 +0300
> > > Toomas Soome mailto:tso...@me.com>
> > > >> schrieb:   
> > >>> On 13 Jul 2018, at 14: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? 
> > >>>   
> > >> 
> > >> 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: 

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Wed, 25 Jul 2018 12:26:13 +0300
Toomas Soome  schrieb:

> > On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
> > 
> > On Wed, 25 Jul 2018 11:46:07 +0300
> > Toomas Soome  wrote:
> >   
> >>> On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
> >>> 
> >>> On Tue, 24 Jul 2018 08:53:36 +0300
> >>> Toomas Soome  wrote:
> >>> 
> >>> 
> >>> Hello  Toomas Soome,
> >>> 
> >>> I CC Allan Jude since I discovered something  weird today regarding the 
> >>> UEFI
> >>> boot capabilities of USB flash devices and SSDs. See below.
> >>>   
> > On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
> > 
> > On Mon, 23 Jul 2018 10:56:04 +0300
> > Toomas Soome  wrote:
> >   
> >>> On 23 Jul 2018, at 10:27, O. Hartmann  wrote:
> >>> 
> >>> On Fri, 13 Jul 2018 18:44:23 +0300
> >>> Toomas Soome mailto:tso...@me.com>> wrote:
> >>>   
> > On 13 Jul 2018, at 17:44, O. Hartmann  > > wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Am Fri, 13 Jul 2018 14:26:51 +0300
> > Toomas Soome mailto:tso...@me.com>
> > >> schrieb:   
> >>> On 13 Jul 2018, at 14: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? 
> >>>   
> >> 
> >> 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
> 

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
"Rodney W. Grimes"  schrieb:

[...]

> > Yea, i was hoping fstyp command would report the FAT type, but it does not 
> > (request
> > for feature?:)  
> 
> FYI, the file(1) command is very good at disecting a disk image to tell
> you what the MBR looks like, and at looking at partitions if pointed at
> them with the -s option.  It should be able to detect FAT12/16/32.
> 
> root@x230a:/home/ISO/x # file -s /dev/md2s1
> /dev/md2s1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "BSD4.4  ", root 
> entries
> 512, sectors 1600 (volumes <=32 MB) , sectors/FAT 5, sectors/track 63, heads 
> 1, serial
> number 0xbd4111ee, label: "EFISYS ", FAT (12 bit), followed by FAT

Thanks for this very helpful hint!

> 
> > 
> > However, the more annoying idea would be to install some OS which will boot 
> > with UEFI
> > on this machine, then copy boot1.efi from freebsd to it (the default 
> > program the UEFI
> > will load is ESP:EFI/boot/bootx64.efi  in case of UEFI64 and
> > ESP:EFI/boot/bootia32.efi for EFI32. However, we do not support EFI32.
> > 
> > note that boot1.efi alone will not do much but printing on screen how it 
> > will search
> > for freebsd, but for the purpose of the test it would suffice - that would 
> > give us
> > confirmed working ESP file system (since the other os would be able to 
> > boot) and then
> > we can confirm if boot1.efi itself is OK.  
> 



- -- 
O. Hartmann

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

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW1i2PwAKCRDS528fyFhY
lFz5Af9MY41hoAND4OoKCOwExAM7oQYVCpHSz+mo94OBVqSCqcnprdvdE2C1+PiN
Uza7lMvB8KVSqcyxuYbIFD0E5A4bAgCk/lzKwE9hTPBt4gdBx4t7N/XPafOEBEGM
8irGozKbAvikSkhAQTMPtwyE+861AvKy2Dw1o+mQo4AfikJI0dgq
=9cKL
-END PGP SIGNATURE-
___
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"

Re: [UEFI] Boot issues on some UEFI implementations

[Rodney W. Grimes]

> > On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
> > 
> > On Wed, 25 Jul 2018 11:46:07 +0300
> > Toomas Soome  wrote:
> > 
> >>> On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
> >>> 
> >>> On Tue, 24 Jul 2018 08:53:36 +0300
> >>> Toomas Soome  wrote:
> >>> 
> >>> 
> >>> Hello  Toomas Soome,
> >>> 
> >>> I CC Allan Jude since I discovered something  weird today regarding the 
> >>> UEFI
> >>> boot capabilities of USB flash devices and SSDs. See below.
> >>> 
> > On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
> > 
> > On Mon, 23 Jul 2018 10:56:04 +0300
> > Toomas Soome  wrote:
> > 
> >>> On 23 Jul 2018, at 10:27, O. Hartmann  wrote:
> >>> 
> >>> On Fri, 13 Jul 2018 18:44:23 +0300
> >>> Toomas Soome mailto:tso...@me.com>> wrote:
> >>> 
> > On 13 Jul 2018, at 17:44, O. Hartmann  > > wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Am Fri, 13 Jul 2018 14:26:51 +0300
> > Toomas Soome mailto:tso...@me.com>
> > >> schrieb: 
> >>> On 13 Jul 2018, at 14: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? 
> >>> 
> >> 
> >> 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 

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

On Wed, 25 Jul 2018 11:46:07 +0300
Toomas Soome  wrote:

> > On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
> > 
> > On Tue, 24 Jul 2018 08:53:36 +0300
> > Toomas Soome  wrote:
> > 
> > 
> > Hello  Toomas Soome,
> > 
> > I CC Allan Jude since I discovered something  weird today regarding the UEFI
> > boot capabilities of USB flash devices and SSDs. See below.
> >   
> >>> On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
> >>> 
> >>> On Mon, 23 Jul 2018 10:56:04 +0300
> >>> Toomas Soome  wrote:
> >>>   
> > On 23 Jul 2018, at 10:27, O. Hartmann  wrote:
> > 
> > On Fri, 13 Jul 2018 18:44:23 +0300
> > Toomas Soome mailto:tso...@me.com>> wrote:
> >   
> >>> On 13 Jul 2018, at 17:44, O. Hartmann  >>> > wrote:
> >>> 
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA512
> >>> 
> >>> Am Fri, 13 Jul 2018 14:26:51 +0300
> >>> Toomas Soome mailto:tso...@me.com>
> >>> >> schrieb: 
> > On 13 Jul 2018, at 14: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? 
> >   
>  
>  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 UEFI
> >>> versions regarding booting only Windows 8/8.1 - and nothing else, but
> >>> the fact that Linux worked confuses me a bit.
> >>> 
> >>> 

Re: [UEFI] Boot issues on some UEFI implementations

[Toomas Soome]

> On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
> 
> On Wed, 25 Jul 2018 11:46:07 +0300
> Toomas Soome  wrote:
> 
>>> On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
>>> 
>>> On Tue, 24 Jul 2018 08:53:36 +0300
>>> Toomas Soome  wrote:
>>> 
>>> 
>>> Hello  Toomas Soome,
>>> 
>>> I CC Allan Jude since I discovered something  weird today regarding the UEFI
>>> boot capabilities of USB flash devices and SSDs. See below.
>>> 
> On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
> 
> On Mon, 23 Jul 2018 10:56:04 +0300
> Toomas Soome  wrote:
> 
>>> On 23 Jul 2018, at 10:27, O. Hartmann  wrote:
>>> 
>>> On Fri, 13 Jul 2018 18:44:23 +0300
>>> Toomas Soome mailto:tso...@me.com>> wrote:
>>> 
> On 13 Jul 2018, at 17:44, O. Hartmann  > wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Am Fri, 13 Jul 2018 14:26:51 +0300
> Toomas Soome mailto:tso...@me.com>
> >> schrieb: 
>>> On 13 Jul 2018, at 14: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? 
>>> 
>> 
>> 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 UEFI
> versions regarding booting only Windows 8/8.1 - and nothing else, but
> the fact that 

Re: [UEFI] Boot issues on some UEFI implementations

[Toomas Soome]

> On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
> 
> On Tue, 24 Jul 2018 08:53:36 +0300
> Toomas Soome  wrote:
> 
> 
> Hello  Toomas Soome,
> 
> I CC Allan Jude since I discovered something  weird today regarding the UEFI
> boot capabilities of USB flash devices and SSDs. See below.
> 
>>> On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
>>> 
>>> On Mon, 23 Jul 2018 10:56:04 +0300
>>> Toomas Soome  wrote:
>>> 
> On 23 Jul 2018, at 10:27, O. Hartmann  wrote:
> 
> On Fri, 13 Jul 2018 18:44:23 +0300
> Toomas Soome mailto:tso...@me.com>> wrote:
> 
>>> On 13 Jul 2018, at 17:44, O. Hartmann >> > wrote:
>>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>> 
>>> Am Fri, 13 Jul 2018 14:26:51 +0300
>>> Toomas Soome mailto:tso...@me.com> >> >> schrieb:   
> On 13 Jul 2018, at 14: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? 
> 
 
 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 UEFI
>>> 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 looks exactly like the ASRock 

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

On Tue, 24 Jul 2018 08:53:36 +0300
Toomas Soome  wrote:


Hello  Toomas Soome,

I CC Allan Jude since I discovered something  weird today regarding the UEFI
boot capabilities of USB flash devices and SSDs. See below.
 
> > On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
> > 
> > On Mon, 23 Jul 2018 10:56:04 +0300
> > Toomas Soome  wrote:
> >   
> >>> On 23 Jul 2018, at 10:27, O. Hartmann  wrote:
> >>> 
> >>> On Fri, 13 Jul 2018 18:44:23 +0300
> >>> Toomas Soome mailto:tso...@me.com>> wrote:
> >>>   
> > On 13 Jul 2018, at 17:44, O. Hartmann  > > wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Am Fri, 13 Jul 2018 14:26:51 +0300
> > Toomas Soome mailto:tso...@me.com>  > >> schrieb:   
> >>> On 13 Jul 2018, at 14: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? 
> >>>   
> >> 
> >> 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 UEFI
> > 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 looks exactly like the ASRock -
> > Windows 7 works, RedHat 7.5 works (I assume I can 

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

On Tue, 24 Jul 2018 02:20:00 -0400
Allan Jude  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@freebsd.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.

> 

___
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"

Re: [UEFI] Boot issues on some UEFI implementations

[Toomas Soome]

> On 24 Jul 2018, at 09:20, Allan Jude  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@freebsd.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)
> 
> 

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

___
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"

Re: [UEFI] Boot issues on some UEFI implementations

[Allan Jude]

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@freebsd.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)

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: [UEFI] Boot issues on some UEFI implementations

[Toomas Soome]

> On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
> 
> On Mon, 23 Jul 2018 10:56:04 +0300
> Toomas Soome  wrote:
> 
>>> On 23 Jul 2018, at 10:27, O. Hartmann  wrote:
>>> 
>>> On Fri, 13 Jul 2018 18:44:23 +0300
>>> Toomas Soome mailto:tso...@me.com>> wrote:
>>> 
> On 13 Jul 2018, at 17:44, O. Hartmann  > wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Am Fri, 13 Jul 2018 14:26:51 +0300
> Toomas Soome mailto:tso...@me.com>  >> schrieb: 
>>> On 13 Jul 2018, at 14: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? 
>>> 
>> 
>> 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 UEFI 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 looks 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 EFI/UEFI 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
> 

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

On Mon, 23 Jul 2018 10:56:04 +0300
Toomas Soome  wrote:

> > On 23 Jul 2018, at 10:27, O. Hartmann  wrote:
> > 
> > On Fri, 13 Jul 2018 18:44:23 +0300
> > Toomas Soome mailto:tso...@me.com>> wrote:
> >   
> >>> On 13 Jul 2018, at 17:44, O. Hartmann  >>> > wrote:
> >>> 
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA512
> >>> 
> >>> Am Fri, 13 Jul 2018 14:26:51 +0300
> >>> Toomas Soome mailto:tso...@me.com>  >>> >> schrieb: 
> > On 13 Jul 2018, at 14: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? 
> >   
>  
>  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 UEFI 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 looks 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 EFI/UEFI 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 

Re: [UEFI] Boot issues on some UEFI implementations

[Toomas Soome]

> On 23 Jul 2018, at 10:27, O. Hartmann  wrote:
> 
> On Fri, 13 Jul 2018 18:44:23 +0300
> Toomas Soome mailto:tso...@me.com>> wrote:
> 
>>> On 13 Jul 2018, at 17:44, O. Hartmann >> > wrote:
>>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>> 
>>> Am Fri, 13 Jul 2018 14:26:51 +0300
>>> Toomas Soome mailto:tso...@me.com> >> >> schrieb:
>>> 
> On 13 Jul 2018, at 14: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? 
> 
 
 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 UEFI 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 looks 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 EFI/UEFI 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 

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

On Fri, 13 Jul 2018 18:44:23 +0300
Toomas Soome  wrote:

> > On 13 Jul 2018, at 17:44, O. Hartmann  wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Am Fri, 13 Jul 2018 14:26:51 +0300
> > Toomas Soome mailto:tso...@me.com>> schrieb:
> >   
> >>> On 13 Jul 2018, at 14: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? 
> >>>   
> >> 
> >> 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 UEFI 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 looks 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 EFI/UEFI 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 

Re: [UEFI] Boot issues on some UEFI implementations

[Toomas Soome]

> On 13 Jul 2018, at 17:44, O. Hartmann  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Am Fri, 13 Jul 2018 14:26:51 +0300
> Toomas Soome mailto:tso...@me.com>> schrieb:
> 
>>> On 13 Jul 2018, at 14: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? 
>>> 
>> 
>> 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 UEFI
> 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 
> looks
> 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 
> EFI/UEFI
> 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 
> 

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Fri, 13 Jul 2018 14:26:51 +0300
Toomas Soome  schrieb:

> > On 13 Jul 2018, at 14: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? 
> >   
> 
> 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 
UEFI
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 
looks
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 
EFI/UEFI
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 
partition?

> 
> rgds,
> toomas

Thank you very much and kind regards,

Oliver

> 
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> 

Re: [UEFI] Boot issues on some UEFI implementations

[Rodney W. Grimes]

> 
> 
> > On 13 Jul 2018, at 14: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.

This sounds like a tool showing you the protective MBR which
is part of GPT.

> > 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. 
> 
> 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:)
> 
> 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.
> 

One must be carefull when looking at a GPT scheme device,
as it still has a "protective MBR" at sector 0 which
covers sectors 1 to N of the device.  Legacy (mbr only)
tools well see this and show it as type 0xEE covering
the whole device.

Some modern tools still show this as an MBR, but
then also show the GPT's inside it.

Some tools never show you the protective MBR.


-- 
Rod Grimes rgri...@freebsd.org
___
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"

Re: [UEFI] Boot issues on some UEFI implementations

[Toomas Soome]

> On 13 Jul 2018, at 14: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? 
> 

The first thing to check is if the secure boot is disabled. We do not support 
secure boot at all at this time. 

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:)

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.

rgds,
toomas



___
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"