Fedora 43 → 44: 4,646 Packages In Eleven Minutes 🚀

21:18:43. I typed one command and walked away.

$ sudo dnf5 offline reboot

21:31:27 — twelve minutes later — the machine came back up on Fedora 44.

No drama. No rollback. No “your system has encountered an error.” Just a progress bar scrolling past in a boot environment I never saw, because by then I was in the other room.

I’ve read a hundred upgrade posts that are really just lists of package names. This one’s the timeline, the two numbers I got wrong, and the one warning line worth reading.

What Actually Happened 📋

Every timestamp below is pulled straight out of this machine’s journal, local time (AEST), on 5 May 2026:

From first instruction to Complete!: 11 minutes 21 seconds.

And there’s a subtlety in that table I didn’t appreciate until I read it back. Count the boots.

Three Boots, Not One 🥾🥾🥾

A normal upgrade reboots twice. dnf system-upgrade reboots three times, and the middle one isn’t a system you’ll ever log into:

1. 16:41 → 21:19:14 — your regular Fedora 43 session, ending on command.
2. 21:19:27 → 21:31:13 — a throwaway upgrade environment. It boots the old fc43 kernel, runs the whole transaction, and never reaches a login prompt. This is the twelve minutes that does the work.
3. 21:31:27 → — Fedora 44, on 6.19.14-300.fc44.

The reason for the middle boot is the whole design: you can’t safely replace the packages of a running system, so dnf swaps you into a minimal environment first. It’s the same instinct as not renovating the bathroom you’re standing in.

If you’re coming from Windows, the mental model is Windows Update’s “Configuring updates, don’t turn off your computer” screen — except you get to choose exactly when it runs, and it tells you what it’s doing.

The Two Numbers I Got Wrong 📉

This is the part I’d have gotten away with if I hadn’t gone back to the log.

Wrong number one: “1,474 packages.”

Somewhere I’d written down that this upgrade touched 1,474 packages. Here’s the line I almost certainly read:

May 05 21:23:44 dnf5[2421]: [1474/4646] Upgrading libvirt-daemon-dr  100% | ...

That [1474/4646] is not a total. It’s a progress counter — package 1,474 of 4,646, frozen mid-scroll at the moment the line got captured. The real number is the denominator.

4,646 packages. Three times the figure I had.

Worth remembering every time you read a log line out of context: [N/TTTT] means where you are, not how much there is. The total is the part after the slash.

Wrong number two: the clock.

I’d also recorded “21:27” as the upgrade time. There’s nothing at 21:27 except [2566/4646] — more progress bar. The events that matter are 21:19:51 (start) and 21:31:12 (Complete!).

I mention both because this blog’s whole premise is that your machine will tell you the truth if you actually read it. It only works if I read it too.

The Warning Worth Reading ⚠️

Right before it finished:

Warning: skipped OpenPGP checks for 2353 packages from repositories:
copr:copr.fedorainfracloud.org:lihaohong:yazi,
copr:copr.fedorainfracloud.org:monkeygold:nautilus-open-any-terminal,
copr:copr.fedorainfracloud.org:scottames:ghostty,
docker-ce-stable, fedora, fedora-cisco-openh264,
rpmfusion-free, rpmfusion-free-updates,
rpmfusion-nonfree, rpmfusion-nonfree-updates, updates

2,353 packages went in without signature verification. dnf’s default behaviour is to skip OpenPGP checks entirely, and it says so — once, in a wall of scrolling text, half a second before it reboots.

This isn’t a bug or a scare story. It’s Fedora’s default, and most of those repos are ones I deliberately added myself — the COPR builds of yazi, ghostty and nautilus-open-any-terminal are exactly the reason this machine feels like mine. Ghostty’s been on here since January.

But it’s a good reminder that “it worked” and “it was verified” are two different claims, and only one of them is in that log line.

Meanwhile, Two DNFs Argued 🍿

Four seconds before the upgrade started:

21:19:50 systemd[1]: Starting dnf-system-upgrade.service - System Upgrade using DNF...
21:19:50 systemd[1]: Starting dnf5-offline-transaction.service - Offline upgrades/transactions using DNF 5...
21:19:50 dnf-3[2420]: another upgrade tool is running. exiting quietly.
21:19:51 dnf5[2421]: Starting system upgrade. This will take a while.

dnf-3 (the Python dnf 4 stack) and dnf5 (the Rust rewrite Fedora is migrating to) both tried to start. dnf-3 looked around, decided something else had the lock, and bowed out — quietly, as promised.

dnf5 did the work.

Honestly? I put that in because it’s the most Fedora sentence I’ve read all year. Two implementations of the same tool, both installed, one politely stepping aside for the other. Nothing broke. It just… sorted itself out.

What Changed Underneath 🔧

Some texture from the transaction, since package lists are boring but weird package lists aren’t:

• The old kernels were removed, not kept. The upgrade environment stripped 6.19.12-200.fc43 and friends before laying down the new ones — which is why today:

  $ rpm -q kernel
  kernel-7.2.4-200.fc44.x86_64
  kernel-7.2.7-200.fc44.x86_64
  kernel-7.2.8-200.fc44.x86_64
  $ rpm -q kernel | grep -c fc43
  0

  Zero fc43 kernels left on the machine. The old release is genuinely gone, not lingering in /boot eating space.

• A handful of packages downgraded. gdk-pixbuf2 went from 2.44.6^really2.44.4-1.fc43 to a clean 2.44.4-2.fc44. Same software, tidier version string — Fedora unwinding one of its ^really version-pinning consolations.

• And yes, there was noise. Roughly twenty lines of snapd/snap-device-helper: No such file or directory from udev, all for Cura Slicer. Cosmetic — a snap hook firing against binaries that aren’t there — and the upgrade rolled straight past it.

The Command, If You Want It 📝

# 1. Download the new release (safe to do while running)
sudo dnf system-upgrade download --releasever=44 --best

# 2. Reboot into the upgrade environment
sudo dnf5 offline reboot

Step 1 downloads and prepares. Step 2 does the actual work while the system is quiescent. You can also split it with --downloadonly if you want the packages staged overnight.

The important part is that step 1 is reversible — nothing changes until you run step 2. That’s the safety valve Windows Update never gave you.

Add These To The Cheat Sheet 📋

Straight into the running Fedora cheat sheet, alongside last month’s shell diagnostics section:

The Windows refugee in me still expects an upgrade to be an event — an afternoon cleared, a progress screen watched, a small prayer. This was eleven minutes and a coffee.

No ceremony. Just a machine that logged every second of it, and would tell me the whole story — down to the individual package — if I bothered to open the log.

Did your Fedora 44 upgrade go quietly, or did it give you a story? Drop a comment below. 👇