I Broke My WSL, Nearly Lost 1.7 Million Files — A Digital Autopsy

TL;DR: Your drive is 100% full. You can't back up. You can't repair. You can only pray. And if you're lucky, the universe sends you an oracle card that says "Embracing Kindness" right when you're about to lose your mind. If you're unlucky, you meet a glass tube. Welcome to the read.

---

Prologue: A Morning Too Bright for a Small Death

That morning, the sun was shining with a tone that seemed to say,

"Good morning, world. Everything is going to be fine."

I was sitting at my desk with a cup of coffee. Outside the window, leaves were swaying gently. Birds were chirping without sin. The universe seemed to have signed a peace treaty with me for that day.

I misread the contract. The contract was written in small print at the very bottom. The kind of contract you find in a predatory loan app with a 2%-per-day interest rate.

I — a developer who is also a carrot farmer — decided to install an AI agent that was trending. Because who needs a virtual machine when you can just run it directly in WSL?

"VMs are for paranoid people."

"WSL is for productive people."

"I'm a senior developer. I know what I'm doing."

"And if something breaks, I'll just restore from backup. Right?"

That last sentence would haunt me for the rest of my life.

curl -fsSLO https://raw.githubusercontent.com/.../install.sh
less install.sh
bash install.sh

The process ran. The terminal was colorful like a Christmas tree lit by someone who really, really loves colors. Downloading dependencies. Installing Node.js, Python, ripgrep, who knows what else. For a moment, I felt like I was watching a digital orchestra performing the symphony of human progress.

Then.

Hang.

Error.

Ctrl+C.
Ctrl+C.
Ctrl+C.
Ctrl+Z.
Ctrl+Z.
Ctrl+C.
Ctrl+Z.

Dam*miT

Close terminal.

"Ah, just run it again, probably."

"Sometimes installs need a second try."

"Microsoft is weird sometimes, but they won't destroy my system."

"And if something breaks, I'll just restore from backup. Right?"

That sentence again. The same sentence. The sentence I said without knowing that the backup did not exist. Never existed. Will never exist. Because my drive was full, and I already knew that, but I chose not to think about it because thinking about it made me uncomfortable.

And there was one more thing I didn't think about. One thing that, if I had just thought about it for five seconds, might have prevented this entire disaster.

I didn't know where my VHDX was stored.

WSL never tells you. No installer asks. No notification pops up in the taskbar. The VHDX just... exists. Somewhere. Inside your computer. Maybe on drive C. Maybe on drive D. Maybe on drive E. I had moved mine two years ago, back when I thought drive C was too full. But I didn't remember where to. And after two years, I stopped asking.

"The VHDX is an abstraction."

"The VHDX is an implementation detail."

"The VHDX is not my problem. My problem is writing code."

And when that abstraction broke, I only then realized that the abstraction stood on top of a drive that was already full.

I opened WSL again.

And there, my life changed.

<3>WSL (124 - Relay) ERROR: CreateProcessParseCommon:996: getpwnam(jack) failed 5
<3>WSL (124 - Relay) ERROR: CreateProcessParseCommon:1005: getpwuid(1000) failed 5
<3>WSL (124 - Relay) ERROR: ConfigUpdateLanguage:2553: fopen(/etc/default/locale) failed 5
<3>WSL (124 - Relay) ERROR: operator():579: getpwuid(0) failed 5
wsl: Failed to start the systemd user session for 'root'. See journalctl for more details.
<3>WSL (124) ERROR: I/O error @util.cpp:1358 (UtilInitGroups)
<3>WSL (124 - Relay) ERROR: CreateProcessCommon:807: Create process failed

I read it. Once. Twice. Three times.

And the only thing that ran through my head was:

"I just destroyed five years of my life with one bash command, and there is no backup."

"I just committed digital suicide."

"Welcome to hell. Population: one."

---

Act One: Denial, or "It's Probably Just a Small Error"

The first reaction of every developer when facing a problem is to believe the problem is a lie. That maybe, if we close our eyes and open them again, reality will change. That Microsoft is just joking.

wsl --shutdown
wsl

The answer?

Catastrophic failure
Error code: Wsl/Service/E_UNEXPECTED

"Catastrophic failure."

Microsoft really chose the right words. Very poetic. Very dramatic. Very aligned with the state of my heart. The word "catastrophic" comes from the Greek katastrophē, meaning "an overturning" or "a destruction." In Ancient Rome, it meant "the end of a drama."

Which, in developer language, means:

"You just lost, bro. Enjoy the rest of your life."

"Catastrophic failure. Two words in English that I will remember until I die."

"If this were a movie, this scene would be scored with violins played by a child in the middle of a ruined city."

I checked the WSL version. 2.6.3.0. Oh, so we just upgraded to a version that... is a bit problematic. Great. Very great. Like buying a new car, and when you drive off the lot, the wheels are already off.

I tried wsl --update.

The older version of Windows Subsystem for Linux cannot be removed.
Update failed (exit code: 1603).

"The older version of Windows Subsystem for Linux cannot be removed."

Excuse me, Microsoft. I never asked you to remove the older version. I only asked you to update it. But it seems the universe has decided that today, I must learn the meaning of the word "helplessness."

