Hi, as you might've heard or even experienced yourself, if you zypper dup'd from Plasma 5 to Plasma 6 while using the desktop, the upgrade was aborted halfway and left you with a partially broken system. That's obviously something that really must not happen! First things first: The bug is addressed in TW Snapshot 20240318+, package libplasma6. Various users recommended to perform the upgrade in a tty (or in screen, tmux, ...), which is generally good advice, but that can also leave the impression that this behavior is acceptable or even expected. That's not really on par with the level of quality we want to achieve. So much so that we think this deserves a dedicated explanation to what went wrong and what has been done. Analysis: "Fortunately" it was easy to reproduce, as it affected pretty much any recent Tumbleweed with Plasma 5. The logs showed that the systemd user units for the Plasma session were explicitly stopped, which led to the RPM scriptlets in packages. The culprit was identified to be the %systemd_user_preun macro in various Plasma 5 packages, which were replaced by Plasma 6 counterparts. This macro handles stopping or restarting user services prior to an uninstallation of a package. In this specific case, the macro did not expect the case that .service files move from one package to another, treated this case like a full uninstallation and stopped the units immediately. https://bugzilla.opensuse.org/show_bug.cgi?id=1221405 Fix: As it's not possible to remove existing %preun scripts or prevent them from executing, a workaround was needed that prevents the effects. A systemd maintainer suggested to set RefuseManualStop=true in all affected units, which was confirmed to work. After some testing for upgrades from Plasma 5 and Plasma 6 with and without ZYPP_SINGLE_RPMTRANS=1, this was submitted. While it would've been possible to bypass some stages of QA for a quicker rollout, we decided to not do that to gain more reassurance that the workaround was safe. https://build.opensuse.org/request/show/1158726 Prevention: The issue was not caught by openQA, which is a surprise as this is one of the main methods users use to upgrade Tumbleweed. To rectify this, two new test scenarios were added: "zdup_in_x_tw2twnext", which runs zypper dup in an xterm in the graphical session, and "update_tw2twnext", which uses the graphical PackageKit frontend of the resp. DE to perform the upgrade. It was validated that "zdup_in_x_tw2twnext" ran against the affected snapshot 20240311 does fail in the same way that affected users, so we know that it is effective to catch issues like this. https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18893 https://github.com/os-autoinst/opensuse-jobgroups/pull/434 https://github.com/os-autoinst/opensuse-jobgroups/pull/436 Next steps: The root cause is the %systemd_user_preun macro's missing handling for package renames resp. the use of it in packages. There is discussion going on how this can be addressed fully. Have a lot of fun, the openSUSE KDE Packaging Team