https://bugzilla.suse.com/show_bug.cgi?id=1205258 https://bugzilla.suse.com/show_bug.cgi?id=1205258#c6 --- Comment #6 from Eric Levy --- Thank you for the explanation. I had no idea about such support coming from tukit. I had reviewed the manual for the command transactional-update, but I have not found any comprehensive guide, tutorial, or manual for the overall system, that is, the general design of the TU framework. I have generally found only documentation for specific components, or high-level overviews of the concept. A comprehensive document that targets the practical use cases for administrators and users, would be very helpful. Elaboration of the inner plumbing would be a helpful too, as an indispensable resource for disaster recovery. To my mind, such a document would useful overall much more so than just a blog post on this particular subject, especially because it may be hard for the right person to find the resource at the time when needed. However, it certainly might help someone at some time, and certainly would be more helpful for the subject than any resource I have found so far. Yes, I agree you found a flaw regarding the privileges of the user shell, which could be resolved through appropriate modifications of the concept. You could simply allow any user to enter the open transaction, with regular permissions. At the present time, I feel compelled to push back against the idea of lack of isolation being a major problem. Locations storing user data are meant to be manipulated by operations initiated by the user, in ways that the user understands. My motivation for submitting the request is that in a vanilla installation, it is possible for the an administrator to install a package on an active system, immediately interact with the modified system, and then, if desired, reverse the system changes, or add new ones. Surely it is possible that such a sequence would leave artifacts in data locations, but such effects are well understood, and no more harmful in the transactional scenario than in the classical one. For cases where some isolation is desired, you could consider adding an option for providing the full environment through temporary snapshots, such that the changes to these locations within the test session will be lost, even if the changes to the system are committed. The purpose would be to test operations, for resolving whether the new system image is one that would be useful for future boot sessions, or not. For example, the build operation is reproducible. If it succeeds in the test environment, it will succeed in new system configuration, once it would become active. Please remember also, if I am not mistaken, that rollback of a previous transaction will not roll back modifications to data directories occurring during any boot sessions following the transaction. Thus, you could be providing more isolation than available currently, by opening the possibility for utilizing the system changes in a special session. My understanding would be that if an administrator must roll back a transaction, any problems encountered would be the same as the ones that cause you to hesitate on the idea I am proposing. The proposed method is simply a means to test the consequences of a transaction before committing it for future boot sessions, and without interrupting the boot session of the live system. Once the changes are confirmed, and the transaction committed, then the system would be rebooted, with predictable effects. If I am not making some important oversight, you might consider supporting the work flow through an accessible set of operations in the tool chain. I believe the concerns I have raised originally are rather common, and without a way to address them, it may be harder for many sites to adopt the system, or to find ways to resolve unforeseen problems after adoption. -- You are receiving this mail because: You are on the CC list for the bug.