Date: Fri, 27 Jul 2018 07:46:21 +0200 From: "O. Hartmann" <ohartmann@walstatt.org> To: Toomas Soome <tsoome@me.com> Cc: "O. Hartmann" <ohartmann@walstatt.org>, "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: <20180727074558.75b2d730@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <7FA45CAF-6869-4DF6-AA93-5F96F83EF958@me.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 26 Jul 2018 19:23:43 +0300
Toomas Soome <tsoome@me.com> wrote:
(reply inline/at the end)
> > 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> wrot=
e:
> >>>>=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> wro=
te:
> >>>>>>=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 regardin=
g 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> w=
rote:
> >>>>>>>>=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.o=
rg
> >>>>>>>>>>>> <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 proble=
ms 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 (IvyBrid=
ge,
> >>>>>>>>>>>>>> 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 revi=
sion
> >>>>>>>>>>>>>> for the Spectre/Meltdown mitigation is available, but I di=
dn't
> >>>>>>>>>>>>>> test that. But please read.
> >>>>>>>>>>>>>>=20
> >>>>>>>>>>>>>> The third box I realised this problem is a brand new Fujit=
su
> >>>>>>>>>>>>>> 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 bsdin=
stall
> >>>>>>>>>>>>>> the OS using UEFI-only boot method on a GPT partitioned de=
vice
> >>>>>>>>>>>>>> fails. The ASRock boards jump immediately into the firmwar=
e,
> >>>>>>>>>>>>>> the Fujitsu offers some kind of CPU/Memory/HDD test facili=
ty.
> >>>>>>>>>>>>>>=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 bri=
ght
> >>>>>>>>>>>>>> and shiny with a much higher resoltion as long the GPU sup=
ports
> >>>>>>>>>>>>>> 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 th=
e GPT
> >>>>>>>>>>>>>> scheme, when initialised via gpart, to let the partitions =
start
> >>>>>>>>>>>>>> at block 1. This might be a naiv thinking, so please be pa=
tient
> >>>>>>>>>>>>>> with me.
> >>>>>>>>>>>>>>=20
> >>>>>>>>>>>>>> I do not know whether this is a well-known issue. On the A=
SRock
> >>>>>>>>>>>>>> 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 vidconsol=
e 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 devi=
ce
> >>>>>>>>>>>>> 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 wo=
rk 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 Win=
dows
> >>>>>>>>>>>> 8/8.1 - and nothing else, but the fact that Linux worked con=
fuses
> >>>>>>>>>>>> me a bit.
> >>>>>>>>>>>>=20
> >>>>>>>>>>>> If this ASRock crap (never ever again this brand!) doesn't w=
ork
> >>>>>>>>>>>> at all - who cares, I intend to purchase new server grade
> >>>>>>>>>>>> hardware. But the more puzzling issue is with the Fujitsu, w=
hich
> >>>>>>>>>>>> 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 dis=
able
> >>>>>>>>>>>> CSM support, that the Firmware will only EFI/UEFI capable
> >>>>>>>>>>>> loader? Or is there a ghosty override somwhere to be expecte=
d?).
> >>>>>>>>>>>> Also on ASRock disabling CSM should ensure not booting a
> >>>>>>>>>>>> dual-bootstrap-capable system. This said, on the recent Fuji=
tsu,
> >>>>>>>>>>>> it seems to boil down to a FreeBSD UEFI-firmware interaction
> >>>>>>>>>>>> problem, while the ASRock is still under suspicion to be bro=
ken
> >>>>>>>>>>>> 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), se=
ctor
> >>>>>>>>>>>>> 1 is GPT table and then sectors 2-33 have GPT partition tab=
le
> >>>>>>>>>>>>> entries, so the first possible data sector is 34 (absolute =
34).
> >>>>>>>>>>>>> Thats assuming 512B sectors. For details see UEFI 2.7 Chapt=
er
> >>>>>>>>>>>>> 5.3.1 page 131. =20
> >>>>>>>>>>>>=20
> >>>>>>>>>>>> Thanks for the explanation. That implies the installer did r=
ight,
> >>>>>>>>>>>> gpart did also right and therefore there must be an issue wi=
th
> >>>>>>>>>>>> the stuff located within the EFI partition? =20
> >>>>>>>>>>>=20
> >>>>>>>>>>> Ok, so, it is not about UEFI bootcode but BIOS, and if we rea=
ch
> >>>>>>>>>>> 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 Es=
primo
> >>>>>>>>>> Q956, refuse booting UEFI, even if properly setup (in terms of=
what
> >>>>>>>>>> FreeBSD provides on recent CURRENT) is applied and CSM is swit=
ched
> >>>>>>>>>> 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" (ada=
0 is
> >>>>>>>>>> the device). =20
> >>>>>>>>>>>=20
> >>>>>>>>>>> btw, you can try to validate the installed boot blocks by usi=
ng
> >>>>>>>>>>> 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 a=
nd
> >>>>>>>>> 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 abov=
e, 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 alw=
ays
> >>>>>>> end with colon?. in this case, the devil is in details:) as I wro=
te
> >>>>>>> above, the command should be:
> >>>>>>>=20
> >>>>>>> chain disk0:
> >>>>>>>=20
> >>>>>>> The disk0p1: etc will only work when partition boot code was inst=
alled
> >>>>>>> (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-bo=
ot
> >>>>>> 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 disk=
0p2:
> >>>>>>>>> and execute it; stage1 would detect FreeBSD ZFS from disk0p4: a=
nd
> >>>>>>>>> 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 n=
ot
> >>>>>>>>> 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 jus=
t not
> >>>>>>>>> use GPT on that machine with CSM. =20
> >>>>>>>>=20
> >>>>>>>> To make it clear here: The only way to boot this box is using CS=
M (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 wr=
ote
> >>>>>>> that the UEFI boot fails when the first partition starts from sec=
tor
> >>>>>>> 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 la=
youts
> >>>>>> 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 she=
ll
> >>>>>>> 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 fail=
ing
> >>>>>>> to start the bootloader in UEFI is secure boot - we do not suppor=
t 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 scre=
en,
> >>>>>>> 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/workst=
ation
> >>>>>> firmware so far booting FreeBSD off in UEFI-native (GPT partition
> >>>>>> scheme, CSM disabled) so far - until now, when I ran into this Fuj=
itsu
> >>>>>> ESPRIMO Q956 with the most recent firmware (as of lat week, week 2=
9 of
> >>>>>> 2018) having the very same problems.=20
> >>>>>>=20
> >>>>>>=20
> >>>>>>=20
> >>>>>> I figured out something strange on the Fujitsu - and that is the s=
ame
> >>>>>> with the ASRock boards.
> >>>>>>=20
> >>>>>> We/I prepare some USB flash drives to boot a NanoBSD for a very sm=
all
> >>>>>> appliance, but nevertheless, the USB flash device is booted on Fuj=
itsu
> >>>>>> 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 B=
IOS
> >>>>>> 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, efiboot=
0 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 s=
imple.
> >>>>>>=20
> >>>>>> This USB flash device boots(!) successfully (UEFI!) on both the AS=
Rock
> >>>>>> 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-att=
ached
> >>>>>> 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 on=
e 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 h=
int
> >>>>> 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 hel=
p how
> >>>> to find out the format (FAT12/16/32) of the ESP, so I assume when us=
ing
> >>>> 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 al=
so
> >>>> 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 pr=
oper
> >>>> 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 co=
pied
> >>>> the the content of boot1.efifat (mdconfig -t vnode ..., I guess we k=
now
> >>>> 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 F=
AT32,
> >>>> 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 decribe=
d.
> >>>> 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 doe=
s 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 suf=
fice
> >>> - that would give us confirmed working ESP file system (since the oth=
er 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 investigat=
e the
> > FAT format, but this might be unnecessary as shown further in this pos=
t.
> > - 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 U=
SB
> > 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 starti=
ng
> > at block 40, the boot1.efifat image dd'ed onto the partition, UFS parti=
tion
> > 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 interfac=
e 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 t=
he
> boot manager entry to be created instead.
This inplication I'd confirm for the recent Fujitsu ESPRIMO Q956 firmware (=
not
tested on ASRock Z77-Pro4 firmware).
>=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 do=
ne
> manually or from some other OS (see https://wiki.gentoo.org/wiki/Efibootm=
gr
> <https://wiki.gentoo.org/wiki/Efibootmgr>; for example, first hit from
> google:D).
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 ESP=
RIMO
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).
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.
To make things sure, I also applied "efibootmgr -a VARIABLENAME".
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.
There is a bug in the manpage of efibootmg(8). It does not explain the opti=
ons
-d and -p, although they could be "implied" by reading carefully. There is =
now
a PR at=20
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230080
for this issue.
So, it's apity that the handbook has no note I could easily find on this;=20
Thank you very much for your patience and help!
Kind regards,
Oliver
>=20
> rgds,
> toomas
>=20
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180727074558.75b2d730>