On Sat, 2017-01-21 at 14:46 +0100, Thorsten Kukuk wrote:
I have run this script now for three month on a default Tumbleweed installation by cron without any problems. But there are RPMs, which will create problems, and which needs to be adjusted. 1. strictly seperate code from user data. /srv is a real nightmare. Either user data will go lost, or the application will not be updated or rolled back. 2. Don't modify data in post install sections, but during boot or first start instead. If the data is in a subvolume, this one will not be accessible during the upgrade. Or the update wouldn't be atomic anymore. 3. Don't create something outside the snapshot subvolume, this will not survive the next reboot. 4. RPM, which installs directories or data into directories, which are subvolumes, needs to be adjusted. This will not work. Example: /var/cache is an own subvolume.
From a practical perspective - is there a list of RPMs that are known be (non-)compliant with this tool (in the sense that trying to update
This is highly intersting, but I'm still a bit confused.
thre system with "transational-update" will (not) break these RPMS), or
is it up to users to find out?
Likewise, as the tool seems to make certain assumptions about the
subvolume structure of the root FS, is there a set of "minimum
requirements" for the way the system is set up?
Regards
Martin
--
Dr. Martin Wilck