When Linux Won't Boot - Kernel Panic and Emergency Mode

When Linux Won't Boot - Kernel Panic and Emergency Mode
Reading time: About 12 min Difficulty: Intermediate

What You'll Learn

  • The meaning and difference between a frozen kernel panic screen, the (initramfs) prompt, and dropping into emergency mode
  • How to triage which stage of boot actually failed
  • The fastest recovery path: booting an older kernel from GRUB, repairing fstab, and running fsck

Conclusion (the triage model)

What to do depends entirely on where boot stopped. Check how far it got, top to bottom.

  1. grub rescue> / grub> → stopped at the bootloader (lost GRUB config or modules)
  2. (initramfs) prompt → the root filesystem could not be mounted (early userspace)
  3. Kernel panic - not syncing: ... → the kernel halted unrecoverably
  4. An emergency / rescue shell → userspace was reached but boot failed partway (usually fstab)

Assumptions (target environment)

  • Distro: Ubuntu / Debian family (systemd and GRUB 2)
  • You can see the screen via a physical console or a cloud serial console / VNC
  • Recovery needs root (the emergency shell runs as root)

Which Stage Did Boot Stop At?

Conclusion: Read the on-screen text to identify the stage. grub means the bootloader, (initramfs) means root mount failed, Kernel panic means the kernel halted, and emergency mode means a failure after userspace started.

Linux boot proceeds roughly in this order. Pinpointing where it stopped is the first step.

Stage On-screen sign Common cause
1. Bootloader grub rescue> / grub> Lost GRUB config or /boot, partition changes
2. Early userspace (initramfs) prompt Root device not found, filesystem corruption
3. Kernel Kernel panic - not syncing: Root cannot mount, missing driver, broken initramfs
4. systemd You are in emergency mode / rescue mode Bad fstab, failed required mount, failed service

Booting an older kernel is worth trying first

If the machine stopped booting right after a kernel update, simply booting the previous kernel from "Advanced options" often fixes it (see below).

What Is a Kernel Panic?

Conclusion: A kernel panic is the kernel halting on purpose after detecting an unrecoverable error. It is most often caused by being unable to mount the root filesystem, or a missing essential driver or broken initramfs.

When the kernel detects a fatal internal inconsistency, it decides that continuing would corrupt data and halts deliberately. That is a kernel panic. Unlike an app crash, the whole system stops.

A typical message:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

This is the sign that the root filesystem could not be mounted. Common causes:

  • A broken or stale initramfs after a kernel update (it lacks the needed storage driver)
  • The kernel's root= parameter points to a changed UUID / device
  • Storage changes (LVM / RAID / disk swap) leave root unfindable

A different variant, Kernel panic - not syncing: Attempted to kill init!, means init (systemd) died right after starting. Suspect a broken initramfs or root filesystem.

The panic screen often scrolls past. The real cause is in the first few lines (the very top). On cloud servers read the serial console log; on physical machines photograph the top of the screen.

How Do I Boot an Older Kernel From GRUB?

Conclusion: Bring up the GRUB menu, open "Advanced options", and pick the previous kernel. If a recent kernel update is the cause, this alone gets you booted.

