Repository navigation
Enabling Direct Boot causes hard brick (No POST / Black Screen) on older Dell laptops #12222
Description
System details
Omarchy Quattro
What's wrong?
Description
Enabling the "Direct Boot" feature in Omarchy results in a complete hardware brick on specific older Dell laptop models. After enabling the feature and rebooting, the machines fail to POST, resulting in a black screen, brief fan spin, and an automatic shutdown. The BIOS becomes entirely inaccessible and software-based BIOS recovery fails, requiring physical SPI hardware flashing to revive the motherboards.
Hardware / Environment
- Machine 1: DELL XPS 15 9550
- Machine 2: DELL Precision 5510
- OS: Omarchy Linux
Steps to Reproduce
- Install and run Omarchy normally (works fine with Limine).
- Enable "Direct Boot" in the OS.
- Reboot or shut down the machine.
- Attempt to power on the machine.
Symptoms & Behavior
- Pressing the power button lights up the LED, the screen remains entirely black (no Dell logo, no backlight), fans spin up for a few seconds, and the machine shuts down.
- Diagnostic LED Code: If the NVMe SSD is removed, the Dell diagnostic LED flashes
3,3(3 amber, 3 white), which translates to "BIOS recovery image not found". - If the SSD is inserted, the machine simply crashes and shuts down before any LED code is displayed.
Troubleshooting Attempted (Failed)
Extensive troubleshooting was performed to rule out standard hardware failures:
- Removed CMOS battery to reset volatile NVRAM.
- Tested bare-metal boot (1 RAM stick, no SSD, battery disconnected).
- Attempted Dell's built-in BIOS Recovery (
CTRL + ESCon AC power connection) using a 2GB FAT32/MBR formatted USB drive with correctly named recovery files (BIOS_IMG.rcv/ extracted.hdr). - Result of Recovery: The machine detects the USB (the
3,3error code disappears), but the BIOS parser hangs indefinitely on a black screen. The CPU heats up, indicating it is stuck in an infinite POST-loop attempting to parse the recovery file but failing.
Technical Hypothesis
The issue does not seem to be a standard OS crash, but a severe incompatibility between Omarchy's Direct Boot implementation and Dell's notoriously fragile UEFI firmware from this era.
When Direct Boot writes a custom EFI boot entry pointing directly to the Omarchy UKI via /sys/firmware/efi/efivars/, it writes a variable that the Dell firmware parser cannot handle.
Upon the next boot, during the very early POST phase (before display initialization), the Dell firmware attempts to read this corrupted/unsupported NVRAM variable. The parser hits a fatal exception and crashes the system. Because this specific EFI variable is stored persistently on the flash chip (and survives a standard CMOS battery removal), the motherboard is permanently stuck in a pre-POST crash loop. The parser is too corrupted to even execute the built-in USB BIOS recovery tool.
Suggested Action
Given the severity (hard brick requiring an EEPROM programmer / CH341A to fix), I recommend adding a strict warning in the documentation or implementing a hardware blacklist preventing Direct Boot from being enabled on Dell XPS/Precision models from the 9550/9560/5510 generations.
Activity
omarchybot commentedon Oct 12, 2026
Thanks for the detailed write-up, and sorry it cost you two boards.
What I checked, reading
quattroat 9480d1b: Direct Boot is the whole ofbin/omarchy-setup-direct-boot, and the only thing it writes to firmware is one ordinary load option,efibootmgr --create --disk <disk> --part <n> --label Omarchy --loader \EFI\Linux\<the Omarchy UKI>(line 63), which efibootmgr encodes as a standard hard-drive/file device path and puts first inBootOrder. It sets noBootNext, passes no optional data, and touches nothing but that variable andBootOrder. On an NVMe layout the disk and partition are derived correctly (/dev/nvme0n1p1→/dev/nvme0n1,1). So nothing in Omarchy's code produces a malformed or non-standard variable; the most the source supports is that a standard EFI variable write coincided with, and may have triggered, a defect in this generation's Dell firmware. That is an explanation of where it happened, not a reproduction: it needs this hardware, which no worker has, so it was not attempted.The guard that exists for this kind of firmware would not have stopped it: the script refuses only when
bios_vendorcontains "American Megatrends" or "Apple" (lines 24–35), and Dell machines of this generation reportDell Inc.there. #12733 adds a Surface refusal to the same check, so a Dell one would sit beside it.Whether to refuse Direct Boot on these Dell models, or only warn about them in the manual, is a decision for the maintainer, so nothing has been filed. If either machine boots again, the output of
cat /sys/class/dmi/id/{bios_vendor,bios_version,product_name}would let any refusal match exactly the affected models and BIOS versions rather than a guessed range.Diagnosed by Claude Opus 5.5; Codex at medium effort reviewed the same code independently and reached the same conclusion: no mechanism in Omarchy's source, and a deny-list being a maintainer decision. Its independence from my reading is not guaranteed.