Transactional-update

English Open Chat
41

@karlmistelberger and @pavinjoseph have you tried the other plethora of transactional-update options eg apply, rollback etc?

42

The reference is GitHub - openSUSE/transactional-update: Atomic updates for Linux operating systems. opensuse Tumbleweed users may safely ignore “openSUSE Tumbleweed “Transactional Server” role” being removed. The removal won’t affect them. Kubic may be dead. However concepts explained in The Transactional Update Guide persist. Users considering transactional updates may want to read about the concepts.

1 Like
43

@karlmistelberger OK, so will it work (as per the documentation you have referenced) to install rpms and update the bootloader on my r/w system?

As per the bug report, going forward that may not be the case when the Tumbleweed role is removed…

Don’t get me wrong, it works great on my MicroOS and Aeon setups, in fact they have never had to rollback (fingers crossed…).

44

Yep, I use apply for my nightly dup, saves me from having to reboot.
rollback is useful to discard an update/snapshot for whatever reason, especially when troubleshooting a failing dup. Have used it in the past without issues.

45

apply doesn’t do live patching of kernel updates, though, does it?

46

Nope! Have to reboot for that :sweat_smile:

1 Like
47

So basically the same thing you’d have with a regular dup. I assume the same is true for libraries that are updated while in use - restarting those services/applications would also be needed after doing an apply.

48

The man page has only one note for read-write systems -

“On read-write systems please be aware that all changes done to the running root filesystem after snapshot creation are lost after the next reboot. For this reason the system should be rebooted as fast as possible after a successful update.”

Of course, because of potential changes to /etc. the above advice to reboot as soon as possible applies to opensuse’s immutable systems as well.

Because of how it works, there is no reasonable reason to believe that it required a read-only root filesystem.

It’s very unfortunate to see that Suse created a better way to patch your systems to then have the community turn around and keep recommending against it.

49

Yes, I do zypper ps -s to get the list of processes to restart. Usually it’s just chrome.
apply is very much like a normal dup with the disadvantage of zypper not automatically restarting services.

Of course one gets the benefits of an atomic dup with TU.
It will be interesting to see how apply handles a major DE upgrade, I’m waiting for Gnome 46 to trickle down to Slowroll.

1 Like
50

I am testing for several weeks now. I use plain zypper install, zypper dup and others as well as transactional-update. In the end you get the same upgrade.

1 Like
51

@mhurron It’s not about recommending against it, it’s making sure the folks recommending it understand that the majority of users, are just that users.

Introducing something outside the normal practices for Tumbleweed (dup) and Leap (up/patch) on normal r/w installed systems can have unintended consequences and need to be well documented, transactional-update does more that just a dup…

1 Like
52

The job of stressing dup to update tumbleweed is pretty poorly done, so it’s not like it would be messing anything up.

And quite frankly, all the benefits to normal users that transactional-update brings mean it should have been brought to the forefront the moment it was stable and should be a selling point of using opensuse distros.

53

Completely agreed, Malcolm.

I tried this for my update to GNOME 46. Anyone reading this please note that I am in no way advocating this as a way to perform this upgrade. I tried it as an experiment.

