How to fix YUM update failure

— ny_wk

A YUM update failure usually happens when a patching run is interrupted, leaving a half-finished transaction, a corrupted RPM database, and duplicate packages that can trigger a kernel panic on reboot. The fix is to complete the broken transaction, clean up duplicates, rebuild the RPM database, and roll back the failed transaction with yum history undo before you ever restart the server.

The scenario below is the classic one on Red Hat Enterprise Linux 6: you launch yum update over SSH to apply OS patches, the network session drops mid-run, and the update stops dead. The RPM database is left in an inconsistent state, yum history refuses to redo or undo the transaction, and a reboot greets you with a kernel panic because the new kernel was only partially installed. This guide walks through a safe, ordered recovery so you can get the box patched without rebuilding it from scratch.

Why a YUM update failure leaves the system broken

When YUM applies updates it runs a single RPM transaction that installs new package versions, upgrades existing ones, and erases the old ones. That transaction is atomic in intent but not in practice once the process is killed. If the SSH session breaks (or the server loses power) partway through, RPM may have written some package files to disk and updated some database entries, but not all of them.

The result is a mix of three problems that feed off each other:

• An incomplete transaction that YUM knows about but cannot cleanly finish or reverse.
• A corrupted RPM database (the Berkeley DB files under /var/lib/rpm), so lookups return errors or hang.
• Duplicate packages — both the old and new version of the same package are registered, which confuses dependency resolution and, for the kernel, can leave an unbootable entry in the boot loader.

The duplicate kernel is what causes the kernel panic: GRUB tries to boot a kernel whose initramfs or modules were never fully written. That is exactly why the single most important rule of this recovery is do not reboot until the cleanup is finished.

Before you start: snapshot or back up

On a production system, the safest recovery is almost never a manual one. If the host is a virtual machine, take a VM snapshot right now, or restore from a recent backup, before touching anything. A snapshot gives you a guaranteed rollback point; the manual steps below are a repair, not a guarantee.

If you have no snapshot and the box is still up, keep it up. As long as the running system has not been rebooted, it is using the old, working kernel and the old shared libraries already loaded into memory — that is your window to fix things.

Step-by-step fix for the YUM update failure

Run every command as root. Work through them in order and read the output of each before moving on — do not blindly chain them.

1. Complete the interrupted transaction. This is the first and most important command. It finishes whatever RPM left half-done.
   yum-complete-transaction
   The yum-complete-transaction tool ships in the yum-utils package. If it is missing, install it with yum install yum-utils (or copy the RPM from your media/repo if YUM itself is unhappy). Do not reboot after this step — duplicates may still be present and the panic risk remains.
2. Review the transaction history.
   yum history
   This lists every transaction with an ID, the action(s), and how many packages were altered. Note the ID of the failed update — in the example below it is transaction 10, flagged with * (a transaction that did not finish cleanly).
3. Scan for RPM problems.
   package-cleanup --problems
   This reports broken dependencies and packages with missing files. package-cleanup is also part of yum-utils.
4. List any duplicate packages.
   package-cleanup --dupes
   Duplicates are the usual aftermath of a killed upgrade — both versions of a package are registered in the RPM DB.
5. Remove the duplicates, keeping the newest version.
   package-cleanup --cleandupes
   By default this erases the older duplicate and keeps the newer one. Read the list it proposes before confirming, especially if the kernel appears.
6. Verify package integrity.
   rpm -Va --nofiles --nodigest
   This validates the RPM database metadata for every installed package. Skipping file and digest checks (--nofiles --nodigest) keeps it fast and focused on database consistency rather than every changed config file.
7. Rebuild the RPM database.
   rpm --rebuilddb
   This regenerates the Berkeley DB index files under /var/lib/rpm and clears most corruption. (Note: it is two leading dashes, --rebuilddb.) On RHEL 6 it is good practice to remove stale lock files first if commands hang: rm -f /var/lib/rpm/__db.* and then run rpm --rebuilddb.
8. Clear the YUM cache.
   yum clean all
   This wipes cached metadata and headers so the next YUM run pulls a fresh, consistent view of the repositories.
9. Re-check the history.
   yum history
   Confirm the failed transaction is still recorded and identify which transactions you need to undo.

Reading the yum history output

Here is a representative yum history listing from a RHN-managed RHEL 6 host. The failed update is transaction 10:

The Action(s) letters mean: I = Install, U = Update, E = Erase, D = Downgrade, O = Obsolete, R = Reinstall. The symbols in the Altered column are status flags: * marks a transaction that aborted, < and > indicate the RPM database changed outside of YUM before/after the transaction, and E/P trailing letters denote errors or scriptlet problems. The * on transaction 10 is your smoking gun.

Rolling back the failed transaction