Right after a kernel update, booting the old kernel is the fastest way to triage.

  1. After power-on, show the GRUB menu (hold Shift, or tap Esc on UEFI, if it doesn't appear)
  2. Choose Advanced options for Ubuntu
  3. Select the previous version of the kernel and boot

Once you're in on the old kernel, rebuild the current kernel's initramfs:

$ sudo update-initramfs -u -k all
$ sudo update-grub

Edit a GRUB boot entry on the fly

With an entry highlighted, press e to edit its boot parameters in place.

  1. Press e on the target entry
  2. Move to the end of the line starting with linux (after ro quiet splash, etc.)
  3. Append the parameter you need (e.g. systemd.unit=rescue.target)
  4. Press Ctrl + X or F10 to boot

This edit is temporary and reverts on reboot. To make it permanent, edit /etc/default/grub and run update-grub.

What If It Stops at the initramfs Prompt?

Conclusion: The (initramfs) prompt means the root filesystem could not be mounted. It is usually filesystem corruption — run fsck, then exit to continue booting.

The BusyBox (initramfs) prompt appears when the kernel started but could not mount root. It is often preceded by a line like:

ALERT!  /dev/sda1 does not exist.  Dropping to a shell!

or a detected filesystem inconsistency. To fix:

# See which block devices are recognized
(initramfs) cat /proc/partitions
(initramfs) ls /dev/sd* /dev/nvme*

# Check and repair the target partition (it must be unmounted)
(initramfs) fsck /dev/sda1

# After repair, continue booting
(initramfs) exit

When fsck asks whether to repair, answer y as a rule. If there are many prompts, use fsck -y /dev/sda1 to accept all. After it finishes, exit returns to the normal boot sequence.

How Do Rescue and Emergency Mode Differ?

Conclusion: rescue.target is single-user-like with local filesystems mounted and basic services, while emergency.target only mounts root read-only with almost nothing running. A bad fstab drops you into emergency automatically.

systemd has two recovery targets. They differ in what you can do.

Target Mounts Services Use
rescue.target Local filesystems Minimal set started Single-user-like. Normal recovery work
emergency.target root only, read-only Almost none Most minimal. Last resort when fstab is broken

Enter rescue / emergency on purpose

In the GRUB editor (e), append to the linux line:

# Rescue mode (recommended; enough for most recovery)
systemd.unit=rescue.target

# Emergency mode (most minimal)
systemd.unit=emergency.target

Shorthands (rescue / emergency / the old single 1) also work, but the systemd.unit= form is reliable. Boot with Ctrl + X and you land in a root shell after entering the password.

Make root writable in emergency mode

In emergency mode root is usually read-only, so you can't edit files. Remount it writable:

$ mount -o remount,rw /

What If a Bad fstab Dropped Me Into Emergency Mode?

Conclusion: A mistake in /etc/fstab or a reference to a missing device stops boot and drops you into emergency mode. Fix the offending line, validate with mount -a, then reboot.

The most common reason for landing in emergency mode is /etc/fstab. A wrong UUID on a new mount, an unplugged device, or a typo leaves systemd waiting on a mount until it gives up.

Recovery:

# 1. Remount root writable
$ mount -o remount,rw /

# 2. Find the failed mount in this boot's log
$ journalctl -xb | grep -i -E 'mount|fstab|dependency'

# 3. Fix fstab (you may temporarily comment out the bad line)
$ nano /etc/fstab

# 4. Reload config and validate every entry
$ systemctl daemon-reload
$ mount -a

If mount -a completes with no errors, fstab is healthy. Any error means that line still has a problem.

An ounce of prevention: add the nofail option to non-essential mounts so a missing device doesn't stop boot. Useful for external disks and network mounts.

UUID=xxxx  /mnt/data  ext4  defaults,nofail  0  2

How Do I Read the Boot Log?

Conclusion: After recovery, read this boot with journalctl -xb and the previous failed boot with journalctl -b -1. Start from the red (failed unit) and Dependency failed lines.

Once you're booted, confirm what happened to prevent a repeat.

# The whole current boot (-x adds explanatory text)
$ journalctl -xb

# The previous (failed) boot
$ journalctl -b -1

# List only the failed units
$ systemctl --failed

Lines like Dependency failed for ... or Failed to mount ... point at the direct cause of the stall. If disk I/O errors are mixed in, suspect hardware failure too.

Reading the previous boot (-b -1) needs a persistent journal. Where /var/log/journal/ is absent, logs vanish on reboot. Make it persistent first: sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald.

What Not to Do

Conclusion: Running fsck on a mounted filesystem, reinstalling before identifying the cause, and missing the top of the panic screen all make things worse. Prioritize the top log lines and identifying the stage.

  • Running fsck on a mounted filesystem → corruption. Always do it read-only / unmounted
  • Judging from the last line of the panic screen → the real cause is at the top; watch for scroll-off
  • Reinstalling the OS without triaging → kills cases fixable by one fstab line or an older kernel
  • Leaving the bad fstab line in place → you drop into emergency on every reboot
  • Rebooting without a persistent journal → the failure log is lost and the cause becomes a mystery

Next Reading