AlmaLinux Package Rollback: How dnf history undo Works and Where It Fails

When an update breaks an AlmaLinux host, the fastest supported rollback is usually not a full image restore. It is reversing the specific dnf transaction that introduced the bad packages. The command dnf history undo <transaction-id> replays the inverse RPM set for that transaction, removing packages that were installed and reinstalling packages that were removed or downgraded. This works because dnf records every package action in a local history database, including the package names, versions, repository labels, and scriptlets involved.

How dnf history Records Package Changes

On AlmaLinux, dnf maintains a transaction history in the system RPM database. Each time you install, update, or remove packages, dnf writes a numbered transaction entry. You can inspect this log with dnf history list, which shows the transaction ID, date, user, and a summary of actions such as "Install" or "Upgrade". A more detailed view is available with dnf history info <transaction-id>, which lists every package touched by that transaction, its architecture, and the repository it came from.

The undo operation does not simply delete files. It calculates an inverse RPM (Red Hat Package Manager, the package format used by AlmaLinux) transaction: packages that were installed are removed, packages that were erased are reinstalled at their previous version, and packages that were upgraded are downgraded. DNF then replays the relevant scriptlets—small maintainer scripts that run before or after package installation or removal—in reverse order where possible. This makes dnf history undo a supported rollback path for package-level changes, but it is strictly limited to what RPM and dnf can track.

Worked Example: Undoing a Bad Update

Suppose you updated a web server stack on AlmaLinux 9 and a new package version introduced a regression. The first step is to identify the transaction. Run the following as root or with sudo:

sudo dnf history list

Look for the transaction that matches the time of the update. Note its ID. Before undoing anything, inspect the transaction to confirm what will be reversed:

sudo dnf history info 42

Replace 42 with your actual transaction ID. Review the output for the package list, any "Obsoleting" entries, and whether configuration files were modified. If the transaction looks correct, reverse it:

sudo dnf history undo 42

dnf will resolve the inverse dependencies and present a transaction summary. Confirm the prompt to proceed. After the command finishes, verify that the target packages are back to their previous versions using rpm -q <package-name> or dnf list installed <package-name>.

If you need to undo every transaction after a certain point, dnf history rollback <transaction-id> reverses all transactions newer than the specified ID. Use this only when the host has no intervening transactions that later services depend on. On a long-running production host, undo of a single transaction is safer than a broad rollback.

What dnf history undo Does Not Reverse

The rollback covers RPM-managed package content and scriptlets. It does not restore arbitrary file edits made under /etc after installation, data written to /var, kernel bootloader state, SELinux (Security-Enhanced Linux) policy customizations, or changes made by non-dnf tools such as pip, npm, or manual rpm --force installs. If an application scriptlet ran database migrations or created new data files, those side effects remain in place.

Configuration files are a common source of confusion. When a package update replaces a configuration file that you have modified, RPM may leave the old file as <file>.rpmsave and install the new default as <file>, or it may leave the new default as <file>.rpmnew and keep your modified file. An undo will not automatically merge or restore these files. After any undo, search for .rpmsave and .rpmnew files in affected directories before restarting services.

Common Mistakes That Break Rollback

• Assuming undo restores modified configs: RPM tracks configuration files specially, but it does not guarantee your edited version is restored. Check for .rpmsave and .rpmnew files.
• Undoing across dependency chains: If a later transaction obsoleted or renamed a package, the inverse resolution for an earlier undo can fail. Run dnf history info first to see if the transaction involves obsoletes or renamed packages.
• Using rollback on a busy host: dnf history rollback undoes everything after the target transaction. If later transactions installed security updates or dependencies for running services, a rollback can break them.
• Mixing manual RPM operations: Packages installed with rpm --force or outside dnf may not appear as normal dnf history entries, making the transaction log incomplete and undo unreliable.

Version Sensitivity and Practical Verification

The exact history schema, undo semantics, and plugin behavior can differ between AlmaLinux major and minor releases and RHEL-compatible streams. Before relying on undo in production, verify the behavior on the exact AlmaLinux minor release and architecture you run.

A safe verification path on a disposable VM is to install a harmless package, remove it, then undo the install transaction and confirm the package is gone and its dependencies are cleaned. Repeat this on your production minor release. Also review /var/log/dnf.rpm.log alongside dnf history info output to understand how scriptlets and configuration files were handled during the original transaction.

Treat dnf history undo as a targeted package rollback tool, not a substitute for backups. It cannot recover data files, reverse arbitrary file edits, or guarantee that dependency resolution will succeed if newer packages have been removed from repositories. Always test the undo in a staging environment that matches production before using it during an incident.