Dropped to the initramfs prompt: how to fix it

What the initramfs prompt means

Ubuntu boots to the (initramfs) prompt when the early boot stage cannot check or mount your root filesystem. There are three usual causes: a filesystem that needs a manual fsck, a root UUID that no longer exists, and an LVM volume that was never activated. Each one has a different fix. Read the messages above the prompt first, because they name the cause.

The initramfs is a small filesystem that the kernel loads before your real disk. Its scripts find the root device, check it, mount it and hand over to systemd. If one of those steps fails, the panic function in Ubuntu's initramfs-tools starts an interactive shell with the prompt (initramfs) . Many people call it the BusyBox prompt. Here that is only a name. The commands the shell has depend on the image, so run help to see its built-in list, and try each command below before you rely on it.

The script behaviour in this guide comes from the initramfs-tools source that Ubuntu 26.04 ships (version 0.151ubuntu1, uploaded 2 April 2026). Older releases such as 24.04 use an older version, so some details there may differ.

You type every command below yourself, at the prompt, in your provider's web console. SSH is not running yet, because the system never got far enough to start services. The examples use /dev/vda1 as the root partition. Yours may be /dev/sda1, /dev/nvme0n1p1 or a /dev/mapper/ path. Always use the name your own server shows.

Tell the three causes apart at the prompt

Scroll up in the console if it lets you, and look for one of the messages below. Then print the kernel command line. It holds the root= setting that the initramfs tried to use:

cat /proc/cmdline

The initramfs-tools manual recommends the form root=UUID=xxx. On most servers this line names a UUID, not a device path.

The filesystem needs a manual fsck

Look for a line of this shape from the initramfs script:

The root filesystem on /dev/vda1 requires a manual fsck

On ext2, ext3 and ext4 you may also see this message from e2fsck, the ext filesystem checker, just above it:

/dev/vda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
	(i.e., without -a or -p options)

This happens because the initramfs runs fsck in automatic repair mode by default. In the source, the repair flag is -a unless a boot parameter changes it. For e2fsck, -a does the same thing as -p, the "preen" mode that only fixes problems it can fix safely without asking. When e2fsck finds damage that needs a human decision, it stops, prints the message above and exits with "errors left uncorrected". The initramfs then refuses to go on and gives you the shell. XFS and other filesystems print different text, so for those look for the "requires a manual fsck" line.

The root device does not exist

Look for a line of this shape. The device part is whatever your root= setting names:

ALERT!  UUID=0f3c...e21a does not exist.  Dropping to a shell!

It means the initramfs waited for the device and never found it. When root= names a UUID, the usual story is a disk change. A restored image or a replaced disk can carry a filesystem with a different UUID than the one the boot configuration still asks for.

The LVM volume was not activated

The message is the same ALERT! line, but the device it names is a logical volume path such as /dev/mapper/ubuntu--vg-ubuntu--lv or /dev/ubuntu-vg/ubuntu-lv. LVM (logical volume manager) creates these paths only when the logical volume is active. Check what exists:

ls /dev/mapper

The volume you expected may be missing while blkid (next section) still shows the partition that holds it. In that case the volume group was simply not activated.

Identify the root device with blkid

blkid lists the partitions the kernel knows about, with tokens such as UUID and TYPE. Its manual page notes that non-root users get cached, unverified data. At the (initramfs) prompt you are already root, so it reads the devices directly.

blkid

Find the line whose UUID matches the one in /proc/cmdline. If one matches, the disk is there, and its TYPE tells you which checker applies (ext4 means e2fsck). If none matches, you are in the missing-device case.

Your initramfs image may not include blkid. These two commands give less detail, but they still show what the kernel sees:

cat /proc/partitions
ls -l /dev/disk/by-uuid

Run fsck on the root filesystem, only while it is unmounted

