Edit: Just remembered that Clover is a Hackintosh bootloader not an official Apple bootloader and a Mac, what I expected when I wrote this answer.
invalid signature
sounds like your OSX install expects a secure boot chain like Secure Boot on Windows platforms. I'm not sure if this applies here but usually hfs-bless
or Macs bless
command were used to allow EFI booting of non-OSX installations on Macs. Similar to how Linux Foundations preloader bridges the gap of an unsigned EFI loader, bless
theoretically should enable the foreign loader (GRUB) to start OSX.
hfs-bless
is available in the Mactel PPA.
Btw. chainloader
should be correct and sudo grub-mkconfig -o /boot/grub/grub.cfg
and sudo update-grub
are the same, just do a whereis
to find the path and look at update-grub
in an editor. ?
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
As I do not know whether Microsoft did change the boot loader signature with the update
(this anyway would be off-topic here) I suggest the following procedure:
First disable hibernation and Fast Boot in Windows.
Boot into Windows - open command prompt as administrator and execute this command:
Then disable (uncheck) Fast Boot in Control Panel -> Energy Settings (show hidden settings).
Shutdown the machine (do NOT reboot) completely.
Then reinstall GRUB bootloader to your Ubuntu installation in EFI mode.
Boot from the Ubuntu install media - then open a terminal and execute:
Note :
sd*
= disk |sd**
= efi partition |sd***
= system partitionIf you do not know the partition numbers you can easily identify them with GParted.
The (Graphic User Interface) tool is already included in the Ubuntu installation media.
If this solution does not work you unfortunately will have to reinstall ubuntu in insecure mode.
Boot into BIOS (UEFI) and disable Secure Boot, then reinstall ubuntu in the way you did before.