Halfway through the installation it throws me back to the login screen. When I try to continue the update/upgrade it does it again.
I already did a rollback with snapper and forgot to note at which package it exactly happened.
So anyone trying to update, beware that the update might not get through.
I’ll wait a week and then try again.
Update
Ashged on reddit:
*Yeah, unfortunately the update doesn’t work within KDE. No idea if/when they’ll make a fix for that.
The update however works outside KDE, in an IceWM desktop or a TTY. For best results, first log out of KDE, then using Ctr+Alt+F1 go a text based enviroment. Log in there, use sudo zypper dup, then after it finishes, reboot and log in to your regular KDE desktop. Plasma 6 should upgrade succesfully.*
I am long-time Tumbleweed user and it really boggles my mind how something like this goes past “quality control” and “testing”.
Major updates to a Linux DE has been like that forever, though.
Not sure what you are saying?
It’s updating your desktop so that’s why it does that. The safest way is to log out of your desktop session and login via terminal (press ctrl+alt+f1 to get to one) and run
zypper dup.Same thing happened to me. I just continued on and changed TTY and all was fine.
I’m not sure what I did differently. I accidentally updated to Plasma 6 by just clicking Update All in the Discover app. I didn’t even realize Plasma 6 was out yet for Tumbleweed. It worked perfectly for me.
I followed Ashged’s guide to install the update and upgrade to KDE6. It worked and now let’s see if I run into any bugs. So far everything seems to work fine.
I was tossed back to the login screen, but was fine otherwise. I am on Wayland by the way, maybe this issue is an X11 exclusive one.
Can’t we isolate DEs somehow? They’ve been always the most complicated and fragile part that brings down the whole system.
I wish I could containerize them easily, but it’s so hard.
It’s easy enough to containerize an entire DE - but if you did that, you be basically running everything from inside the container - at which point you’re back to square one. You’re just shifting the problem from the host to the container, and the solution to fix both is the same: restore from a snapshot, reinstall, or actually try and fix the issue.
Also, a DE shouldn’t bring down the whole system btw - you should always be able to switch to a second TTY to recover, and/or have a backup lightweight DE that you can switch to from your logon screen. Unless of course something really broke and caused a kernel panic and your system is fully frozen (which should be a rare occurrence on Linux-friendly hardware).
Anyways, a realistic solution would be to use an immutable distro, such as one of the Fedora Atomic/uBlue distros. The kind of breakage mentioned by OP won’t be possible in such a distro, because your entire system gets updated as a single image, so it either works or it doesn’t (an atomic operation), and in the event it doesn’t work, you can always switch back to a previous image from the boot menu instantly. You can “pin” known good images, and this sort of image operations makes it easy to switch between latest testing/stable image version, or even switch between entire DEs with a single command. So if your KDE 6 is broken, not only can you just go back to KDE 5 with a single reboot, you can also switch to a GNOME image, or rebase to something else entirely, without messing up anything, without creating a dependency hell.
