[Bug 1366546] Re: Ubuntu doesn't provide \EFI\BOOT\BOOTX64.EFI for UEFI systems

[Benjamin Tegge]

Thank you for your reply. I tested a Toshiba Satellite NB10-A-10N as a
user reported having trouble with a device of that model series
(NB10t-A-101, the "t" in the NB10-A series seems to indicate touch
capability). I just looked into the UEFI Specification Version 2.4
(Errata B) and found "3.4.1.1 Removable Media Boot Behavior":

> On a removable media device it is not possible for the FilePath to
contain a file name, including sub directories. FilePathList[0] is
stored in non volatile memory in the platform and cannot possibly be
kept in sync with a media that can change at any time. [...]

>From my point of view these sentences state: The information which
loader to boot from the supported filesystems is stored in the platform
(simply speaking, an entry in the NVRAM of the mainboard) and not
available when you take out the drive and try to boot it on another
computer.

> If FilePathList[0] points to a device that supports the
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, then the system firmware will attempt
to boot from a removable media FilePathList[0] by adding a default file
name in the form \EFI\BOOT\BOOT{machine type short-name}.EFI.

This describes that booting can be done through
\EFI\BOOT\BOOT{arch}.EFI. I think we agree on that, I'm just adding it
for completeness.

I admit that I haven't read the entire spec, but I do think that there
is a misunderstanding here regarding what removable media is or is not
and that this section defines a fallback for usecases when information
that is only stored in the platform is not available like installing
Ubuntu to an external harddrive, which is still possible with UEFI.
(This fallback should be deployed with the default Ubuntu installation
as it would enable bootable external and internal installations, no
matter if a firmware implementation is considered to be broken, crippled
or non-standard.)

I have seen many cases over at AskUbuntu that I would consider being
occurrences of this issue in retrospect. We would need a tool (or
testcase) that users can run to gather further data if a system follows
the standard and boots so called NVRAM entries successfully or requires
above method to execute a bootloader in UEFI mode that belongs to
Ubuntu.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1366546

Title:
  Ubuntu doesn't provide \EFI\BOOT\BOOTX64.EFI for UEFI systems

Status in “grub2” package in Ubuntu:
  Incomplete

Bug description:
  Ubuntu (desktop/server platform AMD64) as of 14.04 just installs
  shim.efi and grubx64.efi in \EFI\ubuntu\ on the EFI System Partition
  (ESP). This is unreliable as more and more laptops are introduced to
  the market where manufacturers choose to reduce (cripple) the firmware
  functionality to boot only from \EFI\BOOT\BOOTX64.EFI. To make the
  situation worse legacy boot is also *not implementent* anymore in the
  firmware. Mostly mainstream consumer oriented and low budget devices
  are affected.

  Ubuntu should backup contents of \EFI\BOOT\ (these are just normal
  files on FAT32, zipping or taring the directory should be suffcient,
  another run of the installer however should detect an existing backup
  of the original and not overwrite the backup of the original) and
  install a UEFI loader to \EFI\BOOT\BOOTX64.EFI that can boot at least
  Windows and Ubuntu.

  My suggestion would be to use gummiboot [1] in conjunction with
  PreLoader+HashTool [2] as this will allow functional UEFI Secure Boot
  (preloader will provide keys to shim to close the gap in gummiboot)
  and being of low complexity or low resource footprint.

  Contents to be installed to the ESP:

  \EFI\BOOT\BOOTX64.EFI
  > This is a renamed PreLoader.efi.
  \EFI\BOOT\HashTool.efi
  \EFI\BOOT\loader.efi
  > This is a renamed gummiboot.efi to be easily picked up by HashTool (loader.efi is the default).

  content of gummiboot configuration file: \loader\entries\ubuntu-grub-shim.conf
      title          Ubuntu GRUB (Secure Boot)
      efi            \EFI\ubuntu\shimx64.efi

  content of gummiboot configuration file: \loader\entries\ubuntu-grub.conf
      title          Ubuntu GRUB
      efi            \EFI\ubuntu\grubx64.efi

  content of gummiboot configuration file: \loader\loader.conf
      default        Ubuntu GRUB (Secure Boot)
      timeout        4

  If UEFI Secure Boot is enabled, PreLoader will run HashTool on first
  boot to enroll the hash of gummiboot. The TUI dialogs are simple and
  straight forward, but the user should be informed that this might
  happen when installation on a Secure Boot enabled target has been
  completed. Please have a look the ASCII art representation of the TUI
  dialogs [3].

  Notes:
  - gummiboot is not currently packaged in Ubuntu or Debian AFAIK. While having gummiboot packaged as a full GRUB replacement [4] would be nice, we need only the loader binary (gummiboot.efi) to fix this bug.
  - An existing Windows UEFI loader on the ESP is automatically detected and doesn't need to be configured.
  - Replacing an exsiting \EFI\BOOT\BOOTX64.EFI is similar to overwriting the MBR, it's nasty but the most simple solution for the corresponding design.

  I need to emphasize this:
  - Legacy boot is not available on these machines.
  - Users with affected laptops don't understand the issue they run into. -> They can't install/boot Ubuntu anymore, while no other OS vendor did anything particular evil (till now).
    - Giving users instructions which requires little knowledge of how to use the terminal is too difficult to follow for them (they find it nearly impossible and not very ubuntu-like)
    - The community has a lot of users who don't know the difference between booting with UEFI or legacy BIOS, thus suggesting false troubleshooting or tools that don't work or add more confusion to the situation.
    - Telling users to buy fully functional or non-crippled hardware has always been difficult.
  - This a major issue that should be fixed with the next LTS 14.04.x release update or probably an emeregency update of the live media. Waiting more than one year may result in Ubuntu becoming less and less attractive to novice users.

  I'm looking forward to work with you on this issue and provide further
  information where possible.

  [1]: http://freedesktop.org/wiki/Software/gummiboot/
  [2]: http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/
  [3]: http://askubuntu.com/a/520351/40581
  [4]: http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1366546/+subscriptions