On Sat, 2017-01-21 at 14:46 +0100, Thorsten Kukuk wrote:
I have run this script now for three month on a
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
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.
This is highly intersting, but I'm still a bit confused.
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
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?
Dr. Martin Wilck <mwilck(a)suse.com>om>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org