"Maybe this is the universe's way of telling me it's time to switch to a MacBook."

"Or give up on technology and become a full-time carrot farmer."

"Carrots never say 'cannot be removed'."

"Carrots never say 'Catastrophic failure'."

"Carrots only say: water, soil, sunlight."

"And carrots never destroy my life because of a failed update."

---

Act Two: A 500-Line Log, Error 1603, and Microsoft's First Lie

I opened the log file Microsoft provided at C:\Users\...\AppData\Local\Temp\wsl-install-logs.txt.

It was 500 lines. I scrolled. I scrolled again. There were hundreds of lines like:

MSI (s) (18:98) [09:12:11:134]: Using cached product context: machine assigned for product: F993DD9E3A12E9747AFD6DFCB4A2BD3F

"F993DD9E3A12E9747AFD6DFCB4A2BD3F. What is this? The combination to a Swiss bank vault?"

"Or maybe it's my ex's phone number? Equally useless."

"Or is this a secret code to summon a demon? If so, I'm ready. I need help from dark forces."

But among the hundreds of lines, one caught my attention:

Property(S): OutOfDiskSpace = 0

Zero. Which means... no space issue.

Huh?

"OutOfDiskSpace = 0. So this isn't a space issue?"

"Microsoft, please don't lie to me at a time like this."

"I've suffered enough. Don't add lies to the pile."

"I've already lost five years of my life. Don't add illusions to it."

I closed the log. I sat in silence. Something was off. There was something Microsoft wasn't telling me. Something that even the MSI installer itself couldn't detect. Something hidden behind those hexadecimal numbers.

Then I remembered — I had never actually checked my drives.

And that was the moment I realized that this wasn't a disaster. This was a murder. And the perpetrator was me.

---

Act Three: df -h — The Moment I Looked in the Mirror and Saw a Killer

I opened the old WSL terminal that somehow was still running as root, and typed a simple command:

df -h

And the output was one of the most shameful moments of my life as a developer.

Filesystem      Size  Used Avail Use% Mounted on
C:\             101G   96G  5.0G  96% /mnt/c
D:\             137G  137G  1.5M 100% /mnt/d
E:\             112G  106G  5.6G  96% /mnt/e
/dev/sdd       1007G   83G  873G   9% /

I stared at the numbers. I re-read them. I hoped I had read them wrong.

D:\ — 137G used, 1.5 MB available, 100%.

1.5 MB.

Not 1.5 GB. Not 15 GB. 1.5 MB.

That's smaller than a low-res selfie. Smaller than a bad-bitrate MP3. Smaller than the log file I had just read. Smaller than the screenshot I had taken for remembrance. Smaller than an empty .txt file I had never written to.

And on that drive — a drive filled down to the last 1.5 MB — my VHDX was stored. The VHDX that held 1.7 million files. The VHDX that held five years of my life.

"Oh. Oh no."

"So it wasn't the install script that corrupted my filesystem."

"It wasn't Microsoft that destroyed my VHDX."

"It was me."

"I destroyed it."

"I am the murderer of my own data."

I closed my eyes. I closed my laptop. I looked at my carrot garden through the window.

Those carrots were growing peacefully. None of them were full. None of them had errors. None of them said Catastrophic failure. They only needed soil, water, and sunlight. And they always had room to grow.

I, on the other hand, was a developer who had let his D: drive fill to 100%. Down to 1.5 MB. And then I ran an installation script that needed to write hundreds of megabytes into a filesystem running on a drive that had no room left.

"That's like trying to pour water into a glass that's already full, then blaming the glass when the water spills."

"That's like pouring gasoline into a car with no tank, then blaming the engine when it won't start."

"That's like burying someone alive, then blaming the soil for being too dense."

"Enough. I understand now. I am the cause."

And this was the most painful moment. Because at that point, I also realized:

If my drive is full, I cannot make a backup.

To back up an 83 GB VHDX, I need 83 GB of free space. Drive D had 0 GB left. Drive C had 5 GB left. Drive E had 5.6 GB left.

So if I chose not to repair the VHDX, I would lose the data.

And if I chose to repair the VHDX, and something went wrong, I would lose the data.

I was trapped between two possible losses, and I couldn't avoid either one.

This was no longer a story about errors. This was a story about regret. A story about how we can become the executioner of our own lives without realizing it.

"If only I had deleted those pirated movies two weeks ago."

"If only I had moved those old downloads to an external drive."

"If only I had set aside 100 GB. Just 100 GB. For emergencies."

"If only I weren't lazy."

"If only I hadn't thought 'later'."

"If only, if only, if only."

Three of the most painful words in the human language.

---

💡 Mini-Lesson: Where Is Your VHDX Stored?

If you use WSL and don't know where your VHDX is, this is the time to wake up. Most WSL users never know where their VHDX lives. The default:

C:\Users\<your-name>\AppData\Local\Packages\<Distro>\LocalState\ext4.vhdx

Example for Ubuntu from Microsoft Store:

C:\Users\lenovo\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx

And for a manually imported distro (like mine):

D:\Kotonk\WSL\ext4.vhdx   (or wherever you put it)

