## TL;DR
yum history undo is not a time machine: it must re-download the exact older packages, and repos only carry current versions. When undo fails, read its output for the missing package, then downgrade the key packages manually from the vault or a local repo snapshot, or undo the transactions in reverse order (newest first).

```text
yum history undo failed error
```

## Use this when
- yum history undo [id] fails with errors about packages not available or already installed versions.
- The transaction to undo installed a kernel or glibc update that broke the app.
- A later transaction was applied on top of the one you need to undo.

## Not for this skill when
- The change to revert was a config file edit. Restore the file; package history will not help.
- The system uses dnf on RHEL 8 and later. The same concepts apply, but use dnf history commands there.

## Steps
1. List history and confirm the exact transaction ID and what it changed with yum history info. Verify: the transaction contents match the change you want to reverse
2. Attempt the undo and capture the exact package and version it says is unavailable. Verify: the blocking package is named
3. Undo any newer transactions first if they depend on this one, working newest to oldest. Verify: each intermediate undo completes, or you decide on a manual downgrade instead
4. For the unavailable package, fetch the exact older version from the release vault, a satellite snapshot, or your local repo mirror and downgrade it with yum downgrade. Verify: the older version installs and the dependent packages resolve
5. Verify the application or service is healthy on the reverted set, and record why the undo path failed. Verify: health checks pass and the incident note is written

## Variant phrasings
### yum history undo package not available error
The blocking-error phrasing.
### downgrade package version yum older version repo gone
The manual fallback phrasing.
### undo yum update transaction reverse order
The ordering phrasing.

Compatibility: Compatibility: yum 3 on RHEL 7 and CentOS 7 primarily; dnf history behaves similarly on RHEL 8 and later.

## Why it happens
History undo replays a transaction backwards using packages from the currently enabled repos. Distribution repos are moving targets: when a newer update ships, the older RPM is removed from the repo, so the exact version an undo needs often no longer exists anywhere yum can reach. Snapshotted internal repos and vault archives are the only reliable sources for old versions.

## Edge cases / pitfalls
- Fleets that snapshot repos monthly can undo almost anything; fleets on public mirrors often cannot. Treat that as an architecture input.
- Undoing a transaction that included a kernel is safe only while the running kernel is not the one being removed; reboot onto the kept kernel first.
- Database migrations applied by the newer package do not roll back with the package; check the application data layer separately.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nSu09SRdQA6LF43m87BBnw