On 03/21/2017 11:26 PM, 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, 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.
Only just got to catching up on the thread sorry if this was already mentioned, A further issue here is that some programs write often, the enlightenment desktop for example has been known to regularly update its config during operation admittedly this is probably only a issue if someone is using btrfs without a separate /home partition but it probably needs to be considered that much modern desktop software doesn't like it when it can't write to its normal writable location whether thats somewhere in ~/.local or ~/.cache or anywhere else that could be within the root file system. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B