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

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/17/2014 12:26 AM, Benjamin Tegge wrote:
> 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.

Right... *for removable media*.  The normal mechanism is for each boot
loader on the disk to be registered in the efi variable boot catalog,
but this obviously can not be done for removable media so there is a
fallback provided for that case.  This fallback is generally only used
when you explicitly press a key during boot to request booting from
something other than the usual boot loader, and it only allows for
there to be a single boot loader on the removable media.  For
installations on fixed disks you want to be able to have multiple boot
loaders installed so you can run different operating systems.

> 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.

I suspect that such cases are the result of bugs preventing the efi
boot catalog from being properly updated ( there have been several of
those ).  The correct solution is to fix the bug and get the boot
catalog updated correctly rather than to violate the efi spec and
blindly overwrite the fallback boot loader.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUToaSAAoJEI5FoCIzSKrwo6wH/0JYfO9xWFsknM1C/tUqYu16
lRyYQEI4tRguVD1Q+ceWSjknH9c12x6QhcUyR2g048aFjj9GjJUM8RRJfKmUpgCc
9yhzJcA2pZrcuE/df1HB5PkCp45HLV8PEA8xYj3KQHBezCJ6r289ve9FThnUNhFd
WObV817umg4SJtkTISV7YLYAy+asU6HS+t/ARAx98HM6Mwq/R8xhcj5BhshtDC1K
dis4U+UBOmZinWnK8WQwD2dQoTYg7XXbNrDrnUN/B7YnKtqv9vioVaY5xwu/KMjc
9bdCIyfU1NWAI8PExdmr/7EQdXhTjlgEwMknKILZaanvUUcXpaeagPpiMTifqik=
=+c+e
-----END PGP SIGNATURE-----

-- 
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