Transactional-update

English Open Chat
61

Yeah, and using transactional-update won’t protect from that (It actually was on Reddit a few days ago) since that’s a plasma widget installed to the user’s home directory. That was a nasty bug, though - didn’t appear to be anything intentionally malicious about it).

I think the thing that the ‘advocates’ are dismissing too easily (or not considering) is that with MicroOS and transactional-update, the RO nature of the systemroot partition means that the transactional update is truly atomic. You’re either running the old RO systemroot or the new one after a reboot.

But if you don’t reboot after running transactional-update on a RW systemroot, you’re effectively breaking the atomic nature of the update, because any change to the RW systemroot before a reboot is lost. Depending on those changes, they could range from innocuous and “I thought I installed x and it’s gone” to changing things that affect stuff outside the snapshot in a particularly bad way.

Using apply can get around this, if you know what you’re doing and are paying attention. But again, only if you apply immediately after running the upgrade, and only if you’re paying attention and know what you’re doing. I think a lot depends on how apply actually deals with the changes on a live partition.

In a normal update, for instance, if a library is replaced but it is in use, the inode stays open, and the space on the device isn’t freed until it’s no longer in use (that’s my understanding - and is why zypper ps -s can tell you what open files are in use on the system so you can restart processes that are holding those inodes open).

Does apply do the same thing? I honestly don’t know. But if it doesn’t, that could be pretty bad for system stability.

For me, aside from the fact that I saw no real significant difference between using transactional-update to upgrade to the TW release that included GNOME 46 - apart from it adding additional steps to deal with accepting the nVidia driver license - the fact that it breaks the atomic nature of the update unless you do a reboot right afterwards anyways, and if you don’t, then you can end up with an inconsistent system because the snapshot with the updates doesn’t know about any writes to those volumes after the upgrade is done…That just seems like its potentially a recipe for a mess.

4 Likes
62

/etc is writable in MicroOS.

63

Yep.

But I think that’s part of the calculus for using it on MicroOS - and a reboot is typically what you would do after applying an update/upgrade on MicroOS as well, to my knowledge.

I don’t know a lot about what safeguards are in place to deal with potential issues that arise from using apply when looking at libraries like glibc being updated, or services being restarted.

MicroOS’ automated update using transactional-update runs as a service and reboots the system when an update has been applied. I understand on Neon and Kalpa, the user gets a notification to reboot rather than an automatic reboot.

So when used with MicroOS, the window for changes to be made to /etc that would be system-breaking is vanishingly small.

64

@hendersj On MicroOS I’ve only used (or use apply) if installing package(s) to supplement, every thing else is a dup/reboot or automatic overnight via rebootmgr…

1 Like
65

By default, on MicroOS or Leap Micro, after the automated transactional-update dup runs, during the maintenance window, the system is automatically going to reboot as part of that process.

On Aeon/Kalpa, after the dup is run during the maintenance window, we leverage dbus, to do a high priority notify-send that instructs the user to reboot their system, as it’s incredibly annoying on a desktop to have it reboot in the middle of doing something, without any warning.

Now, on Aeon/Kalpa, lets say you’re in running snapshot X, and it updates, creating X+1, but you choose not to reboot.

When the next maintenance window happens, transactional-update isn’t going to snapshot X+1, it’s going to snapshot X, so whatever changes you might have made in the rw parts of the system, such as /etc in the intervening time are going to be preserved.

I honestly haven’t a clue how that interaction works on a RW filesystem, if you choose not to reboot after updating. It may, or may not do the same thing.

1 Like
66

Exactly the same.

67

A normal user of Tumbleweed had better get comfortable with a terminal. Again, the default suggested way to update the system is drop to a cli, preferably by exiting out of your GUI system entirely, and running zypper dup. transactional-update dup actually makes that more friendly, you just need to open whatever terminal you want to use, type transactional-update dup and get greeted with the exact same output you were going to get before.

If you are scared of the cli, you should not be using a rolling release, you are going to have a bad time. Tumbleweed expects more, command line usage is one of those things. If you can not deal with that, if you absolutely must have a GUI for everything, Tumbleweed is the wrong distro for you.

