Date: Fri, 27 Jul 2018 08:54:48 +0300 From: Toomas Soome <tsoome@me.com> To: "O. Hartmann" <ohartmann@walstatt.org> Cc: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>, freebsd-current <freebsd-current@freebsd.org>, Allan Jude <allanjude@freebsd.org> Subject: Re: [UEFI] Boot issues on some UEFI implementations Message-ID: <6C5D21D2-59C6-42DB-AC75-79D98BA5E62B@me.com> In-Reply-To: <20180727074558.75b2d730@freyja.zeit4.iv.bundesimmobilien.de> References: <1E6058D2-5804-480B-B6AF-66AA02CDD7AD@me.com> <201807251430.w6PEUWPn041286@pdx.rh.CN85.dnsmgr.net> <20180726155821.6f9906e9@freyja.zeit4.iv.bundesimmobilien.de> <7FA45CAF-6869-4DF6-AA93-5F96F83EF958@me.com> <20180727074558.75b2d730@freyja.zeit4.iv.bundesimmobilien.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 27 Jul 2018, at 08:46, O. Hartmann <ohartmann@walstatt.org> wrote:
>=20
> On Thu, 26 Jul 2018 19:23:43 +0300
> Toomas Soome <tsoome@me.com> wrote:
>=20
> (reply inline/at the end)
>=20
>=20
>>> On 26 Jul 2018, at 16:58, O. Hartmann <ohartmann@walstatt.org> =
wrote:
>>>=20
>>> On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
>>> "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net
>>> <mailto:freebsd-rwg@pdx.rh.CN85.dnsmgr.net>> wrote:=20
>>>>>> On 25 Jul 2018, at 12:10, O. Hartmann <o.hartmann@walstatt.org> =
wrote:
>>>>>>=20
>>>>>> On Wed, 25 Jul 2018 11:46:07 +0300
>>>>>> Toomas Soome <tsoome@me.com> wrote:
>>>>>>=20
>>>>>>>> On 25 Jul 2018, at 10:59, O. Hartmann <ohartmann@walstatt.org> =
wrote:
>>>>>>>>=20
>>>>>>>> On Tue, 24 Jul 2018 08:53:36 +0300
>>>>>>>> Toomas Soome <tsoome@me.com> wrote:
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Hello Toomas Soome,
>>>>>>>>=20
>>>>>>>> I CC Allan Jude since I discovered something weird today =
regarding the
>>>>>>>> UEFI boot capabilities of USB flash devices and SSDs. See =
below.
>>>>>>>>=20
>>>>>>>>>> On 24 Jul 2018, at 08:16, O. Hartmann =
<ohartmann@walstatt.org> wrote:
>>>>>>>>>>=20
>>>>>>>>>> On Mon, 23 Jul 2018 10:56:04 +0300
>>>>>>>>>> Toomas Soome <tsoome@me.com> wrote:
>>>>>>>>>>=20
>>>>>>>>>>>> On 23 Jul 2018, at 10:27, O. Hartmann =
<ohartmann@walstatt.org>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>> On Fri, 13 Jul 2018 18:44:23 +0300
>>>>>>>>>>>> Toomas Soome <tsoome@me.com <mailto:tsoome@me.com>> wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann =
<o.hartmann@walstatt.org
>>>>>>>>>>>>>> <mailto:o.hartmann@walstatt.org>> wrote:
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>>>>>> Hash: SHA512
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300
>>>>>>>>>>>>>> Toomas Soome <tsoome@me.com <mailto:tsoome@me.com>
>>>>>>>>>>>>>> <mailto:tsoome@me.com <mailto:tsoome@me.com>>> schrieb: =
=20
>>>>>>>>>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann =
<ohartmann@walstatt.org>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> I have two host in private use based on an
>>>>>>>>>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard =
(IvyBridge,
>>>>>>>>>>>>>>>> Socket LGA1155). Both boards are equipted with the =
lates
>>>>>>>>>>>>>>>> official available AMI firmware revision, dating to =
2013. This
>>>>>>>>>>>>>>>> is for the Z77-Pro4-M revision 2.0 (2013/7/23) and for =
the Z77
>>>>>>>>>>>>>>>> Pro4 revision 1.8 (2013/7/17). For both boards a BETA =
revision
>>>>>>>>>>>>>>>> for the Spectre/Meltdown mitigation is available, but I =
didn't
>>>>>>>>>>>>>>>> test that. But please read.
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> The third box I realised this problem is a brand new =
Fujitsu
>>>>>>>>>>>>>>>> Esprimo Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 =
for
>>>>>>>>>>>>>>>> 3413-A1x, date 05/25/2018 (or 20180525).
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> Installing on any kind of HDD or SSD manually or via =
bsdinstall
>>>>>>>>>>>>>>>> the OS using UEFI-only boot method on a GPT partitioned =
device
>>>>>>>>>>>>>>>> fails. The ASRock boards jump immediately into the =
firmware,
>>>>>>>>>>>>>>>> the Fujitsu offers some kind of CPU/Memory/HDD test =
facility.
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> If on both type of vendor/boards CSM is disabled and =
UEFI boot
>>>>>>>>>>>>>>>> only is implied, the MBR partitioned FreeBSD =
installation USB
>>>>>>>>>>>>>>>> flash device does boot in UEFI! I guess I can assume =
this when
>>>>>>>>>>>>>>>> the well known clumsy 80x25 char console suddenly gets =
bright
>>>>>>>>>>>>>>>> and shiny with a much higher 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.
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> I do not know whether this is a well-known issue. On =
the ASRock
>>>>>>>>>>>>>>>> boards, I tried years ago some LinuxRed Hat and Suse =
with UEFI
>>>>>>>>>>>>>>>> and that worked - FreeBSD not. I gave up on that that =
time.
>>>>>>>>>>>>>>>> Now, having the very same issues with a new Fujitsu =
system,
>>>>>>>>>>>>>>>> leaves me with the impression that FreeBSD's UEFI
>>>>>>>>>>>>>>>> implementation might have problems I'm not aware of.
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> Can someone shed some light onto this?=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> The first thing to check is if the secure boot is =
disabled. We
>>>>>>>>>>>>>>> do not support secure boot at all at this time. =
=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Secure boot is in every scenario disabled!
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> 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:) =20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> What are you talking about?
>>>>>>>>>>>>>> What is the point of entry - running system, loader?
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> sysct machdep.bootmethod: BIOS
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> 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. =20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> 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. =20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> 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? =20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Ok, so, it is not about UEFI bootcode but BIOS, and if we =
reach
>>>>>>>>>>>>> BIOS loader at all or not - that is, if the BIOS bootstrap =
is
>>>>>>>>>>>>> actually caring to read the MBR code and start it, since =
once the
>>>>>>>>>>>>> MBR code is started, it is all about our code. =20
>>>>>>>>>>>>=20
>>>>>>>>>>>> I'm getting confused a bit here. Do you mean by "BIOS" the =
CSM? or
>>>>>>>>>>>> do you mean that specific portion of the UEFI firmware, =
which looks
>>>>>>>>>>>> for the proper UEFI partition?
>>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> BIOS as either native or CSM. Note that from boot code point =
of view
>>>>>>>>>>> the CSM boot *is* BIOS boot, we have no access to UEFI =
features.
>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> The boxes in question, most notably the more recent Fujitsu =
Esprimo
>>>>>>>>>>>> Q956, refuse booting UEFI, even if properly setup (in terms =
of what
>>>>>>>>>>>> FreeBSD provides on recent CURRENT) is applied and CSM is =
switched
>>>>>>>>>>>> off in the firmware. Again: GPT partition scheme.
>>>>>>>>>>>>=20
>>>>>>>>>>>> The system boots properly if a second partition of type
>>>>>>>>>>>> "freebsd-boot" is applied and bootcode is properly applied =
via
>>>>>>>>>>>> "gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 2 ada0" =
(ada0 is
>>>>>>>>>>>> the device). =20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> btw, you can try to validate the installed boot blocks by =
using
>>>>>>>>>>>>> recent enough loader (usb or iso) and then you can use =
from OK
>>>>>>>>>>>>> prompt: =20
>>>>>>>>>>>>=20
>>>>>>>>>>>> lsdev provides me with the follwoing informations (CSM =
enabled):
>>>>>>>>>>>>=20
>>>>>>>>>>>> OK lsdev
>>>>>>>>>>>> disk devices:
>>>>>>>>>>>> disk0: BIOS DRIVE C ...
>>>>>>>>>>>>=20
>>>>>>>>>>>> disk0p1: EFI
>>>>>>>>>>>> disk0p2: FreeBSD BOOT
>>>>>>>>>>>> disk0p3: FreeBSD SWAP
>>>>>>>>>>>> disk0p4: FreeBSD ZFS
>>>>>>>>>>>> zfs devices:
>>>>>>>>>>>> zfs:zroot
>>>>>>>>>>>>=20
>>>>>>>>>>>> OK chain disk0
>>>>>>>>>>>> open failed (so for disk0p{1-4}.
>>>>>>>>>>>>=20
>>>>>>>>>>>> OK chain zroot
>>>>>>>>>>>> failed to read disk (just for completeness) =20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> chain command does use only device name (such as disk0: or
>>>>>>>>>>> disk0p2: ), but not zfs pool as device. I just found I =
haven?t
>>>>>>>>>>> ported the code to read the file. =20
>>>>>>>>>>=20
>>>>>>>>>> ??
>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> the point for chain command test is to see if the normal =
read and
>>>>>>>>>>> execute would work, so in your case please try:
>>>>>>>>>>>=20
>>>>>>>>>>> chain disk0: =20
>>>>>>>>>>=20
>>>>>>>>>> As stated above, I did so, and the result is also mentioned =
above, I
>>>>>>>>>> always get "open failed".
>>>>>>>>>> This is the same for=20
>>>>>>>>>>=20
>>>>>>>>>> chain disk0
>>>>>>>>>> chain disk0p1
>>>>>>>>>> chain disk0p2
>>>>>>>>>> chain disk0p3
>>>>>>>>>> chain disk0p4
>>>>>>>>>>=20
>>>>>>>>>> as already said. CSM is enabled in this case. =20
>>>>>>>>>=20
>>>>>>>>> sigh? chain command does take device as argument, device must =
always
>>>>>>>>> end with colon?. in this case, the devil is in details:) as I =
wrote
>>>>>>>>> above, the command should be:
>>>>>>>>>=20
>>>>>>>>> chain disk0:
>>>>>>>>>=20
>>>>>>>>> The disk0p1: etc will only work when partition boot code was =
installed
>>>>>>>>> (which you most likely do not have - the only possible =
candidate could
>>>>>>>>> be FreeBSD ZFS partition). =20
>>>>>>>>=20
>>>>>>>> The command "chain disk0:" works as expected (CSM enabled, GPT
>>>>>>>> partition scheme, but with PMBR bootblock installed and =
freebsd-boot
>>>>>>>> partition conatining gptzfsboot installed.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> to read pmbr (512B) and execute it. The expected outcome =
would be
>>>>>>>>>>> that pmbr boot code would browse the GPT, read stage1 from =
disk0p2:
>>>>>>>>>>> and execute it; stage1 would detect FreeBSD ZFS from =
disk0p4: and
>>>>>>>>>>> load and execute /boot/loader. If that will happen, it means =
the
>>>>>>>>>>> boot code in our stages is just fine, but the bios (CSM) =
does not
>>>>>>>>>>> load pmbr?. if thats true, it would mean that you either =
need to
>>>>>>>>>>> use UEFI boot or need to have some hack to fool the BIOS or =
just not
>>>>>>>>>>> use GPT on that machine with CSM. =20
>>>>>>>>>>=20
>>>>>>>>>> To make it clear here: The only way to boot this box is using =
CSM (as
>>>>>>>>>> it is the same with the ASRock boards mentioned earlier). But =
my
>>>>>>>>>> intention is to disable CSM and use a GPT/UEFI environment =
only! And
>>>>>>>>>> GPT/UEFI doesn't work with FreeBSD, neither with 12-CURRENT, =
nor
>>>>>>>>>> 11.2-RELENG.
>>>>>>>>>>=20
>>>>>>>>>> It would be nice if this could be fixed. I'm more interested =
in the
>>>>>>>>>> fix on the recent Fujitsu device than the outdated ASRock =
crap, but
>>>>>>>>>> if the fix for the Fujitsu Firmware could fix older issues as =
a
>>>>>>>>>> byproduct, I'd appreciate that.
>>>>>>>>>>=20
>>>>>>>>>> Kind regards,
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> ok, somehow I have lost that part of the discussion. Well, you =
wrote
>>>>>>>>> that the UEFI boot fails when the first partition starts from =
sector
>>>>>>>>> 40 - does it mean you have boot when the partition will start =
from
>>>>>>>>> some other sector? I think, there is something else going on. =
=20
>>>>>>>>=20
>>>>>>>> Well, I simply try to describe what I "see" to make things
>>>>>>>> disambiguous. I'm not familiar with the deeper insights of disk =
layouts
>>>>>>>> on a binary level. So, you explained to me the reason, why ESP =
(EGI
>>>>>>>> partition) starts at block 40. I compared that to the FreeBSD =
USB flash
>>>>>>>> image FreeBSD provides, but this is another story since the =
image uses
>>>>>>>> MBR scheme as I figured out.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> What you can do is to see if that firmware will offer you EFI =
shell
>>>>>>>>> option, from there you can try to start the bootx64.efi =
manually and
>>>>>>>>> see what error you will get. However, the number 1 cause for =
failing
>>>>>>>>> to start the bootloader in UEFI is secure boot - we do not =
support it
>>>>>>>>> and secure boot must be switched off.=20
>>>>>>>>>=20
>>>>>>>>> However, they seem to claim "The Secure Boot option is =
available in
>>>>>>>>> the UEFI/BIOS of most if not all ASRock boards. It is disabled =
by
>>>>>>>>> default.?=20
>>>>>>>>>=20
>>>>>>>>> Still suggest to double check if thats really the case. Also, =
if the
>>>>>>>>> bootx64.efi start will fail and no messages are appearing on =
screen,
>>>>>>>>> then either there is something in firmware logs or you could =
get them
>>>>>>>>> from trying to start bootx64.efi from UEFI shell. =20
>>>>>>>>=20
>>>>>>>> Since I'm with this problem since 2014 and try from time to =
time, be
>>>>>>>> ausred that I tried every possible permutationof all reasonable
>>>>>>>> options, even those nonsense, to get rid of that problem.
>>>>>>>>=20
>>>>>>>> I never had any problems with any other UEFI capable =
server/workstation
>>>>>>>> firmware so far booting FreeBSD off in UEFI-native (GPT =
partition
>>>>>>>> scheme, CSM disabled) so far - until now, when I ran into this =
Fujitsu
>>>>>>>> ESPRIMO Q956 with the most recent firmware (as of lat week, =
week 29 of
>>>>>>>> 2018) having the very same problems.=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> I figured out something strange on the Fujitsu - and that is =
the same
>>>>>>>> with the ASRock boards.
>>>>>>>>=20
>>>>>>>> We/I prepare some USB flash drives to boot a NanoBSD for a very =
small
>>>>>>>> appliance, but nevertheless, the USB flash device is booted on =
Fujitsu
>>>>>>>> servers with UEFI-only configurations. I assume at this point =
that
>>>>>>>> disabling on the most recent Fujitsu firmwares on reasonable =
"new"
>>>>>>>> hardware (not older than three years) will disable any(!) =
legacy BIOS
>>>>>>>> capabilities. The same is assumed for the Fujitus ESPRIMO Q956. =
I can
>>>>>>>> not speak for the ASRock A77 Pro4/m boards mentioned =
above/earlier,
>>>>>>>> they are from 2012/2013 and "quite old".
>>>>>>>>=20
>>>>>>>> The NanoBSD image of ours doesn't have a "freebsd-boot" =
partition. The
>>>>>>>> partition scheme of the flash device is GPT. The layout looks =
like
>>>>>>>> this:
>>>>>>>>=20
>>>>>>>> gpart show -l da4 =20
>>>>>>>> =3D> 40 15425456 da4 GPT (7.4G) =20
>>>>>>>> 40 2000 1 efiboot0 (1.0M)
>>>>>>>> 2040 1453584 3 disk1a (710M)
>>>>>>>> 1455624 4096 5 disk3 (2.0M)
>>>>>>>> 1459720 13965776 - free - (6.7G)
>>>>>>>>=20
>>>>>>>> I created the flash with md, gpart and dd straightforward, =
efiboot0 is
>>>>>>>> the ESP partition and its format/content is created via dd
>>>>>>>> if=3D/boot/boot1.efifat of=3D/dev/da4p1 - I presume this is =
very simple.
>>>>>>>>=20
>>>>>>>> This USB flash device boots(!) successfully (UEFI!) on both the =
ASRock
>>>>>>>> boards and the Esprimo Q956!
>>>>>>>>=20
>>>>>>>> But any SSD prepared the same way doesn't. Why?=20
>>>>>>>>=20
>>>>>>>> On the ASRock, I recall having fiddled around with HDD also for =
a while
>>>>>>>> conatining Windows 7/SP1 and FreeBSD. Windows7 booted, FreeBSD =
- I
>>>>>>>> can't remember.=20
>>>>>>>>=20
>>>>>>>> In the lack of proper hardware I'm unable to check whether =
USB-attached
>>>>>>>> HDD or SSD will boot or HDD will boot (just in case the local =
SATA has
>>>>>>>> problems booting UEFI and USB not).
>>>>>>>>=20
>>>>>>>> Kind regards,
>>>>>>>>=20
>>>>>>>> Oliver=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>> Am. well. I think the suggestion to test out FAT32 is still good =
one to
>>>>>>> test. This is because it is known that some vendors do not =
support
>>>>>>> booting FAT12/FAT16 from HDD (the likely reason is that UEFI
>>>>>>> specification does not tell which FAT must be supported, and =
only hint
>>>>>>> about FAT12/FAT16 in context of removable devices). =20
>>>>>>=20
>>>>>> I prepared yesterday a GTP/ZFS-only 11.2-RELENG on the ESPRIMO =
Q956. It
>>>>>> took me a time to circumvent the installer and I had to install =
the
>>>>>> system manually. In that strain, I also "tried" to establish the =
ESP with
>>>>>> FAT32, as Allen Jude suggested earlier. I didn't find any ad hoc =
help how
>>>>>> to find out the format (FAT12/16/32) of the ESP, so I assume when =
using
>>>>>> 12-CURRENT's or 11.2-RELENG's installer with AUTO-ZFS and GPT =
(UEFI)
>>>>>> (only!) the resulting ESP is FAT12 or FAT16 (300mb by default). I =
also
>>>>>> assume, that when dd'ing the /boo/boot1.efifat image to a =
partition, the
>>>>>> format is FAT, but not FAT32. Therefore, I refomatted the =
manually
>>>>>> created ESP (using "gpart add -t efi ...") using "newfs_msdos -F =
32 -b
>>>>>> xxx ...". I had to fiddle around a bit with option -b to fit in a =
proper
>>>>>> format to meet a 512mb ESP - I'm not sure whether this is the =
proper
>>>>>> option to deal with. When using the default and only -F32, the =
size of
>>>>>> the partition has to be 4G at least I assume. Having done that, I =
copied
>>>>>> the the content of boot1.efifat (mdconfig -t vnode ..., I guess =
we know
>>>>>> the drill ...) to the newly formatted ESP to /boot/efi/ ...
>>>>>>=20
>>>>>> Having so far no knowledge of how to asure that the created ESP =
is FAT32,
>>>>>> I assume it is FAT32.
>>>>>>=20
>>>>>> The result is negative on the ESPRIMO Q956. When disabling the =
CSM, the
>>>>>> box is not willing to boot from SSD with the ESP prepared as =
decribed.
>>>>>> So, a chance that this might still be due to a misconfiguration =
lies now
>>>>>> within the -b option of newfs_msdos - if the -b option is assumed =
the
>>>>>> proper option?
>>>>>>=20
>>>>>> At the moment, the ESP of the Esprimo is subject to changes, if =
you wish,
>>>>>> but not in size, since it is limited to 512mb.
>>>>>>=20
>>>>>> Thanks and kind regards,
>>>>>>=20
>>>>>> Oliver =20
>>>>>=20
>>>>> Yea, i was hoping fstyp command would report the FAT type, but it =
does not
>>>>> (request for feature?:) =20
>>>>=20
>>>> 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.
>>>>=20
>>>> 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 <=3D32 MB) , sectors/FAT 5,
>>>> sectors/track 63, heads 1, serial number 0xbd4111ee, label: "EFISYS =
",
>>>> FAT (12 bit), followed by FAT
>>>>=20
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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. =20
>>>>=20
>>>=20
>>> Some new results.
>>> I installed RedHat 7.5 and inestigated the ESP.
>>>=20
>>> - The ESP starts at block 2048, while FreeBSD's ESP starts at block =
40.
>>> - size is both 200mb if installed automatically. I forgit to =
investigate the
>>> FAT format, but this might be unnecessary as shown further in this =
post.
>>> - RedHat's ESP contains ~ 10 MB of data in two
>>> folders, /efi/boot, /efi/redhat. copying FreeBSD's BOOTX64.efi over
>>> RedHat's doesn't change anything, also renaming /efi/boot/fbx64.efi =
of
>>> RedHat's installation. But renaming /efi/redhat renders RedHat to =
fail the
>>> boot process on the Fujitsu with the signs of the built-in =
testprogram as
>>> reported.
>>>=20
>>> I took the liberty and installed 11.2-RELENG again, ZFS only, UEFI =
boot only
>>> (CSM in firmware disabled, but there is still a gptzfsboot-prepared
>>> partition for later use, just for the record). Booting UEFI-only =
fails as
>>> reported. On this installation I copied the RedHat ESP completely =
into
>>> FreeBSD's ESP, renamed /efi/boot/BOOTX64.efi to =
/efi/boot/BOOTX64.efi.rh
>>> and copied FreeBSD's BOOTX64.efi to /efi/boot.=20
>>> The Esprimo Q956 tries then to boot(!) RedHat's kernel. It seems, =
that
>>> the /efi/redhat folder of the ESP is important, if renamed, the =
whole
>>> process dies as I reported earlier.
>>>=20
>>> Still unanswered is the question: why is a NanoBSD prepared =
UEFI-only USB
>>> flash booting with CSM disabled (so asumingly UEFI only then) on =
both
>>> ASRock and Fujitsu (as described in more detail initially and =
earlier),
>>> while SSDs fail? Is there a difference? Since FreeBSD boots in UEFI =
mode
>>> from USB flash prepared as described (straight forward, 800k ESP =
starting
>>> at block 40, the boot1.efifat image dd'ed onto the partition, UFS =
partition
>>> following, no freebsd-boot partition or MBR/PMBR bootcode applied =
ever!), I
>>> think BOOTX64.EFI is technically all right. There must be then an =
issue
>>> with the SATA/SSD/HDD boot pathway.
>>>=20
>>> Hope I could provide some more details, sorry if it sounds confusing =
or way
>>> too long, but I try to descibe the situation as thorough as =
possible.
>>>=20
>>=20
>> OK, this is already good hint. The thing with ESP is that there is =
=E2=80=9Cdefault=E2=80=9D
>> file system tree: EFI/BOOT/BOOT<sysname>.EFI, this is noted as =
default for
>> *removable* media, fortunately it is usable for hard disks as well, =
or at
>> least in most cases.
>>=20
>> Now, for non-removable media, the UEFI does provide boot manager =
interface to
>> define boot entries, and the fact that renaming efi/redhad directory =
did
>> break the redhat boot, is very loud hint. And this means, this system =
is
>> probably ignoring efi/boot tree on non-removable media and is =
expecting the
>> boot manager entry to be created instead.
>=20
> This inplication I'd confirm for the recent Fujitsu ESPRIMO Q956 =
firmware (not
> tested on ASRock Z77-Pro4 firmware).
>=20
>>=20
>> UEFI boot manager can be configured /usually/ manually via firmware =
menu, or
>> by application, such as efibootmgr. The normal approach is to create
>> efi/<vendorname> directory and to copy the application there, then =
create the
>> boot manager configuration.
>>=20
>> See UEFI specification v2.7, chapter 3 Boot Manager, page 79.
>>=20
>> What is different in FreeBSD case is that the whole interface to =
program the
>> UEFI Boot Manager is currently being developed, so either it has to =
be done
>> manually or from some other OS (see =
https://wiki.gentoo.org/wiki/Efibootmgr
>> <https://wiki.gentoo.org/wiki/Efibootmgr>; for example, first hit from
>> google:D).
>=20
> Well, thanks for this important hint! FreeBSD 12-CURRENT's and FreeBSD
> 11.2-RELENG's USB flash devices are capable of booting off on =
Fujitsu's ESPRIMO
> and ASRock's boards. As a note: after "kldload efirt.ko" I was able to =
use the
> already in FreeBSD present toolset efibootmgr(8) and sibblings (the =
tools do
> not do anything useful when booted non-UEFI).
>=20
> Mounting the ESP of the harddrive (in my case, ada0p1) to /mnt and =
following
> the steps in the examples and having created /efi/freebsd/BOOTx64.efi =
as
> recommended by copy from /efi/boot, let me create a proper boot =
variable.
>=20
> To make things sure, I also applied "efibootmgr -a VARIABLENAME".
>=20
> And ... it worked! Yes, it worked! The ESP is FAT32 formatted, I do =
not know
> whether this will also work with FAT12/16, I should test this case, =
too.
>=20
> There is a bug in the manpage of efibootmg(8). It does not explain the =
options
> -d and -p, although they could be "implied" by reading carefully. =
There is now
> a PR at=20
>=20
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230080
>=20
> for this issue.
>=20
> So, it's apity that the handbook has no note I could easily find on =
this;=20
>=20
> Thank you very much for your patience and help!
>=20
> Kind regards,
> Oliver
yep, efibootmgr does call UEFI RuntimeServices to set up the variables, =
and this is only possible when booted UEFI. But glad we finally found =
the root cause. It would be good to have HW notes for such cases, it is =
important to know that those systems wont boot UEFI from HDD unless the =
boot manager setup is done.
rgds,
toomas=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6C5D21D2-59C6-42DB-AC75-79D98BA5E62B>