Probably start here: help.ubuntu.com/community/UEFI
UEFI (~EFI) is a firmware interface that is widespread on recent computers, especially those more recent than 2010. It is intended to replace the traditional BIOS firmware interface that is prevalent on earlier machines. This page provides information about installing and booting Ubuntu using EFI, as well as about switching between EFI mode and legacy BIOS mode using Ubuntu.
UPDATE:
Ubuntu 12.10 is intended to be able to be used with Secure Boot.
Softpedia (Sep-2012) >> Canonical Unveils Plans for Ubuntu 12.10 Secure Boot
Canonical, through Jon Melamut, announced on September 20th that they will plan to implement support for Secure Boot in the upcoming Ubuntu
12.10 (Quantal Quetzal) operating system.
Therefore, after a discussion with Free Software Foundation, Canonical decided to drop the EFILinux bootloader implementation in
favor of the GRUB2 bootloader one, signed with their own keys. ..
Muktware (Oct-2012) >> SecureBoot In Ubuntu 12.10
Ubuntu 12.10 is the first distro that supports the Secure Boot architecture by default. Canonical developers have spent a huge amount
of time making sure that Ubuntu runs fine and without problems in all
hardware. Steve Langasek, an Ubuntu developer has put forward a nice
account in his blog, regarding how they are making Secure Boot
supported.
closes with ..
Langasek says that they will backport the secure boot mechanism to Ubuntu 12.04 release as well, so that the LTS version can be installed
in Secure Boot devices. So the next major service pack of Ubuntu
Precise (12.04.2) will include support for SecureBoot.
The simple solution is to disable Secure Boot, as described on this page of mine. To be sure, it's better to run with Secure Boot enabled, but if the feature isn't working as designed, it's a liability.
For more thorough diagnostics, I recommend you start by examining your EFI boot entries by typing sudo efibootmgr -v
, as in:
$ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0003,0007,0001
Boot0000* rEFInd Boot Manager HD(2,1f4800,82000,5f6b4992-fcfe-4a2c-9e67-98b0a30dfe7d)File(\EFI\refind\refind_x64.efi)
Boot0001* Lenovo Recovery System HD(3,276800,1f4000,de3b7563-97f5-48c6-ab7f-2f5d6d57c644)File(\EFI\Microsoft\Boot\LrsBootMgr.efi)RC
Boot0003* ubuntu HD(2,1f4800,82000,5f6b4992-fcfe-4a2c-9e67-98b0a30dfe7d)File(\EFI\ubuntu\shimx64.efi)RC
Boot0007* Windows Boot Manager HD(2,1f4800,82000,5f6b4992-fcfe-4a2c-9e67-98b0a30dfe7d)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Check the BootOrder
line and examine each of the entires specified in order. For instance, in this example, 0000
is first, and Boot0000
launches rEFInd. What you should examine in more detail is the file that's launched, such as \EFI\refind\refind_x64.efi
for this example's Boot0000
. In the case of a standard Ubuntu Secure Boot launch, the file should be shimx64.efi
, which of course is not the case for this example's Boot0000
-- but it is true for this example's next boot entry, Boot0003
.
This example would probably produce a Secure Boot warning such as you describe on most computers, but after that warning, GRUB and Ubuntu might launch, since when Boot0000
failed, the system would move on to Boot0003
, which should succeed. It's possible that something like this is happening to you -- but it's probably launching grubx64.efi
first, and then either failing to move on or shimx64.efi
might not have an entry. If this is the case for you, you could tweak the boot order with the -o
option to efibootmgr
or create a new entry entirely. The details depend on what you see from efibootmgr -v
and what's actually installed on your hard disk, though.
If your efibootmgr -v
output shows that the computer should be launching shimx64.efi
first, then I recommend you compare that file to the EFI/BOOT/bootx64.efi
file on the Ubuntu installation media that do boot. Check their file sizes with ls -l
and check if they're identical with diff
; for instance:
diff /mnt/cd-media/EFI/BOOT/bootx64.efi /mnt/esp/EFI/ubuntu/shimx64.efi
(The mount points are likely to be different, of course.) These files should be identical, which diff
indicates by providing no output. If they aren't, you could try overwriting the shimx64.efi
on the hard disk with bootx64.efi
from the installation medium. If the two files are not identical because of a package upgrade, that would be cause for filing a bug report. They might not be identical for some other reason, though, like disk corruption or a (very rare) error when copying files.
If the files are identical but the external medium boots and the hard disk doesn't, then that probably means you've got a buggy EFI. You might look for an update on your manufacturer's Web site. (They probably call it a "BIOS update," although it's really not a BIOS.) If that doesn't help, you might try filing a bug report with the manufacturer.
Best Answer
I believe your understanding is correct, except that
shimx64.efi
is delivered in binary form via a package, not generated locally viagrub-install
. (grub-install
is likely to installshimx64.efi
to the ESP, though.) Oh, and it's MokManager, not MoakManager.Before you file a bug report, you should retrace your steps and be 100% sure that you're booting via your locally-compiled GRUB. It's easy to accidentally put a binary in the wrong location or neglect to run
efibootmgr
to adjust the boot order, for instance. (You haven't described how you're installing your customgrubx64.efi
-- are you overwriting the standard Ubuntu binary or putting your new one elsewhere and registering it [and a copy of Shim] viaefibootmgr
?) You might want to runsudo efibootmgr -v
to see your boot details. Pay attention to theBootOrder
andBootCurrent
lines -- the former tells you the order in which boot options will be tried and the latter shows the option that was used to boot the computer. You'll need to cross-reference the numbers with the variousBoot####
lines that describe each boot option. If you installed your own GRUB separate from Ubuntu's GRUB, it's conceivable that the firmware silently bypassed it because of a Secure Boot error and then fell back on the stock Ubuntu Shim/GRUB, which would explain what you're seeing.Another possibility is that Secure Boot is not actually enabled on your computer. You can check this possibility as follows:
In this example, the first line of output (
0000000 0016 0000 0001
) ends in a1
. This indicates that Secure Boot is active. If it ends in a0
, then Secure Boot is disabled on your computer.One other possibility is that you might have somehow installed your local key in the firmware's own db list. This is a difficult task, though, so it's unlikely you've done it accidentally and without realizing it. (See my page on the subject for details on how to set this up.) I mention this possibility mainly for the sake of completeness; it doesn't strike me as likely at all unless you're omitting mention of a previous attempt at mastering Secure Boot in this way.
If you are seeing a bug, it could be in either Shim or in your firmware.
One more caveat is that I'm only passingly familiar with GRUB-specific tools such as
grub-mkstandalone
. As I maintain rEFInd, I prefer to use it, so my knowledge of GRUB tools isn't as in-depth as it might be. Thus, I might be missing some critical detail because it's GRUB-specific.