I can no longer update Tumbleweed

English Applications
21

You may always consider a dry run such as:

erlangen:~ # zypper --non-interactive remove --dry-run --clean-deps ruby
Reading installed packages...
Resolving package dependencies...

The following 102 packages are going to be REMOVED:
  augeas autoyast2-installation checkmedia google-poppins-fonts iptables libip6tc2 libldapcpp0 libmediacheck6 libruby3_2-3_2 libstorage-ng-ruby libyui-ncurses-pkg16 openslp oxygen5-icon-theme oxygen5-icon-theme-large patterns-kde-kde_yast patterns-yast-yast2_basis patterns-yast-yast2_desktop perl-Crypt-SmbHash perl-Digest-MD4 perl-Digest-SHA1 perl-Parse-RecDescent perl-X500-DN perl-XML-LibXML perl-XML-NamespaceSupport perl-XML-SAX perl-XML-SAX-Base ruby ruby-common ruby-solv ruby3.2 ruby3.2-rubygem-abstract_method ruby3.2-rubygem-cfa ruby3.2-rubygem-cfa_grub2 ruby3.2-rubygem-cheetah ruby3.2-rubygem-fast_gettext ruby3.2-rubygem-gem2rpm ruby3.2-rubygem-nokogiri ruby3.2-rubygem-ruby-augeas ruby3.2-rubygem-ruby-dbus ruby3.2-rubygem-simpleidn ruby3.2-rubygem-unf ruby3.2-rubygem-unf_ext syslinux unzip unzip-doc xtables-plugins yast2 yast2-add-on yast2-alternatives yast2-apparmor yast2-bootloader yast2-control-center yast2-control-center-qt yast2-core yast2-country yast2-country-data yast2-firewall yast2-ftp-server yast2-hardware-detection yast2-installation yast2-journal yast2-ldap yast2-logs yast2-mail yast2-metapackage-handler yast2-network yast2-nfs-common yast2-nfs-server yast2-ntp-client yast2-online-update yast2-online-update-configuration yast2-online-update-frontend yast2-packager yast2-pam yast2-perl-bindings yast2-pkg-bindings yast2-printer yast2-proxy yast2-python3-bindings yast2-ruby-bindings yast2-samba-client yast2-samba-serveryast2-scanner yast2-security yast2-services-manager yast2-slp yast2-snapper yast2-storage-ng yast2-sysconfig yast2-tftp-server yast2-theme yast2-theme-oxygen yast2-trans-de yast2-trans-en_GB yast2-trans-stats yast2-transfer yast2-update yast2-users yast2-vm yast2-x11 yast2-xml yast2-ycp-ui-bindings

The following 3 patterns are going to be REMOVED:
  kde_yast yast2_basis yast2_desktop

102 packages to remove.
After the operation, 116.5 MiB will be freed.
Continue? [y/n/v/...? shows all options] (y): y
erlangen:~ #

Nope. They rarely occur on systems with standard repositories enabled:

erlangen:~ # type repos
repos is aliased to `zypper repos --alias --uri --refresh --show-enabled-only --priority'
erlangen:~ # 

erlangen:~ # repos
#  | Alias         | Enabled | GPG Check | Refresh | Priority | URI
---+---------------+---------+-----------+---------+----------+---------------------------------------------------------------------------------
 7 | Packman       | Yes     | (r ) Yes  | Yes     |   90     | https://ftp.fau.de/packman/suse/openSUSE_Tumbleweed/
21 | non-oss       | Yes     | (r ) Yes  | Yes     |   99     | https://download.opensuse.org/tumbleweed/repo/non-oss/
23 | oss           | Yes     | (r ) Yes  | Yes     |   99     | https://download.opensuse.org/tumbleweed/repo/oss/
30 | update        | Yes     | (r ) Yes  | Yes     |   99     | https://download.opensuse.org/update/tumbleweed/
 4 | Geo           | Yes     | (r ) Yes  | Yes     |  100     | https://download.opensuse.org/repositories/Application:/Geo/openSUSE_Tumbleweed/
11 | google-chrome | Yes     | (r ) Yes  | Yes     |  100     | https://dl.google.com/linux/chrome/rpm/stable/x86_64
18 | jalbum        | Yes     | (  ) No   | Yes     |  100     | https://jalbum.net/download/software/yumrepo/
20 | myrepo        | Yes     | (  ) No   | Yes     |  100     | dir:/home/karl/Downloads/myrepo
erlangen:~ #

Host erlangen’s current configuration:

erlangen:~ # inxi -SMCmDy132
System:    Host: erlangen Kernel: 6.2.12-1-default arch: x86_64 bits: 64 Console: pty pts/1 Distro: openSUSE Tumbleweed 20230424
Machine:   Type: Desktop System: Micro-Star product: MS-7C56 v: 2.0 serial: N/A
           Mobo: Micro-Star model: B550-A PRO (MS-7C56) v: 2.0 serial: 07C5622_L41E321872 UEFI: American Megatrends LLC. v: A.90
             date: 03/17/2022
Memory:    RAM: total: 27.28 GiB used: 7.79 GiB (28.5%)
           Array-1: capacity: 128 GiB slots: 4 EC: None
           Device-1: DIMM 0 type: no module installed
           Device-2: DIMM 1 type: DDR4 size: 16 GiB speed: 2133 MT/s
           Device-3: DIMM 0 type: no module installed
           Device-4: DIMM 1 type: DDR4 size: 16 GiB speed: 2133 MT/s
CPU:       Info: 8-core model: AMD Ryzen 7 5700G with Radeon Graphics bits: 64 type: MT MCP cache: L2: 4 MiB
           Speed (MHz): avg: 2150 min/max: 1400/4672 cores: 1: 1400 2: 1400 3: 3800 4: 3800 5: 1400 6: 1400 7: 1400 8: 1400
             9: 3800 10: 1400 11: 3800 12: 1400 13: 3800 14: 1400 15: 1400 16: 1400
Drives:    Local Storage: total: 3.64 TiB used: 1.62 TiB (44.7%)
           ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 970 EVO Plus 2TB size: 1.82 TiB
           ID-2: /dev/sda vendor: Crucial model: CT2000BX500SSD1 size: 1.82 TiB
erlangen:~ #

download.opensuse.org resolves to a working mirror:

erlangen:~ # curl -I https://download.opensuse.org/tumbleweed/repo/oss/x86_64/a2ps-4.15-1.2.x86_64.rpm
HTTP/2 302 
date: Wed, 26 Apr 2023 09:57:32 GMT
server: Apache
location: https://ftp.uni-erlangen.de/opensuse/tumbleweed/repo/oss/x86_64/a2ps-4.15-1.2.x86_64.rpm
vary: Accept,COUNTRY
content-type: application/x-rpm

erlangen:~ #

Always check whether you actually need the package causing zypper to ask for manual action. Remove it if appropriate. If in trouble check for unnneeded packages and remove them too: Cleanup of distribution upgrades

When working as an administrator always sit back and have a cup of coffee or a mug of beer first.

22

I came to the forum today because I had a related problem. There was a libPimK* that could not be updated. There were 5 proposed solutions. Everyone led to a cascade of more files that could not be updated.

I just reinstalled Tumbleweed to resolve a partitioning issue. I failed to remove the iso from the cd drive. Removing it failed to resolve the problem. Going into yast and disabling updating from the iso did solve the problem immediately. Sounds like different files but the same problem.

23

reply to : karlmistelberger

Well, karlmistelberger, I’m taking note of all your advice, but I’ll have to study it before proceeding.
So I have to consider these things: clean deps, dry run, packages unneeded.

Then you told me:
They rarely occur on systems with standard repositories enabled
Do you think I have some repo that doesn’t fit? Have you seen my list? xxxx://paste.opensuse.org/pastes/13c187033f70

From wikipedia : “The Bergkirchweih is an annual Volksfest (beer festival and traveling funfair)…”
Handsome! But why are we talking about beer festivals?

This is yours:
xxxxx://ftp.uni-erlangen.de/opensuse/tumbleweed/repo/oss/x86_64/a2ps-4.15-1.2.x86_64.rpm
This is mine :
xxxxx://opensuse.mirror.garr.it/mirrors/opensuse/tumbleweed/repo/oss/x86_64/a2ps-4.15-1.2.x86_64.rpm

You complain about your mirror, but don’t you think that maybe mine is even worse?

You said:
Always check whether you actually need the package causing zypper to ask for manual action. Remove it if appropriate.
So isn’t it wrong if I try to remove the old version of Ruby as well? I’ve been saying for a while that I want to give it a try.

And then you say: When working as an administrator always sit back and have a cup of coffee or a mug of beer first.
Well, enjoy the moment.

end of reply to : karlmistelberger

I reply to: Prexy

Sorry, I’m not sure that I understand the things you did.
I understand you reinstalled Tumbleweed for partition reasons. So far it’s fine.

But then you said: "I failed to remove the iso from the cd drive ".
What do you mean by this? I do not understand. Are you talking about a virtual drive perhaps? And so what?

Then you said : "Removing it failed to resolve the problem " .
You said you couldn’t remove the iso, now you say you removed it but that didn’t fix the problem. Seems like a contradiction, don’t you think?

Then you said : " Going into yast and disabling updating from the iso did solve the problem immediately ".
I don’t use yast, I don’t like the idea. I suppose the effect of what you’ve done is to remove the iso from the repo list. Do you agree?

And then you say: “Sounds like different files but the same problem”.
If so, then I should just disable the iso repo, as someone already suggested. I think it’s time to try that too.

Thank you all.

24

I’ll try to clarify for you.

I did not feel comfortable with moving partitions to take advantage of unallocated space which I freed up from a Windows partition. To take an easy way out, I reinstalled Tumbleweed from an iso that I downloaded and burned to a CD.

As I do routinely once or twice a week, I used the cli to update, running zypper dup. It came back with a big cascade of errors, saying there were no installers for a file. Trying to resolve that gave me the same error for a different file. There ended up with dozens of files it couldn’t update because of no available installers.

I then realized I had failed to take the CD, with the iso on it, out of my cd/dvd drive. I assumed it was searching the iso for the missing files rather than going out to the repos. So, I took the cd iso out of the drive and tried again. But the problem with updating continued.

I finally thought of one more step. I opened yast, clicked on “Software Repositories” and unchecked the cd/dvd drive and the iso from being checked for updates. In other words: I disabled the iso in the cd drive from updates.

Once I did that, I exited yast, returned to the cli and ran zypper dup. Now, the errors disappeared and it updated quickly and without error.

I hope that clears up confusion.

1 Like
25

:+1:
That’s EXACTLY what one should do after installation is complete and successful … remove the ISO as a “source repo”, as it’s no longer required and causes issues.

26

Prexy, now you’ve made yourself clear.
The fact that you had mentioned iso instead of disk made me think that you had used an uncommon installation method. People try everything.

I don’t know if you’ve read all my posts, but initially I did an experiment, I uninstalled some ruby components and that made yast unusable for now.

However, what you did I believe corresponds to the zypper command: # zypper mr -d n.
Where n. corresponds to the number associated with the repo in the table visible with the command: zypper lr

Even nrickert, before you had told me :
You should disable or delete that repo. Otherwise it will prevent your system from being fully up to date.

So today I tried to do it. But things turned out differently for me.

Before the update I did a refresh and got this error message:

Retrieving the metadata of the 'openSUSE-Tumbleweed-Oss' repository .......................................[error]
The repository 'openSUSE-Tumbleweed-Oss' is invalid.

I don’t show you all the output, because the rest isn’t relevant.

So I re-enabled the iso repo and refreshed again, this time everything went fine.
But I don’t think it’s a good idea at this point to disable the iso repo and try an update.

Probably the presence of the iso repo enabled is causing my problem, but now it is not enough to disable it to go back.
But I think this fact is interesting, that one repo affects another, I hope someone here can tell me something about this curious effect.

Thank you all.

27

Disabling the install repo is normal and should be done At least if you have not screwed around with system :stuck_out_tongue:

If not done it will cause problems eventually.

28

Users may want to use priorities:

erlangen:~ # repos
#  | Alias         | Enabled | GPG Check | Refresh | Priority | URI
---+---------------+---------+-----------+---------+----------+---------------------------------------------------------------------------------
 7 | Packman       | Yes     | (r ) Yes  | Yes     |   90     | https://ftp.fau.de/packman/suse/openSUSE_Tumbleweed/

21 | non-oss       | Yes     | (r ) Yes  | Yes     |   99     | https://download.opensuse.org/tumbleweed/repo/non-oss/
23 | oss           | Yes     | (r ) Yes  | Yes     |   99     | https://download.opensuse.org/tumbleweed/repo/oss/
30 | update        | Yes     | (r ) Yes  | Yes     |   99     | https://download.opensuse.org/update/tumbleweed/

 4 | Geo           | Yes     | (r ) Yes  | Yes     |  100     | https://download.opensuse.org/repositories/Application:/Geo/openSUSE_Tumbleweed/
11 | google-chrome | Yes     | (r ) Yes  | Yes     |  100     | https://dl.google.com/linux/chrome/rpm/stable/x86_64
18 | jalbum        | Yes     | (  ) No   | Yes     |  100     | https://jalbum.net/download/software/yumrepo/
20 | myrepo        | Yes     | (  ) No   | Yes     |  100     | dir:/home/karl/Downloads/myrepo
erlangen:~ #

Standard repos have priority 99. Packman has higher priority 90. Other repos have lower priority 100. More: https://www.youtube.com/watch?v=x8kEaJU6hlw

I didn’t complain. I told what happens. Most of the time MirrorCache does a great job: GitHub - openSUSE/MirrorCache: Download Redirector.

Everything depends on what you want to achieve. As already posted above removing upgraded ruby would remove yast2 too. Presumably you wouldn’t want to do this. I don’t have an installed old version of ruby. I don’t know what would happen. Perform a dry run and see what happens.

Aside from trivial cases real world usage of zypper is like playing chess. You need to get some basic skills first. Later you learn what works best.

1 Like
29

Hello, Opensuse offers you a complete R&R distribution, ready to use, with updates (snapshots) that are tested and released on the whole system (through OpenQA) not package by package.

30

Thanks to everyone who has chimed in since my last post.
Let me start by saying that after posting it, I tried to do what I had in mind for a while, that is uninstall the " ruby3.1-3.1.3-3.2.x86_64" package.
Just as I thought, this broke the deadlock and I was able to update the system right after, without any issues.
The 3.2 version of ruby, previously uninstalled by me at this point reinstalled itself automatically and yast started working again.
I have not tried a second time to disable the repo of the iso to see if it works now, certainly before it was impossible, now we’ll see.

Now I reply to gogalthorp :
You said : Disabling the install repo is normal and should be done.

I didn’t say the opposite, I said that in the situation I’m in I can’t do it, it’s different.
If everything had been solved by disabling the repo I probably wouldn’t have even arrived on this forum.

Now I reply to karlmistelberger :
You say : Standard repos have priority 99. Packman has higher priority 90. Other repos have lower priority 100.

That youtube video is too boring to watch, I think the priority argument is easy to understand: higher priority = higher precedence, I don’t think there is more to discover.
So the core repositories must have the highest priority because that way core parts of the system are preserved. Simple and logical.

MirrorCache: I’m leaving this topic aside as I didn’t quite understand it.

Then you said : …removing upgraded ruby would remove yast2 too. Presumably you wouldn’t want to do this.

Of course I don’t want that, but I knew that if I managed to upgrade, all the necessary packages would reinstall themselves, which they did, so I didn’t see it as a problem.

Then you told me: Perform a dry run and see what happens.

The speech is interesting but I have to understand it better before doing tests.
I’ve found a lot of discussions about a command to delete all unnecessary autoinstalled dependencies.
Various scripts are proposed which combine "zypper packages --unneeded " with " awk " and “zypper rm” but the same authors warn that if used incorrectly they could seriously damage the system.
And after all, it seems that in my case that wasn’t even the problem.

Then you said : sage of zypper is like playing chess. You need to get some basic skills first

I agree, but it seems to me that zypper also has many unsolved bugs, for example in my case the options it offered were correct, but then it couldn’t execute them, so I had to do it by hand.
Others in a similar situation have chosen to reinstall the system.
And honestly speaking, no one here dared to suggest that I try what I finally did.
So it’s safe to assume they wouldn’t have done it in my place.

Now I reply to Vernius :

It’s a point of view and I respect it. Personally, the fact that the ISO already contains a bit of everything I don’t see as an advantage, especially the fact that it includes 4 GUIs.
I believe the packages are tested but on Tumbleweed I have problems with various applications that I don’t have with other distributions.
For example with media players.
Right now on this pc, in addition to tumbleweed, I have arch and debian branch distros.
I can’t blame myself or the pc for the problems if I don’t get them with other distros.
But everyone has their own experience and I thank you for answering my question.

31

After successfully updating the system, as described last time, it remained to check whether it was now possible to deactivate the original iso repo and repeat the update.
The answer is yes, I updated the system without problems, this time completely.

In summary: the problem was given by the simultaneous presence of two versions of ruby, namely 3.1 and 3.2. This generated a conflict.

Zypper figured out the problem and offered some possible solutions, however it was unable to perform any of them.
Among the proposed options was to uninstall the older version of ruby.
Doing this manually fixed the problem.

As reported by many users during this discussion, to prevent similar situations from happening again, it was necessary to disable, in the repo list, the entry that refers to the original installation disk.

The problem that gave rise to this discussion has therefore been completely resolved. If the forum administrators deem it useful, they can mark this thread as resolved.

Thank you once again to all participants in the discussion.

1 Like
32

I don’t think so: I can no longer update Tumbleweed - #4 by malcolmlewis

1 Like
33

Hello karlmistelberger.
Of course I had seen those comments.

malcolmlewis correctly said to delete ruby 3.1 and continue with 3.2. But he didn’t take into account what Sammiev and I are we said, that is, selecting one option or the other was useless, because it didn’t work.

arvidjaar instead said that the jump from version 20230418 to version 20230420 eliminated ruby 3.1. Indeed this statement encouraged me to make the decision.

But he also says: “but I also did not try to “fix” the system in the past by blindly removing something”.
So what I say is true, that he manually would not have done it.
Or at least he wouldn’t be trusted to recommend it to others.

Anyway, I don’t want to argue. Having the problem before your eyes is always different from hearing it explained in words by another.
So I know that helping others in this way is difficult, and you all have to be thanked for what you do.

I hope we can move forward now.

34

Thanks for the feedback given. Some remarks:

“selecting one option or the other was useless, because it didn’t work” is not an answer. You decided to omit any detailed information. It’s frustrating.

The above is your interpretation. My experience with dozens of installations is quite different.

I disagree. Implementing the procedures described in the video very significantly reduced the number of issues encountered with zypper dist-upgrade.

Problems do occur:

However most issues reported in openSUSE forums are due to careless or clueless upgrading.

35

you said :
“selecting one option or the other was useless, because it didn’t work” is not an answer. You decided to omit any detailed information. It’s frustrating.

I don’t know if you’re kidding me but I still make one last attempt and that’s it.
You say, and I believe you, that you have a lot of experience with zypper. So sooner or later you will have come across that error message we were talking about.
We have an example in the third post of this thread. Sammiev’s post.

As you can see there, sammiev is doing a dist-upgrade but gets stopped by an error message.
As you can see, he is offered a multiple choice represented as: [1/2/3/4/s/r/c/d/?]
Each entry corresponds to an alternative operation. The user must choose one, type the corresponding character and press enter.
At this point, the user follows the instructions and makes his choice.
Once this is done, zypper is expected to execute the selected command…but not.
What it does is reprint the error message with all the options and ask you again to choose.
This generates an infinite loop. To stop it you need the C option which is the only one that works, but this also ends the update procedure.

If you don’t understand it now it doesn’t matter, but I don’t want to talk about it anymore.

Sure, we can discuss whether this is a bug or a consequence of misuse by the user, but I don’t think we’d come to an agreement, so I’ll leave the philosophy to you.

You said :
Implementing the procedures described in the video very significantly reduced the number of issues encountered with zypper dist-upgrade.

I can understand written text but speech is too difficult for me to follow.

Extract from your previous discussion:
Upgrade of package kernel-firmware-qcom requires removal of directory /usr/lib/firmware/qcom/LENOVO/21BX to succeed.

Well, that’s why when I asked you if it was the case to try uninstalling ruby 3.1, you should have said yes, instead you said: I don’t know.

You said :
However most issues reported in openSUSE forums are due to careless or clueless upgrading.

That’s for sure, but you find me someone who has never made a mistake and then we’ll talk about it.
Making mistakes is the surest way to learn anything.

36

I have had this happen –

except that it is not an infinite loop. The new message is subtly different from the previous message.

Yes, it can still be frustrating and you still might want to give up. Or start over and make a different first choice.

37

Which is exactly why we wanted to see them to make our decision and provide better advice, not to hear vague description of something OP could not interpret correctly.

38

Nope. The error message never showed up on infamous host erlangen. Out out being careless a different error occurred during unattended upgrade:

erlangen:~ # journalctl -u dup.service -b 9fea6d5c881b4917a8f887dc7b1b44fe --identifier zypper _PID=30078 --no-p
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 this command.
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:~ #

I removed unneeded packages as detailed here: Cleanup of distribution upgrades. Running the cleanup command resulted in the following zypper command being executed:

2023-03-24 06:32   7108  1.14.59  zypper packages --unneeded
2023-03-24 06:32   7137  1.14.59  zypper remove adjtimex fixmath-devel gcc12-c++ gcc12-fortran gcc12-info gcc12-locale gprofng ibus-dict-emoji libfilezilla34 ruby3.1-rubygem-cfa_grub2 ruby3.1-rubygem-cheetah ruby3.1-rubygem-fast_gettext ruby3.1-rubygem-nokogiri ruby3.1-rubygem-ruby-dbus ruby3.1-rubygem-simpleidn util-linux-tty-tools

Checking again revealed more:

2023-03-24 06:33   9345  1.14.59  zypper packages --unneeded

Repeating the procedure resulted in:

2023-03-24 06:34   9417  1.14.59  zypper packages --unneeded
2023-03-24 06:34   9446  1.14.59  zypper remove --clean-deps gcc12 libstdc++6-devel-gcc12 ruby3.1-rubygem-abstract_method ruby3.1-rubygem-cfa ruby3.1-rubygem-unf

On several occasions users boasted in the openSUSE forums: “I never care about unneeded packages”.

I see. You may enable subtitles.

This wasn’t meant to blame you. I added it for other users reading this thread.

39

Here everyone has their own personal speech, without remembering the most important thing, which is that the problem that brought me here has been solved, and it was solved by doing something that no one here advised me to do.

I don’t want to be lacking in courtesy, but it seems to me that nobody here wants to accept this fact.

Again: the problem was solved by manually deleting rubi 3.1.
Can anyone here say they gave me this advice? I do not think so. For me it is not a problem, but it seems that it is for you.

nrickert, you’re probably talking about what happened to Prexy, which is different from what happened to me.
More precisely it happened to me but previously, and when it happened I did something different, I inserted the original DVD and in this way the update was completed.
It wasn’t the right thing to do, but it worked at the time.
In that case, the error messages changed with each attempt, as you say. But it was a different situation from the one I found myself in when I decided to open this discussion.
Last time I explained everything in detail but, I have the impression that you don’t waste much time reading what I write.
You have an idea in mind, and you carry it forward. You tell me it wasn’t an infinite loop but, how can you claim such a thing? Have you come to me to see for yourself?

arvidjaar, you keep repeating that I didn’t give all the information, as if I didn’t show you some of the output.
So now that nrickert exclaims that it wasn’t an infinite loop, you assume that it is. Don’t you think it’s hard for nrickert to determine what really happened since he wasn’t present here?
I won’t repeat what happened, it was clear from the beginning, if you don’t want to believe it, it’s your personal matter.

karlmistelberger, by now you’re hooked on this thing about automatic orphan dependencies.
In my case that wasn’t the problem, at least this time. You are bringing output into this discussion that has nothing to do with this case, and you are making a separate reasoning on your own.

Your speech may be right, but in this discussion it is totally off topic.

40

Despite numerous baseless claims made by forum users (including the original poster of this thread) maintainers of Leap and Tumbleweed encountering zypper asking questions are encouraged to try and remove unneeded packages first and retry zypper dist-upgrade.

erlangen:~ # cat /usr/local/bin/remove-unneeded-packages
#!/bin/bash 
zypper packages --unneeded | grep ^i|cut -d '|' -f3|xargs zypper rm --clean-deps
erlangen:~ #