How do I preview a Linux upgrade before scheduling maintenance?
A transaction preview helps reveal package changes, but it cannot predict every service restart, configuration prompt or application incompatibility. Use it alongside the distribution’s release notes and the application’s support matrix. Routine package updates and a major operating-system release upgrade require different plans.
Before you start
- An authorised SSH session on the Linux server.
Instructions
1. Inspect a proposed package transaction
Use the current repository metadata. APT simulation and DNF’s decline option allow you to inspect the solver’s proposed changes without committing them.
apt-get -s upgradeDebian/Ubuntu: read packages held back and any warnings. This is not a distribution-release upgrade.
sudo dnf upgrade --assumenoRHEL-family alternative: inspect the transaction, then decline automatically. Metadata may still be refreshed.
2. Map changes to service validation
List the currently failed services before maintenance so an older issue is not mistaken for a new regression. Identify applications, scheduled work and kernel components affected by the proposed transaction.
systemctl --failed --no-pagerOn systemd servers this provides a baseline of failed units. Pair it with application-level health checks and planned reboot access.
Check the result
- The maintenance plan names the exact package transaction, service checks, recovery approach and any expected restart or reboot. Review the transaction again when it is actually executed.
Troubleshooting
- A preview proposes removing a critical package
- Stop and inspect repository compatibility, dependency changes and package holds. A solver’s valid transaction can still be wrong for your application.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.