Date: Thu, 26 Jul 2018 19:23:43 +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: <7FA45CAF-6869-4DF6-AA93-5F96F83EF958@me.com> In-Reply-To: <20180726155821.6f9906e9@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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
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.
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.
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.
See UEFI specification v2.7, chapter 3 Boot Manager, page 79.
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).
rgds,
toomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7FA45CAF-6869-4DF6-AA93-5F96F83EF958>