Omarchy Secure Boot + Windows Dual Boot Setup guide

[ykzird]

Omarchy Secure Boot + Dual Boot — Definitive Community Guide

This guide was written after a full hands-on troubleshooting session getting Secure Boot working on Omarchy with Limine 11.2.0. It supersedes Discussion #2296 and incorporates all hard-won lessons. If something in an older guide contradicts this one, trust this one. But as always, your mileage may vary. I honestly do NOT recommend this, as it's not worth the headache; even if you automate the maintenance part of this, it would still be better to have two separate systems for both Linux and Omarchy. Sadly that's not always possible, so I decided to use #2296 as a reference and spin up Claude to see if I could get it working and document as much as I can. Hopefully this will help those wanting to run this!

---

What This Guide Achieves

• Secure Boot enabled with custom keys
• Dual boot with Windows fully preserved
• Limine 11.2.0 config checksum enforcement satisfied
• Plymouth splash workaround documented

---

Critical Things to Understand Before You Start

These are the lessons that took hours to learn; read them first:

1. Only sign the Limine EFI binary. Do NOT sign kernels, initramfs, or any other EFI files. Limine verifies those via its own BLAKE2B hash mechanism embedded in limine.conf. Signing them externally corrupts that verification and causes silent blank screen boot failures.

2. Do NOT run the signing one-liner from Discussion Omarchy Dual-Boot Secure Boot Setup (Custom Keys Guide) #2296. The command sudo sbctl verify | sed -nE 's|^✗ (/.+) is not signed$|sbctl sign -s "\1"|p' | sudo sh will sign files Limine needs to verify itself. This breaks booting.

3. The config checksum must be enrolled BEFORE signing. Running limine enroll-config modifies the binary; any signature applied before this step becomes invalid.

4. /boot/EFI/BOOT/BOOTX64.EFI is the fallback loader, not Limine. The actual Limine binary is at /boot/EFI/limine/limine_x64.efi.

5. sbctl remove-file does not strip the physical signature from the binary. It only removes it from sbctl's database. Use bsdtar to extract a clean binary from the package cache instead.

6. Limine 11.2.0 enforces config checksum strictly. If the checksum is not enrolled, Limine panics with SECURE BOOT IS ACTIVE BUT NO CONFIG CHECKSUM IS ENROLLED regardless of whether your EFI files are signed correctly.

7. hash_mismatch_panic: no hides errors. Set it to yes during troubleshooting so you get visible panic messages instead of silent blank screens.

8. Plymouth (splash) breaks booting with Secure Boot enabled. Remove splash from your kernel cmdline before enabling Secure Boot.

---

Additional notes:

• I used Limine version 11.2.0. If you have a different version, I suggest you upgrade.
• Tested on Omarchy v3.5.0
• I personally tested this on my ASRock X870 motherboard. The other discussion mentions that the previous method has worked on Asus and MSI: Omarchy Dual-Boot Secure Boot Setup (Custom Keys Guide) #2296 (comment) and Omarchy Dual-Boot Secure Boot Setup (Custom Keys Guide) #2296 (reply in thread)

Prerequisites

• Omarchy installed and booting normally with Limine
• Windows installed (if dual booting)
• Secure Boot currently disabled in BIOS
• ~30–45 minutes

Required tools (will be installed during setup)

• sbctl — Secure Boot key management
• pesign — PE signature inspection
• bsdtar — package extraction (usually pre-installed)

---

Phase 1 — Preparation

Step 1: Disable Secure Boot in BIOS

Boot into BIOS (usually F2, F12, or Delete on startup). Disable Secure Boot if not already disabled. Save and exit.

Step 2: Install required tools

sudo pacman -S sbctl pesign

Step 3: Configure dual-boot (if not already done)

sudo limine-scan

If limine-scan is not found: sudo limine-entry-tool --scan

Step 4: Remove splash from kernel cmdline

This is essential. Plymouth's graphical splash screen fails silently under Secure Boot, causing a blank screen.

Edit the Limine config:

sudo nvim /etc/default/limine

Find the line:

KERNEL_CMDLINE[default]+=" quiet splash"

Change it to:

KERNEL_CMDLINE[default]+=" quiet"

Save and rebuild the UKI:

sudo limine-mkinitcpio