The e2fsck manual is clear about mounted filesystems. It says that running it on one is in general not safe. It also says that if e2fsck asks whether to check a mounted filesystem, "the only correct answer is no". In the fsck case the initramfs stops before it mounts root, so the disk should be unmounted. Confirm that before you repair anything:

cat /proc/mounts

Your root partition must not appear in that list. If it does, stop, and use recovery mode or the rescue system instead.

Then work in three steps. First, ask the fsck front end what it would run, without running it:

fsck -N /dev/vda1

Second, take a read-only look. For e2fsck, -n opens the filesystem read-only and answers "no" to every question, so nothing changes:

fsck -n /dev/vda1

Third, repair. -y answers "yes" to every question, which means e2fsck makes every change it proposes without asking you. That is what you want when the other choice is a server that never boots. It still carries risk, so take a snapshot of the broken disk first if your provider allows it. Add -f to force a full check even if the filesystem says it is clean.

fsck -f -y /dev/vda1
echo $?

The fsck front end does not document -y or -n as its own options. It passes them on to the checker for the filesystem type, which here is e2fsck.

The exit code is a sum of conditions. 0 means no errors. 1 means errors were corrected. 2 means errors were corrected and the system should be rebooted. 4 means errors were left uncorrected, so run the repair again and read what it reports. 8 is an operational error, which often means a wrong device name. When the code is 0 or 1, type exit to let the boot continue. When it is 2, type reboot.

Fix a root UUID that no longer exists

blkid may show your root filesystem under a different UUID than the one in /proc/cmdline. In that case the data is fine. Only the pointer to it is wrong. You can get one boot by correcting the pointer in GRUB:

1. Reboot and open the GRUB menu. The recovery mode section below lists the keys.
2. Highlight the Ubuntu entry and press e to edit it.
3. On the line that starts with linux, change the value after root=UUID= to the UUID that blkid showed.
4. Press Ctrl-x to boot the edited entry. Esc throws your edits away and returns to the menu.

Treat this as a one-time way in. Once the server is up, the cause is still in its configuration. Compare the UUIDs in /etc/fstab with the blkid output, and fix the setting that produced the old root= value before you trust the next reboot.

If blkid shows no filesystem that could be root, the disk is not attached or the kernel cannot see it. Nothing at the prompt can fix that. Check the disk in your provider's panel. If you suspect the partition table itself, read how GPT and MBR partition tables differ.

Activate an LVM volume that was not activated

vgchange -a y activates all logical volumes in all volume groups on all devices it can see. Run it if the command exists at your prompt:

vgchange -a y
ls /dev/mapper

If the volume now appears, type exit and the boot continues. If the shell reports that vgchange is not found, your initramfs image does not have the LVM tools. The prompt cannot add them, so move on to recovery mode or the rescue system.

Why exit sometimes returns you to the same prompt

The shell is not the end of the script. It is a pause inside a loop. In the missing-device case, the script waits for the device, calls panic if it is still missing, and checks again when you leave the shell. In the fsck case, checkfs runs the check, calls panic if it fails, and runs the check again after you leave. So exit gives you the same prompt for as long as the cause is still there. Once you have fixed the cause, for example by activating the volume or repairing the filesystem, the next pass succeeds and the boot goes on.

reboot is the right choice when the fix lives outside this boot. A corrected GRUB setting or a repaired /etc/fstab only takes effect on a fresh start, and exit cannot give you that. It is also the right choice after an fsck that returned exit code 2.

One related case: your server may reboot by itself instead of showing the prompt. If so, look for panic= on the kernel command line. With panic=<seconds> set, the script reboots after that delay instead of starting a shell. The initramfs-tools manual describes this as a security feature that disables the debug shell. Remove it in the GRUB editor for one boot to get the prompt back.

Boot recovery mode from Advanced options for Ubuntu

Recovery mode is a GRUB entry that boots to a menu of repair options instead of the normal system. The Ubuntu wiki gives these steps:

1. On a UEFI machine, press Esc while the system starts, perhaps several times, to get the GRUB menu. On a BIOS machine, hold Shift instead.
2. Select the line that starts with "Advanced options".
3. Select the line that ends with "(recovery mode)" and press Return.
4. In the recovery menu, choose the option to drop to a root shell prompt.

On a web console the timing of that key press is hard to hit, so expect to try more than once. The wiki also says that the root partition is mounted read-only in this mode. Remount it before you edit anything:

mount -o remount,rw /

The same wiki page reports that the "Enable networking" option has caused systems to hang. Leave it alone unless you need it.

If GRUB shows no menu at all, its configuration may hide it. With GRUB_TIMEOUT_STYLE set to countdown or hidden, GRUB waits silently first. Pressing Esc or F4, or holding Shift, during that wait shows the menu. If the menu appears but has no recovery entries, the image may set GRUB_DISABLE_RECOVERY=true, which stops GRUB from generating them.

Recovery mode still has to find and mount the root filesystem. If every entry for the newest kernel stops at the same ALERT!, an older kernel in the same "Advanced options" submenu may still work. That route has its own guide. What to do when a VPS will not boot after a kernel update covers picking the older entry, and choosing which kernel boots by default covers keeping it there while you fix the new one.

Use the provider's rescue system when no kernel boots

When every GRUB entry fails, boot your server into the rescue system your provider offers. Providers name and start it in different ways, so follow your provider's panel or documentation for that step. A rescue system boots a separate operating system and attaches your server's disk as a plain disk that is not mounted. You get the same tools as above, without the limits of the initramfs image.

blkid
fsck -f -y /dev/vda1
mount /dev/vda1 /mnt
grep -v '^#' /mnt/etc/fstab

Run blkid first, because the disk can have a different name inside the rescue system. Run fsck before you mount, never after. Once the disk is mounted, compare each UUID in /mnt/etc/fstab with the blkid output. A UUID in fstab that blkid does not list is a mount that will fail on the next boot. Run umount /mnt before you reboot into the normal system.

The prompt may have first appeared in the middle of a release upgrade. Then the broken boot is a symptom, and the half-finished upgrade is the cause. Once the server boots again, work through recovering an Ubuntu upgrade that failed halfway.

Take a snapshot before the next upgrade

Most of the cases above are quicker to undo than to repair. A snapshot taken minutes before a kernel update or a release upgrade turns a dead boot into a rollback. A snapshot taken before fsck -y lets you try again if the repair goes badly. A snapshot usually lives with your provider, next to the disk it copies, so it does not replace a backup. Read the difference between VPS snapshots and backups and keep both: a snapshot for the upgrade, and a backup somewhere else for the day the snapshot is gone too.

FAQ

Why does my Ubuntu server boot to the (initramfs) prompt?

The early boot stage could not check or mount the root filesystem, so the initramfs script called its panic function and started a shell. The message above the prompt tells you which step failed. "requires a manual fsck" or "UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY" means the filesystem needs a repair. "ALERT! ... does not exist" means the root device named in root= was not found. That is often a changed UUID or an LVM volume that was not activated.

Is it safe to run fsck -y at the initramfs prompt?

Only on a root filesystem that is not mounted. Check cat /proc/mounts first. In the fsck case the initramfs stops before it mounts root, so the disk is usually unmounted. -y makes e2fsck accept every fix it proposes without asking. Take a snapshot of the disk first if your provider allows it, and run fsck -n before the repair to see what it plans to change.

Why does typing exit bring back the same initramfs prompt?

The shell runs inside a loop. When you leave it, the script checks for the device again, or runs fsck again. If the problem is still there, it starts a new shell. exit only continues the boot after you have fixed the cause at the prompt.

What if no kernel in the GRUB menu boots?

Use your provider's rescue system. It boots a separate system and attaches your disk without mounting it. From there you can run blkid and fsck on the root partition. Then mount it and compare the UUIDs in /etc/fstab with what blkid reports. How you start the rescue system depends on your provider, so check their panel or documentation.