Strongly disagree with this statement.
Quite the contrary it provides the user/admin with a playground in which they can trial and error to their heart’s content without affecting the current system.
From my previous post
Thanks, I was planning to write a longer article for OpenSuse documenting backups/restore as well, but adding an article to SDB for TU sounds a lot less work so I will start with that
zypperoni is just a little program I put together to async refresh repos and download packages.
Yes there was, they just didn’t exist so you had to bend over backwards to provide some other way of providing the same safety.
The Plasma6 upgrade is a good example, you had to exit out of your session, preferrably completely exit out of a GUI session and then run zypper dup Running patches always ran a risk of restarting services under you and the results of that depend on what the service was doing.
Unless you ran transactional-update which performs the update on a snapshot, not touching the running system and then rebooting into it. Running processes aren’t impacted by changing data or libraries under them and having god knows what’s going to happen.
All valid ways to test an update
But in reality it would be much easier to test why a package is failing to install during dup on your main machine without having to reproduce it package-for-package in a VM.
A normal TW user would perform this on their currently running snapshot and rollback in case there are issues. A TU user would perform this in a new snapshot without affecting the current system, if they get it wrong, discard snapshot and try again. No reboot or rollback required.
@pavinjoseph then perhaps package it up and submit for inclusion in Factory?
Other things to look at, where are your systemd conditionals for AC present, what about inhibitors for suspend to not run or abort, run the tu X minutes or hours after turn on etc…
Incorrect. If it only lives in Base:System that is a development repository.
The only “Official” Sources for software in Tumbleweed are in the OSS, Non-OSS, OpenH264 and whatever other repos you find on a fresh clean install.
Defining “Support” is absolutely a valid discussion to have, even within the context of Tumbleweed, as the “Development Product” of openSUSE.
Good idea, I have much to learn when it comes to packaging for distros in general. I’ve un-packaed and re-packed debian packages when their scripts were proving to be a problem but never packaged one myself much less an RPM
Thankfully it may not be required though, zypper async updates are officially coming soon
Those are in my check-device script. It currently checks the device (laptop) is not on battery or metered network. If I need to skip update(s), I have to manually disable the timer, not the best way to go about it. If you have any advice it would be appreciated!
what about inhibitors for suspend to not run or abort, run the tu X minutes or hours after turn on etc…
This is not implemented by choice, my machine is always on and connected to power. If it’s suspended there must be a reason and I don’t want it to wake up magically!
This is a great idea
Now I understand why @karlmistelberger suggested to have backup and update as separate services.
I would want to delete an incomplete/bad backup, zypperoni cleans up after itself and TU doesn’t require any cleanup (TU’s atomicity would ensure either the whole update is applied or nothing is applied. There cannot be an in-between state).
I think so far I’ve gotten away with it as borgmatic config includes its own cleanup (just the mounts, not the incomplete backup itself) and brownouts may have happened in the night, but as this is a laptop with a battery it probably shrugged it off
freiburg:~ # transactional-update
Checking for newer version.
transactional-update 4.6.0 started
Options:
Separate /var detected.
2024-03-23 07:49:04 tukit 4.6.0 started
2024-03-23 07:49:04 Options: -c841 open
2024-03-23 07:49:04 Using snapshot 841 as base for new snapshot 842.
ID: 842
2024-03-23 07:49:04 Transaction completed.
Calling zypper --no-cd dup
zypper: nothing to update
Removing snapshot #842...
2024-03-23 07:49:05 tukit 4.6.0 started
2024-03-23 07:49:05 Options: abort 842
2024-03-23 07:49:05 Discarding snapshot 842.
2024-03-23 07:49:05 Transaction completed.
transactional-update finished
freiburg:~ #
freiburg got an unattended scheduled upgrade and reboot:
freiburg:~ # journalctl -b -1 -u transactional-update.service -g 'following|reboot'
Mar 23 00:00:43 freiburg transactional-update[16761]: Options: cleanup dup reboot
Mar 23 00:00:48 freiburg transactional-update[18126]: The following 24 packages are going to be upgraded:
Mar 23 00:00:48 freiburg transactional-update[18126]: The following product is going to be upgraded:
Mar 23 00:00:48 freiburg transactional-update[18126]: The following 2 packages are going to be downgraded:
Mar 23 00:01:43 freiburg transactional-update[27612]: 2024-03-23 00:01:43 Options: reboot auto
Mar 23 00:01:43 freiburg transactional-update[27612]: 2024-03-23 00:01:43 Triggering reboot using systemd
freiburg:~ #
transactional-update runs in non-live partial environment (at least on MicroOS it does not mount everything inside new snapshot, I did not check on Tumbleweed), so you may hit packages incompatible with it. Even on MicroOS I remember issues stemming from nor having specific mount point available during update. MicroOS has much more limited package selection and is less likely to hit it.
It will be on your side to troubleshoot the issues, find the root cause and likely to offer a patch. And even then developers may not accept your patch if it happens to be in conflict with the main use case - MicroOS.
“Unsupported” means that developers will unlikely work on problems you encounter.
Of course you are free to step in and do it yourself which is exactly what FOSS is about. You just cannot expect anyone will do it for you.
transactional-update.service basically snapshots the current subvolume (read/write), dups the snapshot, makes the upgraded snapshot the default subvolume and boots into the upgrade (read/write).
13 Transactional updates
Transactional updates are available in SUSE Linux Enterprise Server as a technology preview, for updating SLES when the root file system is read-only.
Your github link;
Know Users
Transactional-update was originally developed for the openSUSE project as the update mechanism for all transactional / read-only systems (openSUSE MicroOS, SUSE Linux Enterprise Micro, SUSE Linux Enterprise Server / openSUSE Leap / openSUSE Tumbleweed “Transactional Server” role) and is used as the update mechanism there.
The role (in bold) is what the bug report refers to which is going to be removed.
4.1. Read-only file system
transactional-update is typically used on a read-only root file system, even though it also supports regular read-write systems.
