Secure Boot Notice

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.

5 Likes

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.

1 Like

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.

I hope this helps resolve your issue.

Sorry for the inconvenience! Try updating with rpm-ostree update, then run it again. Think I found and fixed what you ran into.

Alternatively you can copy & paste the command without the --timeout -1 part.

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:

  1. Completely unable to start the installer via.Ventoy, I had to write the uBlue iso to an USB stick and boot off of that.
  2. I choose the Kionite with latest nVidia drivers, which at last installed.
    (You guys really need a progress bar that shows progress while downloading :wink:)
  3. I completed the install with the reboots for the MOK enrolment successfully.
  4. 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:

  1. The key for akmods.
  2. 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:

sudo mokutil --test-key /etc/pki/akmods/certs/akmods-ublue.der

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:

sudo mokutil --import /etc/pki/akmods/certs/akmods-ublue.der

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…

Q Related to the above:
Which of those enrolled keys are save to be removed from the MOK :thinking:

@alissonoliveira: I did have Secure Boot enabled.

From GNOME’s privacy page in Settings:

image

@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.)

1 Like

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?

Steam Deck does not use secure boot out the box. The new update is out so you can simply update to remove the message.

I recommend disabling secure boot as well.

I can disable secure boot from the BIOS and then just run the update command. Is that right!

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.

Deck Image on a Deck

Then yes you’re correct, disable secure boot and then 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…’

Hope this helps others…