Omarchy Dual-Boot Secure Boot Setup (Custom Keys Guide)

[borgox]

Omarchy Secure Boot Setup Guide

A comprehensive guide for enabling Secure Boot with custom keys on Omarchy Linux distribution while maintaining dual-boot compatibility with Windows.

Table of Contents

1. Introduction
2. Prerequisites
3. Important Safety Notes
4. Step-by-Step Instructions
5. Verification
6. Troubleshooting
7. Additional Resources

Introduction

Secure Boot is a UEFI firmware security standard that helps protect your system from malicious bootloaders and unauthorized operating system modifications. By default, most systems come with Microsoft's Secure Boot keys, which only allow Windows and certain approved Linux distributions to boot.

This guide will walk you through the process of setting up custom Secure Boot keys for Omarchy, allowing you to maintain system security while running your preferred Linux distribution alongside Windows.

What This Guide Accomplishes

• Creates custom Secure Boot keys specific to your system
• Enables Secure Boot protection for Omarchy
• Maintains Windows boot compatibility
• Provides a secure dual-boot environment

Why Custom Keys?

• Enhanced Security: Your system will only boot signed kernels and bootloaders
• Full Control: You control which operating systems can boot on your hardware
• Dual-Boot Friendly: Maintains compatibility with Windows while securing Linux

Prerequisites

System Requirements

• UEFI-based system with Secure Boot support
• Omarchy Linux (latest version recommended)
• Windows (if dual-booting)
• Administrative access to both operating systems
• Basic familiarity with terminal commands and BIOS/UEFI settings

Required Tools

The following tools will be used and/or installed during the process:

• sbctl - Secure Boot key management utility
• limine - Modern UEFI bootloader (should already be installed with Omarchy)

Hardware Considerations

• Ensure your system supports custom Secure Boot keys (most modern systems do)
• Some OEM systems may have restrictions on custom key enrollment
• Have access to BIOS/UEFI setup (know your setup key, usually F2, F12, or Delete)

Important Safety Notes

⚠️ CRITICAL WARNINGS ⚠️

1. Backup Your Current Configuration: This process will modify your UEFI firmware settings and bootloader configuration
2. Recovery Plan: Ensure you know how to disable Secure Boot in your BIOS if something goes wrong
3. System Access: Have a way to access BIOS settings even if the system won't boot
4. Data Backup: While this process shouldn't affect your data, always maintain current backups
5. Time Allocation: Set aside 15-30 minutes for this process without interruptions

Before You Begin

1. Create a system backup or recovery point
2. Document your current BIOS settings (take photos if needed)
3. Ensure stable power supply
4. Close all unnecessary applications
5. Have this guide accessible from another device or printed copy

Step-by-Step Instructions

Phase 1: Preparation and Initial Setup

Step 1: Disable Secure Boot (Should already be disabled if you have Omarchy installed with Limine - the default bootloader)

1. Reboot your system and enter BIOS/UEFI setup (usually F2, F12, or Delete during startup)
2. Navigate to the Security or Boot section
3. Locate "Secure Boot" settings
4. Disable Secure Boot (if not already disabled)
5. Save settings and exit

Note: The exact menu location varies by manufacturer. Look for "Security," "Boot," or "Advanced" sections. If you installed Omarchy with the default Limine bootloader, Secure Boot should already be disabled.

Framework Laptop Users: On Framework laptops, Secure Boot settings are in a special BIOS section. You must hammer F2 immediately on boot before any boot device activates - you cannot access it from the normal BIOS menu. Enter this special setup before the bootloader starts!

Step 2: Install Omarchy (If not already 😊)

1. Boot from your Omarchy installation media
2. Install Omarchy on a new drive (or partition, but a separate drive is recommended)
3. Complete the installation process normally
4. Do not reboot yet if given the option

Important: Installing on a separate drive reduces the risk of affecting your existing Windows installation.

Step 3: Configure Dual-Boot

1. Boot into your newly installed Omarchy system
2. Open a terminal
3. Add Windows to the Limine bootloader:

   sudo limine-scan

