Rolling Back Package Updates on RHEL-Family Systems with DNF History

Every dnf run leaves a numbered record: which packages changed, from which versions, and at whose hand. That ledger is not audit trivia — it is a working undo system built into the distribution. When Tuesday's routine security update breaks Thursday's deploy, you can rewind precisely instead of rebuilding the server or hand-downgrading rpms and hoping the dependency graph forgives you.

Every Transaction Has a Number

sudo dnf history
sudo dnf history info 27

The list shows each transaction's ID, the command line that caused it, the date, and the action counts. The info form expands one row into the full package-by-package delta: what was installed, upgraded, or erased, with old and new versions. The database behind it lives under /var/lib/dnf, survives reboots and upgrades, and reaches back to the day the system was built — the oldest entry is usually the OS installation itself. Find the transaction that introduced the bad state before you reverse anything — the culprit is not always the most recent entry, especially when a regression surfaces days after the update that caused it.

Undo a Single Transaction

sudo dnf history undo 27

history undo inverts one transaction exactly: packages it upgraded return to their previous versions, packages it installed are erased, packages it erased come back. It is the surgical tool, and it has two boundaries. First, the previous versions must still be obtainable from your enabled repos — an older version the mirror no longer carries cannot be restored, and if undo complains about missing packages, re-enable the repo that shipped them or restore a snapshot instead of fighting the mirror. Second, non-package actions travel with you: config edits you made alongside the update, service restarts, and database migrations are yours to reverse.

Roll Back to a Known-Good Point

When several transactions are suspects or you simply want Tuesday morning back, rewind everything after a chosen ID.

sudo dnf history rollback 18

This reverts all transactions numbered above 18, returning the package set to the exact state after transaction 18 completed. It is the blunt instrument: anything installed since then, wanted or not, disappears. That makes it ideal for a staging box wrecked by a bulk upgrade, and wrong for a machine where unrelated work has happened in the meantime — read the history list before you choose undo versus rollback, and snapshot first when data is anywhere near the blast radius.

What Rollback Does Not Fix

• Config files: RPM stages edited configs as .rpmsave or .rpmnew; undo restores package-owned files, not your hand edits in /etc
• Data: schema migrations, uploads, and logs are untouched by design — package state and data state drift apart, and only you can reconcile them
• Kernels: installed kernels are protected by installonly_limit and survive rollbacks; boot the previous kernel from the GRUB menu if the new one misbehaves
• Automation: cron jobs and deploy pipelines that re-apply changes will win the next race — fix the cause, not just the state

Make Update Day Boring

sudo systemctl --failed
sudo dnf history

The rollback path only works if history exists and old versions remain reachable. Three habits keep it that way. Apply security errata automatically with dnf-automatic but run bulk upgrades manually, so you always know which transaction to blame. Snapshot before major upgrades so a restore is available when data, not just packages, is involved. And after every upgrade, check systemctl --failed plus the one service you actually care about before closing the ticket.

Takeaway: dnf history turns package changes from one-way doors into reversible ones — the difference between a five-minute recovery and a rebuild. Practice the undo path on a disposable instance: Netbay deploys VPS in under 60 seconds, and rewinding a broken transaction is far better learned there than at 2 a.m. on production — netbayhosts.in.