The problem you're encountering is a result of the fact that Ubuntu's kernels (the ones with filenames that end in .efi.signed
) are signed by Canonical's Secure Boot key. This key is not included in most computers' firmware, and so will be rejected by most computers' Secure Boot subsystems. (There are a few exceptions to this rule. I have an ASUS P8-H77I motherboard, for instance, that came with Canonical's public key embedded as standard. If yours were so configured you wouldn't be having this problem, though.)
Broadly speaking, you have three options:
- Take full control of Secure Boot -- You can take full control of Secure Boot and install whatever Secure Boot keys you like. If you add Canonical's key, you'll be able to launch Ubuntu's signed kernels directly. This process is tedious, though. For details on how to do it, see my Web page on the subject. In brief, you'll need to generate your own keys, delete your computer's current key set, add your own keys, add Canonical's key, and optionally add any other keys you might want to use (like Microsoft's keys). There are several ways to do this, some of which rely on the firmware's own user interface, and therefore can't be described with 100% accuracy in a generic way.
- Use Shim -- You can use the
shimx64.efi
program that ships with Ubuntu to launch your kernel. To do this, you would put shimx64.efi
in the same directory as the (renamed) kernel and add shimx64.efi
to the boot list (via efibootmgr
) rather than the kernel. One extra trick is that you'll have to pass the kernel's filename and options to shimx64.efi
via appropriate efibootmgr
options. This would be similar to the efibootmgr -c...
command in step #3 of the answer you referenced, but the program file would be shimx64.efi
and the kernel filename would become an option passed via -u
. Note that not all versions of shimx64.efi
support passing options in this way. I don't recall exactly when this feature was added, but you should be OK with a recent version. Note that I've never attempted to do exactly this myself, so I can't provide you with step-by-step instructions; you'll probably have to experiment to figure out the details yourself. This also means that there's a chance it won't work, although in theory it should work.
- Use a more conventional setup -- IMHO, launching the kernel directly, as you're attempting, is not a good approach, even without Secure Boot in the picture. Although using GRUB, rEFind, or some other boot loader or boot manager is technically a complication of the boot process, these boot programs provide tools for managing the boot process that simplify actual setup. Thus, it's better to use one of these tools, IMHO. If you have a specific gripe with GRUB, you might want to share that; it's conceivable that another boot program will address your issue. If you're just doing this as a learning exercise, though, launching the kernel directly has merit. You'll certainly learn something about the EFI boot process and, in your case, Secure Boot, by getting it working.
If you want an easy solution, using a conventional boot loader or boot manager is the way to go. If you want to learn the most, you might want to look into taking full control of Secure Boot -- but be aware that there are a lot of pitfalls along that path, so it's likely to take a while, even with the help of a guide like the one I wrote and referenced earlier. Using Shim is a sort of middle ground -- it's easier to set up than the full-control approach, but you'll learn less doing it this way.
shimx64.efi
is not GRUB; it's something that extends the Secure Boot system. Bothgrubx64.efi
and Ubuntu's Linux kernel are signed by Canonical's key, which is not included in most computers' firmware. Shim causes additional Secure Boot keys to be recognized and loadsgrubx64.efi
(or conceivably another file, depending on how it's launched). – Rod Smith Aug 23 '17 at 14:43