4. Verify that Windows was detected and added to the boot menu

Phase 2: Secure Boot Key Management

Step 4: Prepare UEFI for Custom Keys

1. Reboot into BIOS/UEFI setup
2. Navigate to Secure Boot settings
3. Clear/Remove existing Secure Boot keys
   • Look for options like "Clear Secure Boot Keys," "Delete Keys,", "Reset to Setup Mode" or "Delete all Secure Boot Variables"
   • This puts your system into "Setup Mode"
4. Do not re-enable Secure Boot yet
5. Save and exit, boot back into Omarchy

Critical: Clearing the keys is essential for enrolling custom keys. Your system should now be in "Setup Mode."

Step 5: Install Secure Boot Management Tools

1. In Omarchy, open a terminal
2. Install the required package:

   sudo pacman -S sbctl

3. Wait for installation to complete

Step 6: Verify Setup Mode

1. Check the current Secure Boot status:

   sudo sbctl status

2. Verify the output shows:
   • Secure Boot: Disabled
   • Setup Mode: Enabled

Troubleshooting: If Setup Mode is not enabled, return to BIOS and ensure you properly cleared the Secure Boot keys.
Troubleshooting"":** Don't worry if theres an X on "Setup Mode: Enabled", it's completely normal.

Step 7: Create Custom Keys

1. Generate your custom Secure Boot keys:

   sudo sbctl create-keys

2. This process will create several key files in /usr/share/secureboot/keys/

Expected Output:

Creating secure boot keys...✓
Created Owner UUID: [UUID string]
Creating keys...✓

Step 8: Enroll Keys

1. Enroll your custom keys into the UEFI firmware:

   sudo sbctl enroll-keys -m

   The -m flag enrolls Microsoft keys alongside your custom keys, maintaining Windows compatibility.

2. Expected Output:

   Enrolling keys to EFI variables...✓
   Platform Key enrolled
   Key Exchange Key enrolled
   Signature Database enrolled
   

Step 9: Verify Key Enrollment

1. Check the updated status:

   sudo sbctl status

2. You should now see:
   • Your custom keys listed
   • Platform Key (PK), Key Exchange Key (KEK), and Signature Database (db) entries
   • Setup Mode should now be "Disabled"

Phase 3: Configure System for Secure Boot

Step 10: Update Initial RAM Disk Configuration

1. Edit the mkinitcpio configuration:

   sudo nvim /etc/mkinitcpio.conf

2. Locate the HOOKS line

3. Add "btrfs-overlayfs" to the HOOKS array

   Before:

   HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block filesystems fsck)
   

   After:

   HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block filesystems fsck btrfs-overlayfs)
   

4. Save and exit (ESC, then :wq!)

Note: The btrfs-overlayfs hook is required for proper Secure Boot functionality with Omarchy's file system configuration.

Step 11: Rebuild Boot Configuration

1. Regenerate the initramfs and update Limine configuration:

   sudo limine-mkinitcpio

2. Wait for the process to complete

Expected Output:

==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
Updating Limine configuration...

Phase 4: Final Configuration and Testing

Step 12: Enable Secure Boot

1. Reboot into UEFI firmware setup:

   sudo systemctl reboot --firmware-setup

2. In BIOS/UEFI:
   • Navigate to Secure Boot settings
   • Enable Secure Boot
   • Verify Secure Boot Mode is "Custom"
3. Save settings and exit

Step 13: Test Boot Process

1. Your system should boot normally into the Limine bootloader
2. Test both operating systems:
   • Boot into Omarchy (should work normally)
   • Boot into Windows (should work normally)
3. If either fails to boot, see the Troubleshooting section

Verification

Confirming Secure Boot is Active

Once your system is running, verify Secure Boot is working:

1. In Omarchy:

   sudo sbctl status

   Should show: Secure Boot: Enabled

2. In Windows (if dual-booting):

   • Open System Information (msinfo32)
   • Look for "Secure Boot State: On"

