freebsd stable - Nov 2016 - boot1.efifat's FAT12 volume label prevents booting (some systems)

Recently I played with bsdinstall and UEFI setup, which left the system
unbootable (11.0-Release).
The culprit is the MS-DOS volume lable "EFI        " of the EFI
partition.
At least on Intel Single-Socket Servers (for Xeon E3 IvyBridge/BearToot
+ Haswell/RainbowPass), the UEFI firmware can't handle the identical
path/volumelabel.

Simply reformatting with a different volume label (EFIFAT e.g.) solves
that problem!
Shall I file a bug report?

Btw, can someone explain in short words why BOOT64.EFI seems to be
boot1.efi, but padded with 0x20 up to 128k?

Thanks,

-Harry

On 06 Nov 2016, at 16:07, Harry Schmalzbauer <freebsd at omnilan.de>
wrote:
> 
> Recently I played with bsdinstall and UEFI setup, which left the system
> unbootable (11.0-Release).
> The culprit is the MS-DOS volume lable "EFI        " of the EFI
partition.
> At least on Intel Single-Socket Servers (for Xeon E3 IvyBridge/BearToot
> + Haswell/RainbowPass), the UEFI firmware can't handle the identical
> path/volumelabel.
That is pretty weird.  I wasn't aware that any firmware even used this
label for anything?  Maybe they mount it under a directory named after
the label, or something.

> Simply reformatting with a different volume label (EFIFAT e.g.) solves
> that problem!
> Shall I file a bug report?
Please do, so it is not forgotten.  It is relatively easy to change the
volume label, by editing sys/boot/efi/boot1/generate-fat.sh, and then
regenerating the FAT templates.

> Btw, can someone explain in short words why BOOT64.EFI seems to be
> boot1.efi, but padded with 0x20 up to 128k?
At buildworld time, pre-populated FAT file system templates are used,
instead of playing games with mounting ramdisks and creating file
systems in them.  The build process just inserts the contents of
boot1.efi into a fixed location into the existing FAT template.

And the template is pre-propulated with a 128kiB bootx64.efi file.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20161106/5d9df3d3/attachment.sig>