On Tue, 21 Mar 2017, Thorsten Kukuk wrote:
On Tue, Mar 21, Richard Biener wrote:
On Tue, 21 Mar 2017, Thorsten Kukuk wrote:
On Tue, Mar 21, Johannes Meixner wrote:
Hello Thorsten,
On Mar 20 15:06 Thorsten Kukuk wrote (excerpt):
https://en.opensuse.org/openSUSE:Packaging_for_transactional-updates
It reads: ------------------------------------------------------------------------- ... instead of creating a snapshot, updating the current system and rolling back if an error happened, we create a snapshot, update this snapshot, and do a "rollback" to that snapshot if no error did occur. -------------------------------------------------------------------------
Can you explain therein the reason behind why it is done this way or add a link that points to an explanation?
That's explained in the very first sentences:
"Transactional updates are atomic. This means, either the update is fully applied without any error, or no change is made to the system. Additional, transactional upates should not influence the currently running processes."
If you update the running system, none of this is fullfillable.
But it also means the "running system" part that is transactionally modified should better be readonly as otherwise you lose changes done during transaction start and commit?
If you want to be 100% safe: yes, the root filesystem should be read-only, as we do for SUSE CaaSP for this reason.
But I wonder if the current scheme of doing the modification in the live system and rolling back on error works closer to 100% then (in the case of read-write root). Given a transaction abort should be the minority of cases ...
But, if you run the transactional-update in the night with automatic reboot, or make sure that all data is written in other subvolumes beside the root subvolume, you are mostly safe, too.
Doesn't sound like "no changes to the running system" to me then ;)
So my openSUSE Tumbleweed installations are updated at 3 o'clock in the night automatically and reboot if patches where successfully applied.
But some people already think about porting the read-only root subvolume code to Tumbleweed for transactional updates. But this will require quite a lot of changes to existing RPMs.
So what issue are we solving then? That is, is this for CaaSP only
where we can guarantee the r/o root?
Richard.
--
Richard Biener