Shadowfetch Linux 2.0.1 «Umbra»
Secure Boot
Shadowfetch Linux will not boot on a machine with Secure Boot enabled. The boot media is not signed by a Microsoft-trusted shim, so you have to turn Secure Boot off in your firmware before you can install it, and it has to stay off afterwards. This page explains what that means, what it costs you, and why there is no date attached to fixing it.
The short version
- Boots with Secure Boot enabled
- No. The installer USB will be refused, or will not appear in the firmware boot menu at all.
- Signed by a Microsoft-trusted shim
- No. There is no signed shim for Shadowfetch Linux.
- What you have to do
- Disable Secure Boot in your UEFI firmware before booting the installer.
- After installation
- It stays off. Re-enabling Secure Boot will stop the installed system from booting.
- Is anything signed
- Yes, but not in a way firmware trusts: the ISO and the APT repository are signed with the project's own OpenPGP key, which is not in any manufacturer's key database.
What Secure Boot is
Secure Boot is a UEFI firmware feature. Before the firmware hands control to an operating system, it checks that the boot program has been signed by a key it holds in its own key database, and refuses to run it if not. The intent is to stop something from quietly replacing your bootloader or kernel underneath you.
The keys shipped in that database are almost always Microsoft's. So a Linux distribution that boots with Secure Boot enabled does it by shipping a small first-stage loader called a shim, which Microsoft has signed through its third-party UEFI signing programme; the shim then verifies the distribution's own key and hands off to GRUB and the kernel. It is the shim signature, not the distribution's own, that the firmware is actually trusting.
Shadowfetch has no signed shim. The ISO and the APT repository are signed - with the project's own OpenPGP key, fingerprint 8F13 CE15 35EE 1F4A 2916 A1F7 3C5C 900B 7BE8 0CA1 - but no firmware on earth has that key in its database, and there is no way to make it trusted short of the signing process described below or enrolling a key by hand on each machine.
What turning it off costs you
Disabling Secure Boot is a real security decision, not a formality, and it is worth knowing what you are giving up before you do it.
You lose a check against tampering before the kernel runs
Secure Boot's job is to refuse a bootloader or kernel that has been replaced. With it off, nothing at the firmware level notices if the boot files are swapped. In practice that matters to an attacker who already has physical access to the machine or root on it - it is not protection against ordinary malware in a browser - but it is a real layer and turning it off removes it.
Windows with BitLocker will demand its recovery key
This is the one that catches people. BitLocker seals its key against firmware measurements that include the Secure Boot state, so changing that state makes Windows ask for the 48-digit recovery key on the next boot. Suspend BitLocker from Windows first, or make certain you have the recovery key saved somewhere other than the machine you are about to change. If you skip this and do not have the key, the Windows install is not recoverable.
Windows 11 may report the machine as unsupported
Microsoft lists Secure Boot among Windows 11's system requirements. An already-installed Windows 11 generally keeps booting with Secure Boot off, but it can start reporting the system as not meeting requirements. If you dual-boot and that matters to you, weigh it before installing.
The kernel is not in lockdown
Secure Boot puts the Linux kernel into lockdown mode, which restricts things like loading unsigned modules and writing to kernel memory. Without it, none of those restrictions apply. That is a genuine reduction in hardening, and it is also the reason the proprietary NVIDIA modules build and load without any signing dance on this system.
Nothing after boot changes
For completeness, because the opposite is often assumed: disabling Secure Boot does not weaken disk encryption, does not disable the TPM, and does not affect package signing. Updates still verify against the Shadowfetch repository key exactly as before.
Turning it off
Firmware menus differ by manufacturer and there is no path that is correct on every machine, so this is the general shape of it. If you dual-boot Windows with BitLocker, suspend BitLocker before you start.
Get into firmware setup
Power on and press the setup key before the operating system starts - most commonly Del or F2, sometimes F1, F10 or Esc. The splash screen usually names it. From an existing Windows install you can also go to Settings, System, Recovery, Advanced startup, Restart now, then Troubleshoot, Advanced options, UEFI Firmware Settings.
Find the Secure Boot setting
It usually sits under a Security, Boot or Authentication tab. The wording varies: Secure Boot, Secure Boot Control, or a Secure Boot Mode set to Standard.
If it is greyed out, set a supervisor password first
Several vendors will not let Secure Boot be changed until an administrator or supervisor password exists in firmware. Set one, then the option becomes editable. Write it down - you will need it to change firmware settings again later.
Set it to Disabled, and leave UEFI mode alone
Disable Secure Boot only. Do not enable CSM, Legacy or Compatibility Support Module as a workaround: Shadowfetch installs in UEFI mode, and booting the USB in legacy mode gives you a different, harder problem than the one you started with.
Save, exit, and pick the USB from the boot menu
Usually F10 to save and exit. Then open the one-time boot menu - often F12, F9 or Esc - and choose the USB device. If the USB was invisible before and appears now, Secure Boot was the reason.
If the USB still will not boot with Secure Boot disabled, the problem is something else - how the stick was written, or the firmware's boot order. The install guide covers writing the media, and known issues lists what is already understood to go wrong. If neither fits, please open an issue with the machine model and firmware version.
Check the image yourself instead
With Secure Boot off, the firmware is no longer checking anything for you, which makes verifying the download before you write it worth more than usual. The release carries the signing key, detached signatures and a SHA256SUMS file; checking the checksum takes one command and checking the signature takes two.
Will this be fixed
A Secure Boot signing path is on the roadmap, in the last stage, with no date against it. That is deliberate and it is not going to be replaced with a quarter.
Getting there means building and maintaining a shim, submitting it to the third-party UEFI signing review, waiting in a queue that has historically run for months and is entirely outside this project's control, then keeping a signed bootloader and signed kernel packages current for every release afterwards, along with the key handling that implies. It is a standing commitment rather than a one-off task, and promising a month for it would be a promise made with someone else's calendar.
Until it lands, this page will keep saying no. If you see a date for Secure Boot support anywhere else, it did not come from here.