Note: This generates a new omarchy_linux.efi with the updated cmdline. The hash in limine.conf will need to be updated after this (covered in Phase 4).

Step 5: Comment out the EFI fallback entry in limine.conf

Chainloading an unsigned EFI binary will cause a panic with Secure Boot active.

sudo nvim /boot/limine.conf

Find the section at the bottom and comment it out:

#/EFI fallback
#comment: Default EFI loader
#comment: order-priority=10
#protocol: efi
#path: boot():/EFI/BOOT/BOOTX64.EFI

Step 6: Enable hash mismatch panics for troubleshooting

In /boot/limine.conf, ensure this is set:

hash_mismatch_panic: yes

This gives you visible error messages instead of silent blank screens if anything goes wrong.

---

Phase 2 — Secure Boot Key Management

Step 7: Clear existing Secure Boot keys in BIOS

Reboot into BIOS and navigate to Secure Boot settings. Clear all existing keys. Look for "Delete all Secure Boot Variables", "Reset to Setup Mode", or similar. Set Secure Boot Mode to Custom. Do not re-enable Secure Boot yet. Save and exit, boot back into Omarchy.

ASRock users: Navigate to Security → Secure Boot. Set Secure Boot Mode to Custom first; this unlocks the key management menu.

MSI users: Also set to Custom mode first, and disable "Provision Factory Default Keys" to ensure Setup Mode activates correctly.

ASUS users: When re-enabling Secure Boot later, set OS Type to "Windows UEFI mode". The "Other OS" option is effectively treated as disabled.

Step 8: Verify Setup Mode

sudo sbctl status

Should show:

Secure Boot: Disabled
Setup Mode:  Enabled

An ✗ next to Setup Mode is normal; don't worry about it.

If Setup Mode is not enabled, return to BIOS and ensure you properly cleared all keys (see MSI note above).

Step 9: Create custom keys

sudo sbctl create-keys

Step 10: Enroll keys

sudo sbctl enroll-keys -m

The -m flag includes Microsoft's keys, which is essential for Windows to keep booting. Either of these output formats is fine; proceed regardless:

# Format A
Enrolling keys to EFI variables...✓
Platform Key enrolled / Key Exchange Key enrolled / Signature Database enrolled

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

Step 11: Verify key enrollment

sudo sbctl list-enrolled-keys

Note: sbctl list-keys does not exist in all versions; use list-enrolled-keys instead.

If Setup Mode still shows Enabled after this step, don't panic; several users reported this and still ended up with working Secure Boot after completing all steps.

---

Phase 3 — Update Kernel Hash in limine.conf

Since you rebuilt the UKI in Step 4, the hash in limine.conf is now stale and must be updated.

Step 12: Generate new kernel EFI hash

b2sum /boot/EFI/Linux/omarchy_linux.efi

Copy only the hash string; not the filename that b2sum appends.

Step 13: Update limine.conf

sudo nvim /boot/limine.conf

Find the main Linux entry path line. It will look like:

path: boot():/EFI/Linux/omarchy_linux.efi#<old-hash>

Replace the hash after # with the new one from Step 12. Leave everything else untouched.

Snapshot entries: If you have snapshot entries in your config, their hashes point to their own separate EFI files and do not need updating unless those files changed.

---

Phase 4 — Enroll Config Checksum and Sign Limine

This is the most critical phase. The order of operations is strict; do not deviate.

Step 14: Extract a clean Limine binary from package cache

This ensures no stale signatures interfere with the process.

sudo bsdtar -xOf /var/cache/pacman/pkg/limine-*.pkg.tar.zst usr/share/limine/BOOTX64.EFI | sudo tee /boot/EFI/limine/limine_x64.efi > /dev/null

Verify it is clean (should return nothing):

pesign -S -i /boot/EFI/limine/limine_x64.efi

If pesign -S shows a certificate, the binary is not clean. Do not proceed; see Troubleshooting below.

Step 15: Generate config checksum

b2sum /boot/limine.conf

Copy only the hash string; not the filename.

Step 16: Enroll checksum into the Limine binary

sudo limine enroll-config /boot/EFI/limine/limine_x64.efi <hash-only>

This embeds the checksum into the binary. The binary is now modified.

Step 17: Sign the Limine binary

sudo sbctl sign -s /boot/EFI/limine/limine_x64.efi

The -s flag saves it to sbctl's database for tracking.

Step 18: Verify

pesign -S -i /boot/EFI/limine/limine_x64.efi
sudo sbctl verify

pesign -S should show "Database Key" (your custom key). sbctl verify should show ✓ for limine_x64.efi. All other files showing ✗ is expected and correct; do not sign them.

---

Phase 5 — Enable Secure Boot

Step 19: Reboot into BIOS

sudo systemctl reboot --firmware-setup

In BIOS:

• Enable Secure Boot
• Verify Secure Boot Mode is set to Custom
• ASUS boards: Set OS Type to "Windows UEFI mode"
• Save and exit

Step 20: Fix boot order if needed

If you land in an emergency shell, go back into BIOS and set the boot order to:

1. Limine
2. Windows Boot Manager
3. (anything else)

Step 21: Verify Secure Boot is active

sudo sbctl status

Expected output:

Installed:    ✓ sbctl is installed
Setup Mode:   ✓ Disabled
Secure Boot:  ✓ Enabled
Vendor Keys:  microsoft

In Windows: Start → msinfo32 → confirm Secure Boot State: On.

---

Ongoing Maintenance

After any change to limine.conf or kernel updates

The config checksum and Limine signature must be refreshed every time limine.conf changes (including after kernel updates which update the kernel hash in the config automatically).

Full re-sign sequence:

# 1. Extract fresh binary from package cache
sudo bsdtar -xOf /var/cache/pacman/pkg/limine-*.pkg.tar.zst usr/share/limine/BOOTX64.EFI | sudo tee /boot/EFI/limine/limine_x64.efi > /dev/null

# 2. Remove from sbctl database
sudo sbctl remove-file /boot/EFI/limine/limine_x64.efi

# 3. Enroll new config checksum
b2sum /boot/limine.conf
sudo limine enroll-config /boot/EFI/limine/limine_x64.efi <hash-only>

# 4. Sign fresh
sudo sbctl sign -s /boot/EFI/limine/limine_x64.efi

# 5. Verify
pesign -S -i /boot/EFI/limine/limine_x64.efi
sudo sbctl verify

Editing Limine boot entries

Edit /boot/limine.conf directly. Each entry is a self-contained block; delete the block to remove an entry. Remember to run the full re-sign sequence above after any edit.

BitLocker

If Windows prompts for a BitLocker recovery key after enabling Secure Boot, this is normal; the TPM PCR values shifted when you enrolled custom keys. Enter the recovery key once and it will re-seal to the new state. Subsequent boots will not prompt again.

---

Troubleshooting

"SECURE BOOT IS ACTIVE BUT NO CONFIG CHECKSUM IS ENROLLED"

The config checksum was not enrolled into the Limine binary, or was enrolled into the wrong binary. Ensure you are targeting /boot/EFI/limine/limine_x64.efi and not /boot/EFI/BOOT/BOOTX64.EFI (that is the fallback loader, not Limine).

Blank screen after selecting Linux in Limine

Two possible causes:

1. Hash mismatch: set hash_mismatch_panic: yes in limine.conf to get a visible error, then re-enroll the config and re-sign.
2. Plymouth splash failing: remove splash from KERNEL_CMDLINE in /etc/default/limine and rebuild with sudo limine-mkinitcpio.

"incorrect digest" error when signing

The binary has a stale physical signature embedded. Extract a clean binary from the package cache:

sudo bsdtar -xOf /var/cache/pacman/pkg/limine-*.pkg.tar.zst usr/share/limine/BOOTX64.EFI | sudo tee /boot/EFI/limine/limine_x64.efi > /dev/null
pesign -S -i /boot/EFI/limine/limine_x64.efi  # should return nothing

Then proceed with enroll-config and sign.

pesign shows certificate after extracting from package cache

The binary is not clean. Try removing any embedded PE signature:

sudo objcopy --remove-section=.vendor_cert /boot/EFI/limine/limine_x64.efi /tmp/limine_clean.efi
pesign -S -i /tmp/limine_clean.efi
sudo cp /tmp/limine_clean.efi /boot/EFI/limine/limine_x64.efi

"File doesn't exist in database" from sbctl remove-file

The file was never tracked by sbctl. Skip remove-file and proceed directly to limine enroll-config and sbctl sign -s.

Windows no longer boots

Ensure you used the -m flag when enrolling keys (sbctl enroll-keys -m). Without it, Microsoft's keys are not included and Windows Boot Manager will be rejected by the firmware.

BitLocker recovery key prompt on every Windows boot

Disable BitLocker on the Windows partition, or enter the recovery key once; it should re-seal after that and not prompt again.

Emergency shell on boot

Check your BIOS boot order. Limine must be first. Go to BIOS and set:

1. Limine
2. Windows Boot Manager

Setup Mode still shows Enabled after key enrollment

This is cosmetic on some firmware implementations. Continue with the guide; Secure Boot will still work correctly after reboot.

"Corrupted file detected" for snapshot kernel EFIs

Limine's BLAKE2B hash for a snapshot kernel EFI no longer matches. Regenerate the hash for that specific file and update its path entry in limine.conf:

b2sum /boot/<path-to-snapshot-kernel>.efi

Then update the hash after # in the corresponding limine.conf path entry, and run the full re-sign sequence.

MSI Specific (as per #5306 (comment))

When you reset to setup mode, the keys get reset, but, if you do not disable the setting "Factory Key Provisioni" beforehand, it will automatically add the factory keys (i.e. Microsoft, ...) back on reboot (which disables setup mode again before you are booted into Linux, yes :))

---

Reference: Correct Signing Order

Always follow this exact order. Deviating causes "incorrect digest" errors:

1. Extract clean binary from package cache (bsdtar)
2. sbctl remove-file (if previously tracked)
3. limine enroll-config (embeds checksum — modifies binary)
4. sbctl sign -s (signs the modified binary)
5. pesign -S + sbctl verify (confirm success)

---

Useful Commands

# Check Secure Boot status
sudo sbctl status

# List enrolled UEFI keys
sudo sbctl list-enrolled-keys

# Verify signed files
sudo sbctl verify

# Check if a binary has a signature
pesign -S -i /path/to/file.efi

# Generate BLAKE2B hash
b2sum /path/to/file

# Extract clean Limine binary from package cache
sudo bsdtar -xOf /var/cache/pacman/pkg/limine-*.pkg.tar.zst usr/share/limine/BOOTX64.EFI | sudo tee /boot/EFI/limine/limine_x64.efi > /dev/null

---

Wishlist:

• Fix Plymouth splash screen to preserve the beautiful password prompt
• Add a post update hook in Pacman to run a script that automates this entire process

---

Guide version: 1.1 — April 2026
Tested on: Omarchy with Limine 11.2.0, ASRock X870 PRO RS
Based on: Discussion #2296 + extensive hands-on troubleshooting
Author: @ykzird

[ykzird]

For those interested, I've automated the (re)signing process: https://github.com/ykzird/ykzird-secure-boot

[TheCrether]

I found this at an insanely good time, thank you very much, I can confirm it works with the following setup (including the automation):
Tested on: Omarchy with Limine 11.3.1, MSI B850M MORTAR WIFI (MS-7E61), BIOS Version: E7E61AMSI.1A44*

Since MSI in general has an apparently very interesting implementation for Secure Boot, I also had to do the following (from another Linux install I had before this one, but it still applies):

• When you reset to setup mode, the keys get reset, but, if you do not disable the setting "Factory Key Provisioni" beforehand, it will automatically add the factory keys (i.e. Microsoft, ...) back on reboot (which disables setup mode again before you are booted into Linux, yes :))

[ykzird]

I'm glad to hear this has worked for you! And thank you for the additional info, I've added it to the troubleshooting section.

[eduardoborges]

Thank you for the complete manual!

I did it step by step and at the end when enabling the secure boot when I select omarchy in the limine... the computer restarts.

[ghost]

I'm not sure how it works for others, but is there also a Linux entry that sits under the Omarchy label? That's how it is for me atleast.

[sobiloff]

I couldn't get it to successfully boot from a USB4 external SSD attached to a Gen12 Lenovo Carbon X1. Figured it out with the help of Claude and had it write a summary, but it's pretty long and I didn't want to dump it in here without asking if this is OK? In brief, the fix is a small custom mkinitcpio hook (thunderbolt-auth) that actively polls /sys/bus/thunderbolt/devices/*/authorized, writes 1 to anything unauthorized, and waits for the tunnel and NVMe probe to complete, inserted immediately before block in the HOOKS array, since appending it runs it after the hooks that needed the disk have already given up.