New Tumbleweed Installation - Software Install Slows System

OK, I just upgraded my LEAP 15.4 to Tumbleweed a couple days. I’ll forego the nightmare of finding all my partitions except home mounted as owned by root and related hassles which cost me a day of work fixing things.

My new recurring problem is desktop freezes every time I install a new piece of software (necessitated by the fact that I still run into some software I forgot to reinstall when I upgraded.

Here’s what happens:

  1. I download a utility - in this specific case, AppImageLauncher, as an rpm.
  2. I click on the rpm, call up Yast Software, select the software, install it. and click finish. At this point, Yast should go away, right?
  3. Not noticing whether Yast has gone away, I click on the KDE menu - and the entire task bar freezes.
  4. I notice Yast is still on the taskbar, the KDE menu is frozen, I can’t get a response from any item on the task bar.
  5. After X seconds - greater than 10, less than 30, I didn’t time it - everything unfreezes, Yast goes away, the KDE Menu goes away. Now I can click on it or any task bar item and get a response.

This has happened several times. Anyone have any idea what the problem is and how to fix it? It’s extremely annoying to have this sort of freezes.

For me I would not upgrade my rig from 15.4 etc. to tumbleweed.
What I will do is to preserve my /home and install the latest tumbleweed snapshot iso.
Just my opinion.
Note: Add the application I presently use before proceeding with the installation.
When installation is finish it will pickup the configuration of your new application from the config that you left in your /home…

2 Likes

Then openSUSE should not allow upgrades period.

Not a useful response. “Reinstall” is what I hear from Microsoft for every problem Windows has.

Tumbleweed is a different beast compared to the opensuse 15.4 etc. You should be doing the upgrade if you know the ins and outs of opensuse. I’ve been here for 20 plus years using SuSe/opensuse to anticipate/determine any problem that will arise on my rig during upgrade.

If you don’t have any better ideas than reinstall, just stop responding to this thread, please.

It is my opinion and no one can stop me. I did not respond in a way that it is rude just like the way you responded in this thread. I always been a nice guy in this forum but I can’t tolerate such humiliating answer from anyone.

Then go away.

I hope you find an answer that’s gonna be interesting and make me proud that you got a good help and stays in this forum and opensuse. Good riddance. :wink:

1 Like

All people here are fellow openSUSE users and try to help here as volunteers in good faith. When an answer is not what you expected, you should still be grateful that someone answered, and consider it as good meant advice.

Just crying “go away” will not encourage anybody here to come to your help.

2 Likes

Maybe you can use top or as GUI plasma-systemmonitor to see, if there is something using more CPU time?

Some people hate the console but using Tumbleweed that is not a good combo.

Can you try installing the .rpm using the console?

sudo rpm -i <package.rpm>

Does that work as expected?

I would use zypper install <package.rpm>, because it integrates the package more into the eco-system then only rpm.

But yes. using the CLI would give me more freedom in using tools like top at the same time.

1 Like
erlangen:~ # time zypper -n in https://github.com/TheAssassin/AppImageLauncher/releases/download/v2.2.0/appimagelauncher-2.2.0-travis995.0f91801.x86_64.rpm
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
  appimagelauncher

1 new package to install.
Overall download size: 0 B. Already cached: 2.8 MiB. After the operation, additional 13.3 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): y
In cache appimagelauncher-2.2.0-travis995.0f91801.x86_64.rpm                                                                                                                                                            (1/1),   2.8 MiB    

Checking for file conflicts: .........................................................................................................................................................................................................[done]
Installing AppImageLauncher as interpreter for AppImages
insmod /usr/lib/modules/6.4.12-1-default/kernel/fs/binfmt_misc.ko.zst 
+ systemctl restart systemd-binfmt
(1/1) Installing: appimagelauncher-2.2.0-travis995~0f91801.x86_64 ....................................................................................................................................................................[done]

real    0m4.601s
user    0m1.326s
sys     0m0.360s
erlangen:~ # 

Most of the time I go to a forum, the first two responses are invariably:

  1. “You shouldn’t have done what you did.”
  2. “Reinstall.”

I pointed this out and got a lecture from the poster about how he’s around here 20 years and that I don’t know what I’m doing.