Why this matters: If you don't know where your VHDX is, you won't know which drive to keep free. And if that drive fills up, you'll have the same nightmare as I did.

How to find your VHDX:

In PowerShell:

Get-ChildItem -Path "$env:LOCALAPPDATA\Packages" -Filter "ext4.vhdx" -Recurse -ErrorAction SilentlyContinue | Select-Object FullName, Length

Or search all drives:

Get-ChildItem -Path "C:\", "D:\", "E:\" -Filter "ext4.vhdx" -Recurse -ErrorAction SilentlyContinue | Select-Object FullName, Length

Write it down. In a notebook. Screenshot it. Stick it on your wall. Because in a crisis, you'll forget.

---

Act Four: A Long Night — An Absurd Comedy About Tools That Sell Hope

Before I decided to repair the VHDX the right way, I scoured the internet searching for "WSL recovery tool" and "ext4 repair Windows" and various combinations of words that made Google start showing me ads for SSDs and cloud backups.

Every tool I found was a different story, and every story ended with the same line:

"Register to continue."

"Enter your license key."

"Upgrade to Pro."

"Payment required."

"Enter your credit card."

"We will send a verification email to your registered address."

"Please allow 3-5 business days for processing."

"For faster service, please consider our premium plan."

I made a mental list. But this time, I won't name them. Because I don't want to be sued. I'll only call them by what they deserve to be called: hope sellers.

---

The Reader That Only Reads

A tool that promised to let me browse my broken files — for free. And it delivered. I could see every file, every folder, every config. I could see five years of my life — displayed beautifully on the screen. Old photos. Old code. Old documents I wrote at 3 AM while crying.

But to copy anything? To write anything back? "Upgrade to Pro."

"So I can see all my files, but I can't take them."

"That's like watching your ex through a café window."

"Enjoying the suffering that the law allows."

"And I'm pretty sure if I click 'Upgrade', it will ask for my home address. And my mother's maiden name. And my blood type."

---

The Wizard With the Smiling Ads

A recovery tool whose YouTube ads are full of happy models. They smile. They seem to say: "If you use our product, your life will be as happy as ours." They don't know that I'm crying in front of my laptop.

I downloaded it. I installed it. The scan ran. Result? "42 files found!"

Oh. That was just the dummy files. To see the real files: pay. To save the recovery: pay. To close the app without feeling guilty: impossible, because it will show you a 30% discount popup that's only valid "today only."

"You know, I don't mind paying."

"But I want to know first if your tool can save my files."

"But you hide that behind a paywall."

"So we're both guessing. You're guessing I'll pay. I'm guessing your tool works."

"In this uncertainty, nobody wins. Except you, if I'm stupid."

---

The One That Needed a License

A tool that looked professional. Clean interface. Clear business model: you pay, we work. I downloaded. I installed. I opened. I selected the VHDX. And then:

"Recovery is only available in the Professional version. Please purchase a license."

I stared at the screen with a blank expression. I looked at my bank balance. I looked at my carrot garden outside. I looked at my neighbor watering his plants with calm.

"My neighbor is watering his plants."

"I'm watering my tears."

"And not a single one of them can be recovered from today."

---

The Forensic-Grade One

The kind of tool used by forensic labs and data recovery companies. The price for the Pro version? Hundreds of euros. For a carrot farmer who is also a developer, that's equivalent to several weeks of harvest.

I closed the tab. I wasn't angry. I understood. Every company has to eat. I have to eat too. I have bills too. I have carrots to sell at the market too.

But deep in my small heart, a voice whispered:

"If only you offered a 24-hour trial, I would be grateful for the rest of my life."

"But no. First, register your email."

"Verify. Enter your credit card."

"Consent to marketing emails from who knows how many companies."

"Provide your phone number."

"Provide your mother's maiden name."

"Provide your childhood home address."

"Provide your blood type."

"Provide three references from trustworthy friends."

"And after all that... 'Sorry, your VHDX file is not supported in the trial version.'"

"You know, I'm not asking for my files back for free."

"I'm only asking for a chance to try before I trust you with my money."

"But you treat me like a suspect who must show a credit card before being allowed into the interrogation room."

"Like I'm a thief trying to steal my own files."

---

The Free One From Ancient Times

It's free. Open source. Legendary. Everyone recommends it.

But... the documentation is an 800-page novel written by a man who really, really loves C. I read it. I tried to understand. I typed its name into the terminal.

And then I saw a white-text menu on a black screen that looked like it was from 1998.

"I'm not afraid of the command line."

"I'm just not sure that in the middle of my panic, I can navigate a menu that requires me to remember partition numbers."

"And if I press the wrong key, will I delete the partition that actually survived?"

"Will I change this story from 'I lost one file' to 'I lost everything'?"

"No. I don't want to take that risk."

"At least not before I write my will."

"And my will will say: 'To my wife, I leave my laptop. To my child, I leave my carrots. To Microsoft, I leave a curse.'"

I closed it. I took a deep breath. I returned to the terminal.

Decision: I would repair it myself. With my own hands. With knowledge that had long been buried in my head.

"Sometimes, the most ancient way is the most honest."

"And sometimes, the most ancient way is the only way left."