What to Expect

• ✅ System boots normally with Secure Boot enabled
• ✅ Both Omarchy and Windows boot successfully
• ✅ sbctl status shows Secure Boot as enabled
• ✅ Custom keys are enrolled and active

Troubleshooting

Common Issues and Solutions

System Won't Boot After Enabling Secure Boot

Symptoms: Black screen, boot failure, or "Secure Boot Violation" error

Solutions:

1. Immediate fix: Disable Secure Boot in BIOS, boot normally
2. Check key enrollment: Run sudo sbctl status and verify keys are properly enrolled
3. Rebuild configuration: Run sudo limine-mkinitcpio again
4. Re-sign bootloader:

   sudo sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI
   sudo sbctl sign -s /boot/vmlinuz-linux

5. Verify Keys:

   sudo sbctl verify

Windows No Longer Boots

Symptoms: Windows option missing from boot menu or fails to start

Solutions:

1. Re-scan for Windows:

   sudo limine-scan

2. Check Microsoft keys: Ensure you used the -m flag when enrolling keys
3. Manual Windows entry: Add Windows manually to Limine configuration

"Setup Mode: Disabled" But No Custom Keys

Symptoms: sbctl status shows no custom keys but Setup Mode is disabled

Solutions:

1. Clear keys again in BIOS
2. Verify Setup Mode is enabled before creating keys
3. Re-create and enroll keys:

   sudo sbctl create-keys
   sudo sbctl enroll-keys -m

Kernel Update Breaks Boot

Symptoms: System won't boot after kernel updates

Solutions:

1. Automatic signing: Enable automatic kernel signing:

   sudo sbctl sign -s /boot/vmlinuz-linux
   sudo sbctl sign -s /boot/initramfs-linux.img

2. Hook installation: Install pacman hook for automatic signing:

   sudo sbctl install

Error Messages and Their Meanings

Error Message	Meaning	Solution
"Secure Boot Violation"	Bootloader not signed	Re-sign bootloader files
"Setup Mode: Disabled"	Keys enrolled but possibly wrong ones	Clear and re-enroll keys
"No custom keys found"	Key creation failed	Re-run sbctl create-keys
Windows boot failure	Microsoft keys missing	Re-enroll with -m flag

Recovery Procedures

Complete Recovery (If Nothing Works)

1. Boot from An arch live USB
2. Disable Secure Boot in BIOS
3. Chroot into your installation
4. Restore bootloader:

   sudo limine-mkinitcpio

5. Start over from Step 4 of this guide

Partial Recovery (Secure Boot Issues Only)

1. Disable Secure Boot temporarily
2. Boot into Omarchy
3. Clear and recreate keys:

   sudo sbctl clear-keys
   sudo sbctl create-keys
   sudo sbctl enroll-keys -m

4. Re-enable Secure Boot

Additional Resources

Useful Commands Reference

# Check Secure Boot status
sudo sbctl status

# List enrolled keys
sudo sbctl list-keys

# Sign a file for Secure Boot
sudo sbctl sign -s /path/to/file

# Verify file signature
sudo sbctl verify /path/to/file

# Remove signature from file
sudo sbctl remove-file /path/to/file

Related Documentation

• Omarchy Official Documentation
• Arch Linux Secure Boot Wiki
• sbctl GitHub Repository
• UEFI Specification

Community Support

• Omarchy Community Forums: Get help from other Omarchy users
• Discord: Ohmarchy Discord Server

Security Considerations

Why This Approach is Secure

1. Custom Keys: Only you control what can boot on your system
2. Maintained Compatibility: Windows continues to work through Microsoft key enrollment
3. Verified Boot Chain: Every component of the boot process is cryptographically verified
4. Tamper Detection: Unauthorized modifications to the bootloader or kernel will prevent booting

Maintaining Security

1. Regular Updates: Keep Omarchy and sbctl updated
2. Key Management: Safely store backup copies of your custom keys
3. Monitor Boot Process: Be alert to any unexpected boot behavior
4. Periodic Verification: Regularly run sbctl status to ensure everything remains properly configured

