Yep, that’s an error.
When using transactional-update dup it would have caused TU to discard the snapshot because zypper dup returned non-zero exit code.
To find the reason, search for the error message in:
/var/log/zypp/history
If you want to rollback, now would be a good time.
Then refresh repos and install transactional-update.
Then run: transactional-update shell.
This will create a new read-write snapshot (based on your current root fs subvolume) and drop you into a chroot environment in which you can test running zypper dup without affecting your currently running machine. If all goes well, you can exit out and systemctl reboot automatically into the new snapshot which will be your new default subvolume.
If the error happens again and you want to discard the working snapshot, exit 1 to tell TU it didn’t go well and no changes are made to your existing machine, reboot or not.
What is TU? TU means TW?
Thanks for the detailed instructions, however, they’re above my head. I’ll hire a Linux admin person to fix it.
TU is short for transactional-update 
You should be able to fix it though, it’s probably something silly. Here the failed part is related not to the installation but the post installation script. They package maintainer can’t account for every scenario so it would fail if you have some custom/conflicting configuration.
To see what’s it’s doing you can:
zypper download <pkg-name>
rpm -qp --scripts <path-to-downloaded-pkg>
I hired a Linux admin to install and configure my TW. I don’t know what custom non-standard things he did. I do know he installed apparmor so containerized pihole would work. That’s all I know.
As mentioned earlier, I have no idea which packages to check. I have no idea which ones are “standard” and which ones aren’t.
From the initial post, you would be downloading and checking the scripts of kernel-default package, which is the Linux kernel shipped by OpenSuse.
You can view the AppArmor policy by running:
sudo aa-status
See man 8 aa-status for more details.
1 Like
transactional-update is used with MicroOS, not with Tumbleweed.
The message you’re seeing here is related to snapd, and is likely harmless, but you can look at the logs to see what went wrong. It is likely correctable in TW; @pavinjoseph is correct that it would have caused transactional-update to discard the update entirely, but you’re not using MicroOS, so the path forward will be different.
1 Like
@hendersj TU’s docs state it can be used with both RO/RW systems. I use TU with my normal read-write TW install and it works just fine for what I use it for, i.e., in a systemd timer/service to automatically take offsite backups using borgbackup and if it succeeds to perform transactional-update cleanup reboot dup.
I recommend using it for dup to prevent these sorts of issues.
As a new user, would it not be better to troubleshoot critical tasks like dup within a safe environment rather than directly modifying the currently running system? I think so…
For example, a few days ago TU saved me when some manual modifications I had made to the PAM config as per Suse docs (remove symlink to common-auth-pc and edit common-auth as new file) caused a posttrans script that called pam-config to fail. This caused TU to fail, none of which affected my system.
I see in the morning, TU (the systemd service) has failed. Enter TU shell, look at the zypper logs and the posttrans script, realized manually managing PAM files would cause a benign yet troublesome exit code when posttrans scripts call pam-config and went back to using pam-config for managing the PAM files. Run zypper dup within the tu shell and this time everything went smoothly. At this point I exited out and TU recognized that as “ALL GOOD” and set that as the new default subvolume. Rebooted back into an updated working system.
1 Like
Has this anything to do with the general Tumbleweed user’s way of working?
1 Like
We advanced users do a lot of things that go against recommendations - and we usually get away with it as well because we have knowledge that lets us deal with the fallout.
To my knowledge, there is no generally-accepted recommendation to use TU on Tumbleweed, nor is there any testing of it in that environment as part of the TW builds.
There is absolutely no reason to complicate this issue by adding a layer of complexity that also is not generally tested nor given as a “best practice”.
It works for you on your system - that’s great. Let’s not confuse a relatively inexperienced user by adding an unnecessary layer of complexity to an issue that doesn’t need it.
5 Likes
@invalid_user_name - you can do this step without worrying about using transactional-update - just do this:
sudo less /var/log/zypp/history
Then when in ‘less’ press / and type posttrans\(kernel-default, and that will search for the line that has that message in it. Then look at what comes next.
Or you can copy/paste the relevant parts of that log file into a preformatted text block here (use the button that looks like </> in the toolbar in the editor), and we can look at it here.
I would grab from the %posttrans{kernel-default-6.7.5-1.1.x86_64) script output: line until the next line that starts with %posttrans.
That will tell us exactly what the post transaction script did and which commands failed (and likely why).
I ran this latest upgrade on a VM I have, but I didn’t see this particular message show up.
3 Likes
Yes! Good suggestion. I genuinely appreciate the replies and your efforts, but most of the replies discuss items way over my head. I’m not a technical user. AND I love it that Linux and many distros have gotten to the point where a newb like me can use them without too much trouble. (So happy to be off the surveillance advertising nightmare that is Windows.)
So my huge thanks to all the devs working hard to make Linux and distros newb friendly. Come to my place and I’ll buy all of you a beer! 
1 Like
Update and Issue Resolution, I ran zypper dup this morning and there were no errors listed at the end. So looks like the errors resolved themselves. My hat’s off to all the devs who created an OS that can fix its own errors.
As these messages are created by the post-installation script of a package (as I tried to explain), they will of course only been shown when a particular package is installed. At the next update it is unlikely (though not impossible), that the same package is updated again. Thus it is unlikely that the belonging post-installation script is run, thus no messages.
Thus this is no case of fixing any error at all.
2 Likes
I’m dragged back to reality. In any case, I’ll keep an eye out for future errors like these.
The system could be in an inconsistent state due to the posttrans script failing.
Your advice while practical is like ignoring all the warnings in an IDE because it’s not an immediate error/problem.
Also, the script that failed was for the Linux kernel itself. If it was a userspace app then I could perhaps see the point in not pursuing it further.
I don’t consider myself an advanced user, also I’m new to OpenSuse and Tumbleweed. This is why I recommend new users perform potentially system breaking actions inside a TU shell. If a new user can open a terminal and type in sudo zypper dup how can you say with a straight face it’s harder for them to do sudo transactional-update dup?
The whole point of using TU is that a new user can mess up as much and as many times as they want until they get it right. It’s a safe space to experiment, not unlike a VM. Okay, maybe that’s a little too much but you get the gist.
Who’re these people that come up with best practices, the people who write wikis? I’m sure if you ask the developer of TU, he would say it’s not an issue at all. I submitted a bug report accidentally in TU’s Github instead of Bugzilla (see, new user!) and the fact I’m using a read-write TW installation did not even come up once even though I shared that upfront.
TU documentation explicitly states:
transactional-update is typically used on a read-only root file system, even though it also supports regular read-write systems.
I firmly believe a new user or beginner should master the very minimal amount of tools/skills (snapper, btrfs, TU, backup/restore, how to use rescue ISO) that would allow them to experiment and learn in a forgiving environment where they are not constantly worrying if it’s that next command/action that might break the system without them being able to put it back right. Not setting yourself up in such an environment is a fool-proof method for always staying a beginner and relying on others to solve your problems, solving most of which would be way too complicated had they just done it right the first time. Consequently all of this makes them averse to learning or experimenting altogether. A truly negative feedback loop 
1 Like
Only one solution, I gotta switch to Nix.
It’s not considered a best practice to use transactional-update, to my knowledge. Every TW developer that I’ve talked to over the years has said that the recommended way to do updates on TW is to use zypper dup, not a one has said to use transactional-update dup.
With all the discussions about it (and there have been many, because a lot of people feel like using zypper up on TW is appropriate), it is unlikely that if it was OK to use transactional-update dup that it wouldn’t have come up once, but I have never seen it suggested before.
You’re more than welcome to ask the developers on the MLs for their opinion on the matter, but until it’s explicitly said that it’s considered fine, let’s not confuse people with this advice.
The documentation says a lot of things, some of which might seem to imply (as your example does) that something like this is OK.
Experimentation is fine. Experimentation on production systems is generally not fine - and we have no idea when talking to someone here if they are using the systems for personal use or business, or what the risk factor is for doing something that goes against those recommendations.
I’ve been helping people in online forums for more than 30 years. I encourage people to experiment when it is safe to do so, but a production system is not the place to do that experimentation.
It’s also important to form good habits when managing systems - and learning when it’s OK to “break the rules” depends first on knowing those best practices. I would never encourage someone to form a habit that doesn’t follow best practices until they knew what those best practices were and why they’re considered best practices. When someone is learning, the best way to know when it’s OK to do something other than those best practices is to understand WHY they’re best practices to begin with and to have formed the habit of following them.
1 Like