After updating my CachyOS installation (linux-cachyos 7.1.3-2), the system suddenly became unbootable through the normal Limine boot entry.
Selecting CachyOS from the UEFI boot menu immediately rebooted the machine with no kernel panic or error messages. Interestingly, the EFI Fallback option continued to boot the system successfully.
This article documents the complete investigation, including the commands used, the reasoning behind each step, and the final solution.
Symptoms
Immediately after updating the system:
sudo pacman -Syu
I observed the following:
- Windows Boot Manager continued to boot normally.
- Selecting Limine immediately rebooted the system.
- No kernel panic appeared.
- No emergency shell appeared.
- EFI Fallback (BOOTX64.EFI) booted CachyOS successfully.
At first glance it looked like a broken kernel update, but the investigation revealed otherwise.
Boot into a Live USB
Boot a CachyOS live environment.
Identify the Linux partitions:
lsblk -f
Example:
| Partition | Filesystem | Purpose |
|---|---|---|
/dev/nvme1n1p5 |
FAT32 | EFI System Partition |
/dev/nvme1n1p6 |
Btrfs | Root Filesystem |
Mount the installation:
sudo mount -o subvol=@ /dev/nvme1n1p6 /mnt
sudo mount /dev/nvme1n1p5 /mnt/boot
sudo arch-chroot /mnt
Verify Kernel Installation
First verify that the kernel packages are still installed.
pacman -Q linux-cachyos linux-cachyos-headers
Output:
linux-cachyos 7.1.3-2
linux-cachyos-headers 7.1.3-2
The kernel package itself was not missing.
Verify the Bootloader
bootctl status
Output:
Systemd-boot not installed.
This is expected because CachyOS uses Limine.
Inspect /boot
Initially:
ls -lh /boot
returned only:
EFI/
loader/
limine.conf
amd-ucode.img
This initially suggested that the kernel might be missing.
Rebuild the Initramfs
mkinitcpio -P
Output:
Initramfs stored in
/boot/<machine-id>/linux-cachyos/
This confirmed CachyOS is using Unified Kernel Images (UKIs) rather than storing kernels directly inside /boot.
Verify the Generated UKIs
find /boot -type f
Relevant files:
linux-cachyos/vmlinuz-linux-cachyos
linux-cachyos/initramfs-linux-cachyos
linux-cachyos-lts/vmlinuz-linux-cachyos-lts
linux-cachyos-lts/initramfs-linux-cachyos-lts
Everything required to boot Linux was present.
This ruled out:
- Missing kernel
- Missing initramfs
- Broken UKI generation
Test Every Boot Option
Testing each firmware boot option produced:
| Boot Entry | Result |
|---|---|
| Limine | ❌ Immediate reboot |
| Windows Boot Manager | ✅ Boots |
| EFI Fallback | ✅ Boots CachyOS |
At this point the Linux installation itself was proven healthy.
The problem had to exist before the kernel even started executing.
Inspect EFI Boot Entries
sudo efibootmgr -v
Relevant entries:
Boot000B
\EFI\LIMINE\LIMINE_X64.EFI
Boot000C
\EFI\BOOT\BOOTX64.EFI
The firmware contained two different Limine entry points.
Inspect EFI Files
find /boot/EFI -maxdepth 2 -type f
Output:
/boot/EFI/limine/limine_x64.efi
/boot/EFI/limine/limine_x64.bak
/boot/EFI/BOOT/BOOTX64.EFI
Compare the EFI Binaries
sha256sum /boot/EFI/BOOT/BOOTX64.EFI
sha256sum /boot/EFI/limine/limine_x64.efi
Output:
BOOTX64.EFI
0e4fee4c294d4e82eb01db531974691e8b4a0e9c89f0d7dc107af519575b3d62
limine_x64.efi
37aca59412c36333f775091c3398d49eb0c4b536690fe63e6338321405cf7a71
The hashes were completely different.
Even the file sizes differed.
| File | Size |
|---|---|
| BOOTX64.EFI | 366,648 B |
| limine_x64.efi | 374,840 B |
This strongly suggested that the primary Limine executable had changed during the update.
The Fix
Since the fallback loader booted perfectly, replace the primary Limine executable with the working fallback copy.
sudo cp -f /boot/EFI/BOOT/BOOTX64.EFI \
/boot/EFI/limine/limine_x64.efi
sync
Reboot the system.
The normal Limine boot entry now boots successfully.
Root Cause
The issue was not caused by:
- Btrfs corruption
- Missing kernel
- Missing initramfs
- Broken UKIs
- Broken
limine.conf - Incorrect EFI boot entry
Instead, the problem was isolated to the EFI executable:
EFI/limine/limine_x64.efi
The updated binary caused an immediate reboot on my ASUS firmware.
The older fallback executable:
EFI/BOOT/BOOTX64.EFI
continued to boot correctly.
Replacing the primary executable with the working fallback binary immediately resolved the issue.
Verify the Installed Limine Version
pacman -Q limine
Output:
limine 12.5.0-1
Recommended Follow-up
Keep a backup of the known-working EFI executable:
sudo cp /boot/EFI/limine/limine_x64.efi \
/boot/EFI/limine/limine_x64-working.efi
If a future Limine update introduces the same problem, recovery is as simple as restoring the working binary.
Useful Commands
lsblk -f
find /boot -type f
efibootmgr -v
pacman -Q limine
mkinitcpio -P
sha256sum /boot/EFI/BOOT/BOOTX64.EFI
sha256sum /boot/EFI/limine/limine_x64.efi
cp /boot/EFI/BOOT/BOOTX64.EFI \
/boot/EFI/limine/limine_x64.efi
Final Thoughts
Although the symptoms initially suggested a broken kernel update, the Linux installation itself remained completely functional.
The investigation showed that the failure occurred before the kernel was ever executed. By comparing the EFI executables and observing that only the fallback loader worked, the issue was narrowed down to the primary Limine EFI binary.
Replacing the faulty executable with the working fallback copy restored normal boot functionality without reinstalling the operating system or downgrading the kernel.