Performance Impact

• Boot Time: Minimal impact (typically less than 1 second additional boot time)
• System Performance: No runtime performance impact
• Storage: Negligible additional storage requirements for keys and signatures

---

Conclusion

Congratulations! You now have a fully functional Secure Boot setup with Omarchy that maintains Windows compatibility. Your system is more secure against bootkits and other boot-time malware while preserving the flexibility of a dual-boot configuration.

Remember to:

• Keep your system updated
• Monitor for any boot-related issues after kernel updates
• Maintain backups of your Secure Boot keys
• Share this guide with others who might benefit from enhanced boot security

---

Guide Version: 1.0
Last Updated: October 2025
Author:@borgox

---

This guide is provided as-is for educational and security purposes. Always maintain proper backups and test procedures in a safe environment when possible.

[Danijongo]

This worked smoothly for me, thank you!🎉

• ASUS MOBOs PSA: Step 12.2, Enable secure boot by choosing OS Type = Windows UEFI mode.
  ("Other OS" option would basically be treated = "Disabled")

[pymmog]

Thank you, I thought I did something wrong

[nate-lrt]

having some trouble at step 8. when i enroll the keys, it doesn't show what is expected and instead shows this:

Enrolling Keys to EFI variables...
With vendor keys from microsoft...
Enrolled Keys to the EFI variables!

instead of the platform, database, and exchange keys being enrolled, and when i run sbctl verify, none of the keys are signed. I tried signing them by hand but when i rebooted it gave me the blake2B warning and wouldn't let me get into omarchy. Ive been following the guide exactly until that point. Is this normal? Or am i doing something wrong?

Additionally, when i run status it says that sbctl was installed but it still shows the setup mode as being enabled as well.

I even tried deleting keys from bios and reinstalling omarchy but still getting the same issue. This is on an Asus ProArt x670e motherboard by the way. Thanks in advance!

[nate-lrt]

I also tried the following and still had the same issue:

"Setup Mode: Disabled" But No Custom Keys

Symptoms: sbctl status shows no custom keys but Setup Mode is disabled

Solutions:

Clear keys again in BIOS
Verify Setup Mode is enabled before creating keys
Re-create and enroll keys:

    sudo sbctl create-keys
    sudo sbctl enroll-keys -m

[borgox]

having some trouble at step 8. when i enroll the keys, it doesn't show what is expected and instead shows this:

Enrolling Keys to EFI variables...
With vendor keys from microsoft...
Enrolled Keys to the EFI variables!

instead of the platform, database, and exchange keys being enrolled, and when i run sbctl verify, none of the keys are signed. I tried signing them by hand but when i rebooted it gave me the blake2B warning and wouldn't let me get into omarchy. Ive been following the guide exactly until that point. Is this normal? Or am i doing something wrong?

Additionally, when i run status it says that sbctl was installed but it still shows the setup mode as being enabled as well.

I even tried deleting keys from bios and reinstalling omarchy but still getting the same issue. This is on an Asus ProArt x670e motherboard by the way. Thanks in advance!

Try still proceeding even if it says that

[wanitooo]

having some trouble at step 8. when i enroll the keys, it doesn't show what is expected and instead shows this:

Enrolling Keys to EFI variables...
With vendor keys from microsoft...
Enrolled Keys to the EFI variables!

instead of the platform, database, and exchange keys being enrolled, and when i run sbctl verify, none of the keys are signed. I tried signing them by hand but when i rebooted it gave me the blake2B warning and wouldn't let me get into omarchy. Ive been following the guide exactly until that point. Is this normal? Or am i doing something wrong?
Additionally, when i run status it says that sbctl was installed but it still shows the setup mode as being enabled as well.
I even tried deleting keys from bios and reinstalling omarchy but still getting the same issue. This is on an Asus ProArt x670e motherboard by the way. Thanks in advance!

Try still proceeding even if it says that

