So I rebooted my machine like a normal person and got slapped with a blue GRUB screen:

error: file '/boot/vmlinuz-linux-lts' not found.
you need to load the kernel first

Cool. Very helpful. Load the kernel first. With what, GRUB? My good looks?

I dived deep into the issue just to find this was a pretty common issue caused due to some update cancellations in between update sessions breaking the packages(most probably a patience issue) as well as spent almost an extra of about half an hour session with my claude for more specific information on the issue or rather solution.

If you're reading this because you got the same message, good news: your system is almost certainly fine and you do not need to reinstall anything. I went through the full panic arc so you don't have to, and here's roughly how it went.

First, the dumb mistake everyone makes

I knew the rough shape of the fix from somewhere in the back of my brain: boot a live USB, chroot in, fix it. So naturally, sitting at the grub> prompt, I confidently typed:

grub> mount /dev/sdXn /mnt
error: can't find command `mount'.
grub> arch-chroot /mnt
error: can't find command `arch-chroot'.

GRUB just stared at me. Turns out the GRUB shell is not Linux. It has its own tiny set of commands, and mount and arch-chroot are not among them. Those are things you run later, from an actual live environment. Lesson one: the blue prompt is not a terminal, stop treating it like one.

What the error actually means

GRUB's whole job is to grab a kernel and its initramfs, load them into memory, and hand off. The error shows up when GRUB has a menu entry pointing at a kernel file, in my case /boot/vmlinuz-linux-lts, but that file simply isn't there. Nothing to load means nothing to boot. Hence the passive-aggressive "you need to load the kernel first."

So the real mystery is: where did my kernel go?

Poking around from the GRUB shell

Before doing anything drastic you can actually snoop on your disks from grub>. List partitions with:

ls

I got back something like (hd0,gpt5) (hd0,gpt4) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1). Then you just go fishing through them:

ls (hd0,gpt5)/

The one that spits out boot/ etc/ home/ usr/ var/ ... is your Linux root. Mine was gpt5. Then the moment of truth:

ls (hd0,gpt5)/boot/

And /boot contained... amd-ucode.img and grub/. That's it. No vmlinuz-linux. No initramfs-linux.img. My kernel had ghosted me. (Also, if you see an empty boot/efi folder here, relax, that's just an unmounted mountpoint, not the problem.)

At this point I genuinely considered just wiping the whole thing and starting fresh with some calmer distro. Do not do this. I'll get to why.

Making the rescue USB without a second computer

I only have the one laptop, which felt like a dealbreaker until I remembered it dual-boots Windows, and the Windows install was sitting there completely untouched on its own partition. So I booted into Windows straight from the BIOS boot menu (mash F12 / F2 / Esc at power-on depending on your machine), downloaded the EndeavourOS ISO, and flashed it to a USB stick with Rufus.

If you run EndeavourOS, grab the EndeavourOS ISO. Vanilla Arch, grab the Arch ISO. Matching your actual distro saves you keyring headaches later.

The live USB also tried to ruin my day

Booted the USB, picked the friendly default entry ("open source drivers, all GPUs"), and watched the screen blink at me forever. Black, blink, black, blink, nothing. This is apparently a beloved tradition on laptops with NVIDIA graphics: the normal graphical boot just refuses to come up.

The fix is the entry nobody reads: fallback / nomodeset. Reboot the USB, pick that, and it boots ugly but functional. That got me to a desktop. If you're stuck blinking, that's your move.

Finally, the actual repair

Opened a terminal and ran the one command that changes nothing and tells you everything:

lsblk -f

This shows your partitions and their filesystems. I was looking for two things: my root partition (ext4, helpfully labeled endeavouros) and my EFI partition (small, FAT32). Mine were nvme0n1p5 and nvme0n1p1. Yours might be sda5 / sda1 on an older SATA drive. Use your real names, not mine.

Then mount everything and jump in:

sudo mount /dev/nvme0n1p5 /mnt
sudo mkdir -p /mnt/boot/efi
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
sudo arch-chroot /mnt

When the prompt flips to something like [root@EndeavourOS /]#, you're now living inside your installed system instead of the USB. This is where the real commands work.

The plot twist

I figured I'd just reinstall the kernel and go to bed. But first I checked what was actually installed:

pacman -Q linux linux-lts mkinitcpio

And got this beautiful nonsense:

linux 7.0.12.arch1-1
linux-lts 6.18.36-1
error: package 'mkinitcpio' was not found

There it was. According to pacman, both kernels were perfectly installed. But mkinitcpio was gone. And mkinitcpio is the thing that actually builds your initramfs and gets the kernel images written into /boot during install. No mkinitcpio means the kernel package "installs" but never produces the files GRUB needs. The database lies to your face while /boot sits there empty.

How does mkinitcpio go missing? Usually an upgrade that got interrupted, a /boot that filled up mid-write, or a cleanup / package removal that took more than you meant it to. I genuinely don't remember which crime I committed, but the result was the same.

The fix that finally worked

Install the missing piece, then reinstall the kernels so the hooks actually fire this time:

pacman -S mkinitcpio
pacman -S linux linux-lts amd-ucode

Say yes to the reinstall. (I'm on AMD, hence amd-ucode. Intel folks want intel-ucode. Don't want the LTS kernel? Drop linux-lts and the dead menu entry disappears on its own.)

If pacman starts whining about keyrings or signatures, refresh them first with pacman -Sy archlinux-keyring (add endeavouros-keyring on EndeavourOS) and try again.

Then check that the files actually showed up this time:

ls /boot

And finally, the good stuff:

vmlinuz-linux                     vmlinuz-linux-lts
initramfs-linux.img               initramfs-linux-lts.img
initramfs-linux-fallback.img      initramfs-linux-lts-fallback.img
amd-ucode.img                     grub/

A populated /boot. Chef's kiss. The kernels exist again.

Wrapping it up

Tell GRUB about its newly recovered kernels, then get out:

grub-mkconfig -o /boot/grub/grub.cfg
exit
sudo umount -R /mnt
reboot

Pull the USB on the way down. It booted straight into my normal GRUB menu and into a working desktop like nothing had happened.

While you're in there, two quick checks

Run df -h /boot and make sure it isn't basically full, because a stuffed /boot is a great way to cause this exact mess again. And if you're paranoid, mkinitcpio -P rebuilds every initramfs by hand, though the kernel reinstall already does it for you.

Stuff I'd tell past me

• The grub> prompt is not bash. Stop typing Linux commands into it.
• Don't yank the power during a pacman -Syu. Let kernel upgrades finish, especially on a laptop.
• Keep an eye on /boot free space.
• Read what pacman is about to remove before hitting yes. If it wants to take linux or mkinitcpio with it, that's your sign to stop.
• Keep a flashed live USB in a drawer. It turns "my laptop is bricked" into "ugh, fifteen minutes."

And please don't just reinstall

I almost did. It feels clean when you're frustrated. But reinstalling throws away all your config, takes way longer than the repair, and worst of all, fiddling with partitions next to a Windows install is a fantastic way to accidentally delete Windows too. The repair touches exactly two things: the kernel files and the GRUB config. The reinstall touches your entire disk. You need the same USB stick either way, so just try the repair first.

My system, my dotfiles, my Windows install, all completely fine the whole time. I was just missing a couple of files and one very important package. That's it.