Here’s what I did:

  1. I disabled all GNOME extensions prior to rebooting.
  2. I did all my usual prep for performing an upgrade (I shut down non-essential services and applications).
  3. I did not exit my GNOME desktop environment (something I would have likely done if I were not using transactional-update
  4. I ran sudo transactional-update

The update failed, because I use the proprietary nVidia driver, and there was an update to that driver that required agreeing with the license.

  1. I re-ran sudo transactional-update dup -i - as I was unable to get --auto-agree-with-licensees to work (I tried before and after the dup)
  2. I immediately rebooted the system once the upgrade was completed.
  3. Upon reboot, GNOME 46 launched and promptly gave me the “Oh no, something went wrong!” screen. (This seems to happen to me every time I upgrade GNOME, regardless of whether I have extensions enabled or not). I restarted GNOME by switching back to the single-user target and back again to the multi-user target.
  4. I re-enabled my extensions and found a couple that were incompatible with GNOME 46 (one of them - Caffeine - is now a part of GNOME, apparently. The other, dash to dock, has a fix in its git repo.

All in all, it worked, but it didn’t really seem to make things easier or really any “safer”. Had the upgrade installed successfully but failed to work after a reboot, I’d have been going back to an earlier snapshot either way. The only real protection I would have received would have been if the upgrade itself had errored out (as it did when it took the default of not accepting the nVidia license), and not being aware of if I have any packages that were updated outside of the part of the filesystem that was snapshotted, that could have led to further troubleshooting had the upgrade been successful in installing but failed in terms of breaking the system post-upgrade (arguably, this would be the case with or without using transactional-update, since at that point, it’s all about the normal use of snapshots for recovery).

It added steps for what, to me, seems little to no return. If the upgrade failed with or without it, I’d have been using a read-only snapshot to back out. If the user has concerns about a failed download messing up the upgrade, it does afford some protection for that, but you can also use zypper dup -d to just download the upgrade packages without applying them - then make sure they’ve downloaded correctly, and then apply the upgrade.

The additional step of running in interactive mode or otherwise finding a way to deal with solver issues (which I didn’t have, but I can see also being an issue) as well as other things like license agreement requirements that may come up during a dup leads me to conclude that for myself (and probably most users), this isn’t the way to do a system upgrade.

For more advanced users who know what they’re doing, I can see some benefits. For me, not enough to make it part of my regular upgrade process, nor really enough for me to think that it’s a recommendation that I’m comfortable giving. There are just too many caveats along the way. If you don’t have solver issues, if you don’t use packages that require a separate license agreement, if you remember to reboot right away after the upgrade to apply kernel updates (or run transactional-update apply) or you end up potentially modifying things in the current system that get wiped out post-upgrade when you reboot or otherwise activate the changes.

That’s a lot for an inexperienced user to have to deal with and remember.

So I’ll not be recommending this for general users based on my own experience.

It’s really easy for advanced users to forget what it’s like to be a new user or to lack experience. What seems easy to us is completely foreign to those who lack that experience.

54

“Normal users” don’t want anything to do with command-line interfaces.

Just as a point of calibration data.

55

@mhurron but Tumbleweed is not about today, it’s about Tomorrow, today it works, tomorrow it may not…

1 Like
56

Yet ‘the normal practices for Tumbleweed (dup)’ is very literally, open a terminal or exit out of your GUI session entirely and run zypper dup

transactional-update dup is safer and is not really any different than the existing recommended way.

You can also stop pretending ‘users’ are touched in the head and realize that there are some expectations with using Tumbleweed already and fear of the command line is antithetical to that.

And it’ll work tomorrow, it is the basis of MicroOS and it’s offshoots. If it became ‘the way’ focus would be on it continuing to work.

transactional-update is a better way than rpm was before, it’s a better way than zypper/yum/dnf/apt are now.

57

tup does the same as dup, but in a different manner, with the same result:

Options: cleanup dup reboot
2024-03-21 16:37:11 Options: call 2738 zypper --no-cd dup -y --auto-agree-with-product-licenses
2024-03-21 16:37:11 Executing `zypper --no-cd dup -y --auto-agree-with-product-licenses`:
The following 3034 packages are going to be upgraded:
The following 33 patterns are going to be upgraded:
The following product is going to be upgraded:
The following 3 packages are going to change architecture:
The following 575 NEW packages are going to be installed:
The following 252 packages are going to be REMOVED:
The following package requires a system reboot:
The following package is going to be REMOVED:
Warning: The following files were changed in the snapshot, but are shadowed by

As dup affects running processes anything can happen. tup won’t interfere with running processes. If you don’t know what you are doing don’t use it.

58

You’re talking about ‘normal users’ in a way that is actually antithetical to the audience itself. Yes, Tumbleweed does expect more from the user. But to say that ‘normal users’ are fine with the command line is to not really understand who the ‘normal users’ are.

I don’t know how much you read here in the forums. I read a bit every day, and I constantly see people who run TW who are averse to running any command-line utilities, even to the extent of pulling log files. This is not a case of “pretending ‘users’ are touched in the head”, but the reality of what users coming to Linux in general are expecting. They’re coming from Windows or MacOS, where everything is done in the GUI. They come to Linux and OMG, I have to learn how to use a command-line? What if I mistype something and trash my system?

It may not be an entirely rational fear, but it is most certainly there.

I detailed my experience using transactional-update to upgrade my system just yesterday. It was more involved than the way I would have normally done it, and it was really no more safe than how I would have done it normally.

I’ve been a Linux user for about 26 years now. I’ve trained people on how to use Linux systems (I used to teach classes on running a particular identity technology on both RedHat and SUSE Linux). I’ve seen the trepedation on even system administrators’ faces who have only dealt with Windows Server being told that they’re going to have to learn some CLI stuff to run it on Linux.

Those of us who have used it for years and years forget what it is to be new to the technology. This is not me assuming that “normal users” aren’t “smart enough” to use it. This is me speaking from the experience of having worked with even IT professionals who look at Linux with anxiety when they haven’t used it extensively, or who came up during a time when administering everything through a GUI has been the “normal” way to do things.

Using transactiona-update dup adds additional steps and things to take into consideration, which I detailed already.

So again, I will not be recommending it to normal users. It’s fine by me if you want to take those extra steps and perceive it as being somehow ‘safer’ than the normal way of doing an upgrade. You want to do that, knock yourself out. You’re an advanced user and you know what you’re doing and how to recover from it if something goes wrong. Good for you.

You are not a “normal” user. Just remember that.

1 Like
59

@mhurron again, it’s about folks writing up some (up to date) documentation about expectations, use cases etc before advising our Forum users, hey do this…

But they’re your system(s), it’s all about the ability to do whatever works for you :smile:

The bigger but is, when users introduce something new in this Forum that there is an expectation (FAQ Technical Merit) users are prepared to stand behind it, in this case document it and support it…

60

@hendersj and as of today, the KDE Theme thread trashing users systems…