The Linux Boot Recovery Wiki: Understanding & Fixing Kernel Panics

1. The Anatomy of the Disaster

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

What actually happened?

Your computer's boot process is a relay race. In your case, the baton was dropped between the Kernel and the Hard Drive.

BIOS/UEFI started the computer.

GRUB (the bootloader) successfully loaded the Kernel (vmlinuz).

The Kernel tried to mount your hard drive to start the OS.

The Failure: The Kernel did not have the drivers to read the hard drive format (ext4). Usually, these drivers are inside a helper file called the Initramfs (initrd).

The Crash: Because the initrd file was missing or corrupted (likely due to an interrupted update), the Kernel panicked. It had no hands to grab the hard drive.

2. Core Concepts: The Players on the Field

To fix this, you must understand the four main components of the Linux boot process.

A. GRUB (Grand Unified Bootloader)

What it is: The software that runs before Linux. It is a mini-operating system that lives on a tiny partition of your drive.

Its Job: To find the Kernel and Initramfs, load them into RAM, and tell the Kernel where the rest of the OS is hiding.

The grub> Prompt: This is GRUB's "Manual Mode." You are dropped here if GRUB cannot find its configuration file (grub.cfg).

B. The Kernel (`vmlinuz`)

What it is: The heart of the OS. It speaks to the hardware (CPU, RAM, GPU).

The Name: vmlinuz stands for Virtual Memory Linux Gzip (compressed).

Role: It is the first "real" software to run.

C. The Initramfs (`initrd`)

What it is: The "Initial RAM Filesystem." This is the most critical component in your specific error.

The Problem: The Kernel is tiny. It doesn't include every driver for every hard drive in the world.

The Solution: The initrd is a small, temporary folder loaded into RAM. It contains just enough drivers to mount the real hard drive. Once the real drive is mounted, the initrd deletes itself.

Your Crash: You had the Kernel, but you were missing the initrd. The Kernel was blind.

D. The Root Filesystem (`/`)

What it is: Your actual installation (Ubuntu, your documents, apps).

The Identifier: Linux calls hard drives /dev/sda, /dev/sdb, or /dev/nvme0n1.

- sda1: First drive, first partition.
- sdb2: Second drive, second partition.

3. The "Translation" Problem: GRUB vs. Linux

This is the hardest part of manual booting. GRUB and Linux name hard drives differently.

Hardware	GRUB Name	Linux Name
First Drive	`(hd0)`	`/dev/sda`
Second Drive	`(hd1)`	`/dev/sdb`
NVMe Drive	`(hd0)`	`/dev/nvme0n1`

The Trap: In your recovery, GRUB saw your files on (hd1,gpt2).

GRUB: "I found files on Hard Drive 1."

Linux Translation: "That corresponds to /dev/sdb."

If you tell Linux root=/dev/sda2 but GRUB found the files on (hd1), Linux will look at the wrong drive and crash.

4. The Recovery Procedure (Step-by-Step)

If you are stuck at a black screen with grub>, follow this flowchart.

Phase 1: Exploration

You are blind. You need to find where Ubuntu is installed.

List drives:

```
ls
```
Returns: (hd0) (hd0,gpt1) (hd1) (hd1,gpt2)

Check content:

```
ls (hd0,gpt2)/
```
- If error: unknown filesystem: Wrong drive.
- If efi/: This is the boot partition, not the OS. Keep looking.
- If etc/ home/ boot/: JACKPOT. This is your root drive.

Phase 2: Identification

You need to find a Matched Pair of boot files.

Set the root:

set root=(hd1,gpt2)  <-- Replace with the drive you found in Phase 1

List boot files:

```
ls /boot/
```

The Matching Game:

You must find a version number that exists for BOTH files.
- vmlinuz-6.14.0-37-generic (Exists?) -> YES
- initrd.img-6.14.0-37-generic (Exists?) -> YES
- Result: This is a safe pair.
- vmlinuz-6.17.0-14 (Exists?) -> YES
- initrd.img-6.17.0-14 (Exists?) -> NO (Missing)
- Result: Do NOT use. This will cause a kernel panic.

Phase 3: The Boot Sequence

Type these commands exactly.

1. Load the Kernel

Syntax: linux [path_to_kernel] root=[linux_drive_name] ro

The Logic: You load the file you found, then tell it where the OS lives.

The Command:

linux /boot/vmlinuz-6.14.0-37-generic root=/dev/sdb2 ro

(Note: If (hd1) was your drive, try /dev/sdb2. If (hd0), try /dev/sda2).

2. Load the Ramdisk (Initrd)

Syntax: initrd [path_to_matching_initrd]

The Command:

initrd /boot/initrd.img-6.14.0-37-generic

3. Launch

boot

