Never mind on the Slowroll option … the newest ISO install includes KDE6 (6.0.3 … so not really slow)
Inherent? I guess that depends on your point of view. As aggie said (essentially), the inherent nature isn’t in a fault caused by the engineers at SUSE but in the type of distro that TW is. “Rolling” means you’re on the cutting edge; but if the cutting edge includes something that doesn’t sit well with your machine, you can’t avoid it. To use lingo that was still popular when I first started using SuSE Linux: TNSTAAFL.
In the meantime I’ve adopted the same attitude as aggie: I’ve rolled back to the last snapshot before all this began and I’ve disabled all the repos, so my VM is now frozen in time as a Leap-that-never-was. Will have to stay that way until better times.
All that said, I started using SuSE long before the terms Tumbleweed, LEAP or OpenSuSE even existed. I started using SuSE for the level of quality systems engineering that put amateurish wannabe-distros like RH5.1 to shame; and I
stayed because in any of its forms SuSE has always been a full generation ahead of all other distros in terms of stability, reliability and quality. In short: this little hiccup will not be the end of SuSE for me.
2 Likes
I use Tumbleweed historical snapshots and tumbleweed-cli. It allows me to install additional packages normally if needed and gives around a month before snapshot will rollover.
1 Like
Inherent in that it is somehow caused by versions Tumbleweed is shipping or how it’s packaged.
You are the only person reporting the issue. You’re hardly the only person who upgraded to Plasma 6, others have on a wide variety of platforms, including one that matches yours.
In short, the problem is you. You are doing or have done something and it is causing the problem. Not updating just hides the issue. You need to find out what makes your install so different and fix it.
Which is what I said.
You have at least one other person in this thread who has had problems and at least one other forum thread of issues with the Plasma 6 upgrade. Clearly, I am not.
No, I don’t need to do anything. You want me to keep banging my head against the wall. By comparison, I want to do the thing that keeps my system operating with a minimum of problems so that I can actually use it.
Why did you even create a thread then?
By blocking all updates and disabling all repos you have a vulnerable system now, because other fixes for already known issues/bugs can’t get applied. Congratulations!
This “strategy” contradicts your claim of being a longtime SUSE/linux user. Even mediocre skilled users at least know that sticking your head into sand is no solution…and that a stable and secure system needs repos enabled and updates applied…
Seriously? All right, if you insist. How about for the exact reason I gave in the opening post: because I wanted to know if there was a way to effect a partial block rather than a total one.
And essentially calling me a liar was supposed to do what exactly? Shame me into doing what you want me to? Or goad me? Seriously, what were you hoping to accomplish here?
Right now, I have the following choices:
- Freeze my VM as it is and keep working
- Put time that I don’t have right now in to do a proper new install of TW, set everything up, transfer my data, etc and hope Wayland isn’t going to cause any major issues because I’ve already seen that the X11 edition is unworkably slow
- Set up LEAP, which I similarly don’t really have time for right now and avoid Plasma 6 for as long as I can
- Switch to a completely non-SuSE distro with the same time problems plus move to a basis which will probably be inferior
Guess which one has the fewest downsides for me right now? Especially given that I was trying to figure this out on a Sunday rather than during the week? Because I already know…
Now, does that answer your questions? Because as far as I am concerned, I have an answer to my question and the thread is closed.
You forgot the important one:
You hope that if you start updating again in half a year, all problems solved magically themself?
And you have already everything needed to start troubleshooting. Cloning your VB only takes some seconds. And the clone will be the starting point for starting the troubleshoot. No interuption of your work and you can’t damage anything. If you brake the clone, scrap it and make a new one…
No, I think that eventually I am going to have to set up a new VM from scratch. And talking to me like I’m an idiot is also not going to get me to do anything.
You just described exactly what I’ve been doing since plasma 6 came through the build factory. You’re underestimating how much time that takes. There’s a reason I went looking for a way to just block the new plasma version.
Just finished installing a test TW/Plasma6 guest in Virtualbox 7.0.14_SUSE r161095
(TW 20240407 guest on a TW 20240407 host) and can confirm at least some problems.
Plasma Wayland gets stuck on a black screen.
Plasma on X11 somehow works but is slow, System Monitor eats up all 4 CPUs until you switch to the “History” view, sound spits something then stops, all in all it is unusable for any practical work (other than troubleshooting the setup).
Not to mention the dates problem in the shared folders that is still a mystery.
I’m not complaining, I know that the latest TW as guest on the latest TW as a host might have such hiccups; it’s just a test bed for me so maybe I’ll have some time to troubleshoot in the coming weeks.
I don’t know if Plasma6 is the culprit either, VBox not playing well with the 6.8.x kernels (as guest? as host? both?) is definitely a possibility in my opinion.
I definitely would not blame anybody for freezing a VM setup that is working; but I would use at least a stable host for any serious work.
1 Like
The short answer is if you have to ask, you probably don’t have enough non-rollback experience to deal what happens if you misstep. Can - yes. Easy - no way I can imagine, unless someone else provides a list of locks to create, or an actual locks file that includes only KDE/Plasma and its many QT and other deps.
There is always some way to block an upgrade of a non-foundational package. KDE/Plasma qualifies in that regard, as there are other DEs and WMs readily available.
Zypper locks, and if you prefer, YaST taboos, are the means. It takes a lot of trial and error to make up a list for something so complex as a major DE. I have a whole bunch of TW installations, at least 40, all on hardware, of which somewhere around 30%-40% still include KDE/Plasma/Qt 5, and none of which have any KDE/Plasma/QT 6 packages installed.
Zypper locks can use wildcards, which helps a lot, but the KDE fleet has so many different rpm names, it takes a lot of zypper al and dup iterations get zypper dup to a state where a Y can be given to proceed, instead of N to try another locks adjustment. My current locks file iteration is 607 lines, of which roughly 1/6 represent lines zypper ll would report as locks. Some locks lock only one package (e.g. spectacle, kmix), some a few or several (konsol*, breez*), and several large fleets (libKF*, plasm*, qt*). My list, long as it is, wouldn’t come close to enough for a default openSUSE KDE/Plasma installation, as mine start out limited to packages I might ever use (solver.onlyRequires = true in /etc/zypp/zypp.conf) and pretty much stay that way.
It takes a lot of work, and eventually some required support package will be replaced by a new version that can’t work with some installed package, when you’ll have to choose between another DE, no more upgrading, or allowing the upgrade to 6, and in the meantime, security risk will probably be escalating.
Yeah, I figured. I tried what you’re trying and went to the forum after getting the selection of packages to lock wrong for the umpteenth time.
Thanks!
What I tried worked, but it took more than umpteen, more like lebenty umpteen, one lock at a time, until the problem count finally dropped to zero.
I feel your pain brother.
Well, what I considered doing, is to run zypper dup (booting to the snapshot just before KDE6 was released) and copy everything listed for the massive update - that would give me a good baseline to start with, then I could lock many based on a some wildcard matches, and then narrow down to the more individual packages.
Then I said, “way too meticulous”. So, my solution? Last night I installed Leap 15.6 Beta on the laptop, replacing the existing / previous TW install. (Slowroll just updated to KDE6, so that wasn’t an option).
I installed Leap, then did an rsync of my /home subdir backup (did it prior to install) , and everything is running as it was before (kde5 layout, settings, Latte dock stuff, all my documents, and applications settings). It all took less than an hour.
Definitely going on the options list. Thanks for the tip!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.