I don’t respond well to that kind of passive aggression. Sorry if that sounds churlish, but that’s how it is.

The package works fine. It’s the KDE freeze that I’m having an issue with.

The package works fine. It’s the KDE freeze that I’m having an issue with. Seriously, has no one bothered to read the original post?

If you’re saying that Tumbleweed is incapable of installing a package using the Yast GUI, then I don’t know what to tell you. Why does Tumbleweed have a GUI install mechanism if it doesn’t work? So far Tumbleweed looks 98% the same as LEAP, so I don’t know what the same mechanism which are on LEAP won’t work in Tumbleweed.

I can understand updating the system using zypper because of the large rolling release updates rather than using the GUI. But this wasn’t a system dup, this was installing one program. After I installed the system initially, I spent half a day installing other individual programs from the GUI. Sometimes I got the task bar freeze, sometimes I didn’t.

But beyond that is the main point: The installation went fine. The AppImage Launcher works fine. What happened next is that the task bar froze for 30 seconds. That’s the problem.

Before anyone asks if I’m using Nvidia drivers - apparently a common cause of this sort of problem - no, I’m not. I’m on an AMD Ryzen 2600X, with an AMD Radeon RX550 graphics card using the X.Org subsystem and amdgpu driver.

A Google search has since revealed that this sort of thing has been an issue for KDE for, one guy said, 10-15 years! However, I have been using openSUSE LEAP since at least version 11 and I’ve never seen it. So I’m concerned that this is specific to Tumbleweed as opposed to LEAP. I know other distros have had similar issues with KDE in the past, as noted above.

Did you bother to do what was already requested several post ago?

  • use top or systemmonitor
  • look in your journal for errors or warnings
  • how much RAM is installed and how much is utilized

Yes, I did. The system is not showing anything wrong in systemmonitor. I couldn’t find anything in the journal that looked like it was involved (but I’m no expert at reading line after line of gibberish.) I have 64GB of RAM and barely 6GB is in use.

So, yes, I did bother. I’m also doing Google searches and there’s all sorts of things causing KDE to freeze either entirely or just parts such as the System Tray or Task Bar or the KDE Menu. Disheartening to think how easily KDE can be broken, despite my using it for years with very little problems.

If KDE Plasma on openSUSE could be broken that easily the forum would be full of it. But it isn’t. The problems are particular to your system.

Even if you don’t want to hear it and the chance for going ballistic is high…i will give it a go.

Upgrading from Leap 15.4 to Tumbleweed has a risk for breaking the system as the package versions and changes between these two variants are already high. It is noted on several pages that you must not skip a version. That means you must not upgrade e.g. Leap 15.3 → Leap 15.5.
But you skipped a version (Leap 15.5) by directly jumping from Leap 15.4 → Tumbleweed.
References:
https://en.opensuse.org/SDB:System_upgrade#General_rules
https://en.opensuse.org/openSUSE:Tumbleweed_upgrade#Online_Upgrade
This MAY work, but the chances are good that you break something if you don’t follow these guidelines. For this scenario, advanced administration skills are required.

All other directories except /home belong to root. That is standard. Also additional partitions get mounted as root as long as you didn’t change the ownership or set the user flag in fstab. So this is also standard.
At this point i already get cautious because it is unclear what you have done with your system or how deep your knowledge about basic linux file permissions is.

Based on your provided information, nobody can help you. You need to have top or systemmonitor open and recreate such a system hang by installing a package. From there it may be possible to analyze further.

In your position i would tend to do a complete fresh Tumbleweed installation. Such installations with skipped releases are hard (if only) to analyze. If you have free space on a partition, you could try to install a test Tumbleweed there to rule out any hardware bottlenecks. If the test installation is fine…erase all and do a new installation. This requires that you have backups of your data which you need…

It’s also ■■■■■■■ stupid. I can see it in a server system but this is a personal system and the option when installing or upgrading and finding existing partitions should be to offer to install them in /etc/fstab.

But that’s not relevant now.

I will wipe my ■■■■■■■ system and do a clean install and waste another day or two - and I’m fairly sure the problem will remain.

I knew it was a waste of time to come here. It always is.