I can no longer update Tumbleweed

English Applications
1

Hello everyone.
Yesterday I tried updating the Tumbleweed system, like I always do, using Zypper.

Instead of proceeding as usual the program reported a problem to me, the following is a part of the text:
Problem: ruby3.2-rubygem-abstract_method-1.2.1-2.31.x86_64 requires ‘ruby(abi) = 3.2.0’ to install, but cannot provide this requirement

Then he offered me 4 possible solutions and then asked me to choose like this:
Choose from the above solutions by number or ignore, retry, or cancel [1/2/3/4/i/r/a/d/?] (a):

I tried them all, one at a time, but all that happened was that the message replayed.

Finally, I manually tried solution 1, which involved these two steps:

  • uninstalling ruby3.2-rubygem-abstract_method-1.2.1-2.30.x86_64
  • uninstalling ruby3.2-3.2.2-1.1.x86_64

I did this but as soon as I tried the update again, the same message came back, as if I hadn’t uninstalled anything.

I don’t know if it has anything to do with it, but I recently attempted to install nvidia proprietary drivers from here :
openSUSE Software

That didn’t work, so I had to uninstall. At that point everything seemed fine, a couple of days later I did the update and the problems started.

Thanks in advance for any suggestion.

2

@_woebegone Hi and welcome to the Forum :smile:
When you say updating, what command are you using?

When was the last time you updated this system?

3

The exact same problem here for the last few days, updating usually every other day if not everyday.

sudo zypper dist-upgrade
[sudo] password for root: 
Loading repository data...
Reading installed packages...
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.
Computing distribution upgrade...
2 Problems:
Problem: the to be installed ruby3.2-rubygem-unf_ext-0.0.8.2-1.6.x86_64 requires 'ruby(abi) = 3.2.0', but this requirement cannot be provided
Problem: the installed ruby3.1-3.1.4-1.1.x86_64 requires 'libruby3_1-3_1 = 3.1.4', but this requirement cannot be provided

Problem: the to be installed ruby3.2-rubygem-unf_ext-0.0.8.2-1.6.x86_64 requires 'ruby(abi) = 3.2.0', but this requirement cannot be provided
 Solution 1: Following actions will be done:
  deinstallation of ruby3.2-rubygem-unf_ext-0.0.8.2-1.5.x86_64
  deinstallation of ruby3.2-3.2.2-1.1.x86_64
 Solution 2: deinstallation of ruby3.1-3.1.4-1.1.x86_64
 Solution 3: keep obsolete ruby3.1-3.1.4-1.1.x86_64
 Solution 4: break ruby3.2-rubygem-unf_ext-0.0.8.2-1.6.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c/d/?] (c):

Doesn’t matter what you select or try it just keeps on repeating itself.

4

Hi you need to select the options to delete ruby 3.1 items and let them move to ruby 3.2.
In your example select solution 2

5

Update from 20230418 to 20230420 indeed performs removal of Ruby 3.1 and its sub-components. There is no conflicts in my case but I also did not try to “fix” the system in the past by blindly removing something. So the correct resolution seems to be removing Ruby 3.1 when asked.

We cannot comment on your statement “it keeps repeating” because we do not see it. Show full output (starting with command line itself) which includes everything you did, not just “part of the text”. It may be long so upload to https://susepaste.org/.

6

I fixed it by deleting the OS after 10 1/2 years of using OpenSUSE.
It was a nice ride while it lasted. :rofl:

7

After “10 years of using” there should be enough knowledge to solve such basic hickups :wink:

1 Like
8

Presumably the hiccup was caused by clueless administration. Upgrade works as always. No need to fix Tumbleweed by deleting it. :wink:

9

Sorry for not replying sooner, I see I’m not the only one having this problem.

malcolmlewis told me : @_woebegone Hi and welcome to the Forum :smile:
I answer: thank you, I’m happy to be here

malcolmlewis asked me : When you say updating, what command are you using?
I answer: according to the guides, being Tumbleweed I always and only use: “# zypper dup” preceded by “# zypper refresh”

malcolmlewis asked me : When was the last time you updated this system?
I answer : 04.04.2023. Sometimes I wait too long to do it, but I’ve never had major problems.

The output showing sammiev is identical to mine. And like him I can say: Doesn’t matter what you select or try it just keeps on repeating itself.

