Do I have to babysit updates and other questions from a new user

Using transactional update avoids all these issues :slight_smile:
The currently running system is not affected at all until the reboot.

A transactional update (also known as atomic upgrade) is an update that

is atomic:

The update does not influence the running system.

The machine can be powered off at any time. When powered on again either the unmodified old state or the new state is active. It is not possible to have a running system in an intermediate state.

can be rolled back:

If the upgrade fails or if a newer software version turns out to not be compatible with your infrastructure, the system can quickly be restored to a previous state.

Source.

Edit 1:
Btw, my system has done two transactional-updates over the last few days. No issues yet :crossed_fingers:. I ran sudo rpmconfigcheck as per an earlier suggestion and it found a new postfix config file for me to manually update. Thanks @nrickert !

Yep, this is what I was thinking about. I use VSCode as my primary editor and it’s heavy on plugins. It even closes slow after an update prior to restarting the app. Some apps on Windows for example would ask you to close them prior to installing an update.

Personally I wouldn’t want to mess up my app profile/cache due to running them with old files in memory though. It may not be much fuss to start from scratch for some apps since most of them have some sort of cloud sync going on, but one app that I would absolutely hate starting anew is my Thunderbird profile with all its custom config I’ve done. Would take me a solid 2 hours to re-setup that thing.

Booted host 6700k into slowroll, performed transactional-update and rebooted:

slowroll:~ # journalctl -b -p3
Feb 13 13:10:23 slowroll kernel: DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x0000000078800000-0x0000000088ffffff], contact BIOS vendor for fixes
Feb 13 13:10:23 slowroll kernel: x86/cpu: SGX disabled by BIOS.
Feb 13 13:10:29 slowroll systemd-vconsole-setup[749]: No usable source console found: Device or resource busy
Feb 13 13:10:29 slowroll systemd[1]: Failed to start Virtual Console Setup.
Feb 13 13:10:29 slowroll systemd-vconsole-setup[773]: No usable source console found: Device or resource busy
Feb 13 13:10:29 slowroll systemd[1]: Failed to start Virtual Console Setup.
Feb 13 13:10:31 slowroll postfix/postmap[1173]: fatal: bad string length 0 < 1: myhostname =
Feb 13 13:10:32 slowroll postfix/postmap[1202]: fatal: bad string length 0 < 1: myhostname =
Feb 13 13:10:33 slowroll postfix/postmap[1254]: fatal: bad string length 0 < 1: myhostname =
Feb 13 13:10:34 slowroll postfix/postmap[1283]: fatal: bad string length 0 < 1: myhostname =
Feb 13 13:10:35 slowroll postfix/postmap[1365]: fatal: bad string length 0 < 1: myhostname =
Feb 13 13:10:36 slowroll postfix/postalias[1397]: fatal: bad string length 0 < 1: myhostname =
Feb 13 13:10:37 slowroll postfix[1510]: fatal: bad string length 0 < 1: myhostname =
Feb 13 13:10:38 slowroll systemd[1]: Failed to start Postfix Mail Transport Agent.
Feb 13 13:10:38 slowroll jackdbus[1809]: default: failed to stat "/home/karl/.config/jack/conf.xml", error is 2 (No such file or directory)
Feb 13 13:10:38 slowroll jackdbus[1809]: default: open() failed to open conf filename.
slowroll:~ # rpmconfigcheck 
Searching for unresolved configuration files
slowroll:~ # 

Some improvements since last try, but still annoying.

1 Like

What about it? :thinking:
I’m thinking about moving to slowroll once it’s mainlined.

Slowroll and Transactional update are options available with Tumbleweed and don’t add complexity to development and maintenance, which is a great idea.

For TU, I agree. But Slowroll has its own repos, testing, and security update track so not sure how much Suse can save on development and maintenance by not releasing an ISO (which they already do now in an automated way IIRC).

SUSE doesn’t have anything to do with it.

The lack of an ISO is something you would want to take up with the Slowroll developers, as that is something that is entirely up to them to decide to do or not.

1 Like

“Slowroll is still rather new and is based on openSUSE Tumbleweed packages.”

1 Like

So I double checked the systemd service while it was running and it appears to be defaulting to the system.slice.

