Implement system-upgrade plugin #1209
Conversation
Implementing transaction callbacks for Plymouth and keeping the progress bars on stdout meant extending RpmTransCB, meaning RpmTransCB had to move to the public API.
|
I've done an initial review by scanning through the code. @kontura, please feel free to proceed with your planned proper review 🙂 |
|
We need |
This commit brings in systemd-devel as a build dependency for dnf5-plugins so system-upgrade can log directly to journald and so the `log` subcommand can search the journal for upgrade logs. Perhaps in a subsequent patch, this dependency can be put behind a switch.
evan-goode
force-pushed
the
evan-goode/system-upgrade
branch
from
c104b43 to
1dd933d
Compare
|
|
||
| auto transaction = goal->resolve(); | ||
| if (transaction.get_problems() != libdnf5::GoalProblem::NO_PROBLEM) { | ||
| throw libdnf5::cli::GoalResolveError(transaction); |
There was a problem hiding this comment.
I would prefer more specific error here but we also need the resolve logs.
Can we at least add comment saying something like: This indicates some bigger problem since the transaction was already successfully resolved before.
We would like to be able to run any command offline using some generic switch. Some more details in: #1224 |
|
Superseded by #1280 which implements |
For #1052.
The
system-upgradeplugin is responsible for performing "offline" upgrades of the system. It has three main subcommands:dnf5 system-upgrade download: Does a dry run of an upgrade to a newreleaseverand stores the resulting transaction for later.dnf5 system-upgrade reboot: Creates a "magic symlink" at/system-updateto trigger the start ofdnf5-system-upgrade.serviceon the next boot, then reboots. See https://www.freedesktop.org/software/systemd/man/latest/systemd.offline-updates.html.dnf5-system-upgrade.servicewill take the place of the usual boot target so we can preform the upgrade without disturbing too many running processes.dnf5 system-upgrade upgrade: Not intended to be run by the user directly, but rather bydnf5-system-upgrade.service. Loads the transaction saved bysystem-upgrade downloadand performs the upgrade. Interacts with Plymouth (if it's available) to show upgrade progress on the animated boot screen. The usual DNF 5 stdout is additionally logged to journald. Reboots or powers off when the upgrade is complete.This implementation is, for the most part, a straightforward port of the DNF 4 system-upgrade plugin in dnf-plugins-core (formerly in dnf-plugins-extras). It uses the DNF 5 transaction load/store API.
It's still a work in progress, but most of the functionality from DNF 4 system-upgrade is ported over and it's been successfully updating F38 to F39 without hiccups. Things left to do:
logsubcommanddnf-plugins-extrasto make sure no historical issues with DNF 4 system-upgrade are present in the new implementationtest_system_upgrade.pyIn my opinion, each of these (perhaps with the exception of the
logsubcommand) is a high-priority item, but they could be split off into future PRs if desired.