malcolmlewis tells sammiev :
Hi you need to select the options to delete ruby 3.1 items and let them move to ruby 3.2. In your example select solution 2

I say to malcolmlewis :
this is not possible, because : Doesn’t matter what you select or try it just keeps on repeating itself.

arvidjaar says :
Update from 20230418 to 20230420 indeed performs removal of Ruby 3.1 and its sub-components. There is no conflicts in my case but I also did not try to “fix” the system in the past by blindly removing something. So the correct resolution seems to be removing Ruby 3.1 when asked.

I say to arvidjaar :
Maybe I didn’t understand, but when you update a rolling don’t you already have the latest version of the system? What do you mean then by saying: update from 20230418 to 20230420?
In the repo list I have this entry : " openSUSE-20221001-0 " I think it’s the ISO I originally installed but I don’t know why it appears as a repo entry.
Sometimes during the update I was asked to insert the DVD with the original ISO to restore some components to their original state. If I don’t do this the update fails.
I find it strange, this doesn’t happen in Arch and such.

But " removing Ruby 3.1 when asked" doesn’t work, because : Doesn’t matter what you select or try it just keeps on repeating itself.

arvidjaar says : “We cannot comment on your statement “it keeps repeating” because we do not see it.”
I say to arvidjaar :
It is not clear? When you choose one of the options indicated in the error message, it repeats itself and repeats the same options as before, ad infinitum.

karlmistelberger says: "Upgrade works as always. "
I reply to karlmistelberger: maybe for you!

Thank you all for participating, I hope you will give me some suggestions. I don’t want to be like Sammiev.

1 Like
10

You should disable or delete that repo. Otherwise it will prevent your system from being fully up to date.

11

@_woebegone Hi can you run the following commands and paste the output;

zypper lr -dE
zypper -vvv dup

The -vvv adds verbosity to the output…

12

nrickert: You should disable or delete that repo. Otherwise it will prevent your system from being fully up to date.

Well, I didn’t know. Could this be the cause of the problem?

malcolmlewis , the output you asked for contains many web urls and this forum seems to prevent new users from putting more than two of these in a post. Can I email you somewhere?

13

Yes, it could be.

In my experience, that repo is disabled at the end of the install. But I sometimes enable at first as I add a few more packages. And in once case I forgot to disable again, and ran into update problems.

14

Thank you for the information, but unfortunately knowing the probable cause of the problems does not automatically lead to a solution.
I’m considering manually following the second option, so “deinstallation of ruby3.1-3.1.4-1.1.x86_64”, after all I don’t have much to lose, if I don’t get other suggestions.

15

@_woebegone you can use https://paste.opensuse.org/

16

OK, here it is: openSUSE Paste

17

To show output in english you can use…

LANG=C sudo zypper -vvv dup
18

Basically for everybody. Upgrading depends on coherent administration. Infamous host erlangen upgrades unattended for weeks and months. On rare occasions zypper asks what to do, similar to the top post:

erlangen:~ # journalctl --since yesterday  -u dup --identifier zypper  _PID=30078
Apr 24 03:42:26 erlangen zypper[30078]: Retrieving repository 'Haupt-Repository (NON-OSS)' metadata [..........done]
Apr 24 03:42:26 erlangen zypper[30078]: Building repository 'Haupt-Repository (NON-OSS)' cache [...done]
Apr 24 03:42:39 erlangen zypper[30078]: Retrieving repository 'Haupt-Repository (OSS)' metadata [....................................................................................................................................done]
Apr 24 03:42:41 erlangen zypper[30078]: Building repository 'Haupt-Repository (OSS)' cache [....done]
Apr 24 03:42:41 erlangen zypper[30078]: Loading repository data...
Apr 24 03:42:41 erlangen zypper[30078]: Reading installed packages...
Apr 24 03:42:42 erlangen zypper[30078]: 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 thi>
Apr 24 03:42:42 erlangen zypper[30078]: Computing distribution upgrade...
Apr 24 03:42:42 erlangen zypper[30078]: Problem: the installed hypre_2_20_0-gnu-mpich-hpc-devel-2.20.0-1.17.x86_64 requires 'superlu-gnu-hpc-devel = 5.3.0', but this requirement cannot be provided
Apr 24 03:42:42 erlangen zypper[30078]:   deleted providers: superlu-gnu-hpc-devel-5.3.0-1.11.noarch
Apr 24 03:42:42 erlangen zypper[30078]:  Solution 1: Following actions will be done:
Apr 24 03:42:42 erlangen zypper[30078]:   deinstallation of hypre_2_20_0-gnu-mpich-hpc-devel-2.20.0-1.17.x86_64
Apr 24 03:42:42 erlangen zypper[30078]:   deinstallation of hypre-gnu-mpich-hpc-devel-2.20.0-1.17.noarch
Apr 24 03:42:42 erlangen zypper[30078]:  Solution 2: keep obsolete superlu-gnu-hpc-devel-5.3.0-1.11.noarch
Apr 24 03:42:42 erlangen zypper[30078]:  Solution 3: break hypre_2_20_0-gnu-mpich-hpc-devel-2.20.0-1.17.x86_64 by ignoring some of its dependencies
Apr 24 03:42:42 erlangen zypper[30078]: Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c
erlangen:~ #

