Locked out of my own encrypted Arch laptop after a motherboard repair

My laptop is a Dell running Arch Linux — LUKS encryption on top of LVM, booted by systemd-boot. A power fault kept it down for 12 hours. It went in for a motherboard repair, and the repair shop only replaced the power IC; nothing else was reset or changed. It came back unable to boot, and getting it to boot took another 3 hours.

What broke

First the firmware reported "No bootable device found". Then systemd-boot itself failed:

Error loading EFI binary …\6.17.3-arch2-1\linux Not Found

What I tried

My first move was to delete the firmware boot entries. That left NVRAM with nothing to boot at all.

Then I re-ran the bootloader install from a chroot. That chroot didn't have efivars bind-mounted, so the install could never write a boot entry to NVRAM.

What worked

I re-entered the chroot with efivars properly bind-mounted. The check is one command, and from inside the chroot it must list entries:

ls /sys/firmware/efi/efivars/

With efivars in place, bootctl install wrote a fresh NVRAM entry, and "No bootable device" was gone.

bootctl install

That left the second error. In the loader entries I found two that conflicted:

• a stale UKI-style entry pointing at a directory that didn't exist on the EFI partition
• arch.conf, pointing at /EFI/Linux/ — where the kernel wasn't

I deleted the stale entry:

rm /boot/efi/loader/entries/<stale-uki-entry>.conf

Then I pointed arch.conf at the kernel files actually on the ESP and added the intel-ucode initrd:

# /boot/efi/loader/entries/arch.conf
title   Arch Linux
linux   /vmlinuz-linux
initrd  /intel-ucode.img
initrd  /initramfs-linux.img
options cryptdevice=UUID=<luks-uuid>:cryptroot root=/dev/mapper/volgroup0-root rw

Worth knowing

• A repair that only touches the power IC can still leave you with a laptop that won't boot. Budget time for the boot chain, not only the hardware.
• Deleting the firmware boot entries is not a reset. It leaves NVRAM with nothing to boot.
• Before running bootctl install from a chroot, check that /sys/firmware/efi/efivars/ lists entries from inside it. Without efivars, the install can't write a boot entry to NVRAM.
• "No bootable device" and the missing kernel were two separate faults: bootctl install cleared the first by writing an NVRAM entry; the second was in the loader entries on the ESP.