"Because all modern ways expect money I don't have."

"Or a sacrifice of data I don't want to give."

---

Act Five: Building a Hospital for a Dying VHDX

Every patient needs a hospital. And my VHDX — a file holding my entire digital life — was a dying patient.

I needed a "doctor." The doctor couldn't be Ubuntu (because Ubuntu was the broken one). So, I installed another distro: Debian.

Why Debian?

• It's small (about 300 MB).
• Stable as a rock.
• Never dramatic.
• Older than some of my colleagues.
• And most importantly: it has no past with Microsoft Installer.

wsl --install -d Debian

Within a few minutes, my hospital was up. Complete with a new user, an easy-to-remember password, and a will of steel.

Now, I needed to bring the "patient" to this hospital.

wsl --shutdown
wsl --mount --vhd "D:\Kotonk\WSL\ext4.vhdx" --bare

Output: The operation completed successfully.

My first sigh of relief since that morning.

---

Act Six: The Device Identification Ritual — Where /dev/sdX Is a Myth

Here, I must admit. I made a big mistake by not thinking clearly.

I saw an online tutorial that said:

e2fsck -f -y /dev/sdX

And I — a senior developer who should have known better — ran that command as is.

e2fsck 1.47.2 (1-Jan-2025)
e2fsck: No such file or directory while trying to open /dev/sdX
Possibly non-existent device?

Of course there's nothing. /dev/sdX is a placeholder, not a device name. Using /dev/sdX is like looking for a file named filename.txt on a hard drive.

"If only the tutorials on the internet were a bit clearer, I wouldn't have spent the first ten minutes blaming Linux."

"But no. They write sdX assuming every reader already knows what it means."

"But every reader, especially one in a panic, won't know."

"And every second I spend guessing is a second bringing me closer to a heart attack."

Lesson one: Never trust a tutorial that uses sdX without explaining that you must replace it.

After I ran lsblk -f, it finally became clear:

NAME FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda  ext4   1.0
sdb  ext4   1.0
sdc  swap   1           44ce0641-...
sdd  ext4   1.0         9f108056-7828-4919-8b8d-d5a755b8437c
sde  ext4   1.0         a048fd43-...                        955.3G     0% /mnt/wslg/distro

sdd. The device that's 1 TB, has type ext4, and no mountpoint.

That was it. My VHDX.

"sdd. Two letters and one number."

"That's what will determine whether I lose five years of my life or not."

"Sometimes I feel like life is unfair."

"Sometimes I feel like life is just a puzzle made by someone who really loves writing error messages."

"And sometimes I feel like I am a character in an unfunny joke, written by someone who doesn't like me."

---

Act Seven: e2fsck — The Moment I Prayed to God and the Linux Kernel Simultaneously

I took a breath. I placed my hands on the keyboard. I said words I hadn't said since my thesis defense:

"Lord, if my blessings are still in this file, please let them survive."

"If this is not the time for me to lose everything, please show me the way."

"If I still deserve to keep this data, please give me a second chance."

"I promise to back up. I promise to buy an external drive. I promise to delete those pirated movies."

And I pressed Enter.

wsl -d Debian -u root -- e2fsck -f -y /dev/sdd

The output flowed:

/dev/sdd: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (242242018, counted=242242017).
Fix? yes

Free inodes count wrong (65398741, counted=65398740).
Fix? yes

/dev/sdd: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdd: 1710124/67108864 files (0.2% non-contiguous), 26193439/268435456 blocks

1,710,124 files.

Not a hundred. Not a thousand. Not ten thousand.

One million, seven hundred ten thousand, one hundred twenty-four files.

And every one of them was still there.

I sat still. Didn't move. Didn't speak. I stared at the screen with the kind of gaze you might see in a father watching his child come home from war. The gaze of a man who just survived death. The gaze of a man who just realized that this world, though sometimes cruel, is also sometimes kind.

"They're still there. All of them are still there."

"Lord, I don't know what I did to deserve this, but thank you."

"I will never let my D: drive fill up again. I promise."

"I will delete those old files. I will move those pirated movies. I will buy an external drive."

"Even if I have to sell a few carrots at the market. By God, I will do it."

I picked up my coffee. Cold since two hours ago. I drank it. It was bitter. But for the first time that morning, I smiled.

---

Act Eight: Systemd, or "The Bug That Isn't in Any Documentation"

When I tried to boot Ubuntu, the battle wasn't over.

wsl -d Ubuntu

wsl: Failed to start the systemd user session for 'jack'. See journalctl for more details.
<3>WSL (207 - Relay) ERROR: CreateProcessCommon:818: execvpe(/bin/bash) failed: I/O error

"Failed to start the systemd user session for 'jack'."

This is a known bug in WSL 2.6.x and 2.7.x. The systemd user session fails to start, so WSL can't execute /bin/bash as a regular user.

It's like having a car whose engine is healthy but whose ignition key is broken. You can see the car. You can touch it. You can cry next to it. But you can't start it.

"Of course. Of course there's another problem."

"If life were easy, maybe I'd be someone else."

"If life were easy, maybe I wouldn't have to write this article on dev.to."

"If life were easy, maybe I'd be a full-time carrot farmer, and I'd never know what 'Catastrophic failure' means."

The solution was simple but required courage: disable systemd temporarily.

I mounted the VHDX again, this time with auto-mount:

wsl --mount --vhd "D:\Kotonk\WSL\ext4.vhdx"

And then... something funny happened.

The disk was successfully mounted as '/mnt/wsl/DKotonkWSLext4vhdx'.

Notice the path: /mnt/wsl/DKotonkWSLext4vhdx.

Microsoft concatenated the entire path D:\Kotonk\WSL\ext4.vhdx into a single folder name without separators.

"Microsoft. You are geniuses in many ways."

"But there are some things that make me sure you made this decision on a Friday afternoon, five minutes before going home."

"Or maybe you did it on purpose. To test the patience of humanity."

"If so, you succeeded. Congratulations. I surrender. I will become a full-time carrot farmer."

I verified /bin/bash:

ls -la /mnt/wsl/DKotonkWSLext4vhdx/bin/bash
-rwxr-xr-x 1 root root 1446024 Mar 31  2024 /mnt/wsl/DKotonkWSLext4vhdx/bin/bash

There. Healthy. 1.4 MB.

I disabled systemd:

bash -c "echo '[boot]' > /mnt/wsl/DKotonkWSLext4vhdx/etc/wsl.conf && \
         echo 'systemd=false' >> /mnt/wsl/DKotonkWSLext4vhdx/etc/wsl.conf"

Unmount. Boot Ubuntu.

And...

Welcome to Ubuntu 24.04.4 LTS.

---

Act Nine: Cleaning Up the Remains — Locale, User, and Memories

Ubuntu booted. But I logged in as root, not jack. And the old error about /etc/default/locale still haunted me.

From inside the root shell, I ran cleanup operations:

grep jack /etc/passwd
# jack:x:1000:1000:,,,:/home/jack:/bin/bash   <- user still exists!

ls -la /home/ | grep jack
# drwxr-x--- 79 jack jack 4096 Sep 29 05:14 jack   <- ownership correct!

echo 'LANG=en_US.UTF-8' > /etc/default/locale
cat /etc/default/locale
# LANG=en_US.UTF-8

All green. User jack exists. Home has 79 folders. Permissions correct.

"79 folders. How many years of work do these 79 folders represent?"

"I don't know. I don't want to count. I'll get sad again."

"And I've been sad enough for today. Enough for this week. Enough for this month."

Exit the root shell. In PowerShell:

wsl --shutdown
wsl --manage Ubuntu --set-default-user jack
# The operation completed successfully.
wsl

And...

╭─jack@Jack 🕒 Tue Sep 29 12:08:26 📁 /mnt/c/Users/lenovo ✅

Jack. Not root. All files intact. All normal.

And I, for the first time that morning, genuinely smiled. Not a bitter smile. Not a cynical smile. A sincere smile.

"We won."

"Not a big victory. Not a victory that will be remembered in history."

"But a victory that is enough."

"And sometimes, a victory that is enough is the best victory we can hope for."

---

Act Ten: df -h — When the Universe Slapped Me for the Second Time

I ran a few simple commands to make sure everything was fine:

cd ~
pwd
# /home/jack

uname -a
# Linux Jack 6.18.33.2-microsoft-standard-WSL2

whoami
# jack

df -h

And there, I saw again something that made me sigh deeply:

Filesystem      Size  Used Avail Use% Mounted on
C:\             101G   96G  5.0G  96% /mnt/c
D:\             137G  137G  1.5M 100% /mnt/d
E:\             112G  106G  5.6G  96% /mnt/e
/dev/sdd       1007G   83G  873G   9% /

D:\ is still 100% full. C:\ is still 96%. E:\ is still 96%.

That day, I had repaired my WSL. But the root cause is still there.

"This disaster isn't really over."

"This disaster is just waiting for its next chance to happen again."

"If I don't clean my drives, this will happen again."

"Maybe not this week. Maybe not this month."

"But it will happen again."

"And I have to decide: will I let my drives fill until they die, or will I do something about it?"

I closed my laptop. I went outside. I walked to the back garden. The evening breeze blew gently. The sun was starting to set. And for some reason, in the middle of that silence, I remembered someone who had drawn a card for me that day.

---

Act Eleven: The Oracle Card — When the Universe Sent a Tiny Angel on a Crescent Moon

I'm not a superstitious person. I'm a developer. I believe in logic, in e2fsck, in lines of code that run as instructed. I believe problems have solutions, and solutions have documentation. I believe the universe consists of atoms and energy, not of signs and omens.

But that day, the universe seemed to be speaking through an unusual channel.

Someone I know — someone I respect — drew a card for me that day. And the card said:

"Embracing Kindness."

An angel with layered wings of purple, pink, and blue. Sitting in lotus position on a crescent moon. Around it, stars and cosmic nebulae. Below it, a white ribbon with the words: "Embracing Kindness."

The person who drew the card said:

"We are connected across space and time."

And for a moment, I was silent.

Because those words felt strange, but also very real. In the middle of all the 1603 errors, Catastrophic failure, and the dying VHDX, there was one simple message: Be kind to yourself.

