Managing Linux packages with dnf history and rollback

Package updates are essential for security and reliability on RHEL, CentOS Stream, Fedora, Rocky Linux and AlmaLinux systems. They can also introduce an incompatible library, a changed configuration file or a service failure. The dnf history feature records package transactions, making it possible to inspect changes and reverse selected operations when repository versions and dependencies still permit it.

This approach is especially useful for administrators managing systems across Australian time zones. A package change scheduled for a Sydney web server may affect teams in Perth, while daylight saving can shift maintenance windows between Melbourne and Brisbane. The commands below provide a practical way to investigate package activity, plan a recovery and reduce downtime.

How dnf records package transactions

Every install, upgrade, removal or distribution synchronisation performed through DNF is assigned a transaction ID. Start with a concise history view:

sudo dnf history

The output usually shows the ID, date, action, number of altered packages and the user who initiated the transaction. To inspect one operation in detail, replace 42 with the relevant ID:

sudo dnf history info 42

This displays installed, upgraded, downgraded and erased packages. It can also reveal whether a change was made manually or by an automated management process. For a broader audit, sudo dnf history userinstalled lists packages explicitly installed by an administrator rather than pulled in only as dependencies.

The history database is local to the machine. It does not replace configuration management, backups or monitoring, and it may not fully describe changes made outside DNF. Keeping regular records is particularly valuable where the Linux tutorials are used alongside internal runbooks for RHEL-family administration.

Inspect a transaction before reversing it

A rollback should begin with evidence, not a blind command. Compare the transaction timestamp with service alerts, system logs and deployment records. On a production host, check whether the package change affected Nginx, systemd units, PHP, database clients or kernel components.

sudo dnf history list
sudo dnf history info 42
rpm -qa --last | head -20

Review repository availability before attempting a reversal:

sudo dnf repolist
sudo dnf list --showduplicates package-name

Older package versions may have disappeared from an active mirror. This is common when a repository moves through its normal lifecycle, or when a RHEL subscription repository no longer exposes a required build. Australian organisations using local cloud regions in Sydney or Melbourne should also account for repository access controls, proxy rules and outbound filtering.

A history record identifies what DNF did; it does not guarantee that the previous state can be recreated. Kernel changes, database migrations and application data changes need separate recovery procedures. If a transaction changed data formats, reversing the RPM packages alone may leave the service unusable.

Undo one package transaction

To reverse a single transaction, use:

sudo dnf history undo 42

DNF calculates the opposite operation. Packages installed by transaction 42 may be removed, while upgraded packages may be downgraded to their earlier versions. Review the proposed transaction carefully, then confirm only when the package set makes sense.

For a non-interactive maintenance script, -y can be added, but it is safer to test interactively first:

sudo dnf history undo 42 --assumeno
sudo dnf history undo 42

The --assumeno option previews the operation and answers “no” automatically. A dependency conflict can prevent the undo, especially if later packages require the newer version. In that case, do not force removal casually. Identify the dependent packages, test in a staging environment and consider restoring a complete virtual machine snapshot.

Services should be checked after the operation:

sudo systemctl daemon-reload
sudo systemctl restart nginx
sudo systemctl status nginx --no-pager
sudo journalctl -u nginx -b --no-pager

Restart only services relevant to the changed packages. A rollback performed during an Australian peak trading period, such as a weekday morning for a Melbourne retailer, should include a documented outage window and a second administrator available to verify the result.

Roll back several later transactions

dnf history rollback reverses all transactions performed after a selected transaction ID. For example:

sudo dnf history rollback 42

If transaction 42 was the last known-good state, DNF attempts to undo transactions 43 and later. This is broader than history undo, so inspect the history first and ensure that the selected point is correct. A rollback may include unrelated security updates, package removals or dependency adjustments made after the incident.

A safer workflow is to capture the current state, preview the proposed action and record the result:

rpm -qa | sort > packages-before-rollback.txt
sudo dnf history info 42
sudo dnf history rollback 42 --assumeno

For Australian government or regulated workloads, package activity should fit the organisation’s change-control process and security records. The Privacy Act 1988 may apply where logs contain personal information, while the Australian Cyber Security Centre’s Essential Eight emphasises timely patching. A rollback should therefore be treated as a temporary risk decision, followed by a controlled security update once the cause is understood.

Checks and rollback safeguards

Before changing a live system, confirm the following:

• The transaction ID and affected package list are correct.
• Required repositories or subscription channels are available.
• A recent VM snapshot, filesystem backup or rebuild path exists.
• The service owner and maintenance window are recorded.

After the rollback, verify these areas:

• Package versions and enabled repositories.
• Service status, listening ports and application health.
• Kernel selection and boot behaviour after a reboot.
• Logs, monitoring alerts and user-facing functions.

Command	Purpose	Scope
dnf history	Show transaction summaries	Read-only
dnf history info ID	Inspect one transaction	Read-only
dnf history undo ID	Reverse one transaction	Single transaction
dnf history rollback ID	Reverse later transactions	Multiple transactions
dnf history redo ID	Repeat a previous transaction	Reapplies recorded action

dnf history redo ID can be useful after testing a known-good change, although repository differences may alter the result. On Fedora and CentOS Stream, package versions can move quickly; on RHEL, repository channels and entitlements have a stronger effect on what can be installed. Rocky Linux and AlmaLinux administrators should check their configured mirrors and repository priorities before relying on an old transaction.

The key point is that DNF history is a recovery aid, not a complete disaster-recovery system. Inspect the transaction, verify repository availability, preview the dependency changes and test affected services. When package rollback is combined with backups, monitoring and disciplined change records, administrators can restore a stable Linux state with far less guesswork.