Is it possible to break install with wrong glibc?


The recent TW comes with new glibc version and accordingly it installs all packages fresh.

What happenz if I try to install a single package (let’s say: screen) BEFORE this update and TW wants to install the new glibc as a dependency? Will it mess up my system if I proceed with the installation of screen and glibc as a dependency?

For reference:

You won’t really know until you try it.

If updating “screen” requires the new “glibc”, then that may force the update of several other packages. If the dependencies are set right in the packages, it shouldn’t break anything.

My personal update practice is to update “zypper”, “rpm”, “libzypp”, “libsolv” and a few others before I do the “zypper dup”.

For the update in question, my preliminary update already pulled in the new “glibc” and I think it updated around 40 packages (I didn’t keep records), which is a lot more than usually happens with the preliminary update. And then, of course, the subsequent “zypper dup” updated 2000 or so packages.

The only thing that broke, was that when finished I did not have any network access. But rebooting fixed that.

Hi and thanks for replying!

I still don’t really know how to safely update this remote box (without the risk of loosing access), unfortunately no screen installed yet.

Maybe some other opinions/options… :slight_smile:

I have a test TW install that is several weeks behind with upgrades. Just trying to upgrade glibc (from 2.32 to 2.33) brings in automatic updates for:

Pay attention to the last one, that might be the culprit for network loss or DNS malfunction…
As written in another thread that big upgrade crashed my Gnome session but I was able to complete the “dup” (packages already cached, so I really don’t know if the system had network access at that point…) and rebooted right after that, with no further problems.

Older versions of screen are still available, for instance here:
Maybe downloading an older version and install via rpm is a viable option?

It is probably safe to use “ssh” for that.

And isolate graphical target if that is running on the remote machine…

That did the trick! Many thanks!

The ssh connection with screen didn’t break, but it was good to have screen running for the update…