[Bug 1366546] Re: Ubuntu doesn't provide \EFI\BOOT\BOOTX64.EFI for UEFI systems
Phillip Susi
psusi at ubuntu.com
Tue Nov 11 18:24:03 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/11/2014 11:21 AM, Benjamin Tegge wrote:
> I checked on the Toshiba Satellite NB10-A-10N during my testing
> and after the installation was done when I ran `efibootmgr -v` the
> typical all lowercase "ubuntu" entry was in the output. When I
> restored the drive to the initial state and removed the entry to
> reinstall with secure boot enabled the result was the same on this
> machine: the catalog was updated. I think we can rule that out.
Can I assume it was also set as the default boot choice? i.e.
BootOrder listed its number first? It would be worth checking if
deleting the bootx64.efi got it to obey the boot catalog.
> I'd rather put the blame on the manufacturers or who ever writes
> the firmware, but that wouldn't help solving the problem I guess.
> :)
True; it is ultimately on the motherboard manufacturers, but they can
only get away with this because Microsoft installed a boot loader
where they have no business doing so.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
iQEcBAEBAgAGBQJUYlRDAAoJEI5FoCIzSKrwwPkH/3BICXyPRQE8XumFH7hWAXl+
IS1CbQa6CDViGlTgzHFwhduEXgHj6IuhK9ARBsT075FSK0OrzDG+Nc0qqNha+sSI
UnGjJiL9opmGD8JcZzoLKw4P8wFJ1TwRWf4PupGw6XEYcKJrrOL7mKwTW6EG99pY
l8FzcMa5VFk0IY/o/ksrCkvPC+qSlTSZUjdgSjsD88e1lHCzcQ6NoQZpQW44lprP
Vw4mr8Oycz28mveVw6EV2uk//uIKzNd0xr3INMyF3kXfi0fLPtW0thbSEhvhNUDy
QpiB6BndKSNMD/fbfhb0mmh9VzWjEpZuzqr51lRX47QLE9j46IEFpczqRXUMuCA=
=hkk+
-----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
More information about the foundations-bugs
mailing list