Same thing happened to me. Proceeded with the steps as advised with some changes. Just to note down what I did for the others for reference:

NOTE: New to archlinux

After running sudo limine-mkinitcpio. I ran sudo sbctl verify and noticed that most EFIs still weren't signed.

@glauberdmo mentioned below that running sudo limine-mkinitcpio for them wasnt enough so they ran:

sudo sbctl verify | sed -nE 's|^✗ (/.+) is not signed$|sbctl sign -s "\1"|p' | sudo sh

NOTE: Seems like we had the same sbctl version as list-keys also was not available in my commands.

I ran the same command to sign them. Reran sudo limine-mkinitcpio and rebooted to the firmware to enable secure boot.

Was still able to boot to Omarchy normally. Ran sudo sbctl status. Both secure boot was enabled and setup mode disabled as expected.

Was also able to boot into Windows normally.

Other notes:

• On an MSI B650 motherboard
• Dual booting Omarchy and Windows on the same drive

[kurtismiller01]

For frame work systems this post could help https://community.frame.work/t/secureboot-setup-mode/14889

[jacksteussie]

for the automatic signing step in the troubleshooting section where it says

sudo sbctl sign -s /boot/vmlinuz-linux
sudo sbctl sign -s /boot/initramfs-linux.img

vmzlinuz-linux isn’t an option for me for some reason. why is that? also the next step install doesn’t seem to be a valid command for sbctl.

[glauberdmo]

Just to collaborate with troubleshootings:

In my case the keys were created in /var/lib/sbctl/keys
Also the keys is possible to check using sudo sbctl list-enrolled-keys (sbctl list-keys doesn't exist in my sbctl version)
Is expected something like it:

PK:
  Platform Key
KEK:
  Key Exchange Key
  Microsoft Corporation Third Party Marketplace Root
  Microsoft RSA Devices Root CA 2021
DB:
  Database Key
  Microsoft Corporation Third Party Marketplace Root
  Microsoft Root Certificate Authority 2010
  Microsoft RSA Devices Root CA 2021
  Microsoft RSA Devices Root CA 2021
  Microsoft Root Certificate Authority 2010

and to sign each efi the command sudo limine-mkinitcpio was not enough, I did:

sudo sbctl verify | sed -nE 's|^✗ (/.+) is not signed$|sbctl sign -s "\1"|p' | sudo sh

[Alexander-Garcia]

Thank you for that command. I had to run the same

[kaliberr44]

Can this file /etc/mkinitcpio.conf be overridden by Omarchy system update?

[Anodyine]

Thanks for the thorough guide.

I'm a little concerned that this might not provide any substantial protection over having secure boot disabled. My understanding is that even if limine is signed, it will gladly boot whichever kernel it is pointed to without verifying it. I could be wrong, but I think this means that an attacker could still swap the file that limine points to since it isn't verified.

We might need to verify that configuration file too as is described in the tip here:

https://wiki.archlinux.org/title/Limine

and keep our private keys that we use to sign the limine bootloader off disk. that way, an attack can't just resign their own version of the kernel, regenerate the hash, and put it into the config. I guess my point is that just have secure boot on isn't enough since there are multiple steps in the limine boot process.

I would like to be wrong, because I want to use the Omarchy defaults and avoid configuring systemd-boot. Will you confirm or deny my suspicions?

[RileyLunaris]

The guide was well laid out and is easy to follow.

I have a relatively new Omarchy install (2 days)
and I am new to Linux (~3 months) (EndeavourOS i3wm)

My outputs were a little different than this:
after completing and rebooting, it loaded into the Emergency shell.
I don't know the best method to remedy this, however I was able to reboot using the power button and getting back into the bios/boot menu

on the boot menu: it shows 2 of my main drives, 1 listed as Omarchy, the other as limine
When I select the 2nd it boots into an Omarchy boot menu and then loads the OS

New Secure boot is enabled, but I am still figuring out the remedy with the original drive not being bootable.

[RileyLunaris]

[Alexander-Garcia]

If some people are getting the emergency shell - go into your BIOS and make sure Limine is listed first in your boot sequence list. I had omarchy listed first and when switching it to Limine -> windows -> omarchy I no longer had to hit F12 to get into boot menu and manually choose limine. Now we can avoid the emergency shell

[martinmose]

Thanks a lot, for this comment 🙏

[ryanmgray]

if sudo limine-scan command not found, use sudo limine-entry-tool --scan
if sudo limine-mkinitcpio command not found, run yay -S limine-mkinitcpio-hook and then retry sudo limine-mkinitcpio

[MerePebble]

Great guide. Had almost no issues at all. There is just one thing. If you want to delete boot entries from limine. Go to /boot/limine.conf or anywhere else where you store the file and delete manually the boot entries you don't like. They are usually in this format:
//Boot entry
...
...
...

//Another boot entry

Just delete the section you don't want limine to display. I spent like 10 minutes looking this up so I hope I saved you the time.

[mucstermuc]

Thank you! this worked for me.
The only issues I had were with my MSI motherboard where I had to set Secure Boot Mode to "Custom" before I was able to access the Key management menu and Delete all Secure Boot Variables. I also had to disable the "Provision Factory Default keys" setting so ensure the sbctl status showed up as
Secure Boot: Disabled

[obsesivegamer]

Yup I was fumbling around wondering why Setup Mode is disabled after clearing the variables. Thank you sir

[brwaters]

This worked great for me. Using an Asus board so the comments helper with respect to enabling secure boot. It's a combination of two options and whether secure boot is on or not is slightly obfuscated.

Should I enabling automatic signing and hooks from the troubleshooting step, or is that not necessary?

[maurisrx]

Thank you for the great guide! It works with my Lenovo Legion 5 laptop. It works with both secure boot and TPM settings enabled. Some of my windows software requires secure boot and TPM to be enabled so this is a good solution for me to be able to use both Omarchy and Windows 11.

[tombobe1]

I am new to linux and dualbooting. Followed the guide everything works almost perfectly with secure boot enabled but now everytime I boot windows I have to fill in my bitlocker recovery key anyone with an idea to fix that?

[maurisrx]

I am new to linux and dualbooting. Followed the guide everything works almost perfectly with secure boot enabled but now everytime I boot windows I have to fill in my bitlocker recovery key anyone with an idea to fix that?

For me, I don't need Windows encryption so I disabled it to prevent the bitlocker key prompt on each login.

[karandhillon]

@borgox this is a very well written and detailed guide! Had no problems setting this up. Thank you so much for putting in the effort!

[Deterbug]

Hello, i am having this a problem.

~ ❯ sudo limine-mkinitcpio
[sudo] password for yadiel:
install: cannot change permissions of ‘/boot/EFI/Linux’: Read-only file system

[crocswithsocks]

Thanks for the guide, worked perfectly although after step 9 my system still reported Setup Mode: Enabled, but following the rest of the steps continued to work and get secure boot enabled successfully in Windows/Omarchy.

[jamescraig17]

Thanks for the feedback, Will — really glad the guide worked well overall! 😊 The “Setup Mode: Enabled” message you saw after step 9 is actually *expected* in some cases (especially on certain OEM systems or when using custom keys via `mokutil`) — it simply means the MOK (Machine Owner Key) database is still in an insecure state until the key enrollment is finalized *and* the system reboots into a state where the UEFI firmware recognizes the enrolled keys. In many cases (as you observed), the secure boot *does* come up correctly after reboot, even if `mokutil --sb-state` still shows “Setup Mode: Enabled” temporarily. This can happen because: - The system hasn’t yet re-enrolled the keys into the *persistent* UEFI variable storage (e.g., `PK`, `KEK`, `db`) at the firmware level. - Some UEFI implementations report `Setup Mode` as “enabled” until the *next* boot cycle completes after key enrollment. - `mokutil --sb-state` reflects the *kernel’s* view of Secure Boot state, which may lag slightly behind the actual firmware enforcement — especially if keys were enrolled but not yet fully activated. A quick check you can run *after reboot* to confirm: ```bash sudo mokutil --sb-state # or more thorough: sudo efibootmgr -v ``` And to verify signed kernel/loader is in use: ```bash journalctl -b | grep -i "secure" # Look for "SecureBoot enabled" or "shim locked" ``` If everything booted securely (e.g., you see `shim locked` or no "insecure mode" warnings in logs), then you’re good — the Setup Mode warning is mostly cosmetic in this case. Thanks again for trying it out and sharing your experience! If you’d like, feel free to suggest a clarification for the guide (e.g., a note in step 9) to help future users — happy to update the doc. 🙌

[caleb]

The latest upgrade of Omarchy required me to add ENABLE_ENROLL_LIMINE_CONFIG=yes to my /etc/default/limine.conf file and re-enroll my keys. Which means I had to go back into setup mode, encroll the keys, recreate my initramfs image.

I really should learn how all of this works. I only need this stuff because some games on Windows require it, but whenever it breaks I'm scrambling.

It's funny that dual booting was harder in the mid 90s in some ways, then got pretty easy, and with secure boot it seems like there's more hoops :)

