I had a working dual boot system, Kubuntu 15.04 and Windows 8.1 - after an update 3-4 weeks ago, Ubuntu wont boot when secure mode is enabled. I get an error message "Invalid Signature Detected. Check secure boot policy in setup" - in red. Hitting ok boots directly into windows. Disabling secure boot allows to boot into ubuntu.

I've tried boot-repair from a live usb, I've tried to add an entry with efibootmgr, pointing to EFI/ubuntu/shimx64.efi, I've reloaded the keys in the bios menu, no luck. PC is an asus bu401lg.

Despite the impressive number of posts on the subject, I am stuck !

Any help would be appreciated,

----- result of efibootmgr -v
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0007,000B,000C
Boot0000* ubuntu    HD(1,800,32000,13b34077-a16e-4891-072-3ba610c5cadf)File(\EFI\ubuntu\grubx64.efi)
Boot0007* Windows Boot Manager  HD(1,800,32000,13b34077-a16e-4891-b072-3ba610c5cadf)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.}...i................
Boot000B* UEFI: VerbatimSTORE N GO 5.00 ACPI(a0341d0,0)PCI(14,0)USB(3,0)HD(1,800,e8f800,45a9c3de)..BO
Boot000C* ubuntu    HD(1,800,32000,13b34077-a16e-4891-b072-3ba610c5cadf)File(\EFI\Ubuntu\grubx64.efi)
  • yea, I have seen this "bug" too. Run boot repair and follow the instruction. help.ubuntu.com/community/Boot-Repair . Basically you need a signed kernel image and boot repair will download one for you – Panther Jul 31 '15 at 3:41
  • thanks - I've already run boot-repair, from a usb witha kubuntu 15.04, and didnt get any improvement – cerien Jul 31 '15 at 4:00
  • Post the like boot-repair gave you. What hardware are you running ? – Panther Jul 31 '15 at 4:01
  • Thanks for helping out. The link to the info: paste.ubuntu.com/11973405 - I am running on an Asus BU401LG,. Note that there are 2 disk, an SSD where the OS are installed, called sdb (yes, b), and a classic data disk, sda. On sdb, I have a windows 8.1 and Ubuntu 15, on sda, just data (thought it appears to have an MBR) – cerien Jul 31 '15 at 13:56

Some computers have EFIs that don't accept the Secure Boot signatures on some EFI binaries. I've seen this problem on my ASUS P8H77-I motherboard. Basically, take two signed binaries (say, shim1.efi and shim2.efi), both of which are recognized as properly signed by another motherboard. On my ASUS, just one of those binaries may be recognized as valid; the other may be rejected. Needless to say, this is extremely frustrating. I don't know for certain if it's a bug in the firmware or if there's something wrong in the way the binaries are built or signed and that some EFIs are letting bad signatures past. I've not yet seen the problem with binaries built with the TianoCore EDK2 toolkit, but I have seen it with binaries built with GNU-EFI. (To the best of my knowledge, Shim is always built with GNU-EFI.)

In any event, if this is the problem, the solution is to revert to a known-working Shim binary. If you don't have a copy of your old Shim, try this one:


It's old, but it's proven to be reliable for me. If you use it, you'll probably have to register Ubuntu's key via MokManager. The key is available in an Ubuntu package, but I don't recall which one offhand. I've collected a bunch of keys in my rEFInd project; you can download them piecemeal here:


You'll need the canonical-uefi-ca.der file to boot Ubuntu's version of GRUB.

If you try replacing your Shim, I recommend you back up your old one and the associated MokManager binary and then copy the new one and its associated MokManager binary over the original filenames. (This may involve renaming shimx64.efi to shim.efi or vice-versa.) Ordinarily, an Ubuntu installation's Shim will be in /boot/efi/EFI/ubuntu/.

All this said, it's conceivable that something else is wrong, especially if you're certain your system hasn't upgraded Shim recently. An unsigned GRUB might be to blame, for instance.

  • Thanks for this insight, and also for your explanations on your website. One important thing is that secure boot worked for a couple of months. I think this can be caused by the fact that efibootmgr shows that boot000 points to \EFI\ubuntu\grubx64.efi and not shimx64.efi - i've tried to add another entry (first in boot seq) with shimx64, but it didnt work - do you think this could be the cause ? – cerien Jul 31 '15 at 20:24
  • Please edit your question to show the output of sudo efibootmgr -v. Add four spaces to the start of each line to maintain legibility. Note that the boot numbers (Boot0000, Boot001A, etc.) have nothing to do with the boot order; that is determined by the BootOrder variable. It's possible that your boot order has gotten messed up, so with any luck that may be all you'll need to fix. – Rod Smith Jul 31 '15 at 20:35
  • I have tried to add the shimx64.efi with the following command: efibootmgr -c -d /dev/sdb -p 1 -l '\EFI\ubuntu\shimx64.efi' -L "Ubuntu shimx64" - but it did not work – cerien Jul 31 '15 at 21:07
  • The command you specified should work if Shim is on /dev/sdb1. If so, you should see an entry in the efibootmgr -v output pointing to the shimx64.efi binary, and the BootOrder line should show that entry's number first in the list. If you don't see the new entry, then something was wrong with the command; and if you see it but it's not first in BootOrder, you may need to use the -o option to efibootmgr to adjust the boot order. Updating the efibootmgr -v output you added may be helpful at this point. – Rod Smith Jul 31 '15 at 22:24
  • thanks for helping so much ! after issuing the command, it actually appeared as first in boot order and shimx64 is on /dev/sdb1 - I will try again and let you know – cerien Jul 31 '15 at 23:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.