Issue may arise with the machine owner key following an Ubuntu installation.
Issue may arise with the machine owner key following an Ubuntu installation.
Hey there, I just set up a dual-booted Ubuntu on my Windows 10 laptop. Since it has an Nvidia GPU, I added custom drivers during installation. To secure it, I had to set a secure boot password. During one step I got stuck and clicked "Back," which brought me back to the password setup screen but with a new error when trying to create the password. I decided to stop and try again. The second time I booted up, it showed a blue "MOK management" screen where I entered the key from the first setup. It then started the normal installation process without any issues. This time I followed the same steps except skipped the "Back" button, and everything installed smoothly. I also had to enroll the key again this time. My concern is whether having two keys could cause problems, and if so, can I remove one? Otherwise everything seems fine, even the proprietary drivers.
This situation is somewhat unusual, but not overly serious. It largely depends on your system's configuration. When you power on the computer, press the designated key (usually Del or F10/F2) and then proceed to clear the secure boot password in the BIOS. It seems the Ubuntu installation requires this step for proper functionality.
An alternative method exists if you prefer using a custom key pair instead of the standard tool. Since I manage my own keys and signing certificates, the process remains similar to Ubuntu. You can manually add your certificate to the trusted keys in the BIOS. After that, browse to the USB installation drive for the Secure Boot certificate files. You might also find the ones I provided, and you can check their MD5 values if needed. Once added, everything should function correctly out of the box.
If you still require Secure Boot disabled, it won't affect operation. If you decide to retry using MOK, simply put the system into setup mode—by removing all keys from the DB. This will place the system in setup mode for the next boot, allowing MOK access. You can always restore factory keys to revert everything back to its original state (keys from Microsoft and OEM will be reinstated).
Alternatively, you can keep the current configuration and rely on the default setup.
Hello, your question is clear. The secure boot password is meant for use only once—typically when the MOK manager prompts you to enter it at startup. Ideally, you'd like to remove the first key you created during a failed setup attempt so it won't be needed again. You mentioned using the "mokutils" command, but I'm not sure about the exact steps. Could you provide more details on how to proceed with that tool?
I believe the installer gives a slightly confusing impression. It appears configuring secure boot together with third-party drivers might completely block secure boot. If you’re okay with that, it’s simpler to turn off secure boot in BIOS and reinstall, or set a password—failing to enter it at startup should work. Without the third-party drivers (especially for graphics), x won’t launch. I think the best approach is to disable secure boot in BIOS and start fresh, or add the Ubuntu key (standard ones) back into the BIOS while keeping secure boot enabled. Keep in mind you should initially turn off third-party drivers and install them manually later. It’s been a while since I set up an Ubuntu system—previously I used KDE Neon, experimented with mok, shims, and hashtool—but creating and signing keys was surprisingly straightforward. (You might check the guide here: https://wiki.gentoo.org/wiki/User:Sakaki...ecure_Boot)
I think I resolved the problem using the steps you described. I checked the enrolled keys with "mokutil --list-enrolled" and found three: the Canonical master key, two Ubuntu Decur Boot Module Signature keys, and one from my earlier setup. I deleted the second key by exporting its .der files and deleting it via MOK manager, which required entering a one-time password on the next boot. After that, the key no longer appeared in the list. Running glxgears confirmed the Nvidia driver was still functional. This seems to have fixed the issue.