Bazzite will soon be switching to the fsync kernel, and bringing all of the changes we’ve been making in :testing to :latest. Thanks to work by EyeCantCU, we’re now able to sign custom kernels with the same key we sign akmods with – this means for users running with Secure Boot you will need to enroll our akmod key.
Most of you should have this already, but out of an abundance of caution we will be taking a week to update our documentation and allow anyone who hasn’t entered this key to do so prior to pushing the update.
If you are using secure boot and have not enrolled this key, the next update of Bazzite will fail to boot while secure boot is enabled in your BIOS. The good news is you can boot into the previous image from GRUB to work around this, and then enroll the key from there.
To enroll the secure boot key, please run ujust enroll-secure-boot-key and enter the password ublue-os if prompted.
This update will make it possible for us to support a wider array of hardware (Ally, Legion, and Steam Deck OLED), and give us HDR support in gamemode and in the next release of KDE.
How will this affect new installs of bazzite, especially concerning having to go into the BIOS and turn secure boot off for a time? Will turning secure boot off for new installs of bazzite be necessary to boot?
New installs will add this key during the ISO install. For rebasing from a Fedora OSTree distro, you’ll want to enroll the key prior to running the rpm-ostree rebase command (If secure boot is enabled). Documentation for how to do that will be in the README.
This is the same key that we used previously for kmods, so if you have secure boot and made use of any of our kernel modules or the Nvidia drivers you’re already ready to go.
I saw the notification in my terminal, so I tried running the command:
ujust enroll-secure-boot-key
Thish had this output:
echo 'Enter password "ublue-os" if prompted after your user password.'
Enter password "ublue-os" if prompted after your user password.
sudo mokutil --import /etc/pki/akmods/certs/akmods-ublue.der --timeout -1
Usage:
mokutil OPTIONS [ARGS...]
Options:
--help Show help
--list-enrolled List the enrolled keys
--list-new List the keys to be enrolled
--list-delete List the keys to be deleted
--import <der file...> Import keys
--delete <der file...> Delete specific keys
--revoke-import Revoke the import request
--revoke-delete Revoke the delete request
--export Export keys to files
--password Set MOK password
--clear-password Clear MOK password
--disable-validation Disable signature validation
--enable-validation Enable signature validation
--sb-state Show SecureBoot State
--test-key <der file> Test if the key is enrolled or not
--reset Reset MOK list
--generate-hash[=password] Generate the password hash
--ignore-db Ignore DB for validation
--use-db Use DB for validation
--import-hash <hash> Import a hash into MOK or MOKX
--delete-hash <hash> Delete a hash in MOK or MOKX
--set-verbosity <true/false> Set the verbosity bit for shim
--set-fallback-verbosity <true/false> Set the verbosity bit for fallback
--set-fallback-noreboot <true/false> Prevent fallback from automatically rebooting
--trust-mok Trust MOK keys within the kernel keyring
--untrust-mok Do not trust MOK keys
--set-sbat-policy <latest/previous/delete> Apply Latest, Previous, or Blank SBAT revocations
--pk List the keys in PK
--kek List the keys in KEK
--db List the keys in db
--dbx List the keys in dbx
--timeout <-1,0..0x7fff> Set the timeout for MOK prompt
--list-sbat-revocations List the entries in SBAT
Supplimentary Options:
--hash-file <hash file> Use the specific password hash
--root-pw Use the root password
--mokx Manipulate the MOK blacklist
--ca-check Check if CA of the key is enrolled/blocked
--ignore-keyring Don't check if the key is the kernel keyring
error: Recipe `enroll-secure-boot-key` failed on line 41 with exit code 255
It looks like it failed when trying to use mokutil.
The issue you’re experiencing is likely due to Secure Boot being disabled.
To check the status of Secure Boot, run the following command:
$ mokutil --sb-state
If the output indicates “SecureBoot disabled”, you’ll need to look up instructions on how to enable Secure Boot for your specific motherboard model.
After enabling Secure Boot and restarting your computer, you may encounter an error when loading some drivers, especially if you have an NVIDIA image. However, you should still reach the login screen. At that point, press CTRL+ALT+F4 to switch to a terminal interface without the GUI. At the terminal prompt, log in with your username and password. Once logged in, enter following command:
ujust enroll-secure-boot-key
Be sure to follow any subsequent instructions that appear.
Hi, just some feedback from me.
(Fresh user on here AND Fedora)
After a lot of strugling with the “Universal Blue” network installer in SecureBoot via Ventoy, which needed the TPM to be disabled:
Completely unable to start the installer via.Ventoy, I had to write the uBlue iso to an USB stick and boot off of that.
I choose the Kionite with latest nVidia drivers, which at last installed. (You guys really need a progress bar that shows progress while downloading )
I completed the install with the reboots for the MOK enrolment successfully.
And now comes the BUG…
The nVidia drivers were REJECTED due to missing keys in the MOK…
I checked the enrolled keys and noticed 2 new keys, BOTH of these keys were added as a single MOK enrollment:
The key for akmods.
Some key with just numbers as CN.
So with some knowledge from my past reading on the subject, i thought Hell why not check the key on the running system:
Which revealed that it was NOT enrolled, so it must be a different one as the one enrolled by the installer.
So out of curiosity i enrolled the above key using:
And what ya guess, after a reboot to complete the enrollment, the nVidia driver was accepted…
Although I see the below errors, a few times, in dmesg output:
[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to apply atomic modeset. Error code: -22
[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 0
These get repeated when the screensaver kicks in and the user returns to the display…
@kylegospo: Thanks! I upgraded, rebooted, and then re-ran the command:
$ ujust enroll-secure-boot-key
echo 'Enter password "ublue-os" if prompted after your user password.'
Enter password "ublue-os" if prompted after your user password.
sudo mokutil --timeout -1
[sudo] password for garrett:
sudo mokutil --import /etc/pki/akmods/certs/akmods-ublue.der
SKIP: /etc/pki/akmods/certs/akmods-ublue.der is already enrolled
echo 'When you reboot your computer, follow the instructions to start MOK util'
When you reboot your computer, follow the instructions to start MOK util
echo 'by pressing a key, then enroll the secure boot key and enter "ublue-os" as the password'
by pressing a key, then enroll the secure boot key and enter "ublue-os" as the password
I didn’t notice anything at all after running that command and rebooting. Is this expected?
Edit: Ah, I was on unverified again, as I did switch back to stock Fedora meanwhile, then switched back. I’ll switch to signed once more and reboot.
Edit 2: Back on signed. I’m not sure if the key was added and if things work. I guess so? I didn’t see any error. But I also didn’t see anything else. (I had previously added a key a while back.)
I currently have a problem with my SteamDeck bazzite image: I enrolled the key, entered the password in MOK after a reboot and the message still persists. The BIOS says that SecureBoot is enabled. Is this intentional or did I something wrong?
I may have misunderstood you, are you running the deck image, or running ON a steam deck?
If you’re running the deck image on another device that normally supports secure boot, the previous warning does not disappear under any circumstance, so as long as you’re enrolled the key you can update.
Just a FYI at all:
With the current ISO image of bazzite, you need to turn secure boot OFF, you can enable it again after you have finished installing and updating.
The MOK key that is getting installed by the initial setup is a wrong one, which.you can even skip/deny, the new one after update is the correct one which you need to enroll…’
Has anyone else had the SBAT error when trying to boot a ublue system?
I recently reinstalled Windows 11, left some free space to install Aurora again, updated Windows and did a BIOS update. I had Aurora installed before and had the ublue and Vebtoy MOKs installed.
After using Windows a couple days, I went to install Aurora using Ventoy and was greeted with the SBAT error message. I disabled Secure Boot, booted Ventoy and Aurora installer and finally partitioned the free space with an additional EFI, Boot and LUKS partition for Aurora.
I have not been able to successfully have Secure Boot enabled and boot GRUB. As a test, I factory set SecureBoot to back to just the PK and enabled, no problems booting Windows there. I then tried to put SecureBoot into setup mode, which disables SecureBoot and even though I then select Enable again for SB, it stays Disabled.
I re-ran the MOK enrollment and it is pending, but I am also unable to get SecureBoot to enable and bring up the blue enrollment screen again.
I should also state that GRUB and Aurora boot without issues with SecureBoot disabled.
When I first installed Aurora to dual boot, it didn’t add an EFI entry. I used efibootmgr to add an entry for aurora and pointed it to \EFI\fedora\grubx64.efi and it should have been \EFI\fedora\shimx64.efi.
I was able to also re-add Ventoy’s MOK as well.
I really don’t know why aurora couldn’t add the EFI entry on install. This is my partition setup.
)
