Bug 214282 - UEFI boot fails due to boot1.efifat's volume label "EFI "
Summary: UEFI boot fails due to boot1.efifat's volume label "EFI "
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 11.0-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: Kyle Evans
URL: https://lists.freebsd.org/pipermail/f...
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-06 19:54 UTC by Harald Schmalzbauer
Modified: 2018-04-19 01:11 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Schmalzbauer 2016-11-06 19:54:00 UTC
At least on Intel single socket servers the UEFI firmware can't handle the msdosfs (FAT12) volume label"EFI        ", which is currently used with "/boot/boot1.efifat" image (tested on 11-release, most likely also on 10.3-release).

Firmware's boot process somehow confused the label "EFI" with the boot path, also containing EFI (as far as I remember the meaning of the failure message).
Affected systems are S1200BT and S1200v3RP e.g.

Simply reformatting with a different volume label solved the problem.

According to Dimitry Andric, it's easily fixable for build process by changing the label name in "sys/boot/efi/boot1/generate-fat.sh".
Sorry, I don't have sources handy right now, so no patch attached. Could suggest one of course, but would take longer to process the one from here instead of direct edit I guess ;-)

Besides changing boot1.efifat, bsdinstall could be modified to work arround; but that's not the right thing IHMO.

People affected (or unsure if they also suffer from this firmware obstacle) could try the following (assuming index 1 of /dev/da0's GPT is the EFI-sys-part):
'newfs_msdos -L DA0BOOT1 /dev/da0p1 && mount /dev/msdosfs/DA0BOOT1 /mnt'
'mkdir -p /mnt/EFI/BOOT && cp /boot/boot1.efi /mnt/EFI/BOOT/BOOTx64.efi'
'echo "BOOTx64.efi" > mnt/EFI/BOOT/startup.nsh && umount /mnt'

Just in case this report is found while people are searching for solution…

-harry
Comment 1 commit-hook freebsd_committer 2018-04-16 13:18:35 UTC
A commit references this bug:

Author: kevans
Date: Mon Apr 16 13:18:19 UTC 2018
New revision: 332561
URL: https://svnweb.freebsd.org/changeset/base/332561

Log:
  Rename volume label for ESP

  Harry Schmalzbauer reports that some firmware, in his experience, trips
  over the ESP we install due to the volume label. It has been theorized that
  this is due to some confusion with the label and the path on the ESP to
  boot1.efi.

  Regardless, Harry found that renaming the label seems to fix it.

  PR:		214282
  MFC after:	3 days

Changes:
  head/stand/efi/boot1/generate-fat.sh
Comment 2 commit-hook freebsd_committer 2018-04-19 01:11:26 UTC
A commit references this bug:

Author: kevans
Date: Thu Apr 19 01:10:54 UTC 2018
New revision: 332746
URL: https://svnweb.freebsd.org/changeset/base/332746

Log:
  MFC r332561,r332573: Rename volume label for ESP

  MFC r332561: Rename volume label for ESP

  Harry Schmalzbauer reports that some firmware, in his experience, trips
  over the ESP we install due to the volume label. It has been theorized that
  this is due to some confusion with the label and the path on the ESP to
  boot1.efi.

  Regardless, Harry found that renaming the label seems to fix it.

  MFC r332573: Regenerate FAT templates after r332561

  PR:		214282

Changes:
_U  stable/11/
  stable/11/stand/efi/boot1/fat-amd64.tmpl.xz
  stable/11/stand/efi/boot1/fat-arm.tmpl.xz
  stable/11/stand/efi/boot1/fat-arm64.tmpl.xz
  stable/11/stand/efi/boot1/fat-i386.tmpl.xz
  stable/11/stand/efi/boot1/generate-fat.sh