[opensuse-factory] ANNOUNCE: transactional updates for Tumbleweed
Hello, I would like to announce a new package in Tumbleweed: "transactional-update". What is this, and why is this from interest for you? Tumbleweed is a rolling release distribution. Which means, even intrusive changes will be applied to a running system, which is in use by the user. For a lot of updates this is no problem, but sometimes there are updates, which make trouble. Only remember the email from Martin Wilk from Jan 16th, 2017: "CAREFUL: New Tumbleweed snapshot 20170112 released!". Or think about the pam-config update last year. For another project I wrote a script updating a distribution in a transactional way. I was asked by many people if I couldn't provide that for Tumbleweed, too. So, here it is. What are transactional updates? A transactioan update: - is atomic - The update does not influence your running system. - It's either successful applied or nothing is changed. So no broken RPMs are flying around in the system. - can be rolled back - if the upgrade fails or if the update is not compatible, you can quickly restore the situation as it was before the upgrade. What do you need to be able to use it? - A recent installation of Tumbleweed (updating from older versions, especially installations made with openSUSE 13.x, will not work) with btrfs and snapshots enabled. If your installation is not recent enough, the script will tell and warn you and refuse to work. How does it work? In short, we create a snapshot of the system, update this snapshot, do a "rollback" (or better "somersault") to this new snapshot and with the next reboot, the updates are there. And if they don't work, boot the old snapshot and continue to work, until the problem is fixed with another update. So, everything is fine? No, it is not. The original project did work with a read-only root filesystem. Which means, after taking the snapshot, the original data couldn't be modified and no data could go lost. With Tumbleweed, all changes you are doing to the root filesystem subvolume after starting the script will be lost with the next reboot into the new snapshot. Which means, after running the script, you should immeaditly reboot to activate the changes and avoid data lossage. Modifications in other subvolumes are fine. 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. 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. 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). Same problem for all other subvolumes like /var/log, /var/spool, etc. So, now you can test the script and I hope it is from use for many of you. I'm pretty sure there are still situations which the script cannot handle, and a lot of you have ideas about how to improve it. I'm happy about every patch or idea. And of course adjusted RPMs, which have no problem with this update method. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2017.01.21 15:46, Thorsten Kukuk rašė:
Hello,
I would like to announce a new package in Tumbleweed: "transactional-update".
Nice idea! But for installation of critical packages, maybe would be better to use this schema: 1) just download critical RPMs (don't install emediately); 2) at next reboot (or re-login, depending on situation), at early stage of boot, do installation of thees RPMs; 3) if necessary automatically reboot again. I believe this schema can work not only for BTRFS filesystem (with snapshoots), but also with reliable EXT4 (that don't support snapshots). This is just idea to enhence situation. Maybe "transactional-update" could benefit from it in case of problematic packages. -- Regards -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Jan 21, opensuse.lietuviu.kalba wrote:
2017.01.21 15:46, Thorsten Kukuk rašė:
Hello,
I would like to announce a new package in Tumbleweed: "transactional-update".
Nice idea! But for installation of critical packages, maybe would be better to use this schema:
1) just download critical RPMs (don't install emediately);
2) at next reboot (or re-login, depending on situation), at early stage of boot, do installation of thees RPMs;
That's what windows is doing. The disadvantage is, that your machine is blocked until all updates are installed. And that had already really bad ramifications for some people (I will bring examples at FOSDEM). This is exactly what we don't want. And, as I wrote, the original project is using a read-only filesystem, where your idea would not work at all. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Jan 21, Thorsten Kukuk wrote:
On Sat, Jan 21, opensuse.lietuviu.kalba wrote:
2017.01.21 15:46, Thorsten Kukuk rašė:
Hello,
I would like to announce a new package in Tumbleweed: "transactional-update".
Nice idea! But for installation of critical packages, maybe would be better to use this schema:
1) just download critical RPMs (don't install emediately);
2) at next reboot (or re-login, depending on situation), at early stage of boot, do installation of thees RPMs;
That's what windows is doing. The disadvantage is, that your machine is blocked until all updates are installed. And that had already really bad ramifications for some people (I will bring examples at FOSDEM). This is exactly what we don't want.
I forgot two other disadvantages of your approach: 1. updates are not atomic, if a patch couldn't be applied correct, your system will be in an undefined state. 2. it will not help at all for problems like the incompatible pam-config update, from which you cannot recover with your idea.
And, as I wrote, the original project is using a read-only filesystem, where your idea would not work at all.
Thorsten
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
21.01.2017 17:53, opensuse.lietuviu.kalba пишет:
2017.01.21 15:46, Thorsten Kukuk rašė:
Hello,
I would like to announce a new package in Tumbleweed: "transactional-update".
Nice idea! But for installation of critical packages, maybe would be better to use this schema:
1) just download critical RPMs (don't install emediately);
2) at next reboot (or re-login, depending on situation), at early stage of boot, do installation of thees RPMs;
3) if necessary automatically reboot again.
This is supported by PackageKit for quite some time already https://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/
I believe this schema can work not only for BTRFS filesystem (with snapshoots), but also with reliable EXT4 (that don't support snapshots).
This is just idea to enhence situation. Maybe "transactional-update" could benefit from it in case of problematic packages.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 2017-01-21 at 16:53 +0200, opensuse.lietuviu.kalba wrote:
2017.01.21 15:46, Thorsten Kukuk rašė:
Hello,
I would like to announce a new package in Tumbleweed: "transactional-update".
Nice idea! But for installation of critical packages, maybe would be better to use this schema:
1) just download critical RPMs (don't install emediately);
2) at next reboot (or re-login, depending on situation), at early stage of boot, do installation of thees RPMs;
3) if necessary automatically reboot again.
I believe this schema can work not only for BTRFS filesystem (with snapshoots), but also with reliable EXT4 (that don't support snapshots).
This is just idea to enhence situation. Maybe "transactional-update" could benefit from it in case of problematic packages.
This is already possible - using the so-called offline update method (probably undertested) pkcon update -d # download available updates) pkcon offline-trigger # Set system to boot to offline-update on next boot If you use GNOME Software to update your system, this is also exactly what is happening behind the curtains. It has the advantage of being in a 'minimal running system where only few things can go wrong' (but still can go wrong so far) - and it has the disadvantage that it applies updates when you are booting or restarting. The transactional update method surely has its merits over the offline- update method in the fact that the user does not have to wait for the update during boot... with the negative effects as described by Thorsten. Cheers, Dominique
21.01.2017 16:46, Thorsten Kukuk пишет:
4. RPM, which installs directories or data into directories, which are subvolumes, needs to be adjusted. This will not work.
Why? Solaris Live Update supports it for ages. It builds environment that includes any arbitrary filesystem (you define). So it's not "this will not work" but "this is not implemented". -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Jan 21, Andrei Borzenkov wrote:
21.01.2017 16:46, Thorsten Kukuk пишет:
4. RPM, which installs directories or data into directories, which are subvolumes, needs to be adjusted. This will not work.
Why? Solaris Live Update supports it for ages. It builds environment that includes any arbitrary filesystem (you define). So it's not "this will not work" but "this is not implemented".
How does Solaris Live Update merge a Postgresql7 database with a Postgresql8 database, for example? Would be really interesting to know ... Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
21.01.2017 19:55, Thorsten Kukuk пишет:
On Sat, Jan 21, Andrei Borzenkov wrote:
21.01.2017 16:46, Thorsten Kukuk пишет:
4. RPM, which installs directories or data into directories, which are subvolumes, needs to be adjusted. This will not work.
Why? Solaris Live Update supports it for ages. It builds environment that includes any arbitrary filesystem (you define). So it's not "this will not work" but "this is not implemented".
How does Solaris Live Update merge a Postgresql7 database with a Postgresql8 database, for example?
It does not because it is out of its scope. What it does is install packages. If data that is managed by package binaries is incompatible with new version of binaries, you cannot convert it during package installation anyway - this has to be deferred until some later point in time when new binary is run for the first time. I read your quoted statement as "package cannot contain files from different subvolumes/filesystems". Now, *that* I cannot agree with - nothing prevents you from cloning these subvolumes, building new version of boot environment that includes all these clones and switching to it on reboot. Whether this is feasible in each particular case, is separate question.
Would be really interesting to know ...
Thorsten
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On Sat, Jan 21, Andrei Borzenkov wrote:
It does not because it is out of its scope. What it does is install packages. If data that is managed by package binaries is incompatible with new version of binaries, you cannot convert it during package installation anyway - this has to be deferred until some later point in time when new binary is run for the first time.
Ok, so that's exactly what I wrote initial, too.
I read your quoted statement as "package cannot contain files from different subvolumes/filesystems". Now, *that* I cannot agree with - nothing prevents you from cloning these subvolumes, building new version of boot environment that includes all these clones and switching to it on reboot. Whether this is feasible in each particular case, is separate question.
Looks like Solaris ZFS can handle different subvolumes as one. btrfs does not have this feature, but it wouldn't help in this case, too. We do create the subvolumes on purpose. Either they contain high volatile data (e.g. /var/cache), or they contain data you don't want to loose during update or rollback (var/lib/pgsql, /var/spool/mail). And I'm speaking about this subvolumes: an RPM should not contain data which is in the "main" root subvolume, and a "data" subvolume. Either you will have data lossage on update or rollback, or you have inconsistent RPMs (the changes in a "data" subvolume are missing after reboot. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On samedi, 21 janvier 2017 14.46:19 h CET Thorsten Kukuk wrote:
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). Same problem for all other subvolumes like /var/log, /var/spool, etc.
I've some difficulties to understand why it's bad ? I want to have my squid cache stored and stay on disk so it's persitant. Same apply for zypper If I want to keep packages ... -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Jan 21, Bruno Friedmann wrote:
On samedi, 21 janvier 2017 14.46:19 h CET Thorsten Kukuk wrote:
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). Same problem for all other subvolumes like /var/log, /var/spool, etc.
I've some difficulties to understand why it's bad ? I want to have my squid cache stored and stay on disk so it's persitant. Same apply for zypper If I want to keep packages ...
Assume e.g. you want to cleanup your disk because you are running out of disk space. And this is a requirement of the FHS, too: An admin should always be allowed to delete the cache and applications should be able to handle that. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On dimanche, 22 janvier 2017 10.56:46 h CET Thorsten Kukuk wrote:
On Sat, Jan 21, Bruno Friedmann wrote:
On samedi, 21 janvier 2017 14.46:19 h CET Thorsten Kukuk wrote:
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). Same problem for all other subvolumes like /var/log, /var/spool, etc.
I've some difficulties to understand why it's bad ? I want to have my squid cache stored and stay on disk so it's persitant. Same apply for zypper If I want to keep packages ...
Assume e.g. you want to cleanup your disk because you are running out of disk space. And this is a requirement of the FHS, too: An admin should always be allowed to delete the cache and applications should be able to handle that.
Thorsten
The inside of (I'm still using a real example) of /var/cache/squid can be cleaned at any time by the administrator. And the actual systemd service file will handle according to the configuration the rebuild of cache hierachy. But /var/cache/squid has to be owned by someone so it can be cleanup in case of removal of squid package. Seem to what I understand from you point of view, is that we should have a %ghost /var/cache/squid in %files section and then a squid.conf in /usr/lib/ tempfiles.d that create this directory if not existing on boot. Did I understand your proposal when translated to real package ? -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Jan 22, Bruno Friedmann wrote:
But /var/cache/squid has to be owned by someone so it can be cleanup in case of removal of squid package.
And that is an error in reasoning: /var/cache/squid will not be deleted if you deinstall squid, because this directory would still contain files. So after deinstallation of squid, if you have a directory /var/cache/squid which is not owned by any package. That the package was formerly owned by squid does not help you in any way, except if you did never configure and run squid. It is only helpful as long as the package is installed. (Which does not mean I'm in favour of removing this directory from the packagelist, only the reason why it is important for de-installation is wrong).
Seem to what I understand from you point of view, is that we should have a %ghost /var/cache/squid in %files section and then a squid.conf in /usr/lib/ tempfiles.d that create this directory if not existing on boot.
Did I understand your proposal when translated to real package ?
Yes, this is what I mean. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne neděle 22. ledna 2017 12:00:19 CET, Thorsten Kukuk napsal(a):
On Sun, Jan 22, Bruno Friedmann wrote:
But /var/cache/squid has to be owned by someone so it can be cleanup in case of removal of squid package.
And that is an error in reasoning: /var/cache/squid will not be deleted if you deinstall squid, because this directory would still contain files. So after deinstallation of squid, if you have a directory /var/cache/squid which is not owned by any package. That the package was formerly owned by squid does not help you in any way, except if you did never configure and run squid. It is only helpful as long as the package is installed. (Which does not mean I'm in favour of removing this directory from the packagelist, only the reason why it is important for de-installation is wrong).
May I ask how such cleanup should be done after removal of the package? I'm sorry, I'm bit confused. And little bit moving it into philosophy: generally, if I uninstall something and after some time I install it back. Should I start with empty settings or continue where I interrupted usage of that software (configuration as well as data?. Generally, I like the idea, it seems to be very robust method. Do I understand it correctly, that as soon as I continue work in userpsace (e.g. with browser or office application), I can safely postpone reboot? But what about applications writing something into /tmp? -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/
On 2017-01-22 12:59, Vojtěch Zeisek wrote:
May I ask how such cleanup should be done after removal of the package? I'm sorry, I'm bit confused. And little bit moving it into philosophy: generally, if I uninstall something and after some time I install it back. Should I start with empty settings or continue where I interrupted usage of that software (configuration as well as data?.
The behaviour in SuSE/openSUSE since I know it is to leave the data and configuration intact. The installation/removal/upgrade by rpm only touches the code. And also the config, but never replacing it fully: sometimes the new config is activated, sometimes the old. Both versions are in place, one renamed. Actually an rpm feature. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Dne neděle 22. ledna 2017 13:15:17 CET, Carlos E. R. napsal(a):
On 2017-01-22 12:59, Vojtěch Zeisek wrote:
May I ask how such cleanup should be done after removal of the package? I'm sorry, I'm bit confused. And little bit moving it into philosophy: generally, if I uninstall something and after some time I install it back. Should I start with empty settings or continue where I interrupted usage of that software (configuration as well as data?.
The behaviour in SuSE/openSUSE since I know it is to leave the data and configuration intact. The installation/removal/upgrade by rpm only touches the code. And also the config, but never replacing it fully: sometimes the new config is activated, sometimes the old. Both versions are in place, one renamed.
OK. As far as I know it is not possible to force cleanup of such data/ configuration files when removing package. Correct? Wouldn't it be nice to have such option when using zypper? I hope I don't hitchhike the thread too much... -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/
On 23.01.17 08:27 Vojtěch Zeisek wrote:
OK. As far as I know it is not possible to force cleanup of such data/ configuration files when removing package. Correct? Wouldn't it be nice to have such option when using zypper?
How to distinguish between deinstallation and deinstallation before installing the newer version of the package? Could be tricky... Johannes
Dne pondělí 23. ledna 2017 11:03:08 CET, Johannes Kastl napsal(a):
On 23.01.17 08:27 Vojtěch Zeisek wrote:
OK. As far as I know it is not possible to force cleanup of such data/ configuration files when removing package. Correct? Wouldn't it be nice to have such option when using zypper?
How to distinguish between deinstallation and deinstallation before installing the newer version of the package? Could be tricky...
Yes, so what about optional parameter to do so? -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/
On Mon, 2017-01-23 at 11:12 +0100, Vojtěch Zeisek wrote:
Dne pondělí 23. ledna 2017 11:03:08 CET, Johannes Kastl napsal(a):
On 23.01.17 08:27 Vojtěch Zeisek wrote:
OK. As far as I know it is not possible to force cleanup of such data/ configuration files when removing package. Correct? Wouldn't it be nice to have such option when using zypper?
How to distinguish between deinstallation and deinstallation before installing the newer version of the package? Could be tricky...
Yes, so what about optional parameter to do so?
Userdata is user owned data - also configuration is 'owned/created' by the user. I'd consider it terrible practice to delete any data the USER/OWNER put on his machine on package removal. Cheers, Dominique
On 23.01.17 11:21 Dominique Leuenberger / DimStar wrote:
Userdata is user owned data - also configuration is 'owned/created' by the user. I'd consider it terrible practice to delete any data the USER/OWNER put on his machine on package removal.
I think Vojtěch means something like "apt-get purge xyz". Johannes
Dne pondělí 23. ledna 2017 11:35:38 CET, Johannes Kastl napsal(a):
On 23.01.17 11:21 Dominique Leuenberger / DimStar wrote:
Userdata is user owned data - also configuration is 'owned/created' by the user. I'd consider it terrible practice to delete any data the USER/OWNER put on his machine on package removal.
I think Vojtěch means something like "apt-get purge xyz".
Exactly. Thank You. -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/
On Mon, Jan 23, Vojtěch Zeisek wrote:
Dne pondělí 23. ledna 2017 11:35:38 CET, Johannes Kastl napsal(a):
On 23.01.17 11:21 Dominique Leuenberger / DimStar wrote:
Userdata is user owned data - also configuration is 'owned/created' by the user. I'd consider it terrible practice to delete any data the USER/OWNER put on his machine on package removal.
I think Vojtěch means something like "apt-get purge xyz".
Exactly. Thank You.
What "apt-get purge" is doing is the default of RPM? "apt-get purge" does NOT delete any user data. "apt-get purge" does only delete configuration files, except it is in the users home directory or something similar. What does RPM? - it always removes the configuration files. If the configuraton file was changed, a backup (*.rpmsave) will be keeped. So please be a little bit more verbose what you want to archive compared to the current status. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne pondělí 23. ledna 2017 14:00:46 CET, Thorsten Kukuk napsal(a):
On Mon, Jan 23, Vojtěch Zeisek wrote:
Dne pondělí 23. ledna 2017 11:35:38 CET, Johannes Kastl napsal(a):
On 23.01.17 11:21 Dominique Leuenberger / DimStar wrote:
Userdata is user owned data - also configuration is 'owned/created' by the user. I'd consider it terrible practice to delete any data the USER/OWNER put on his machine on package removal.
I think Vojtěch means something like "apt-get purge xyz".
Exactly. Thank You.
What "apt-get purge" is doing is the default of RPM?
"apt-get purge" does NOT delete any user data. "apt-get purge" does only delete configuration files, except it is in the users home directory or something similar. What does RPM? - it always removes the configuration files. If the configuraton file was changed, a backup (*.rpmsave) will be keeped.
So please be a little bit more verbose what you want to archive compared to the current status.
I'm sorry, this was my mistake. I thought "apt-get purge" is deleting also the data, not only configuration; and RPM leaves everything in place. My concert was if there is/could be optional parameter to delete also the data and configuration when removing particular package. Sorry for the too much noise. -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/
On Mon, 23 Jan 2017 14:29:48 +0100 Vojtěch Zeisek <vojtech.zeisek@opensuse.org> wrote:
Dne pondělí 23. ledna 2017 14:00:46 CET, Thorsten Kukuk napsal(a):
On Mon, Jan 23, Vojtěch Zeisek wrote:
Dne pondělí 23. ledna 2017 11:35:38 CET, Johannes Kastl napsal(a):
On 23.01.17 11:21 Dominique Leuenberger / DimStar wrote:
Userdata is user owned data - also configuration is 'owned/created' by the user. I'd consider it terrible practice to delete any data the USER/OWNER put on his machine on package removal.
I think Vojtěch means something like "apt-get purge xyz".
Exactly. Thank You.
What "apt-get purge" is doing is the default of RPM?
"apt-get purge" does NOT delete any user data. "apt-get purge" does only delete configuration files, except it is in the users home directory or something similar. What does RPM? - it always removes the configuration files. If the configuraton file was changed, a backup (*.rpmsave) will be keeped.
So please be a little bit more verbose what you want to archive compared to the current status.
I'm sorry, this was my mistake. I thought "apt-get purge" is deleting also the data, not only configuration; and RPM leaves everything in place. My concert was if there is/could be optional parameter to delete also the data and configuration when removing particular package. Sorry for the too much noise.
dpkg -i --auto-deconfigure removes the configuration data as well. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Jan 22, Vojtěch Zeisek wrote:
Generally, I like the idea, it seems to be very robust method. Do I understand it correctly, that as soon as I continue work in userpsace (e.g. with browser or office application), I can safely postpone reboot? But what about applications writing something into /tmp?
You can postpone the reboot to any time you want. But the risk increases that changes to the root subvolume are made, which will go lost. Applications writing to /tmp should not expect that this will survive a reboot. Quite the opposite, data in /tmp is defined as not surviving a reboot. But since /tmp is a subvolume, it is no problem in this case. But writing to e.g. /etc is a problem. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
On Mon, Jan 23, Ludwig Nussel wrote:
Thorsten Kukuk wrote:
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?
That was my very first idea, but is not possible because of /var/lib/rpm. The RPM database has to stay on the root subvolume. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Thorsten Kukuk wrote:
On Mon, Jan 23, Ludwig Nussel wrote:
Thorsten Kukuk wrote:
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?
That was my very first idea, but is not possible because of /var/lib/rpm. The RPM database has to stay on the root subvolume.
May sound heretical but it could be moved to /usr :-) /usr will be rw during package installation (ie when the rpmdb needs to be modified) and can be ro otherwise. If we think of /usr as the location where the operating system is, then it could be argued that the index of things that are part of the operating system also belongs there. 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
Ludwig Nussel wrote:
If we think of /usr as the location where the operating system is,
But it's not. OS is on 'boot' and 'root' (/lib for modules mostly). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Thorsten Kukuk wrote:
On Mon, Jan 23, Ludwig Nussel wrote:
Thorsten Kukuk wrote:
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?
That was my very first idea, but is not possible because of /var/lib/rpm. The RPM database has to stay on the root subvolume. Thorsten
====== Problem: any system setup according to "best practices" would have a heavy read/write volume like "/var" on a separate volume already. Generally, it's considered "best practice" to put subdirs with substantially different update/write cycles to be split off to a separate volume. I sometimes wonder if '/etc' is busy enough to split off of root, but its changes are limited to configuration changes for the most part, and not likely to be on a near continuous basis like '/var'. I wouldn't assume that '/var' is on a root volume -- mine has never been that way. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jan 23, L A Walsh wrote:
Thorsten Kukuk wrote:
On Mon, Jan 23, Ludwig Nussel wrote:
Thorsten Kukuk wrote:
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? That was my very first idea, but is not possible because of /var/lib/rpm. The RPM database has to stay on the root subvolume. Thorsten ====== Problem: any system setup according to "best practices" would have a heavy read/write volume like "/var" on a separate volume already.
Generally, it's considered "best practice" to put subdirs with substantially different update/write cycles to be split off to a separate volume.
"best practice" is always special and not common practice. If you want to use snapshots and rollback, your "best practice" is a bad choice and you need to find a new "best practice", which works together with snapshots, rollback and your requirements.
I wouldn't assume that '/var' is on a root volume -- mine has never been that way.
If you use btrfs with snasphots and rollback, it is always on the root volume. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Thorsten Kukuk wrote:
"best practice" is always special and not common practice. If you want to use snapshots and rollback, your "best practice" is a bad choice and you need to find a new "best practice", which works together with snapshots, rollback and your requirements.
I wouldn't assume that '/var' is on a root volume -- mine has never been that way.
If you use btrfs with snasphots and rollback, it is always on the root volume.
---- "Best practices" wouldn't apply to someone using brtfs considering the ongoing problems people post to open-suse. I can't see it being ready for a production system or one that one wants to "keep up" and have 24x7 uptime. NOTE: this seems to already be a problem. Anyone who tries to update their system or software with Yast, *CAN'T* because the "presumed" snapshot ability doesn't seem to get installed with upgrades. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mon, 2017-01-23 at 12:27 -0800, L A Walsh wrote:
If you use btrfs with snasphots and rollback, it is always on the root volume.
---- "Best practices" wouldn't apply to someone using brtfs considering the ongoing problems people post to open-suse. I can't see it being ready for a production system or one that one wants to "keep up" and have 24x7 uptime.
I just want to clarify... there's a huge gap between the issues we see with btrfs and Tumblweeed and the issues that come up with btrfs on SLES. Tumbleweed, with it's _massive_ package churn, highlights a lot of issues with btrfs that no SLES customer would ever hit. So, the differentiation on what makes a "24x7 uptime" server isn't the file system, but the whole OS: and here Tumbleweed is a clearly inferior choice to SLES. - -- James Mason Technical Architect, Public Cloud openSUSE Member SUSE jmason@suse.com -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEg/RjZ+RraZBnLRN4GzlRiGxEkCMFAliGaqsACgkQGzlRiGxE kCPklwf/fqhVes5o4cbwKfZQi8htI8c5C8/aHRpFZcwJsqjhwJRk6W5/UoX+9UJx JmNhgAp9/KH01javbldrmyiBvrrqBTYDN2US5Khay4Bs+Xix1Qw0o7tjdBvR6nL4 4wEmFHy9pCpyZqy7i6EN6MbokTUTyiBtCIT2G+HsdjSu4h60sd0bUpu2NG5tJ1I6 REmhgXhtBZB+ZXnUHKPvlxjbM6RusOm1gqRk5FJeOL/nv83XphfAJRirAfVylDgG Zx+ztTUDsGBGAysMfRRZOU+wBOIBdYD4yWQjh8wFld3Qwd5UhaohbHh7QheZAaDp 3l+vOt+3ujbZ+dX4Twl85ZCZbkATHw== =//Jc -----END PGP SIGNATURE----- N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
On Monday 2017-01-23 13:56, Ludwig Nussel wrote:
Thorsten Kukuk wrote:
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.
How so? Is /opt not snapshotted? If not, why is it treated different than /usr in this regard? (Not that openSUSE RPMs should ever use /opt… ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
On Monday 2017-01-23 13:56, Ludwig Nussel wrote:
Thorsten Kukuk wrote:
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.
How so? Is /opt not snapshotted? If not, why is it treated different than /usr in this regard?
/opt is created as separate subvolume by default. As such out of sync with the rpm db. I don't know the exact reason but the difference between /opt and /usr is that /opt allows admins to put files bypassing package management. If /opt wasn't separate rollbacks would potentially also roll back (non-rpm'd) 3rd party software which may be surprising. 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
On Monday 2017-01-23 14:34, Ludwig Nussel wrote:
Jan Engelhardt wrote:
On Monday 2017-01-23 13:56, Ludwig Nussel wrote:
Thorsten Kukuk wrote:
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.
How so? Is /opt not snapshotted? If not, why is it treated different than /usr in this regard?
/opt is created as separate subvolume by default. As such out of sync with the rpm db.
I do not see the issue yet - the subvolume mounted as /opt ought to have the same hierarchy level as /usr and /var so that it gets included in snapshots (read: if it does not, it better should). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jan 23, Jan Engelhardt wrote:
I do not see the issue yet - the subvolume mounted as /opt ought to have the same hierarchy level as /usr and /var so that it gets included in snapshots (read: if it does not, it better should).
/opt is for ISVs and they can write user data there, like databases. You don't want to loose changes to that data during rollback. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23 January 2017 at 15:37, Thorsten Kukuk <kukuk@suse.de> wrote:
On Mon, Jan 23, Jan Engelhardt wrote:
I do not see the issue yet - the subvolume mounted as /opt ought to have the same hierarchy level as /usr and /var so that it gets included in snapshots (read: if it does not, it better should).
/opt is for ISVs and they can write user data there, like databases. You don't want to loose changes to that data during rollback.
But doesn't the status quo mean you can have a situation where the RPM database and the reality of /opt are two very different things? Theoretical Case in point, something like Oracle DB, which users rpms User installs Oracle DB rpms which produce /opt/oracle and starts using the database User then rollsback to a period before the installation (for whatever reason) /opt/oracle is preserved, the binaries and data are all still there; This is a good thing, no arguments there. But now rpmdb would have absolutely no record of the Oracle DB rpm How would a user be expected to uninstall the Oracle DB rpm in this case? (I realise this is straying OT as the problem is present with the status quo and not made any better or worse with Transactional updates) -R -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On Mon, Jan 23, Richard Brown wrote:
On 23 January 2017 at 15:37, Thorsten Kukuk <kukuk@suse.de> wrote:
On Mon, Jan 23, Jan Engelhardt wrote:
I do not see the issue yet - the subvolume mounted as /opt ought to have the same hierarchy level as /usr and /var so that it gets included in snapshots (read: if it does not, it better should).
/opt is for ISVs and they can write user data there, like databases. You don't want to loose changes to that data during rollback.
But doesn't the status quo mean you can have a situation where the RPM database and the reality of /opt are two very different things?
Yes, as for any other subvolume. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 23.01.2017 um 15:37 schrieb Thorsten Kukuk:
/opt is for ISVs and they can write user data there, like databases. You don't want to loose changes to that data during rollback.
I do not yet use snapper and btrfs, and after reading this, I'm glad I don't. If I would put my application on my production server in /opt, then later attempt to update it, I certainly would expect to be able to roll back from that failed attempt. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Dienstag, 24. Januar 2017 20:32:55 CET Stefan Seyfried wrote:
Am 23.01.2017 um 15:37 schrieb Thorsten Kukuk:
/opt is for ISVs and they can write user data there, like databases. You don't want to loose changes to that data during rollback.
I do not yet use snapper and btrfs, and after reading this, I'm glad I don't.
If I would put my application on my production server in /opt, then later attempt to update it, I certainly would expect to be able to roll back from that failed attempt.
Of course you are free to put opt under snapper control as well, but you are not forced to do it - /opt is explicitly out of the control of the distribution. If /opt were included in the snapshots by default, you would be for sure one of the first persons calling names for taking it out of your control. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jan 24, Stefan Seyfried wrote:
Am 23.01.2017 um 15:37 schrieb Thorsten Kukuk:
/opt is for ISVs and they can write user data there, like databases. You don't want to loose changes to that data during rollback.
I do not yet use snapper and btrfs, and after reading this, I'm glad I don't.
If I would put my application on my production server in /opt, then later attempt to update it, I certainly would expect to be able to roll back from that failed attempt.
Luckily all you need to do is to not put /opt in an extra subvolume, and even you can be happy using btrfs with snapshots :) Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 <mwilck@suse.com>, 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@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jan 31, Martin Wilck wrote:
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 thre system with "transational-update" will (not) break these RPMS), or is it up to users to find out?
openSUSE Tumbleweed has far too many RPMs as it would be possible for me to verify, which will work and which not. A quick way to check if the RPMs you have installed are fine from a package list view: if the RPMs don't install anything into subvolumes, they are fine. If they install something into subvolumes, they are not. Additional you have to verify the pre/post install sections, what they are doing and if they access data in subvolumes during upgrade. This will fail.
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?
As written, you need a recent installation of openSUSE/SLE with btrfs and snapshots enabled. The assuption the script makes it, that snapshots and rollback with btrfs on your system works. Nothing more. If you include /opt or /usr/local into your snapshot, you need to adjust the script (or send me a patch to autodetect this :) ). But that should be all. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (17)
-
Andrei Borzenkov -
Bruno Friedmann -
Carlos E. R. -
Dominique Leuenberger / DimStar -
James Mason -
Jan Engelhardt -
Johannes Kastl -
L A Walsh -
Ludwig Nussel -
Martin Wilck -
opensuse.lietuviu.kalba -
Peter Linnell -
Richard Brown -
Stefan Bruens -
Stefan Seyfried -
Thorsten Kukuk -
Vojtěch Zeisek