● bkupd.service - Backup and transactional update/reboot
     Loaded: loaded (/etc/systemd/system/bkupd.service; static)
  ...
     CGroup: /system.slice/bkupd.service

Gave the service a try:

6700k:~ # journalctl -b -u transactional-update.service --no-pager 
Feb 23 08:03:59 6700k systemd[1]: Starting Update the system...
Feb 23 08:04:00 6700k zypper[3098]: Repository 'Haupt-Repository (NON-OSS)' is up to date.
Feb 23 08:04:00 6700k zypper[3098]: Repository 'Haupt-Repository (OSS)' is up to date.
Feb 23 08:04:00 6700k zypper[3098]: Repository 'Hauptaktualisierungs-Repository' is up to date.
Feb 23 08:04:00 6700k zypper[3098]: Repository 'Branch project for package btrbk (openSUSE_Tumbleweed)' is up to date.
Feb 23 08:04:00 6700k zypper[3098]: Repository 'jalbum' is up to date.
Feb 23 08:04:00 6700k zypper[3098]: Repository 'packman' is up to date.
Feb 23 08:04:00 6700k zypper[3098]: All repositories have been refreshed.
Feb 23 08:04:01 6700k systemd[1]: transactional-update.service: Found left-over process 3117 (scdaemon) in control group while starting unit. Ignoring.
Feb 23 08:04:01 6700k systemd[1]: transactional-update.service: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
Feb 23 08:04:01 6700k transactional-update[3138]: Checking for newer version.
Feb 23 08:04:01 6700k transactional-update[3138]: transactional-update 4.5.0 started
Feb 23 08:04:01 6700k transactional-update[3138]: Options: cleanup dup reboot
Feb 23 08:04:01 6700k transactional-update[3138]: Separate /var detected.
Feb 23 08:04:03 6700k transactional-update[3138]: 2024-02-23 08:04:02 tukit 4.5.0 started
Feb 23 08:04:03 6700k transactional-update[3138]: 2024-02-23 08:04:02 Options: -c1086 open
Feb 23 08:04:03 6700k transactional-update[3138]: 2024-02-23 08:04:03 Using snapshot 1086 as base for new snapshot 1087.
Feb 23 08:04:03 6700k transactional-update[3138]: ID: 1087
Feb 23 08:04:03 6700k transactional-update[3138]: 2024-02-23 08:04:03 Transaction completed.
Feb 23 08:04:03 6700k transactional-update[3138]: Calling zypper --no-cd dup
Feb 23 08:04:05 6700k transactional-update[3625]: 2024-02-23 08:04:05 tukit 4.5.0 started
Feb 23 08:04:05 6700k transactional-update[3625]: 2024-02-23 08:04:05 Options: call 1087 zypper --no-cd dup -y --auto-agree-with-product-licenses
Feb 23 08:04:05 6700k transactional-update[3625]: 2024-02-23 08:04:05 Executing `zypper --no-cd dup -y --auto-agree-with-product-licenses`:
Feb 23 08:04:05 6700k transactional-update[3625]: Loading repository data...
Feb 23 08:04:05 6700k transactional-update[3625]: Reading installed packages...
Feb 23 08:04:05 6700k transactional-update[3625]: 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 command.
Feb 23 08:04:05 6700k transactional-update[3625]: Computing distribution upgrade...
Feb 23 08:04:05 6700k transactional-update[3625]: The following 101 packages are going to be upgraded:
Feb 23 08:04:05 6700k transactional-update[3625]:   alsa-utils apache-commons-logging apparmor-abstractions apparmor-docs apparmor-parser apparmor-parser-lang apparmor-profiles apparmor-utils apparmor-utils-lang autofs bluez bolt branding-openSUSE fde-tpm-helper git git-core git-email git-svn git-web grub2 grub2-branding-openSUSE grub2-i386-pc grub2-snapper-plugin grub2-systemd-sleep-plugin grub2-x86_64-efi java-11-openjdk java-11-openjdk-headless jitterentropy-devel libaa1 libapparmor-devel libapparmor1 libbluetooth3 libdav1d7 libdbusmenu-qt5-2 libdecor libdecor-0-0 libell0 libfreebl3 libheif1 libhwy1 libjasper7 libjitterentropy3 libmariadb3 libodbc2 libpipewire-0_3-0 libpng16-16 libqalculate22 libqt5-qtwebengine libquicktime0 libreoffice-branding-openSUSE libsoftokn3 libstorage-ng-lang libstorage-ng-ruby libstorage-ng1 libsystemd0 libudev1 libutempter0 libvidstab1_1 libvlc5 libvlccore9 libwebrtc-audio-processing-1-3 libzvbi0 man mozilla-nss mozilla-nss-certs openSUSE-release openSUSE-release-appliance-custom patterns-server-file_server patterns-server-lamp_server perl-Bootloader perl-Git pipewire pipewire-alsa pipewire-lang pipewire-modules-0_3 pipewire-spa-plugins-0_2 pipewire-spa-tools pipewire-tools plymouth-branding-openSUSE python3-apparmor qalculate-data signon-plugin-oauth2 systemd systemd-doc systemd-lang systemd-network udev vlc vlc-codec-gstreamer vlc-lang vlc-noX vlc-qt vlc-vdpau vncmanager vorbis-tools wallpaper-branding-openSUSE wget wget-lang wsdd yast2-qt-branding-openSUSE yast2-trans-de
Feb 23 08:04:05 6700k transactional-update[3625]: The following 2 patterns are going to be upgraded:
Feb 23 08:04:05 6700k transactional-update[3625]:   file_server lamp_server
Feb 23 08:04:05 6700k transactional-update[3625]: The following product is going to be upgraded:
Feb 23 08:04:05 6700k transactional-update[3625]: openSUSE Tumbleweed
Feb 23 08:04:05 6700k transactional-update[3625]:   20240220-0 -> 20240221-0
Feb 23 08:04:05 6700k transactional-update[3625]: 101 packages to upgrade.
Feb 23 08:04:05 6700k transactional-update[3625]: Overall download size: 148.2 MiB. Already cached: 0 B. After the operation, additional 169.3 KiB will be used.
Feb 23 08:04:05 6700k transactional-update[3625]: Continue? [y/n/v/...? shows all options] (y): y
Feb 23 08:04:07 6700k transactional-update[3625]: Retrieving: alsa-utils-1.2.11-2.1.x86_64 (Haupt-Repository (OSS)) (1/101),   1.2 MiB
Feb 23 08:04:07 6700k transactional-update[3625]: Retrieving: alsa-utils-1.2.11-2.1.x86_64.rpm [.error]
Feb 23 08:04:07 6700k transactional-update[3625]: Download (curl) error for 'https://cdn.opensuse.org/tumbleweed/repo/oss/x86_64/alsa-utils-1.2.11-2.1.x86_64.rpm':
Feb 23 08:04:07 6700k transactional-update[3625]: Error code: Connection failed
Feb 23 08:04:07 6700k transactional-update[3625]: Error message: Could not resolve host: cdn.opensuse.org
Feb 23 08:04:07 6700k transactional-update[3625]: Abort, retry, ignore? [a/r/i/...? shows all options] (a): a
Feb 23 08:04:07 6700k transactional-update[3625]: Problem occurred during or after installation or removal of packages:
Feb 23 08:04:07 6700k transactional-update[3625]: Installation has been aborted as directed.
Feb 23 08:04:07 6700k transactional-update[3625]: Please see the above error message for a hint.
Feb 23 08:04:07 6700k transactional-update[3625]: 2024-02-23 08:04:07 Application returned with exit status 8.
Feb 23 08:04:07 6700k transactional-update[3139]: ERROR: zypper --no-cd dup on /.snapshots/1087/snapshot failed with exit code 8!
Feb 23 08:04:07 6700k transactional-update[3139]: Use '--interactive' for manual problem resolution.
Feb 23 08:04:07 6700k transactional-update[3139]: Removing snapshot #1087...
Feb 23 08:04:07 6700k transactional-update[3688]: 2024-02-23 08:04:07 tukit 4.5.0 started
Feb 23 08:04:07 6700k transactional-update[3688]: 2024-02-23 08:04:07 Options: abort 1087
Feb 23 08:04:07 6700k transactional-update[3688]: 2024-02-23 08:04:07 Discarding snapshot 1087.
Feb 23 08:04:07 6700k transactional-update[3688]: 2024-02-23 08:04:07 Transaction completed.
Feb 23 08:04:07 6700k transactional-update[3138]: transactional-update finished
Feb 23 08:04:07 6700k systemd[1]: transactional-update.service: Main process exited, code=exited, status=1/FAILURE
Feb 23 08:04:07 6700k systemd[1]: transactional-update.service: Failed with result 'exit-code'.
Feb 23 08:04:08 6700k systemd[1]: Failed to start Update the system.
Feb 23 08:04:08 6700k systemd[1]: transactional-update.service: Consumed 5.601s CPU time.
6700k:~ # 

It reproducibly fails with “Could not resolve host: cdn.opensuse.org” while a straight zypper dist-upgrade always succeeds. Any idea?

Hey Karl, good to see you back :smile:
Hmm, this sounds similar to zyppreoni’s initial problem where it didn’t catch the symlinked resolv.conf.

Perhaps you could enter TU shell for debugging:

sudo transactional-update --interactive --drop-if-no-change shell
dig a cdn.opensuse.org
...
exit 1
6700k:~ # transactional-update --interactive --drop-if-no-change shell
Checking for newer version.
transactional-update 4.5.0 started
Options: --interactive --drop-if-no-change shell
Separate /var detected.
2024-02-23 09:48:49 tukit 4.5.0 started
2024-02-23 09:48:49 Options: --discard -c1090 open 
2024-02-23 09:48:50 Using snapshot 1090 as base for new snapshot 1091.
ID: 1091
2024-02-23 09:48:50 Transaction completed.
Opening chroot in snapshot 1091, continue with 'exit'
2024-02-23 09:48:50 tukit 4.5.0 started
2024-02-23 09:48:50 Options: --discard call 1091 bash 
2024-02-23 09:48:55 Executing `bash`:
transactional update # dig a cdn.opensuse.org
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused

; <<>> DiG 9.18.24 <<>> a cdn.opensuse.org
;; global options: +cmd
;; no servers could be reached

transactional update # exit
2024-02-23 09:49:50 Application returned with exit status 9.
2024-02-23 09:49:50 tukit 4.5.0 started
2024-02-23 09:49:50 Options: --discard close 1091 
2024-02-23 09:49:50 No changes to the root file system - discarding snapshot.
2024-02-23 09:49:50 Discarding snapshot 1091.
2024-02-23 09:49:51 Transaction completed.
transactional-update finished
6700k:~ # 

I have no idea what is going on.

The command transactional-update --interactive --drop-if-no-change shell creates a new read-write snapshot (1091) based on your current default snapshot (1090), mounts all the requisite mountpoints from /etc/fstab for dup/in/rm and drops you into a chroot (based on the new snapshot #1091) shell.

The command dig a cdn.opensuse.org queries the DNS resolver for where the DNS A (IP address) record for cdn.opensuse.org is.

Since its output didn’t include a resolver like 8.8.8.8 or whatever nameservers are in your /etc/resolv.conf it means it couldn’t get the resolv.conf information.
This is because TU doesn’t mount variable/working directories such as /var or /run from the host as that would mean the actions (dup/in/rm) carried out within the TU shell are no longer atomic. As your /etc/resolv.conf is a symlink to /run/NetworkManager/resolv.conf naturally it’s not available within the TU shell.

Finally, TU discarded the new snapshot 1091 (due to option --drop-if-no-change) as we made no changes to it within the TU shell.

1 Like

One more thing, you should be able to delete the /etc/resolv.conf symlink with newer versions of NetworkManager (NM). NM would automatically create a new resolv file that’s not a symlink on (re-)starting NM. This should get TU working for you :slightly_smiling_face:

1 Like

Replaced symlink /resolv.conf by a file with the same name and contents of /run/NetworkManager/resolv.conf. transactional-update.service readily upgraded and rebooted host 6700k:

6700k:~ # journalctl -b -1 -u transactional-update.service --identifier systemd
Feb 23 11:27:41 6700k systemd[1]: Starting Update the system...
Feb 23 11:30:04 6700k systemd[1]: transactional-update.service: Deactivated successfully.
Feb 23 11:30:04 6700k systemd[1]: Stopped Update the system.
Feb 23 11:30:04 6700k systemd[1]: transactional-update.service: Consumed 1min 36.896s CPU time.
6700k:~ # 
1 Like

Moved /etc/resolv.conf and restarted NetworkManager. This indeed created a new file (and not a symlink).

1 Like