vmlinuz-4.18.12-041812-generic has invalid signature
I have dual boot with windows 10 and ubuntu 18.10 (Upgraded today) Update: I managed to boot to older kernel that i chose from «Advanced options for Ubuntu» in grub But I need to upgrade my kernel and if I do that I still get the same problem.
I solved my problem following this tutorial to sign /boot/vmlinuz file for secure boot, Just notice the last part of the tutorial
I’m experiencing this same problem now after updating the firmware of my Lenovo T480 and I don’t understand why the older kernels still work.
3 Answers 3
https://github.com/jakeday/linux-surface/blob/master/SIGNING.md has more specific instructions on kernel signing (adapted from the same tutorial linked in the accepted answer). The instructions are reproduced in full as follows:
Signing a custom kernel for Secure Boot
Instructions are for ubuntu, but should work similar for other distros, if they are using shim and grub as bootloader. If your distro is not using shim (e.g. Linux Foundation Preloader), there should be similar steps to complete the signing (e.g. HashTool instead of MokUtil for LF Preloader) or you can install shim to use instead. The ubuntu package for shim is called shim-signed , but please inform yourself on how to install it correctly, so you do not mess up your bootloader.
Since the most recent GRUB2 update (2.02+dfsg1-5ubuntu1) in Ubuntu, GRUB2 does not load unsigned kernels anymore, as long as Secure Boot is enabled. Users of Ubuntu 18.04 will be notified during upgrade of the grub-efi package, that this kernel is not signed and the upgrade will abort.
Thus you have three options to solve this problem:
- You sign the kernel yourself.
- You use a signed, generic kernel of your distro.
- You disable Secure Boot.
Since option two and three are not really viable, these are the steps to sign the kernel yourself.
Instructions adapted from the Ubuntu Blog. Before following, please backup your /boot/EFI directory, so you can restore everything. Follow these steps on your own risk.
# This definition stops the following lines failing if HOME isn't # defined. HOME = . RANDFILE = $ENV::HOME/.rnd [ req ] distinguished_name = req_distinguished_name x509_extensions = v3 string_mask = utf8only prompt = no [ req_distinguished_name ] countryName = stateOrProvinceName = localityName = 0.organizationName = commonName = Secure Boot Signing Key emailAddress = [ v3 ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical,CA:FALSE extendedKeyUsage = codeSigning,1.3.6.1.4.1.311.10.3.6 nsComment = "OpenSSL Generated Certificate" Adjust all parts with to your details.
openssl req -config ./mokconfig.cnf \ -new -x509 -newkey rsa:2048 \ -nodes -days 36500 -outform DER \ -keyout "MOK.priv" \ -out "MOK.der" openssl x509 -in MOK.der -inform DER -outform PEM -out MOK.pem sudo mokutil --import MOK.der You will be asked for a password, you will just use it to confirm your key selection in the next step, so choose any.
- Restart your system. You will encounter a blue screen of a tool called MOKManager. Select «Enroll MOK» and then «View key». Make sure it is your key you created in step 2. Afterwards continue the process and you must enter the password which you provided in step 4. Continue with booting your system.
Note: if MOKManger does not load on reboot then change the boot order. link
sudo mokutil --list-enrolled sudo sbsign --key MOK.priv --cert MOK.pem /boot/vmlinuz-[KERNEL-VERSION]-surface-linux-surface --output /boot/vmlinuz-[KERNEL-VERSION]-surface-linux-surface.signed sudo cp /boot/initrd.img-[KERNEL-VERSION]-surface-linux-surface
- Reboot your system and select the signed kernel. If booting works, you can remove the unsigned kernel:
sudo mv /boot/vmlinuz-[KERNEL-VERSION]-surface-linux-surface sudo mv /boot/initrd.img-[KERNEL-VERSION]-surface-linux-surface sudo update-grub Now your system should run under a signed kernel and upgrading GRUB2 works again. If you want to upgrade the custom kernel, you can sign the new version easily by following above steps again from step seven on. Thus BACKUP the MOK-keys (MOK.der, MOK.pem, MOK.priv).
«Error: Invalid signature» when configuring dual boot Ubuntu 14.04 and Windows 10
After installing the Windows 10 upgrade on my laptop, it ruined the grub boot manager, and I could only boot in windows 10. I fixed the boot manager using a live cd with the boot-repair tool, but it only recognized the Ubuntu partition, and not the Windows one. So I edited the /etc/grub.d/40_custom file and added the following contents:
After running sudo update-grub2 , I got an entry in the boot menu, but the partition does not load. It gives the following error:
Does anybody know how one can overcome this error? My most recent boot-repair dump is here: http://paste.ubuntu.com/11965327/, and the partition I want to boot is this one:
sda4: __________________________________________________________________________ File system: ntfs Boot sector type: Windows 8/2012: NTFS Boot sector info: No errors found in the Boot Parameter Block. Operating System: Boot files: /bootmgr /Windows/System32/winload.exe @Fabby: That’s interesting. I would rather not mess up my ubuntu partition since it’s the one use primarily. I am now downloading the windows 10 image from microsoft, and I will try to install it as non-UEFI if it has the option.
3 Answers 3
There are some peculiarities about your installation:
- Your computer has two Windows Recovery Environment partitions, /dev/sda1 and /dev/sda5 . My guess is one is from your previous Windows installation and the other is for the new installation, but I can’t be positive of that. I doubt if this duplication is causing you any problems per se; I mention it simply because it’s a sign of a history of changes to the machine, and such changes may be both the cause of problems and make it difficult to figure out what’s wrong.
- Your EFI System Partition (ESP) is /dev/sda4 . This is perfectly legal, but is unusual; the ESP is normally /dev/sda1 or /dev/sda2 . The ESP holds EFI-mode boot loaders and related files. My hunch is that the ESP was created late in the machine’s history — perhaps it was Ubuntu-only at one point and then you installed Windows, which created the ESP in this unusual location.
- The Boot Info Script output doesn’t identify any EFI boot loaders on the ESP. My suspicion is that they do exist, but the script has omitted these entries. (I’ve seen this happen from time to time.) OTOH, if those files are missing, then it means that Windows has failed to install its boot loader. The same may be true of Ubuntu, too; but see below.
- Your disk uses the GUID Partition Table (GPT), which means that Windows will install to and boot from this disk only in EFI mode; but there’s evidence of a BIOS-mode installation of GRUB, the standard Ubuntu boot loader. Such a mish-mash means that you’d not be able to boot Windows from a BIOS-mode GRUB on this computer. It could be you’ve also got an EFI-mode GRUB and had been booting that way; or maybe you had been switching between OSes by using the computer’s built-in boot manager (typically accessed by hitting Esc, Enter, or a function key at start time).
At this point, your best bet is to install an EFI-mode boot loader for Linux. There are two ways to do this that are relatively safe and easy. Both work best if you first enter your firmware and completely disable any option to boot using BIOS, CSM, or legacy mode. (Those are three terms for the same thing.) Sometimes these options are phrased the other way — you must enable EFI or UEFI support. With that done, do one of two things:
- Method 1: Boot your Ubuntu install disk, ensure you’ve booted in EFI mode by looking for the /sys/firmware/efi directory (if it’s present, you’ve booted in EFI mode), install the boot-repair package, and run it. This should repair your installation by installing an EFI version of GRUB. This usually works, but occasionally it doesn’t. I realize you’ve already run Boot Repair, but my suspicion is that you ran it in BIOS mode, which of course means it would install the BIOS-mode GRUB, which will be useless for booting Windows.
- Method 2: If you haven’t done so already, disable Secure Boot in your firmware. You can then download and prepare a boot medium from the CD-R or USB flash drive version of my rEFInd boot manager. Boot to it; it should show you a menu with at least one option for each of Windows and Ubuntu. Test these to be sure you can boot both OSes, then boot Ubuntu. At this point, you can install the rEFInd Debian package or PPA. (Alternatively, you could install the EFI version of GRUB.) You may be able to re-enable Secure Boot at this point, but you may need to jump through some extra hoops to get it to work.
There should be no need to re-install Ubuntu, and probably not to re-install Windows. BIOS-mode and EFI-mode installations of Ubuntu are identical except for the boot loader (and related partitions — but you’ve got the partitions to handle both modes).
Grub2 fails to chainload Windows 7 with error «invalid signature»
I’ve built a new UEFI 64-bit system with both Windows 7 and Ubuntu 11.10 installed (on separate hard drives). I’d like to be able to boot Windows 7 from the grub menu, but I have so far been unsuccessful in getting grub to chainload it. After getting the grub menu, I choose the option for the command line and I can see that bootmgfw.efi is at (hd1,gpt1)/efi/Microsoft/Boot/bootmgfw.efi . However, when I attempt to chainload I get an error:
grub> chainloader (hd1,gpt1)/efi/Microsoft/Boot/bootmgfw.efi error: invalid signature I am not sure whether I chose the UEFI boot option when I installed Linux from the LiveCD, and so I am wondering if the grub I have is perhaps unable to chainload in this manner? In any case I am not sure how to get the chainload to work.
1 Answer 1
As I began to suspect when I was writing my question, the issue is that Linux was installed using MBR, so that grub was unable to chainload an EFI Windows 7. I reinstalled Linux, this time making sure to select the UEFI boot option for the LiveCD from BIOS. With Linux now installed with an EFI grub, I was able to add a grub menu entry for Windows 7 and chainload successfully.
I used this link to create the menu entry for Windows 7.
After doing sudo vi /etc/grub.d/40_custom and adding the menu entry to the end of the file, don’t forget to run sudo update-grub .
If you found the solution to your own problem, go ahead and mark it «answered» by clicking the checkmark next to your answer. It may help someone in the future 🙂
Ha yeah I will do that as soon as the site lets me; yesterday when I tried to accept my own answer it informed me I need to wait a day, and just now it says 10 hours remain. But I’ll take care of it tomorrow.