Support commit, syncfs, /etc merge just before reboot #545
Comments
cgwalters
changed the title
does that mean we would properly handle the "power loss" case where I've "upgraded" but not yet reboot yet and i suffer a power loss? |
|
The short answer is "yes". I'm not sure exactly what your concern is, but the only power loss thing to be concerned about here is that if you get a system crash during the "final processing" phase where we do the /etc merge and bootloader swap, you'd be left in the current system, not the new one. |
|
ok cool. so if we lost power before reboot we'd simply stay in the state where we are booting into the old deployment on every boot. Would the user just |
|
The way I'd been thinking of implementing things, the update would still be "pending" when the system came back up, so doing a reboot would retry the |
cgwalters
changed the title
|
I think we should also try to only do The user-visible effect here though would be that it'd be possible for an operation that was applied live could be "undone" after a system crash. Things get tricky though as we need to think about the flatpak (and other container) use cases. What degree of expected durability is there? Perhaps scoping in the change to |
I was playing with `--download-only` a bit with an eye to having something like this be used by Cockpit/gnome-software instead of what it's doing now, but a problem is that at the moment we don't have a way to reflect the "changed" state back to clients. This is a first step towards that by simply printing a different message. I think really to make all of this work more nicely though, including supporting e.g. rpm database diffs, we are going to have to instead work on the [pending deployment(ostreedev/ostree#545) path.
I was playing with `--download-only` a bit with an eye to having something like this be used by Cockpit/gnome-software instead of what it's doing now, but a problem is that at the moment we don't have a way to reflect the "changed" state back to clients. This is a first step towards that by simply printing a different message. I think really to make all of this work more nicely though, including supporting e.g. rpm database diffs, we are going to have to instead work on the [pending deployment](ostreedev/ostree#545) path. That way we'll have done the depsolve, stored repo timestamps etc.; we'll be able to accurately show what *did* change rather than try to recreate what will happen on the next `rpm-ostree upgrade --cache-only`.
I was playing with `--download-only` a bit with an eye to having something like this be used by Cockpit/gnome-software instead of what it's doing now, but a problem is that at the moment we don't have a way to reflect the "changed" state back to clients. This is a first step towards that by simply printing a different message. I think really to make all of this work more nicely though, including supporting e.g. rpm database diffs, we are going to have to instead work on the [pending deployment](ostreedev/ostree#545) path. That way we'll have done the depsolve, stored repo timestamps etc.; we'll be able to accurately show what *did* change rather than try to recreate what will happen on the next `rpm-ostree upgrade --cache-only`. Closes: #1118 Approved by: jlebon
|
PR: #1503 |
Add API to write a deployment state to `/run/ostree/staged-deployment`, along with a systemd service which runs at shutdown time. This is a big change to the ostree model for hosts, but it closes a longstanding set of bugs; many, many people have hit the "losing changes in /etc" problem. It also avoids the other problem of racing with programs that modify `/etc` such as LVM backups: https://bugzilla.redhat.com/show_bug.cgi?id=1365297 We need this in particular to go to a full-on model for automatically updated host systems where (like a dual-partition model) everything is fully prepared and the reboot can be taken asynchronously. Closes: ostreedev#545
Add API to write a deployment state to `/run/ostree/staged-deployment`, along with a systemd service which runs at shutdown time. This is a big change to the ostree model for hosts, but it closes a longstanding set of bugs; many, many people have hit the "losing changes in /etc" problem. It also avoids the other problem of racing with programs that modify `/etc` such as LVM backups: https://bugzilla.redhat.com/show_bug.cgi?id=1365297 We need this in particular to go to a full-on model for automatically updated host systems where (like a dual-partition model) everything is fully prepared and the reboot can be taken asynchronously. Closes: ostreedev#545
Add API to write a deployment state to `/run/ostree/staged-deployment`, along with a systemd service which runs at shutdown time. This is a big change to the ostree model for hosts, but it closes a longstanding set of bugs; many, many people have hit the "losing changes in /etc" problem. It also avoids the other problem of racing with programs that modify `/etc` such as LVM backups: https://bugzilla.redhat.com/show_bug.cgi?id=1365297 We need this in particular to go to a full-on model for automatically updated host systems where (like a dual-partition model) everything is fully prepared and the reboot can be taken asynchronously. Closes: ostreedev#545
PR: #1503
Migrating this from coreos/rpm-ostree#40 and https://bugzilla.gnome.org/show_bug.cgi?id=758088
To fix the "changes in
/etcare lost" problem, we add the concept of a "staged deployment". Currently there are conceptually 3 parts toostree_sysroot_deploy_tree()which is used for upgrades, etc.This changes to just be the first phase. We record the staged state in
/run/ostree/staged-deployment. A new systemd serviceostree-finalize-staged.serviceis activated when the new APIostree_sysroot_stage_tree()is used, and runs at shutdown time to do the configuration merge and bootloader.The text was updated successfully, but these errors were encountered: