APT rollback — quick reference
APT has no apt history undo like YUM on RHEL 7. Use the log to see what changed, then downgrade, remove, or restore from backup.
Read what changed
| When to use | Command |
|---|---|
| Recent install/remove transactions | `grep -E '^(Start-Date |
| Same log with older rotations | zgrep Start-Date /var/log/apt/history.log* |
| Detailed per-package actions | `grep -E '^(Start-Date |
| When a package was last upgraded | grep -w 'package_name' /var/log/apt/history.log |
Downgrade and hold
| When to use | Command |
|---|---|
| List installable versions | apt-cache policy package_name |
| Install a specific older version | sudo apt install package_name=version |
| Preview downgrade without applying | sudo apt install package_name=version --simulate |
| Block future upgrades for a package | sudo apt-mark hold package_name |
| Release a hold | sudo apt-mark unhold package_name |
| List held packages | apt-mark showhold |
Reverse a recent install
| When to use | Command |
|---|---|
| Remove packages from a bad install | sudo apt remove package1 package2 |
| Remove and delete config files | sudo apt purge package1 package2 |
| Drop unused dependencies | sudo apt autoremove |
APT rollback — command syntax
There is no separate apt-rollback binary. Rollback workflows combine:
/var/log/apt/history.log # transaction summary (install, remove, upgrade blocks)
/var/log/apt/term.log # detailed apt output per run
apt-cache policy PKG # installed and candidate versions
apt install PKG=VER # pin install to one version from the policy table
apt-mark hold|unhold PKG # freeze version across apt upgradeFor full-system restore after a bad upgrade, use filesystem snapshots (LVM, btrfs, cloud volume backup) — outside APT itself.
APT rollback — command examples
Essential See recent APT transactions
The history log records each apt run with start time, command line, and package lists.
Run the command:
grep -E '^(Start-Date|Commandline|Install|Remove|Upgrade)' /var/log/apt/history.log | tail -24Sample output:
Start-Date: 2026-07-01 14:14:41
Commandline: apt-get install -y traceroute tmux
Install: libevent-core-2.1-7t64:amd64 (2.1.12-stable-10, automatic), traceroute:amd64 (1:2.1.6-1), tmux:amd64 (3.5a-3)
End-Date: 2026-07-01 14:14:46
Start-Date: 2026-07-01 14:37:50
Commandline: apt-get install -y stress rpm
Install: rpm:amd64 (4.20.1+dfsg-1), stress:amd64 (1.0.7-1), ...Match the timestamp to when the problem started, then note package names from Install, Remove, or Upgrade lines.
Essential Find installable versions for downgrade
Before downgrading, check which versions exist in your configured repositories.
Run the command:
apt-cache policy tmuxSample output:
tmux:
Installed: 3.5a-3
Candidate: 3.5a-3
Version table:
*** 3.5a-3 1001
1001 http://archive.ubuntu.com/ubuntu plucky/main amd64 PackagesPick a version from the table (not only Installed / Candidate). If only one version exists, you need an older suite mirror or snapshot — APT cannot invent packages.
Essential Preview installing an older version
When multiple versions exist, simulate before changing the system.
Run the command:
sudo apt install tmux=3.5a-3 --simulateSample output:
NOTE: This is only a simulation!
apt needs to be run as root to make changes.
tmux is already the newest version (3.5a-3).
Summary:
Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0Replace tmux=3.5a-3 with the older version from apt-cache policy. Read the Removing / Installing lines for dependency side effects.
Common Hold a package at the current version
After downgrading, hold stops apt upgrade from bumping the package again.
Run the commands:
sudo apt-mark hold tmux
apt-mark showholdSample output:
tmux set on hold.
tmuxRelease with sudo apt-mark unhold tmux when you are ready to upgrade that package again.
Common Undo a fresh install by removing packages
If history.log shows a single apt install you regret, remove those package names (not always every automatic dependency).
Run the commands:
sudo apt remove --simulate traceroute
sudo apt remove traceroute
sudo apt autoremove --simulateSample output:
The following packages will be REMOVED:
traceroute
Summary:
Upgrading: 0, Installing: 0, Removing: 1, Not Upgrading: 0autoremove drops dependencies nothing else needs. It does not restore files from upgraded packages.
Common Search rotated history logs
Long-running servers rotate history.log into .gz files.
Run the command:
zgrep -h "Commandline: apt" /var/log/apt/history.log* | tail -10Sample output:
Commandline: apt-get install -y traceroute tmux
Commandline: apt-get install -y stress rpmUse the matching Start-Date block in the uncompressed or compressed file for full package lists.
Common Confirm what is installed now
Cross-check history.log against the live system.
Run the command:
dpkg -l tmux traceroute 2>/dev/null | grep ^iiSample output:
ii tmux 3.5a-3 amd64 tmux terminal multiplexer
ii traceroute 1:2.1.6-1 amd64 Traces the route taken by packetsii means installed and configured. Compare versions with the log before you downgrade or remove.
Advanced See what a full upgrade would change
Before rollback, know what apt upgrade would still change.
Run the command:
apt list --upgradable 2>/dev/null | head -10Sample output:
Listing...An empty list after Listing... means nothing is pending upgrade. Combine with holds so a fixed package stays pinned during future upgrades.
Advanced What APT cannot do (vs yum history)
RHEL YUM can yum history undo ID. APT has no equivalent single command.
On Ubuntu you combine:
- Read
history.logfor the transaction apt install pkg=oldverorapt remove pkgapt-mark holdif needed- Filesystem snapshot for full-system rollback
See yum history rollback for the RPM-side workflow.
A strong answer is:
"APT logs transactions but doesn't undo by ID — I use history.log, downgrade with package=version, hold if needed, and snapshots for full-system recovery."
APT rollback — when to use / when not
| Use this APT rollback workflow when | Use something else when |
|---|---|
|
|
apt rollback vs yum history
| APT (Debian/Ubuntu) | yum/dnf history (RHEL) | |
|---|---|---|
| Transaction log | /var/log/apt/history.log |
yum history / dnf DB |
| One-shot undo | No native undo ID |
yum history undo ID |
| Downgrade one package | apt install pkg=ver |
yum downgrade pkg |
| Full-system rollback | Snapshots, reinstall | yum history rollback + snapshots |
Plan Debian rollbacks explicitly; do not assume yum parity.
Related commands
| Command | One line |
|---|---|
| apt | Install, remove, upgrade packages |
| apt-cache | Query versions and dependencies |
| dpkg | Low-level installed package state |
| yum history rollback | RPM transaction undo/rollback |
APT rollback — interview corner
Does apt have yum history undo?
No. APT records runs in /var/log/apt/history.log but provides no apt history undo <id>.
You reverse changes by removing packages, installing package=version, or restoring snapshots.
A strong answer is:
"APT logs transactions in history.log but doesn't undo by ID — I downgrade with apt install pkg=version, hold if needed, or restore from snapshot for big rollbacks."
Where does apt record installs and removals?
/var/log/apt/history.log — blocks with Start-Date, Commandline, Install, Remove, Upgrade.
/var/log/apt/term.log — verbose apt output for the same runs.
Rotated logs are gzip files in the same directory.
A strong answer is:
"history.log for the transaction summary — I grep Start-Date and Commandline, then read Install/Remove lines for package names."
How do you downgrade a package with apt?
apt-cache policy package_name
sudo apt install package_name=1.2.3Use --simulate first. Hold afterward if upgrades should not bump it again.
A strong answer is:
"policy shows available versions, install pkg=ver downgrades, apt-mark hold keeps it there across upgrade."
What does apt-mark hold do?
Freezes a package at its current version — apt upgrade skips it until apt-mark unhold.
Useful after a manual downgrade or when a new release breaks your stack.
A strong answer is:
"hold pins a package so upgrade won't touch it — I unhold when I'm ready to test the newer version again."
How do you roll back an entire system after apt upgrade?
APT alone cannot rewind hundreds of packages reliably. Use LVM/btrfs snapshots, cloud volume backup, or reimage — then treat history.log as forensic detail only.
A strong answer is:
"For full-system rollback I use snapshots or backups — apt handles single-package fixes, not whole-OS time travel."
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
Package pkg=ver not found |
Version not in any repo | Enable old-suite mirror, or obtain .deb manually |
| Downgrade wants to remove half the system | Dependency conflict | --simulate first; consider hold + partial fix |
held packages never upgrade |
apt-mark hold |
apt-mark showhold; unhold when ready |
| history.log empty | Logging disabled or new VM | Check /var/log/apt/ permissions and logrotate |
| Removed package still broken | Config left behind | apt purge; check /etc/ backups |
References
- apt command cheat sheet
- yum history rollback — RPM transaction undo
- apt(8) man page
- Debian Wiki — Apt
