Our recent SLES11SP1 system was proposing an automated migration to SP2. As it was the first time I was seeing the auto-update tools for registered systems, I thought why not…
When it was checking the system, the migration tool quickly complained about a conflict between version 4.3.4_20091019-0.7.35 of libstdc++ that was installed and version 4.6.2_20111026-1.1.4 that it was requiring (or wanting to install). It was proposing the option of removing old version or ignoring the conflict.
But, before to go ahead, I wanted to have a look with yast. When I saw that 4.3.4 was installed, I decided to remove it and install 4.6.2 with yast directly, thinking the migration tool would be happy…
Yast, installed 4.6.2, checked and updated dependencies, etc… success.
But then, I wanted to open a Gnome terminal, what silently failed, so I though it was wise to reboot the system…
When it came back, I only got a console login, no Gnome. Fortunately, the server is in run level 5 and most production services are running.
But well, there now are incompatibilities in this system and it must be fixed.
I could try to fix incompatibilities manually, one by one, but I’m fearing never to get the system back to a stable state, or to spoil the system in a way that auto-update tools would no more be able to maintain this system.
So my question to experienced people: what would be the best way to recover this system? Re-installing libstdc++43 manually (but I’m not sure how dependencies would be handled in that backwards direction), go ahead with the migration with the hope it will not fail at some point and it will fix everything (in that case how to do it from the command line).
Thanks in advance for your suggestions.
PS: I know, I should have made a backup :-/