The Upgrade Finished Four Days Ago — My Directory Names Never Got The Memo 🦴

On 5 May 2026, dnf system-upgrade swapped 4,646 packages in eleven minutes, twenty-one seconds. When it finished, there was not one fc43 kernel left on this machine. I checked.

Four days later I went digging, and found a path that still insisted the machine was running Fedora 43.

The Dig 🔍

$ find ~ -maxdepth 3 -type d \( -iname '*fedora43*' -o -iname '*fedora-43*' \)
~/TuneUPScripts/OMEN-Fedora-43

One hit. One directory, on a machine that hadn’t been Fedora 43 for four days.

Here’s the discipline I want to hold myself to, because I’ve been burned by my own memory before: every date in this post is a filesystem timestamp, not a recollection. stat -c '%w' gives you a file’s birth time, and birth times don’t flatter anybody. If a date below is wrong, the disk is wrong.

Fossil #1: A Fedora 44 Script Hiding In A Fedora 43 Folder 📜

Inside OMEN-Fedora-43/ sits a file called 90_prepare_fedora44_upgrade.sh.

Read that again. The script that prepares the Fedora 44 upgrade lives in the folder named for the release it was about to leave. The naming equivalent of packing your bags inside the house you’re moving out of.

$ stat -c '%w' ~/TuneUPScripts/OMEN-Fedora-43/90_prepare_fedora44_upgrade.sh
2026-05-05 21:03:38.889318444 +1000

Born 21:03:38, and its modify time is identical to the second — it was written once and never touched again. Inside it:

TARGET_RELEASE=44
...
echo "Preparing Fedora ${TARGET_RELEASE} upgrade for this OMEN Fedora setup."

And from my shell history, 21:05:42:

$ sudo bash /home/bitzy/TuneUPScripts/OMEN-Fedora-43/90_prepare_fedora44_upgrade.sh

Two minutes four seconds after it was written. Ten minutes and thirty-four seconds before the download started at 21:16:16.

So the sequence is:

The upgrade itself took eleven minutes. The folder name took none of them.

Fossil #2: A Snapshot From Fifteen Minutes Before The World Ended 🪟

$ stat -c '%w' ~/.config/save-my-windows/layout.json
2026-05-05 21:01:39.588448308 +1000

Written 21:01:39 — fourteen minutes and thirty-seven seconds before the download began. Its content is one line that matters:

"Start Here.txt (~/TuneUPScripts/OMEN-Fedora-43) - Text Editor"

A saved window layout: a text editor parked on a Start Here.txt inside the Fedora 43 folder. The modify time is still 21:01:39. Three boots, 4,646 packages, one complete release change — and this file was never rewritten. It’s a photograph of the machine as it was at 21:01 on 5 May, still sitting on disk four days later, looking at a directory that no longer described the system it was in.

That’s the part that got me. Not that the file survived — plenty of files survived. It’s that nothing flagged it. No warning, no log line, no “hey, this path is from the old release.” The system simply has no mechanism for noticing.

Fossil #3: The deprecated/ Nobody Deprecated 🗄️

$ stat -c '%w' ~/TuneUPScripts/OMEN-Fedora-43/deprecated
2026-04-25 19:51:54.154252049 +1000

Two files went in eighty-one seconds later, both born the same minute — 2026-04-25 19:53:15 — during the April tuning week, ten days before the upgrade:

• 90_bootup_numlock_wrong_cpu_service.sh — 489 bytes
• 95_enable_numlockx_system_service_wayland.sh — 523 bytes

Two abandoned attempts at making NumLock behave at boot, shelved in a folder whose name is the entire extent of the thinking that went into it. The folder’s own modify time still reads 2026-04-25 19:53:15 — nothing has been added or removed since. The upgrade didn’t change that either.

Why dnf Can’t Help You Here 🧯

This is the part nobody warns you about after a release upgrade.

dnf system-upgrade is transactional about packages. It resolves dependencies, verifies signatures, rolls back on failure. It is genuinely excellent at its job — it proved that on 5 May.

But it does not know that a directory exists. Directories aren’t in the transaction. Neither are:

• Path strings inside config files — a JSON blob pointing at OMEN-Fedora-43
• Your own naming decisions — that folder name was mine, and I made it when Fedora 43 was true
• Muscle memory — the cd I’d type without thinking
• The label on the tin — TuneUPScripts/ hasn’t been just “tunes” since roughly December

So the system ends up split into two eras, and the seam runs entirely through your stuff. The OS is honest — rpm -q kernel | grep -c fc43 returns 0 — but everything downstream of the OS is running on stale labels, and there is no tool that audits labels.

Dig For Your Own 🦴

Two commands, both safe, both read-only:

# 1. Directory names carrying an old release
$ find ~ -maxdepth 3 -type d \( -iname '*fedora43*' -o -iname '*fedora-43*' \)
~/TuneUPScripts/OMEN-Fedora-43

# 2. Config files still referencing it
$ grep -rl "OMEN-Fedora-43" ~/.config/save-my-windows
~/.config/save-my-windows/layout.json

Swap fedora43 for whatever your previous release was — f43, 43, ubuntu2404, win10. The pattern is always the same: something in your filesystem was named at a moment when a statement about your system was true, and the statement has since expired without anyone editing the file.

If you want to know when a fossil formed, that’s stat -c '%w', and it’s the most useful command in this entire post:

$ stat -c '%w' ~/TuneUPScripts/OMEN-Fedora-43
2026-04-25 21:29:54.519465576 +1000

What Windows Does With Its Own Fossils 🪟

Here’s the thing I couldn’t stop thinking about while doing this.

Windows has exactly this problem, and it knows. After an in-place upgrade, Windows drops C:\Windows.old\ on your drive — a folder named for the release you just left, full of the previous installation. It’s the same fossil I found, except Microsoft went and gave it a name and an address.

And then Microsoft put a timer on it. Per Microsoft’s own support docs, your previous version of Windows is automatically deleted ten days after you upgrade. If you want it gone sooner, Disk Cleanup has a checkbox for it — Previous Windows installation(s).

Ten days. An automatic cleanup, and a manual escape hatch with a UI.

My OMEN-Fedora-43/ folder has no timer, no Disk Cleanup entry, and no mechanism by which anything will ever remove it but me. Fedora gave me a cleaner system and then declined to have an opinion about my folder names — which, honestly, is the correct thing for an operating system to do. It’s just a very funny contrast when the OS you fled did schedule the cleanup for you.

Windows is the friend who throws out your old things when you’re not looking. Fedora is the friend who hands you the box and says this is your problem now.

I know which one I prefer. I’d just like the box to be a little smaller.

Add These To The Cheat Sheet 📋

Straight into the running Fedora cheat sheet, alongside the shell diagnostics section:

Four days after the upgrade, the machine was perfect and the names were wrong. That asymmetry is the whole story: the upgrade owns the packages, and I own the naming.

It’s not a bug, and it isn’t going to get fixed by anyone upstream. It’s just the part of the job that stays yours — the part where a directory you named in April quietly outlives the truth that made the name make sense.

I’m leaving OMEN-Fedora-43/ exactly where it is. Not out of laziness. It’s the only timestamped record I have of when the tuning happened, and stat -c '%w' has already proven more useful than a tidy name would be.

What’s the oldest fossil in your home directory? Run the find above and tell me what it drags up. 👇