"Space and time."

"Maybe it doesn't mean space and time literally."

"Maybe it means: in the middle of all this chaos, you still have time to forgive yourself."

"You still have time to stop blaming yourself for not backing up."

"You still have time to stop feeling stupid for letting your D: drive fill up."

"You still have time to stop feeling like a failure because of one bash install.sh command."

I looked at my carrots. They never blamed themselves when the soil was dry. They just grew. They just survived. They just waited for the next rain. They never said "Catastrophic failure." They never said "Contact your technical support group." They just grew, in silence, in a silence that never judged.

And I — a developer who is also a carrot farmer — realized something I might have known all along but always forgot.

We are all angels learning to embrace kindness. Even when we have just destroyed our own VHDX.

We are all angels sitting on a crescent moon, in the middle of cosmic chaos, trying to stay calm.

We are all angels whose wings are layered in color, even if sometimes we forget we have wings.

I smiled. I took a deep breath. I returned to my laptop.

And I wrote a note to myself in my notebook:

"Today, I almost lost 1.7 million files. But I didn't lose them. And today, I learned to forgive myself. Thank you, 'Embracing Kindness' card. Thank you, universe, for reminding me that in the middle of all this chaos, there is still room for kindness."

---

Act Twelve: The Glass Tube Locked Shut — When the Universe Slapped Me for the Third Time

The next day, I opened WSL again. With a calm feeling. With a feeling that the storm had passed. With a feeling that I had paid a heavy price for a valuable lesson.

I opened my project. I ran sudo nano /etc/wsl.conf to fix some configuration. I ran ps -aux to see running processes. Everything was normal. Everything was calm.

Then I tried to run MySQL.

sudo service mysql start

mysql: unrecognized service

Oh. MySQL wasn't installed. Of course. Because my VHDX had just recovered. I had to reinstall some packages. I ran:

sudo apt update && sudo apt install mysql-server -y

The process ran. Downloading packages. Downloading indexes. Downloading metadata.

And then.

E: Failed to fetch http://security.ubuntu.com/ubuntu/... Could not create temporary file for /var/lib/apt/lists/partial/... - mkstemp (30: Read-only file system)

W: Problem unlinking the file /var/lib/apt/lists/... - TransactionAbort (30: Read-only file system)

E: Unable to mkstemp /tmp/clearsigned.message.Y4tvZn - GetTempFile (30: Read-only file system)

E: The package lists or status file could not be parsed or opened.

Read-only file system.

Three words that made my blood stop flowing.

I tried sudo systemctl start mysql:

sudo: systemctl: command not found

Of course. Because systemd was disabled. Because I disabled it yesterday.

Then I tried a simple command:

php -l scripts/migrate-all.php

-bash: /usr/bin/php: Input/output error
-bash: /usr/bin/direnv: Input/output error
-bash: /usr/bin/date: Input/output error
-bash: /usr/bin/sed: Input/output error

Input/output error. Input/output error. Input/output error.

I stared at the screen. I stared at those words. I stared at /usr/bin/date that couldn't be run. /usr/bin/sed that couldn't be run. Even date — the simplest command in the Linux world, a command that just shows the date and time — couldn't be run.

"No."

"No. No. No. No."

"I just fixed it yesterday. I just saved 1.7 million files. I just prayed to God and the Linux kernel. I just saw a tiny angel on a crescent moon. And now... now what is this?"

I tried pressing Ctrl+C. Couldn't. I tried closing the terminal. It kept appearing.

-bash: /usr/bin/direnv: Input/output error
-bash: /usr/bin/date: Input/output error
-bash: /usr/bin/sed: Input/output error

I tried again. Ctrl+C.

-bash: /usr/bin/direnv: Input/output error
-bash: /usr/bin/date: Input/output error
-bash: /usr/bin/sed: Input/output error

MY FILESYSTEM WAS READ-ONLY.

I sat in my chair. I stared at my screen. I stared at the ceiling. I stared at my carrot garden through the window. And I felt like I was watching a replay of everything I had been through yesterday, but this time with a crueler twist.

Yesterday, my filesystem was corrupt. I repaired it.

Today, my filesystem was locked. And I didn't know why.

I sat there for several minutes. Reflecting. Thinking. Trying to understand.

And then, I realized. I realized what was happening.

Drive D: was still full. 99%. 1.9 GB left. That wasn't enough.

Yesterday, I repaired the filesystem with e2fsck. But I didn't fix the root cause: drive D: was still too full to hold filesystem operations.

Every time I wrote to WSL — installing packages, editing files, running apt update — the filesystem tried to write to the VHDX. The VHDX tried to write to drive D:. Drive D: had no room. The Linux kernel, as a last-ditch defense mechanism, locked the filesystem into read-only. Not because the filesystem was corrupted. But because the host disk was full.

It's like a doctor saying: "I've healed your wound. But you're still in a room with no oxygen. So your wound will reopen."

Or more precisely:

My filesystem wasn't a broken glass tube. My filesystem was a glass tube locked tight from the outside, because drive D: was so full that no key could turn.

I saw the metaphor clearly. A beautiful glass tube, holding my entire digital life — files, photos, code, memories. But the lid was locked. Not because the tube was broken. Not because its contents were broken. But because there was no room to turn the key.

