Justinaquino: Imported from gi7b wiki

2026-03-06T10:07:42Z

Imported from gi7b wiki

New page

= The Linux Boot Recovery Wiki: Understanding & Fixing Kernel Panics =

== 1. The Anatomy of the Disaster ==

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

=== 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''' (<code>vmlinuz</code>).

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''' (<code>initrd</code>).

'''The Crash:''' Because the <code>initrd</code> 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 <code>grub></code> Prompt:''' This is GRUB's "Manual Mode." You are dropped here if GRUB cannot find its configuration file (<code>grub.cfg</code>).

=== B. The Kernel (<code>vmlinuz</code>) ===

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

'''The Name:''' <code>vmlinuz</code> stands for '''V'''irtual '''M'''emory '''Lin'''ux G'''z'''ip (compressed).

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

=== C. The Initramfs (<code>initrd</code>) ===

'''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 <code>initrd</code> 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 <code>initrd</code> deletes itself.

'''Your Crash:''' You had the Kernel, but you were missing the <code>initrd</code>. The Kernel was blind.

=== D. The Root Filesystem (<code>/</code>) ===

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

'''The Identifier:''' Linux calls hard drives <code>/dev/sda</code>, <code>/dev/sdb</code>, or <code>/dev/nvme0n1</code>.
** '''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.

{| class="wikitable"
! Hardware !! GRUB Name !! Linux Name
|-
| '''First Drive''' || <code>(hd0)</code> || <code>/dev/sda</code>
|-
| '''Second Drive''' || <code>(hd1)</code> || <code>/dev/sdb</code>
|-
| '''NVMe Drive''' || <code>(hd0)</code> || <code>/dev/nvme0n1</code>
|}

'''The Trap:'''
In your recovery, GRUB saw your files on <code>(hd1,gpt2)</code>.

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

Linux Translation: "That corresponds to <code>/dev/sdb</code>."

''If you tell Linux <code>root=/dev/sda2</code> but GRUB found the files on <code>(hd1)</code>, 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 <code>grub></code>, follow this flowchart.

=== Phase 1: Exploration ===

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

'''List drives:'''

#:<syntaxhighlight lang="bash">
ls
</syntaxhighlight>
#:''Returns: <code>(hd0) (hd0,gpt1) (hd1) (hd1,gpt2)</code>''

'''Check content:'''

#:<syntaxhighlight lang="bash">
ls (hd0,gpt2)/
</syntaxhighlight>
#:* ''If <code>error: unknown filesystem</code>:'' Wrong drive.
#:* ''If <code>efi/</code>:'' This is the boot partition, not the OS. Keep looking.
#:* ''If <code>etc/ home/ boot/</code>:'' '''JACKPOT.''' This is your root drive.

=== Phase 2: Identification ===

You need to find a '''Matched Pair''' of boot files.

'''Set the root:'''

#:<syntaxhighlight lang="bash">
set root=(hd1,gpt2) <-- Replace with the drive you found in Phase 1
</syntaxhighlight>

'''List boot files:'''

#:<syntaxhighlight lang="bash">
ls /boot/
</syntaxhighlight>

'''The Matching Game:'''

#:You must find a version number that exists for '''BOTH''' files.
#:* <code>vmlinuz-6.14.0-37-generic</code> (Exists?) -> YES
#:* <code>initrd.img-6.14.0-37-generic</code> (Exists?) -> YES
#:* '''Result:''' This is a safe pair.
#:* <code>vmlinuz-6.17.0-14</code> (Exists?) -> YES
#:* <code>initrd.img-6.17.0-14</code> (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:''' <code>linux

$$path\_to\_kernel$$

root=

$$linux\_drive\_name$$

ro</code>

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

'''The Command:'''

<syntaxhighlight lang="bash">
linux /boot/vmlinuz-6.14.0-37-generic root=/dev/sdb2 ro
</syntaxhighlight>
*''(Note: If <code>(hd1)</code> was your drive, try <code>/dev/sdb2</code>. If <code>(hd0)</code>, try <code>/dev/sda2</code>)''.

