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