"Yesterday, I lost access to the tube because its contents were broken."

"Today, I lost access to the tube because the tube was locked tight."

"And the lock couldn't be turned because drive D: was full."

"I wasn't just the murderer of my own data."

"I was also the jailer of my own data."

"I locked that tube from the outside, and now I can't open it."

I laughed. A small laugh. A bitter laugh. The laugh of someone who no longer has tears left to cry.

"This is funny."

"This is really funny."

"The universe sent me a tiny angel on a crescent moon yesterday."

"And today, the universe sent me a glass tube locked tight."

"Maybe this is the universe saying: 'You haven't finished learning yet, kid.'"

"Maybe this is the universe saying: 'You've learned to forgive yourself. Now, learn to clean your room.'"

I closed my laptop. I stood up. I walked to drive D: in File Explorer. I saw the number I had seen many times before: 99% full. 1.9 GB free.

I stared at that number. I stared at it like an old enemy. An enemy I had defeated yesterday, but who returned today with the same face.

"Alright, D:."

"You won yesterday. You won today."

"But tomorrow, I will delete those files. I will move those movies. I will empty you down to 50%."

"And you will never be able to lock my glass tube again."

---

💡 Mini-Lesson: Why Filesystems Go Read-Only

If you ever see an error like this:

-bash: /usr/bin/date: Input/output error
Could not create temporary file ... Read-only file system

This does NOT mean your filesystem is corrupt. It means the Linux kernel has locked your filesystem into read-only for one of two reasons:

1. The host disk is full — the drive where your VHDX is stored (e.g., drive D:) has no room to write. This is what happened to me.
2. The internal filesystem is corrupt — the ext4 filesystem inside the VHDX found an inconsistency it couldn't automatically repair, so the kernel decided to lock it to prevent further damage.

How to check for the first one:

In PowerShell (Windows):

# Check D: drive space
Get-PSDrive -PSProvider FileSystem | Select-Object Name, @{N='Used(GB)';E={[math]::Round($_.Used/1GB,2)}}, @{N='Free(GB)';E={[math]::Round($_.Free/1GB,2)}}

In WSL:

df -h /mnt/d

How to fix the first one: Free up space on drive D:. That's it. Once there's room, the filesystem can be remounted as read-write:

sudo mount -o remount,rw /

How to fix the second one: Run e2fsck from a rescue distro (as I did yesterday).

How to prevent both: Never let the drive hosting your VHDX fill above 90%. Leave at least 20-30 GB of breathing room. Because the Linux kernel doesn't politely tell you. It just locks your filesystem and says: "Read-only file system."

---

💀 Epilogue: Reflections of a Developer Who Is Also a Carrot Farmer (and a Tiny Angel on a Crescent Moon, and a Glass Tube Locked Shut)

Now, my WSL runs fine. All files are there. My shell is beautiful with powerline icons. My coffee has been replaced with a new one — warm, though no longer the first cup. My D: drive is still 99% full, but I've promised myself I'll clean it. Tomorrow. Or the day after. Or next week. But I will do it.

And here, I want to close this story with something honest.

Throughout my life as a developer, I've experienced many things. Bugs that couldn't be reproduced. Clients asking for revisions at 11 PM. Deadlines that seemed to be made by the devil himself. I once stayed up 48 hours to fix a problem whose solution turned out to be a single character.

But these past two days — two days full of 1603 errors, Catastrophic failure, e2fsck, systemd, read-only filesystem, and a tiny angel on a crescent moon — these two days taught me something no book or tutorial ever could.

They taught me the meaning of vulnerability.

That everything we build — projects, careers, data, memories — can collapse in a single bash command. That a full drive can destroy five years of our life. That 1.5 MB can be the distance between safe and gone. That the universe isn't always fair. That technology, however advanced, still stands on fragile foundations: disk space, electricity, and luck.

And they also taught me the meaning of kindness.

That in the middle of all that chaos, there was an oracle card that said "Embracing Kindness." That there was a tiny angel sitting on a crescent moon, reminding me to forgive myself. That there were carrots in the back garden growing peacefully, not caring whether my WSL was broken.

That evening, I sat on the back porch, staring at my carrot garden. My neighbor passed by the front of the house, carrying a hoe. He saw me, and smiled.

"What's up with you?" he asked. "You look like you just came back from a war."

I smiled. I looked at my carrots. I looked at my closed laptop on my lap. I looked at the sky beginning to darken.

"My WSL broke," I answered casually. "But it's fixed now."

My neighbor didn't understand what WSL was. He didn't know what Linux, ext4, or VHDX meant. He was just a carrot farmer, like me — except he didn't write code. He nodded slowly, looked at my carrots, and said:

"Good. Your carrots look healthy."

And he continued on his way.

I stared at those carrots for a long time. Their green leaves swayed gently in the evening wind. The soil around them was dark and damp. Their roots, invisible, worked in silence to grow downward, piercing the earth, seeking water and nutrients.

"Yes."

"My carrots are healthy. My WSL is healthy. I am healthy."

"Maybe this is what peace feels like."

