DEV Community

Cover image for Surviving a Kernel Panic: My Ubuntu War Story
Naomi Jepkorir
Naomi Jepkorir

Posted on

Surviving a Kernel Panic: My Ubuntu War Story

#linux #tutorial #ubuntu

When your backlog is full of data science models and software engineering tasks, the last thing you need is your OS failing to boot because of a kernel panic, no?

Well, this happened to me. I was given the option to reboot, did it the first time, and I was back in after choosing an older kernel version from the menu. It happened a second time, a third time... and I was just okay with it, saying, "I'll fix it later."
This worked like a charm right up until Linux decided it had had enough. It finally threw an Input/output error, locked the root filesystem / into Read-only mode, and locked me out completely.

A laptop screen showing a Linux terminal failing to execute commands, flooded with
I couldn't even poweroff via the terminal.

The silver lining came when I realized I had a Kali Linux installer ISO sitting on a flash drive nearby. In case you find yourself in this,let's call it "very specific" situation, here is how to perform open-heart surgery on your system before you do anything rash like wiping your drive.

Step 1: The Hard Reset & The USB Boot

Since the terminal was completely frozen, a graceful shutdown was out of the question. Long-press the power button to force the PC to power off. Turn it back on and immediately open your startup menu (usually by spamming Esc, F12, or F9 depending on your laptop model). From there, boot directly into your rescue USB.

Step 2: Dropping into the Underworld (The BusyBox Shell)

Because I was using a Kali Linux installer ISO (not a Live Desktop), there was no beautiful graphical interface to save me. I had to navigate the installer menu and select "Execute a shell".

This drops you into a raw, stripped-down BusyBox ash shell. From here, we need to find exactly where the broken Ubuntu system lives on the hard drive.

Run this command to list your partitions:

fdisk -l
Enter fullscreen mode Exit fullscreen mode

Scan the output for your main Linux filesystem. In my case, Ubuntu was sitting on /dev/sda2.

Step 3: Find and repair

Because I was forced to hard-reset the machine multiple times while the OS was locked up, the filesystem metadata was corrupted. Files were left hanging in memory, creating "orphaned inodes." If you try to boot with a corrupted filesystem, Linux will panic to protect your data.

NOTE: Make sure your broken partition is not mounted.
Quick check just to be safe:

umount /dev/sda2/
Enter fullscreen mode Exit fullscreen mode

It's time to repair the drive. Run the ext4 filesystem check tool on your specific partition:

e2fsck -y /dev/sda2
Enter fullscreen mode Exit fullscreen mode

(💡Tip: The -y flag is crucial here. It automatically answers "yes" to the hundreds of prompts asking if you want to fix individual corrupted sectors. Without it, you will be holding down the 'Y' key for an eternity).

Once the screen stops scrolling, you are looking for the holy grail: a message declaring your drive /dev/sda2: clean.

A Linux terminal displaying the output of the raw `e2fsck` endraw command successfully clearing orphaned inodes and reporting the raw `/dev/sda2 ` endraw filesystem as clean.

Step 4: The Boot Menu & The Investigation

With the filesystem repaired, type reboot (or hard reset again if the shell is stubborn) and unplug the USB.

Do not let it boot normally. As soon as the PC turns on, spam esc to bring up the GRUB boot menu. Go to Advanced options for Ubuntu and manually select an older kernel version (e.g., 6.14.x instead of the newest one).

Once you are successfully booted into your desktop, open a terminal. It is time to find the killer. List all installed kernels:

dpkg --list | grep linux-image
Enter fullscreen mode Exit fullscreen mode

If you read the output carefully, you'll likely spot the culprit. Look at the two letters on the far left of the list:

ii means Installed and Intact (This is your stable, older kernel).

it means Installed, Triggers pending (This is a half-baked, broken kernel).

In my case, the system had tried to automatically update to the 6.17 kernel in the background. But a third-party module, specifically VirtualBox DKMS, failed to compile for the new kernel architecture. VirtualBox crashed, which halted the entire kernel installation halfway through, leaving my machine with an unbootable OS.

Step 5: The Execution(Purging the Rot)

Now we just need to clean up the mess and permanently delete the broken kernel so the system stops trying to default to it.

First, get the blocking software out of the way (you can reinstall it later):

sudo apt remove --purge virtualbox-dkms
Enter fullscreen mode Exit fullscreen mode

Next, tell the package manager to unjam itself and fix any half-installed dependencies:

sudo apt --fix-broken install
Enter fullscreen mode Exit fullscreen mode

Now, drop the hammer on the broken kernel (replace the version numbers with the broken one from your dpkg list):

sudo apt purge linux-image-6.17.0-19-generic linux-headers-6.17.0-19-generic
Enter fullscreen mode Exit fullscreen mode

Finally, sweep up the orphaned packages and update your boot menu to lock in your stable kernel as the new default:

sudo apt autoremove
sudo update-grub
Enter fullscreen mode Exit fullscreen mode

All good 😊✨

A little note...

Isn't it funny how things completely falling apart is usually the best way to figure out how they actually work?

But hey, in case you found yourself in this situation, found your way here, and this still doesn't work... you should probably just delete that OS 😂 or contact your local AI agent.

Top comments (1)

Collapse
 
dnzambuli profile image
Daniel Damunza •

The level of patience on display here is legendary. If I had a Kali live image, I'd have flashed my machine and been halfway through a fresh OffSec setup by the time you found the root cause. Incredible persistence. But, what’s the long-term plan if you need VB for a future project? Back to the trenches?