[JGJones]

have you done a sbctl verify to check that the boot images are signed? Sign those that aren't. Then run limine-mkinitcpio to rebuild the boot images again and should be good to go. I had the same thing as you. I don't have the ENABLE_ENROLL_LIMINE_CONFIG=yes line in my /etc/default/limine file.

[gunotham]

I had done the signing 2-3 months back, after the latest update this is the error when booting up with secure boot on. I have tried re-signing the images.

[caleb]

@gunotham Yeah, I was getting that panic. It seemed like just adding the enroll line to limine and regenerating initramfs didn't do the trick. I had to enter secure boot setup mode and re-add the keys to the UEFI to get it to work.

[martinmose]

I did the same as @caleb - that's also what worked for me.

[gunotham]

Similarly went into setup mode, and resigned keys. Added ENABLE_ENROLL_LIMINE_CONFIG in the config as well. Now it works without any issues. Thanks @caleb

[RufflesHaveRidge]

New omarchy update broke secure booting for omarchy entirely for me. I would not recommend updating yet. I tried even what caleb suggested. It appears the problem has something to do with limine. Will update if I find a fix.
Edit: I got it to work! I'm not really entirely sure how. I reinstalled limine with limine-install, used sbctl sign-all, did sbctl enroll-keys -m, and used limine-mkinitcpio while in setup mode, booted into bios and enabled secure boot but it still said not active, rebooted and secure boot works now. I believe limine-install is what did the trick.

[martinmose]

I ran into a lot of issues too and even made my Linux install unbootable at one point so I had to fix it from a USB. Don't give up.

Me and AI have put together this guide (also shared on Discord). It's not perfect and might include some leftovers from my earlier attempts but hopefully it helps.

secure-boot-limine.md

[RufflesHaveRidge]

I appreciate it! Thanks for the help. I'll keep trying to fix it.

[acraig78]

This worked on a Corsair AI Workstation 300 with separate Windows and Omarchy SSDs with these extra steps

Phase 2: Step 4 - The BIOS "Reset to Setup Mode" option did not actually delete the PK so the system immediately re-enters User Mode. The only way to get into Setup Mode was to navigate into the Key Management submenu and explicitly delete the PK entry, after which sbctl enroll-keys -m in step 8 would proceed.

Phase 2: Step 8 - The KEK and db variables had immutable flags set, requiring chattr -i before enrollment would complete.

[dkeysil]

Faceit AC gamers just lost access because they banned self signed bootloader

Faceit support message:

Unfortunately as we need to prevent cheats from loading while Secure Boot is enabled, we can no longer allow self-signed bootloaders. The only solution is to use a bootloader signed by a known distribution (e.g. Ubuntu) or to boot directly into Windows with the UEFI boot menu when you want to use the AC.

[caleb]

Time to hook up the old Amiga 2000 again and just use that for gaming.