'''2. Load the Ramdisk (Initrd)'''

'''Syntax:''' <code>initrd

$$path\_to\_matching\_initrd$$

</code>

'''The Command:'''

<syntaxhighlight lang="bash">
initrd /boot/initrd.img-6.14.0-37-generic
</syntaxhighlight>

'''3. Launch'''
<syntaxhighlight lang="bash">
boot
</syntaxhighlight>

{| class="wikitable" style="border: 2px solid red; background-color: #ffcccc; color: black;"
! 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 (<code>Ctrl+Alt+T</code>) and run these commands in order:

'''Fix partially installed updates:'''

#:<syntaxhighlight lang="bash">
sudo dpkg --configure -a
</syntaxhighlight>

'''Generate the missing initrd files (The Magic Fix):'''

#:<syntaxhighlight lang="bash">
sudo update-initramfs -u -k all
</syntaxhighlight>
#:''This looks at every installed kernel and builds the missing <code>initrd</code> file that caused your crash.''

'''Update the GRUB menu:'''

#:<syntaxhighlight lang="bash">
sudo update-grub
</syntaxhighlight>
#:''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.
#:<syntaxhighlight lang="bash">
ls -lh /boot/initrd.img*
</syntaxhighlight>
#: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:'''

#:<syntaxhighlight lang="bash">
sudo reboot
</syntaxhighlight>

== 6. Troubleshooting: When the Fix Fails ==

=== Scenario: The "DKMS" Error (Amdgpu / Nvidia) ===
If you see output like this:
<code>dkms autoinstall on 6.17.0-14 ... failed for amdgpu(10)</code>
<code>make ... bad exit status: 2</code>

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

'''The Solution:'''

'''Remove the bad driver:'''

#:<syntaxhighlight lang="bash">
sudo apt-get remove amdgpu-dkms
</syntaxhighlight>
#:(Replace <code>amdgpu-dkms</code> with <code>nvidia-dkms-xxx</code> if needed).

'''Retry the update:'''

#:<syntaxhighlight lang="bash">
sudo dpkg --configure -a
</syntaxhighlight>

=== Scenario: The "Half-Baked" Kernel ===
If <code>update-grub</code> 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.
#:<syntaxhighlight lang="bash">
sudo apt-get purge linux-image-6.17.0-14-generic linux-headers-6.17.0-14-generic
</syntaxhighlight>
#:''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: <code>rmdir: failed to remove '/lib/modules/6.17.0-14-generic': Directory not empty</code>

'''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.
#:<syntaxhighlight lang="bash">
sudo rm -rf /lib/modules/6.17.0-14-generic
</syntaxhighlight>
#:(Make sure you type the version number exactly correctly).
#:Then update grub one last time:
#:<syntaxhighlight lang="bash">
sudo update-grub
</syntaxhighlight>

== 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:''' <code>Kernel Panic ... unable to mount root fs on unknown-block(0,0)</code>

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

=== The Diagnosis ===
When the user ran <code>ls /boot/</code> inside the GRUB shell, the output revealed the root cause immediately:

'''Kernel 6.17.0-14:''' Found <code>vmlinuz-6.17.0-14</code> but '''NO''' <code>initrd.img-6.17.0-14</code>.
*:''Conclusion:'' The default kernel was broken/incomplete.

'''Kernel 6.14.0-37:''' Found <code>vmlinuz-6.14.0-37</code> '''AND''' <code>initrd.img-6.14.0-37</code>.
*:''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 <code>(hd1,gpt2)</code>. In GRUB language, <code>hd1</code> usually means the ''second'' physical disk.

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

'''The Fix:''' The user changed the command to <code>root=/dev/sdb2</code> (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:

<code>initrd-6.14 (Working):</code> 134MB

<code>initrd-6.17 (Broken):</code> 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 ===
<syntaxhighlight lang="bash">
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
</syntaxhighlight>

Understanding & Fixing Kernel Panics 260212 - Revision history

Justinaquino: Imported from gi7b wiki