WARNING: YOU ARE NOT DONE YET
Do not celebrate when the desktop appears. Booting manually is like putting on a spare tire. It gets you home, but the "flat tire" (the broken kernel) is still broken. If you restart your computer now without doing Phase 5, the Kernel Panic will return immediately. You are logging in solely to run the repair tools that couldn't run from the black screen.

5. The Permanent Fix (Once you are logged in)

Goal: Repair the broken "Initrd" file so the computer can boot automatically next time.

Open a terminal (Ctrl+Alt+T) and run these commands in order:

Fix partially installed updates:

```
sudo dpkg --configure -a
```

Generate the missing initrd files (The Magic Fix):

```
sudo update-initramfs -u -k all
```
This looks at every installed kernel and builds the missing initrd file that caused your crash.

Update the GRUB menu:

```
sudo update-grub
```
This scans the folder, sees the new fixed files, and adds them to the boot menu.

CRITICAL SAFETY CHECK: The File Size Test

Before rebooting, verify that the new file is actually complete.
```
ls -lh /boot/initrd.img*
```
COMPARE THE SIZES:
- Working Kernel: e.g., 134MB (Contains OS + Graphics Drivers)
- New Kernel: e.g., 70MB (Contains only OS, missing Drivers)
If the new file is significantly smaller (missing >40MB), DO NOT REBOOT. The fix failed. Go to Section 6.

Reboot:

```
sudo reboot
```

6. Troubleshooting: When the Fix Fails

Scenario: The "DKMS" Error (Amdgpu / Nvidia)

If you see output like this: dkms autoinstall on 6.17.0-14 ... failed for amdgpu(10) make ... bad exit status: 2

What it means: You have a third-party driver that is incompatible with the new kernel. The driver installation crashes, which stops the initrd from being built, or results in a "Half-Baked" kernel (see below).

The Solution:

Remove the bad driver:

```
sudo apt-get remove amdgpu-dkms
```
(Replace amdgpu-dkms with nvidia-dkms-xxx if needed).

Retry the update:

```
sudo dpkg --configure -a
```

Scenario: The "Half-Baked" Kernel

If update-grub sees the new kernel, but the file size is small (e.g. 70MB vs 130MB), the drivers are missing.

The Solution: You must Purge the broken kernel and stick to the older one.

```
sudo apt-get purge linux-image-6.17.0-14-generic linux-headers-6.17.0-14-generic
```
Note: If the prompt asks [Y/n] and aborts anyway, run the command again and press 'y' firmly.

Scenario: "Directory not empty" during purge

If you see: rmdir: failed to remove '/lib/modules/6.17.0-14-generic': Directory not empty

What it means: The package manager tried to delete the kernel folder, but some "junk" files (usually from the failed driver compilation) were left inside. Linux won't delete a folder if it isn't empty.

The Solution: You must manually delete the leftover folder.

```
sudo rm -rf /lib/modules/6.17.0-14-generic
```
(Make sure you type the version number exactly correctly).

Then update grub one last time:
```
sudo update-grub
```

7. Case Study: The "Missing Initrd" Scenario

This section documents the specific incident experienced by the user, serving as a real-world example of the recovery process.

The Symptoms

Initial Error: Kernel Panic ... unable to mount root fs on unknown-block(0,0)

GRUB Situation: The Advanced Options menu was broken or inaccessible, dropping the user into the grub> command line.

The Diagnosis

When the user ran ls /boot/ inside the GRUB shell, the output revealed the root cause immediately:

Kernel 6.17.0-14: Found vmlinuz-6.17.0-14 but NO initrd.img-6.17.0-14.

Conclusion: The default kernel was broken/incomplete.

Kernel 6.14.0-37: Found vmlinuz-6.14.0-37 AND initrd.img-6.14.0-37.

Conclusion: This was the "spare tire." It was a complete, working pair.

The "Curveball": Drive Translation

The user's computer had multiple drives.

GRUB's View: GRUB identified the installation on (hd1,gpt2). In GRUB language, hd1 usually means the second physical disk.

The User's Mistake: The user initially tried root=/dev/sda2. In Linux, sda is usually the first disk.

The Fix: The user changed the command to root=/dev/sdb2 (the Linux name for the second disk), and the system booted successfully.

The Verification (Preventing a Second Crash)

Before the final reboot, the user noticed a size mismatch:

initrd-6.14 (Working): 134MB

initrd-6.17 (Broken): 73MB This indicated the AMD drivers were missing from the new kernel. The user Purged kernel 6.17 entirely to ensure a safe boot.

The Winning Command Sequence

set root=(hd1,gpt2)
linux /boot/vmlinuz-6.14.0-37-generic root=/dev/sdb2 ro
initrd /boot/initrd.img-6.14.0-37-generic
boot