Fix initramfs load failure: exit shell at boot

Quick answer

At the initramfs prompt, run blkid to find your root partition's UUID. Then edit the GRUB entry at boot: press e, find the linux line, change root=UUID=... to root=/dev/sda2 (or whatever blkid showed), press Ctrl+x or F10 to boot. It'll likely work immediately.

Context – why this happens

What's actually happening here is the kernel loaded the initramfs, but initramfs couldn't mount your real root filesystem. The reason is almost always one of two things:

The root= parameter in GRUB points to a UUID that doesn't match any partition anymore.
The root filesystem driver is missing from initramfs (rare on stock kernels, common with custom kernels or LVM on encrypted drives).

This happens most often after you cloned a disk or restored a backup that changed partition UUIDs. Or when you moved the root filesystem to a different drive (like SSD to NVMe) without updating /etc/fstab and GRUB. I've seen it a lot on Debian 12 after a failed update-grub.

The initramfs shell you're in is basically a minimal Linux with busybox. It has blkid, ls, mount, cat. You can't run systemctl or journalctl because the real system hasn't started.

Step-by-step fix

List block devices
Run blkid. Look for a line with TYPE="ext4" or TYPE="xfs" or whatever your root filesystem is. Note the UUID and the device name (like /dev/sda2 or /dev/nvme0n1p2).

Test mounting manually
Run mount /dev/sda2 /mnt (use the device from step 1). If it says mount: can't find /dev/sda2, your device name is wrong – maybe it's /dev/nvme0n1p2. But if it mounts without errors, the hardware path is fine, and it's a UUID problem.

Reboot and edit GRUB
Press Ctrl+Alt+Del to reboot. As soon as the boot menu appears, press e on your kernel entry. Find the line starting with linux or linuxefi.

Change root parameter
On that line, look for root=UUID=.... Replace the entire UUID with the device name from step 1, like root=/dev/sda2. Or you can use the correct UUID from blkid if you wrote it down.

Boot
Press Ctrl+x (or F10 on some BIOS). The system should boot normally. If it does, you've confirmed the cause.

Make it permanent
Once booted, run sudo update-grub. This regenerates the GRUB config with the current UUIDs from your partitions. If that doesn't fix it (rare), edit /etc/default/grub and set GRUB_CMDLINE_LINUX="root=UUID=..." with the correct UUID, then run sudo update-grub again.

Alternative fixes

If step 1 shows no partitions at all – blkid returns nothing. Your disk controller driver is missing from initramfs. Rebuild initramfs with the right drivers:

# from the initramfs shell, if you have internet
curl -O http://your-server/vmlinuz-...
# but honestly, this is easier:
# boot from a live USB, chroot into your system, then run:
dkms autoinstall
update-initramfs -u -k all

If the root partition is encrypted (LUKS) – initramfs can't unlock it. You'll see cryptsetup errors. Boot from a live USB, unlock the drive manually: cryptsetup luksOpen /dev/sda2 cryptroot, then mount /dev/mapper/cryptroot, chroot, and update /etc/crypttab. Then run update-initramfs -u.

If you're using Btrfs with subvolumes – the root= parameter might need rootflags=subvol=@ appended. Add it after root=/dev/sda2 like: root=/dev/sda2 rootflags=subvol=@.

Prevention tip

Before cloning a disk or reinstalling a bootloader, always run sudo update-grub and sudo update-initramfs -u after the copy but before rebooting. If you can't boot the new disk, attach it as secondary, chroot, and run those commands. The reason step 3 works is that GRUB stores the root UUID in its config, and initramfs also has a copy of the UUID – both must match reality.

Real-world scenario: I cloned a Debian 12 system from a 256GB SSD to a 1TB NVMe. The clone tool (dd) copied everything, but the NVMe's partition UUIDs were different because the partition table got rewritten during the resize. Boot failed at initramfs. Fixed it by editing GRUB to use root=/dev/nvme0n1p2, booted, ran update-grub, never saw it again.