I close this story with something I will probably repeat to myself for the rest of my life:

We are all glass tubes. Our contents are fragile. Our lids can lock at any moment. And sometimes, we forget to keep space around us so that the key can turn.

We are all carrots. We grow in silence. We don't care whether the digital world above us is in chaos. We only need soil, water, and sunlight.

We are all tiny angels on a crescent moon. We have layered, colorful wings. We just often forget that we have wings.

And sometimes, the only thing we can do is forgive ourselves. And water the carrots.

---

To every developer who has ever lost data:

You are not alone. We have all been there. We have all sat in this chair, staring at a blank screen, feeling like the world is laughing at us.

But you will recover. Your files will recover. And one day, you will tell this story, and someone else will learn from your experience.

That's why we write. That's why we share. That's why we keep moving forward.

Stay sane. Stay backed up. And don't forget to water your carrots.

— jack, developer, carrot farmer, and tiny angel on a crescent moon learning to embrace kindness (and to keep the glass tube unlockable) 🖤🥕🌙

---

P.S.: If anyone knows why Microsoft doesn't provide wsl --repair-filesystem in 2026, please let me know. I'm collecting signatures for a petition. And maybe I'm also considering sending a letter to Satya Nadella. With attached photos of my carrot garden. And a photo of a glass tube locked shut. And a photo of a tiny angel on a crescent moon.

P.P.S.: If you have an idle external drive and want to donate it for my WSL backup, I will be grateful for the rest of my life. In return, I will send you a sack of carrots every harvest. Seriously. I'm not joking. This is not a dark joke. This is a real offer from a developer who just survived digital death twice in two days.

---

🎓 Final Lessons (and You Should Learn Them Too)

1. Disk Space Is the Foundation of Everything

This is the most painful lesson of all. If your drive is 96-100% full, you cannot:

• Backup your VHDX (needs free space).
• Update WSL (MSI needs room to extract).
• Repair the filesystem (ext4 needs room for the journal).
• Install new packages (which triggers corruption).
• Run simple commands like date (because the filesystem becomes read-only).

Disk space is the foundation of all your operations. Nothing else matters more to preserve. Not CPU, not RAM, not GPU. Everything collapses when disk space runs out.

I learned this with the price of 5 years of data. Don't let yourself pay more than I did.

2. BACKUP. YOUR. VHDX.

This is not advice. This is a sacred command. ext4.vhdx is the only container of all your Linux data. If that file disappears, everything disappears. No "restore from git." No "just pull again." Gone. Permanently.

Minimum backup:

• Zip /home/<user> to a .tar.gz archive periodically.
• Push repos to GitHub every day.
• Copy the VHDX to cloud storage even if it's slow.

Better backup:

• Buy an external drive. A 1 TB external drive costs less than a few weeks of carrot harvest.
• Copy the VHDX weekly.

Best backup:

• Snapshot the VHDX before big experiments.
• Automate daily backups via script.

3. Know Where Your VHDX Lives

Most WSL users don't know. The default is:

C:\Users\<user>\AppData\Local\Packages\<distro>\LocalState\ext4.vhdx

Or, if you've moved it:

D:\<your-chosen-location>\ext4.vhdx

Write it down. In a notebook. Screenshot it. Print it. Stick it on the wall. Because in a crisis, you'll forget.

4. Know How to Rescue Your VHDX

Write this down in your notebook:

# 1. Mount the VHDX in a rescue distro
wsl --mount --vhd "D:\Kotonk\WSL\ext4.vhdx" --bare

# 2. Find the device (usually sdd, but DON'T ASSUME!)
wsl -d Debian -u root -- lsblk -f

# 3. Repair the filesystem (REPLACE /dev/sdd with the correct device!)
wsl -d Debian -u root -- e2fsck -f -y /dev/sdd

# 4. Unmount
wsl --unmount "D:\Kotonk\WSL\ext4.vhdx"

# 5. Boot again
wsl -d Ubuntu

# 6. If the filesystem is read-only:
wsl -d Ubuntu
sudo mount -o remount,rw /

5. Prepare a Rescue Distro Before the Crisis

I will never again be without Debian as my "hospital." It's only 300 MB. It functions like insurance.

wsl --install -d Debian

Do it now, not during the crisis.

6. Don't Install Random Scripts in Your Main WSL

Installation scripts from any project — however popular — can leave the filesystem in an inconsistent state mid-way. WSL is a production environment for many of us. Treat it like production:

• Test in a VM first (VirtualBox, Hyper-V, Multipass).
• Or in a container (Docker/Podman).
• Or in a VHDX snapshot that can be rolled back.

7. Don't Trust Tutorials That Use /dev/sdX

I'll repeat: /dev/sdX is a placeholder, not a valid device name. Every time you see it in a tutorial, replace it with the device name that appears in your lsblk.

8. Read-Only Filesystem Doesn't Mean Corrupt

If you see a Read-only file system error, that's NOT the end of the world. It's a Linux kernel defense mechanism. First check if the host drive is full. If yes, free up space, then run sudo mount -o remount,rw /. If it's still read-only, then run e2fsck from a rescue distro.

---

Fin.

---

late post, already in draft for too long... due to another error, and significant other error...