Just want to do a quick check: are there any risks / downsides of using transactional-update on OpenSUSE Tumbleweed? I know it is essentially a wrapper script around zypper, but it seems like a good (safe) option to use with big system updates like we just had with the release of KDE6.
I don’t personally want to use an immutable distro at home (not going into that here), but that doesn’t mean some of the tools can’t be a useful asset when they are available on Tumbleweed like this one is.
Transactional-update was introduced 2018 for Leap and Tumbleweed. After some time the immutable distros like MicroOS got born. Since the immutable openSUSE distros exist, the transactional-update role is rather unmaintained for Leap/Tumbleweed.
There is an actual bugreport which will remove the transactional-update server role from YaST as it is unmaintained, incompatible and unsupported on Leap/Tumbleweed.
transactional-update is intended for immutable distros. There it is also well maintained.
I am not using the role and I don’t run a server. Just asking about the utility that executes. The role does more, that’s indeed a bit redundant with the existence of MicroOS. I just intend to interactively and incidentally execute a transactional-update vs a standard zypper dup.
@throttlemeister and as indicated in the bug report, it’s not intended for use on Tumbleweed or supported, just zypper dup 
It’s your system, you can decide to use or not, it may work fine @pavinjoseph uses it… When Tumbleweed drops Apparmor and moves to selinux you could be in for some fun…
Understand that Tumbleweed is the openSUSE development platform for products, to get a package into a release/product it has to be submitted to there first, there maybe no intention of it being “fit for use” in Tumbleweed, but it will exist…
Yay, I need to find a new distro.
transactional-server on tumbleweed works very well and was one of the reasons I moved to opensuse. Sorry to see it go.
Oh well, bye.
@mhurron look at MicroOS? Works great there (with selinux)…
Anything that expects to just use Flatpack and containers is not going to happen.
Tumbleweed transactional was exactly what I wanted, and worked just fine with SELinux.
@mhurron so no reason to not rock on with what you have…
Blockquote @throttlemeister and as indicated in the bug report, it’s not intended for use on Tumbleweed or supported, just
zypper dup
The bug report talks only about the role, and I do not use the role, nor am I intending to use the role. I do not care about the role. Again, the role does a lot more than a single, incidental, manually triggered update. I am only asking about the command /usr/sbin/transactional-update which is installed by zypper in transactional-updateand does not install the role, or the additional tools that are required for it. It only installs the command and a module for dracut to update the bootconfig. No systemd stuff, no automatic updates, no automatic reboots, none of it.
Just a manual execution of /usr/sbin/transactional-update followed by a manual reboot when it is covenient.
Twiddling with the basic definitions of the distro makes the entire thing a little suspect.
Also, removing the role means I can not create new VM’s in the future correctly.
@throttlemeister it’s not about the role, it’s about what is supported (Forum, Bug reports etc), you are free to do what ever you want 
Seems there are a number of folks using it on Tumbleweed @mhurron @pavinjoseph
Wha… 
This is what I understood from the Bugzilla report. I asked the developer for clarification, hopefully he responds positively.
The transactional server role is unsupported and not maintained. It does not work with the defaults of qemu/kvm/libvirt and it’s incompatible with SELinux.
We don’t have the resources to implement and test everything three times, for Tumbleweed, MicroOS and this system role.
@karlmistelberger too on some of his machines IIRC.
@pavinjoseph Selinux is out there somewhere (follow the Factory mailing list) , what do you expect, Tumbleweed is the openSUSE development platform… There is nothing stopping folks to get it working and release to the masses AND support. Just like slowroll is basically one person…
I guess I’ll take my chances.
Talking about supported is a bit weird though, as technically Tumbleweed is not supported other than by the willingness of the community. It’s FOSS and without a support contract with in this case SUSE, you are SOL regardless if you are unable to figure things out yourself or the community at large cannot help you.
At the same time, the package “transactional-update” is in the Base:System repo, which makes it very much an official part of the Tumbleweed ecosystem.
So let’s not confuse the topic with discussions about ‘support’. As long as it is in the official repos, it’s ‘supported’ functionality. It may go away, or it may not, but until that time… Doubt this part is going though, as it is also used by MicroOS.
I had a look at the script (it’s a shell script) and it is basically creating a new snapshot of the current running snapshot, chrooting into it, running an update with zypper dup. It has some fancy smancy integrity checks that it’s doing as well as some cleanup, but it’s not all that terribly exciting. If you fancied, you could do it yourself. I don’t, cause this is easier. 
Regarding my personal experience with transactional-update
I have been using TU (transactional-update) for the last 2 months and it works very well on Tumbleweed / Slowroll. Has already saved me from some bad updates, including virtiofsd one and some others I can’t remember.
The cool thing about TU is that it does not apply the updates on your currently running snapshot ever, or the currently running system (unless you want it to) and it will fail gracefully when zypper dup fails to install a package. With the power of atomic updates, your system would never be in an inconsistent state due to an upgrade failing halfway through due to power loss, crash, etc. or simply because you chose to ignore a failing-to-install package during a large dup and forgot to follow through with a fix afterwards.
It provides the administrator (you) a fairly easy method of performing trial and error manual updates if something does go wrong with the automated update (mostly due to scripts associated with a package failing). All without affecting your current snapshot/system, having to switch to a console TTY, or rebooting into a read-only snapshot to perform snapper rollback.
The principle of how it works:
Creates a new read-write snapshot of the current default snapshot/subvolume you’re in.
All actions are performed within a chroot inside this new snapshot without affecting your current snapshot/system. E.g., calls zypper dup / in / rm / etc. on this new snapshot subvolume using zypper’s -R flag.
If the zypper action succeeds, then the newly created snapshot is set as the new default subvolume, otherwise the new snapshot is discarded.
Your next reboot will take you into the new default snapshot or you can tell TU to apply the updates live on your current running system by replacing the currently running /usr, /boot, etc.
How to use it:
I use it mainly for nightly dups, but I will share some of my personal notes here (all commands to be run as root or with sudo).
Installing TU:
zypper in transactional-update
# this systemd service is required to create RPM dirs in /var as TU does not mount /var in the new snapshot to maintain atomicity.
systemctl enable --now create-dirs-from-rpmdb.service
Performing a dup and reboot:
transactional-update --drop-if-no-change cleanup reboot dup
# See transactional-update --help
My nightly dup systemd timer’s service file, just for reference as you will need to adapt it for your own use:
#/etc/systemd/system/bkupd.service
[Unit]
Description=Backup and transactional update/reboot
[Service]
Type=oneshot
ExecStartPre=/usr/local/bin/check-device
ExecStartPre=/usr/bin/borgmatic --verbosity 1 --syslog-verbosity 1
ExecStartPre=/usr/bin/snapper -c root create -c number -d 'RO snap before dup'
ExecStartPre=-/usr/bin/zypperoni ref
ExecStartPre=-/usr/bin/zypperoni --no-confirm dup-download
ExecStart=/usr/sbin/transactional-update apply cleanup dup
ExecStartPost=/usr/bin/systemctl restart kdump.service
ExecStartPost=/usr/bin/systemctl restart kexec-load.service
#ExecStartPost=/usr/bin/systemctl reboot
@throttlemeister that all depends on the Maintainer, whilst it exists the Maintainer may have it targeted for a specific use case.
But as others have indicated, it works for them today, it may not tomorrow…
The developers/maintainers have targeted it for the following 3 platforms:
From the Bugzilla report, it seems they are removing [3] as it no longer makes sense to keep that in the default Tumbleweed/Leap installer as MicroOS exists. I have asked for clarification anyway just to make sure 
IMHO such tools are often used by ppl which do not have much interest in learning something about their system. It is an easy way out of any problem and out of all chances to learn something. This would only be acceptable when it is used on a high availability server use case…
As ext4 (ext3) user since some decades, there was never a need for such tools. Never had a fatal data loss, nor a case where such tools were needed.
It is funny when users which never learned how to maintain a system their self, insist that such tools are the best and you absolutely need them. Even on systems where they are not intended for…
For systems which are designed for transactional-update like the immutable ones, it is necessary to use it. But not on standard OS like Leap and Tumbleweed.
My 2 cents…
@pavinjoseph I suggest you create a openSUSE SDB article, you might also want to describe your setup (prerequisites), what it needs, what filesystems it supports etc what is zypperoni?
@hui likewise, I use btrfs and xfs, no snapper, no rollbacks required, no home/devel repos I don’t even have mine added (just a local plain rpm repo), nor do I use the non-oss one. It’s a development system and as close as possible to Tumbleweed as it can be…
But I digress…