With the database rebuilt and duplicates gone, undo the bad transactions, newest first, so dependencies unwind in the right order. In the example, transactions 12 and 11 were partial erases tied to the failed update, so they are undone before reattempting:

1. yum history undo 12
2. yum history undo 11

Undoing in reverse order (highest ID first) matters: a later transaction may depend on the state a newer one left behind, so unwinding top-down avoids dependency conflicts. After the undo completes cleanly, the system should be back to a coherent set of packages — typically with the kernel downgraded one or two levels to the last known-good version.

Now, and only now, it is safe to reboot:

1. reboot

The server should come back up on the older, intact kernel. With a working system again, re-run the update:

1. yum -y update

If no interruption happens this time, the OS upgrades cleanly to the target patch level, including the new kernel.

Common pitfalls to avoid

• Rebooting too early. The number-one mistake. A reboot before duplicates are cleaned and the transaction is finished is what turns a recoverable mess into a kernel panic.
• Patching over a fragile SSH connection. The original failure was caused by an SSH drop. Always run long updates inside screen or tmux (screen -S patch then yum update) so a disconnect does not kill the process.
• Confusing the dash count. It is rpm --rebuilddb with two dashes; a single-dash typo silently does nothing useful.
• Letting --cleandupes remove the wrong kernel. Always read the proposed removal list. You want to keep enough working kernels to boot, not strip the box bare.
• No backup. Treating manual repair as a substitute for a snapshot. It is not — it is a fallback.

How to verify the fix worked

After the system is back up and patched, confirm everything is healthy:

• No duplicates remain: package-cleanup --dupes should return nothing.
• No dependency problems: package-cleanup --problems should be clean.
• The transaction completed: yum history shows the new update with no * flag.
• The right kernel is running: compare uname -r against the latest installed kernel from rpm -q kernel.
• Updates are current: yum check-update reports nothing pending (exit code 0).

If any of these still show errors after a full pass, stop improvising and open a support case with Red Hat. On a system still under subscription, Red Hat Technical Support can inspect the RPM transaction logs and guide a clean recovery far more safely than repeated manual guesses.

Important: RHEL 6 is end-of-life — use DNF on modern systems

The commands above target RHEL 6, which reached the end of its Extended Life-cycle Support and is no longer maintained. If you are running a current release (RHEL 8, 9, or 10), YUM is now a thin compatibility wrapper around DNF, and the equivalent recovery commands are slightly different:

• Complete an interrupted transaction: dnf-utils provides the logic, but the modern path is usually dnf history redo <ID> or simply re-running dnf update.
• Roll back: dnf history undo <ID> and dnf history rollback <ID>.
• Find duplicates: dnf repoquery --duplicates, then remove with dnf remove --duplicates.
• The RPM database moved to a SQLite backend, so rpm --rebuilddb is rarely needed; corruption is handled by rpm --rebuilddb still working as a no-op-friendly fallback.

The principle is identical across versions: finish the transaction, clean duplicates, then roll back before rebooting. Only the tool name changes.

Key Takeaways

• Never reboot a server with a half-finished YUM transaction — that is what triggers the kernel panic.
• Start every recovery with yum-complete-transaction, then clean duplicates with package-cleanup --cleandupes.
• Rebuild a corrupted RPM database with rpm --rebuilddb and clear the cache with yum clean all.
• Undo failed transactions newest-first using yum history undo <ID>, reboot onto the older kernel, then re-run yum -y update.
• A VM snapshot or recent backup beats any manual fix; patch inside screen/tmux to prevent SSH drops in the first place.

Frequently Asked Questions

What does yum-complete-transaction do?

It finishes a YUM/RPM transaction that was interrupted, completing the install, upgrade, or erase steps RPM had already started. It reads the saved transaction files in /var/lib/yum and reconciles the package state so YUM is usable again. Run it before anything else and do not reboot immediately afterward.

Why does my server kernel panic after a failed yum update?

Because the new kernel package was only partially installed — its initramfs or modules were never fully written before the update stopped. The boot loader still points at that broken kernel, so booting it panics. Clean up the duplicate kernel and roll back to the previous version before you reboot.

How do I undo a yum update?

Use yum history to find the transaction ID, then yum history undo <ID> to reverse it. Undo multiple transactions newest-first. On RHEL 8 and later the command is dnf history undo <ID>, or dnf history rollback <ID> to return the system to the exact state after a chosen transaction.

Is it safe to run rpm --rebuilddb on a production server?

Yes — it only rebuilds the RPM database index files and does not change installed packages. It is a standard step for fixing database corruption. To be safe, back up /var/lib/rpm first (for example cp -a /var/lib/rpm /var/lib/rpm.bak) so you can restore the original DB if anything goes wrong.

For more Linux sysadmin walkthroughs and patching tips, subscribe on YouTube @explorenystream.