Thorsten Kukuk wrote:
[...] Another problem is: we are using snapshots and rollback, so face the same issues as with snapshots and rollback. 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.
So yet another reason to enforce the packaging guideline change that was approved last year. No more abuse of /srv in packages.
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.
That has implications for /opt. It cannot be used by rpms anymore.
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. Quite some RPMs create directories and data there, and some of them will stop working if you remove this directories. That's bad even without transactional updates, a system administrator should always be allowed to delete the cache. A better way is to create the directories during boot with tmpfiles.d(5).
Or somehow teach rpm to handle that transparently. Like e.g. declaring subvolumes as %_netsharedpath and let some hook script figure out what to generate via tmpfiles mechanism. A similar problem exists today already with /run.
Same problem for all other subvolumes like /var/log, /var/spool, etc.
I wonder if we should also rethink the subvolume layout a bit while we are at it. Maybe instead of creating lots of separate volumes, /var itself needs to become a subvolume? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org