One missing file. Three days of silence. One kernel panic.

Jill Ravaliya — Thu, 12 Mar 2026 05:20:26 +0000

The login screen never appeared.

Instead:

KERNEL PANIC!
VFS: Unable to mount root fs on unknown-block(0,0)

Purple screen. Dead machine.

I hadn't touched the kernel. I hadn't run any experiments
on the host. I had done everything right — kept all my
dangerous kernel module work inside a VM, exactly so
this couldn't happen.

And yet.

It started three days before I even knew something was wrong.

That's the part that got me.

Not a dramatic crash. Not a warning. Not a single
error on screen during three consecutive days of
silent failures — while I used the laptop normally,
completely unaware.

The system was lying to me the whole time.

What I found when I started reading logs.

A missing file that should have been created
during kernel installation.

A script that checked for that file —
didn't find it — printed nothing —
and returned success.

GRUB trusted that success signal.
Built a boot entry pointing to a file
that didn't exist.
And I rebooted into a panic.

The most dangerous failures aren't the loud ones.
They're the ones that look like everything is fine.

The full investigation is on my GitHub.

Every log. Every wrong assumption.
Every step that narrowed it down.

The exact silent failure chain — from a missing
VirtualBox header file all the way to an unbootable
NVMe system — with zero warnings to the user.

Ubuntu engineers confirmed the bug within 2 hours
of me filing it. It affected 110+ users.

For see full Investigation, click here !

What this actually taught me.

Filtering logs for errors would not have found this.

The failure was logged quietly. A status change.
A missing file. A script returning success
when it shouldn't have.

Systems don't fail loudly.
They fail quietly first.
Sometimes for three days in a row.
While showing you nothing.

Learning to read that silence —
that's the real skill.

What's the quietest failure you've ever debugged?
Drop it below — I'd love to know. 👇

Find me here:

GitHub — where I commit daily
LinkedIn — where I share the stories -

I tried Python. Something felt wrong. Then I touched the Linux kernel — and everything clicked.

Jill Ravaliya — Tue, 24 Feb 2026 05:48:58 +0000

Some journeys don't start with tutorials.
Mine started with one random question at 2am.

"How does a computer actually work?"

Not how to use one.
Not how to code on one.
How does it actually work — underneath everything.

That question pulled me into a two-month rabbit hole.

Jacquard looms. Babbage's machine. Ada Lovelace.
Vacuum tubes. Relays. Punch cards. Transistors.
Turing. Enigma. Clocks. Quartz. GHz.

I wasn't studying for anything.
I just couldn't stop.

Then I tried Python.

Everyone said start with Python.
So I did.

But something felt wrong.

I was writing features. Moving data around.
It worked. But it felt... hollow.

Like I was operating a machine I didn't understand.

Then one night I opened a Linux terminal for the first time.

I typed:

uname -r

Output:

6.14.0-37-generic

I didn't know what that number meant.
So I looked it up.

That was the kernel version.
The thing running underneath everything.

I started reading about:

Init systems
Boot sequences
Ring 0 vs Ring 3
How user space talks to kernel space
How a simple open() call travels from your Python script all the way down to hardware

That was the feeling I was looking for.

Six months later.

Wrote my first kernel module — a character device driver
Hit a kernel panic on my host machine — not the VM
Read every log file until I found the root cause
Filed a bug report on Launchpad
Ubuntu engineers confirmed it within 2 hours

The bug affected 110+ users.

A single missing file was silently taking down entire boot sequences on NVMe systems — with zero warning to the user.

I found it because I couldn't stop reading logs.

What systems programming actually teaches you.

It's not about features.
It's not about frameworks.

It's about understanding what's actually happening underneath —
when everything looks fine on the surface
but something is quietly broken.

Systems don't just fail loudly.
They fail quietly first.

Learning to see that silence — that's the real skill.

Who I am.

I'm Jill Ravaliya — Linux kernel developer, daily GitHub committer, systems thinker.

I work at Reliance Industries and spend every free hour going deeper into how Linux actually works — not from tutorials, but from breaking things and reading logs until they talk back.

This is where I'll share the deep technical stuff:

Kernel internals
Device drivers
Boot systems
Real bugs from real machines

If you're wired for systems too — follow along.

Find me here:

where I commit daily - GitHub
where I share the stories - Linked-In

What's coming next.

The full investigation of that kernel panic.

Every log.
Every wrong assumption.
Every step that led to the bug.

A silent success path that should never have existed —
and how one missing file nearly made my system permanently unbootable.

See you in the next one.

DEV Community: Jill Ravaliya