I can no longer update Tumbleweed

OK, here it is: openSUSE Paste

To show output in english you can use…

LANG=C sudo zypper -vvv dup

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

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

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.

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.

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.

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.

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

:+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.

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.

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.

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

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.

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.

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

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

1 Like

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.

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.

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.