I’m not the one claiming ‘normal users’ can’t, I’m saying they can and there’s no reason to pretend they can’t if the command is transactional-update but are perfectly capable of it as long as it’s zypper.

68

It has nothing to do with CLI vs GUI. Read what I and @hendersj wrote.

1 Like
69

I’m not saying they can’t. I’m saying that they’re less comfortable than more advanced users.

Please read and understand what I’m saying. Using transactional-update has additional considerations that “normal” Linux users aren’t well-versed in. Can they learn? Sure.

Is learning as an adult an easy thing? For some people, yes. For others, it isn’t.

Look, I’ve spent a fair amount of my career working in adult education - specifically around technical education. I understand how adults learn technical skills, and the barriers that are in place (mostly self-imposed). It takes more than just saying “you can do this” and then pointing at the documentation.

There is a difference between following a set of instructions and actually understanding the implications of what you’re doing, and that understanding generally doesn’t come from following a procedure.

But when something unexpected happens in that procedure - results that were unexpected, etc - that’s when actually understanding the implications of what you’re doing becomes important.

So just saying “yeah, do this thing that the people who created it don’t recommend you do is fine” puts peoples’ systems at risk.

Even those who recommend it don’t really seem to understand the full implications of treating transactional-update as just “another way to run zypper dup”. Y’all say it’s “safer” - but can’t really demonstrate that it is, because there are bad assumptions being made about how transactional-update works. You say “the documentation says you can use it on RW filesystems just fine” (emphasis mine), but just because you can doesn’t mean you should, at least not without understanding the ramifications of doing it.

I can also run rm -rf --no-preserve-root / on my system. Should I? Probably not, unless I want to completely trash my system.

I mean, the documentation for rm tells me explicitly that if I want to override the special protection for root, I can do that, right?

That’s what makes the argument “the documentation says I can” a really poor argument in favor of it. Documentation simply documents the capabilities. It doesn’t tell you whether or not it applies to your situation because the documentation cannot cover every potential situation. It’s up to the user to understand the implications of the actions they’re about to undertake, and when people who know a lot more than I do about how these things work (ie, the developers working on these parts of the system) say “I don’t think that’s a good idea”, I tend to listen to what they have to say. After all, they did build the thing.

That doesn’t mean there can’t be other ways of doing things, and like I said before, if you want to take the risk on your systems, go ahead. You’ve got the experience and expertise to understand if that method is right for you.

But encouraging people without that experience to give it a try is simply dangerous and irresponsible. You’re not going to be the ones (most likely) dealing with the fallout of an upgrade gone wrong. Yeah, you might be there to help them.

At best, using transactional-update in this manner should be considered experimental at best.

Like I shared before, I tried it. I gave it a fair shake. I did not go into running it on my real, live, production system saying “I hope this fails spectacularly”. I went in with an open mind, I noted what worked and what didn’t. The issues for me were relatively minor. But all it did was add an unnecessary step to my process for running zypper dup. It didn’t make the upgrade “safer” in any way whatsoever. All it did, for me, was add unnecessary complexity.

4 Likes
70

All Tumbleweed installs I manage use System Role “Desktop with KDE Plasma”. Partitioning is Super Simple:

3400g:~ # fdisk -o Device,Size,Type -l /dev/nvme0n1 
Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: Samsung SSD 950 PRO 512GB               
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A84F222E-0177-499B-A7EA-BDA6F31E2196

Device           Size Type
/dev/nvme0n1p1   100M EFI System
/dev/nvme0n1p2 476.8G Linux filesystem
3400g:~ #

Default subvolumes are used:

3400g:~ # lsblk -o Path,Fstype,Mountpoints /dev/nvme0n1p2
PATH           FSTYPE MOUNTPOINTS
/dev/nvme0n1p2 btrfs  /var
                      /usr/local
                      /srv
                      /root
                      /opt
                      /home
                      /boot/grub2/x86_64-efi
                      /boot/grub2/i386-pc
                      /.snapshots
                      /
3400g:~ #

Snapper is enabled:

3400g:~ # snapper list
    # | Type   | Pre # | Date                     | User | Cleanup | Description              | Userdata     
------+--------+-------+--------------------------+------+---------+--------------------------+--------------
   0  | single |       |                          | root |         | current                  |              
2686  | single |       | Thu Nov  2 09:20:02 2023 | root |         | writeable 20230810T1905  |              
2689  | single |       | Fri Nov  3 14:00:00 2023 | root |         | writeable 20230822T1648  |              
2724  | pre    |       | Mon Jan  1 09:36:52 2024 | root | number  | zypp(zypper)             | important=yes
2725  | post   |  2724 | Mon Jan  1 09:36:57 2024 | root | number  |                          | important=yes
2728  | pre    |       | Thu Jan  4 06:56:59 2024 | root | number  | zypp(zypper)             | important=yes
2729  | post   |  2728 | Thu Jan  4 06:57:01 2024 | root | number  |                          | important=yes
2730  | pre    |       | Thu Jan  4 06:58:56 2024 | root | number  | zypp(zypper)             | important=yes
2731  | post   |  2730 | Thu Jan  4 06:59:00 2024 | root | number  |                          | important=yes
2732  | single |       | Thu Jan  4 07:28:53 2024 | root | number  | rollback backup of #2695 | important=yes
2739  | pre    |       | Thu Mar 21 18:32:50 2024 | root | number  | zypp(zypper)             | important=no 
2740  | post   |  2739 | Thu Mar 21 18:32:55 2024 | root | number  |                          | important=no 
2741  | pre    |       | Thu Mar 21 18:46:21 2024 | root | number  | yast remote              |              
2742  | post   |  2741 | Thu Mar 21 19:06:40 2024 | root | number  |                          |              
2743  | pre    |       | Thu Mar 21 19:06:48 2024 | root | number  | yast remote              |              
2744  | post   |  2743 | Thu Mar 21 19:08:03 2024 | root | number  |                          |              
2745  | pre    |       | Thu Mar 21 21:14:09 2024 | root | number  | zypp(zypper)             | important=no 
2746  | post   |  2745 | Thu Mar 21 21:14:35 2024 | root | number  |                          | important=no 
2747  | single |       | Thu Mar 21 22:34:43 2024 | root | number  | Snapshot Update of #2738 |              
2748  | pre    |       | Fri Mar 22 05:50:43 2024 | root | number  | zypp(zypper)             | important=no 
2749  | post   |  2748 | Fri Mar 22 05:50:53 2024 | root | number  |                          | important=no 
2750  | pre    |       | Fri Mar 22 07:58:12 2024 | root | number  | zypp(zypper)             | important=yes
2751  | post   |  2750 | Fri Mar 22 07:58:22 2024 | root | number  |                          | important=yes
2752  | single |       | Fri Mar 22 22:24:07 2024 | root | number  | Snapshot Update of #2747 |              
2753  | pre    |       | Sat Mar 23 06:56:03 2024 | root | number  | zypp(zypper)             | important=no 
2754  | post   |  2753 | Sat Mar 23 06:56:10 2024 | root | number  |                          | important=no 
2755  | single |       | Sat Mar 23 21:34:21 2024 | root | number  | rollback backup of #2752 | important=yes
2756  | single |       | Sat Mar 23 21:34:21 2024 | root |         | writable copy of #2747   |              
2757* | single |       | Sat Mar 23 21:37:05 2024 | root | number  | Snapshot Update of #2756 |              
2758  | pre    |       | Sun Mar 24 06:35:36 2024 | root | number  | zypp(zypper)             | important=no 
2759  | post   |  2758 | Sun Mar 24 06:35:42 2024 | root | number  |                          | important=no 
3400g:~ #

  • Snapper deals with both: zypper dist-upgrade (dup) and transactional-update (tup).

  • Current system is #2757*, created by running systemctl start transactional-update.service.

  • zypper remove sysconfig-netconfig created pair #2758/2759

  • systemctl start transactional-update results in:

3400g:~ # journalctl --since 7:00 -u transactional-update.service 
Mar 24 07:18:32 3400g systemd[1]: Starting Update the system...
Mar 24 07:18:32 3400g transactional-update[4236]: Checking for newer version.
Mar 24 07:18:34 3400g transactional-update[4236]: transactional-update 4.6.0 started
Mar 24 07:18:34 3400g transactional-update[4236]: Options: cleanup dup reboot
Mar 24 07:18:34 3400g transactional-update[4236]: Separate /var detected.
Mar 24 07:18:34 3400g transactional-update[4236]: Adding cleanup algorithm to snapshot #2756
Mar 24 07:18:35 3400g transactional-update[4236]: 2024-03-24 07:18:35 tukit 4.6.0 started
Mar 24 07:18:35 3400g transactional-update[4236]: 2024-03-24 07:18:35 Options: -c2757 open
Mar 24 07:18:35 3400g transactional-update[4236]: 2024-03-24 07:18:35 Using snapshot 2757 as base for new snapshot 2760.
Mar 24 07:18:35 3400g transactional-update[4236]: ID: 2760
Mar 24 07:18:35 3400g transactional-update[4236]: 2024-03-24 07:18:35 Transaction completed.
Mar 24 07:18:35 3400g transactional-update[4236]: Calling zypper --no-cd dup
Mar 24 07:18:36 3400g transactional-update[4236]: zypper: nothing to update
Mar 24 07:18:36 3400g transactional-update[4237]: Removing snapshot #2760...
Mar 24 07:18:36 3400g transactional-update[5545]: 2024-03-24 07:18:36 tukit 4.6.0 started
Mar 24 07:18:36 3400g transactional-update[5545]: 2024-03-24 07:18:36 Options: abort 2760
Mar 24 07:18:36 3400g transactional-update[5545]: 2024-03-24 07:18:36 Discarding snapshot 2760.
Mar 24 07:18:37 3400g transactional-update[5545]: 2024-03-24 07:18:37 Transaction completed.
Mar 24 07:18:37 3400g transactional-update[4236]: transactional-update finished
Mar 24 07:18:37 3400g systemd[1]: transactional-update.service: Deactivated successfully.
Mar 24 07:18:37 3400g systemd[1]: Finished Update the system.
Mar 24 07:18:37 3400g systemd[1]: transactional-update.service: Consumed 2.342s CPU time.
3400g:~ #

Nothing to do.

  • systemctl start dup results in:
3400g:~ # journalctl --since 7:00 -u dup.service 
Mar 24 07:20:42 3400g systemd[1]: Starting Dist Upgrade...
Mar 24 07:20:42 3400g nm-online[6183]: [41B blob data]
Mar 24 07:20:42 3400g systemd[1]: Started Dist Upgrade.
Mar 24 07:20:42 3400g zypper[6189]: Loading repository data...
Mar 24 07:20:43 3400g zypper[6189]: Reading installed packages...
Mar 24 07:20:43 3400g zypper[6189]: Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this co>
Mar 24 07:20:43 3400g zypper[6189]: Computing distribution upgrade...
Mar 24 07:20:43 3400g zypper[6189]: Nothing to do.
Mar 24 07:20:43 3400g systemd[1]: dup.service: Deactivated successfully.
Mar 24 07:20:43 3400g systemd[1]: dup.service: Consumed 1.110s CPU time.
3400g:~ #

Nothing to do.

  • With pending upgrades dup and tup would install the same packages. The only difference is the default subvolume.

  • dup applies the upgrade to the current default subvolume.

  • tup snapshots the current default subvolume, applies the upgrade to the snapshot, makes the snapshot the default subvolume and reboots into the new default.

  • transactional-update.service can be readily modified using systemctl edit transactional-update.service.

  • Performing some exercises helps in understanding what is going on. Snapshots #2686 /2689 are restored from Backup at /HDD/btrbk_snapshots/3400g/ROOT.20230810T1905 and /HDD/btrbk_snapshots/3400g/ROOT.20230822T1648.

  • snapper rollback works readily with all of the snapshots, no matter whether they were created by dup, tup or restore from backup. Rolled back from tup and tuped again #2752/2755/2757:

2752  | single |       | Fri Mar 22 22:24:07 2024 | root | number  | Snapshot Update of #2747 |              
2755  | single |       | Sat Mar 23 21:34:21 2024 | root | number  | rollback backup of #2752 | important=yes
2756  | single |       | Sat Mar 23 21:34:21 2024 | root | number  | writable copy of #2747   |              
2757* | single |       | Sat Mar 23 21:37:05 2024 | root | number  | Snapshot Update of #2756 |
1 Like
71

Hello everyone,

I thought to share the rather disappointing :sweat: but not yet alarming updates from the Bugzilla report on the future of transactional-update.

  1. For now, they’re simply removing the transactional server role from Yast installer. As an alternative you can use MicroOS installer for the same functionality.
  2. But in the future, transactional-update may not be supported on read-write systems if it conflicts with new features for read-only systems which is their primary and I would say only focus (as per this comment).

This is obviously very bad, I’ve never seen a project advertise a functionality and then remove it after several years (and several thousand users relaying on it) simply because that wasn’t their focus. Wth! Why advertise such a feature if it wasn’t their focus all along simply to entice people to try their new software?! :roll_eyes:

72

The only advertising was from some users, which used it in a way not intended by the devs. And the same users didn’t believe the warnings from the experienced, long standing openSUSE users, that transactional-update is officially not supported on Tumbleweed.

Wrong calculation. Most users know that the intended and documented way of upgrading Tumbleweed is via zypper dup. There was only a handfull of ppl which tried to use other ways like transactional-update on Tumbleweed.
You can do it on your machine. It is yours. But don’t expect any official support when it is not intended for the usecase.

73

The developers very much intended for it to be used in read-write systems!

From the docs [emphasis mine]

transactional-update is typically used on a read-only root file system, even though it also supports regular read-write systems.

And several times in the manpage

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.

Sets the default root file system. On a read-only system the root file system is set directly using btrfs. On read-write systems snapper(8) rollback is called.

Well, I obviously stand corrected that the docs and manpages written by OpenSuse are not to be trusted ever and should instead consult the forums for advice before using anything.

74

You seem to only nitpick the parts of the informations which fits your view. I can only recommend to open your mind and read again carefully through the given documentation and comments in this thread. Malcolm already pointed out (nearly at the beginning of this thread) that you are always refering to the documentation of the dead Kubic project. Again: This project is dead! It is no longer existing! It is retired! Did you miss the information?

75

I’m not cherry-picking. It’s the exact same content in the transactional-update manpages on my TW / Slowroll system:

pavin@suse-pc:~> man 8 transactional-update | grep -A2 read-write
       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.

--
           Sets the default root file system. On a read-only system the root file system is set directly using btrfs. On read-write systems snapper(8) rollback is
           called.

Not my fault the transactional-update info is still hosted on the Kubic website. Whether that project is retired in favor of newer ones the information still holds true (for now). Maybe they forgot to update the manpages, but I don’t think that is the case here. The devs deliberately created a feature, continued to support it and their priorities have now changed so far from their original goal that they’re now openly admitting a feature they’ve advertised and supported for years may be dropped anytime in the future because they don’t care about the users at all! :rage:

76

This is your point of view. It is your right. But still not true.

You should already know that software development is a dynamic process. Project goals change. Support starts and ends. Features get introduced and retired. Some users always complain and others help to shape the future.

77

Care to explain? :thinking:

78

This is pure flaming and not true.

And btw did you know that openSUSE is open source and build by volunteers? Stop complaining and help to shape the future of this distribution by productively contributing to this project. If you have ideas how to make transactional-update a better way for upgrading Tumbleweed, change the code, make pull requests, maintain it.

There are countless ways to productively contribute to a project. Twisting the facts and insulting the volunteers of openSUSE by claiming they don’t care is not one of it.

79

Simply saying not true over and over again without any explanation when I have provided evidence to the contrary does not make any sense whatsoever. :man_shrugging:

But you’re entitled to hold your opinion in the face of overwhelming evidence @hui.
Lots of people do that in this world, it’s their right as you said, of course.

1 Like
80

Hm, not in this thread…