Presumably years ago I removed some packages without specifying --clean-deps. This left behind some stuff which blocked yesterday’s upgrade.

I fixed the issue by running zypper rm --clean-deps hypre* and restarting the upgrade service dup:

erlangen:~ # journalctl -q --since yesterday -u dup -g 'following|consumed'
Apr 24 03:42:42 erlangen zypper[30078]:  Solution 1: Following actions will be done:
Apr 24 03:42:42 erlangen systemd[1]: dup.service: Consumed 4.296s CPU time.
Apr 24 18:46:46 erlangen zypper[6360]:  Solution 1: Following actions will be done:
Apr 24 18:48:28 erlangen zypper[8403]: The following 335 packages are going to be upgraded:
Apr 24 18:48:28 erlangen zypper[8403]: The following product is going to be upgraded:
Apr 24 18:48:28 erlangen zypper[8403]: The following 14 packages are going to be downgraded:
Apr 24 18:48:28 erlangen zypper[8403]: The following package is going to change architecture:
Apr 24 18:48:28 erlangen zypper[8403]: The following 4 NEW packages are going to be installed:
Apr 24 18:48:28 erlangen zypper[8403]: The following 4 packages are going to be REMOVED:
Apr 24 18:48:28 erlangen zypper[8403]: The following package requires a system reboot:
Apr 24 18:53:44 erlangen systemd[1]: dup.service: Consumed 1min 12.789s CPU time.
erlangen:~ #

http://www.mistelberger.net/chillin.svg

1 Like
19

Hi! I have always worked with the system of choosing the option to keep the package obsolete and wait for the next snapshots to solve the conflict.
And last but not least, I have been on Opensuse for two years now and I have never looked back with other distributions. In my opinion Tumbleweed is the best Linux R&R experience right now. Thanks for opensuse

2 Likes
20

deano_ferrari? Sounds like an Italian name. Let’s try to do as you say:
https://paste.opensuse.org/pastes/8771dbc553cd
Is that okay?

karlnistelberger, i see malcolmlewis liked your post, good sign.
Hmm… so according to you, karlmistelberge, the solution would be in “–clean-deps” .

I’m starting to think that these problems are very frequent in openSUSE, am I right?

Infamous host erlangen …
I didn’t know what “erlangen” meant, so I searched and found: Erlangen - Wikipedia
A city? Where are the repo servers located? You’re not making it easy for me, man.
And this is your prompt : " erlangen:~ # ", it won’t be a coincidence.

So you solved it with " rm --clean-deps hypre* “, what do you recommend to try? (to me) For example: “rm --clean-deps ruby* " ? Sounds risky!
One moment! But is this also useful if “RPM files caching” is disabled?
No, I’m wrong. The guide says that :” --clean-deps” is used for auto-installed dependencies. Dependencies to remove when they are no longer associated with anything.

And this? : …mistelberger.net/chillin.svg. Does it mean anything?

Vernius says :
Hi! I have always worked with the system of choosing the option to keep the package obsolete and wait for the next snapshots to solve the conflict.

And I ask you, Vernius: how would you apply this idea to my case?

Vernius says :
In my opinion Tumbleweed is the best Linux R&R experience right now.

I have to tell you, Vernius: i’m certainly not an expert, I’ve been trying it for a while, to compare it with Arch and the like. I can only say that with Arch I have had much less problems but maybe it’s up to me.
But I’m curious, Vernius: what makes you say Tumbleweed is the best?

Thank you all.