I upgraded my SLES11SP3 to SLES12SP1 using the .ISO in a USB memory stick.
Everything went smoothly but now most (if not all) X11 commands are broken, leaving my server (256 cores) almost usless to my users.
Before upgrading I saved my SLES11Sp3 system in a disk and now I can use its libraries. In /usr/lib64_SLES11SP3 I copied /usr/lib64 and now I can use it. If I do
setenv LD_LIBRARY_PATH /usr/lib64_SLES11Sp3
then xterm works even if with some warnings:
Warning: translation table syntax error: Unknown keysym name: DRemove
Warning: … found while parsing ‘DRemove: ignore()’
Warning: String to TranslationTable conversion encountered errors
Unfortunately the same trick doesn’t work for other commands, eg. emacs
I have to say that due to grub problems I booted the system manually and before booting I didn’t explicitely defined a graphic terminal.
As a result I have no graphic console and none of the following commands starts it:
systemctl isolate graphical.target
init 5
but before booting I DIDN’T type any of the following grub command:
insmod efi_gop
insmod efi_uga
insmod gzio
insmod gettext
insmod gfxterm
insmod gfxmenu
insmod png
terminal_output gfxterm
Thus my hope is that the missing graphical console is the reason of my xcb_* errors.
Since my booting procedure is still a mess I can’t verify the above hope.
soon after the upgrade in /usr/lib64 there was a problem:
libxcb.so pointed to a missing .so
cd /usr/lib64
ls -ls libxcb.so*
0 lrwxrwxrwx 1 root root 15 Aug 11 13:51 libxcb.so -> libxcb.so.1.1.0
0 lrwxrwxrwx 1 root root 15 Mar 2 2014 libxcb.so.1 -> libxcb.so.1.0.0
116 -rwxr-xr-x 1 root root 113536 May 24 2013 libxcb.so.1.0.0
The file /usr/lib64/libxcb.so.1.1.0 was missing, being present only its previous version libxcb.so.1.0.0
I found out that in the SLES12SP1 DVD1 there is a rpm named libxcb1-1.10-1.21.x86_64.rpm which contains the version 1.1.0 of libxcb.
Such rpm was not installed during the upgrade process (I don't know why) and when I had a look into it I found there the missing
xcb_take_socket
rpm2cpio /mnt/suse/x86_64/libxcb1-1.10-1.21.x86_64.rpm |cpio -idmv
./usr/lib64/libxcb.so.1
./usr/lib64/libxcb.so.1.1.0
255 blocks
nm -D ./usr/lib/libxcb.so.1 |grep xcb_take_socket
0000a8f0 T xcb_take_socket
since in /usr/lib64 there was not any libxcb.so.1.1.0 I copied there the one in ./usr/lib/
In /usr/lib64 I then modified the links libxcb.so and libxcb.so.1 to point to the new libxcb.so.1.1.0
Now all seems to work properly!
I hope this helps somone.
Ciao,
Emanuele
soon after the upgrade in /usr/lib64 there was a problem:
libxcb.so pointed to a missing .so
cd /usr/lib64
ls -ls libxcb.so*
0 lrwxrwxrwx 1 root root 15 Aug 11 13:51 libxcb.so →
libxcb.so.1.1.0
0 lrwxrwxrwx 1 root root 15 Mar 2 2014 libxcb.so.1 →
libxcb.so.1.0.0
116 -rwxr-xr-x 1 root root 113536 May 24 2013 libxcb.so.1.0.0
The file /usr/lib64/libxcb.so.1.1.0 was missing, being present only
its previous version libxcb.so.1.0.0
I found out that in the SLES12SP1 DVD1 there is a rpm named
libxcb1-1.10-1.21.x86_64.rpm which contains the version 1.1.0 of
libxcb.
Such rpm was not installed during the upgrade process (I don’t know
why) and when I had a look into it I found there the missing
xcb_take_socket
seems my according response go lost somewhere… installing the RPM is highly recommended over copying the files manually, since future updates will only be applied based on the installation status of the RPM, not based on files.
Another issue I saw was that
since in /usr/lib64 there was not any libxcb.so.1.1.0 I copied there the one in ./usr/lib/
implies that the 32-bit version of the library was put into the directory for 64bit libraries, which would still break applications requesting the 64bit version… my original reply recommended to use “file” on both library copies to confirm that /usr/lib64 contains the 64bit version and /usr/lib has the 32-bit version.
I suppose now I should do something like this:
zypper in -f libxcb1-1.10-1.21.x86_64.rpm
I did a test and I got as follows:
zypper in -f -D libxcb1-1.10-1.21.x86_64.rpm
Refreshing service ‘Advanced_Systems_Management_Module_12_x86_64’.
Refreshing service ‘Containers_Module_12_x86_64’.
Refreshing service ‘SUSE_Linux_Enterprise_Server_12_SP1_x86_64’.
Refreshing service ‘SUSE_Linux_Enterprise_Software_Development_Kit_12_SP1_x86_64’.
Refreshing service ‘Web_and_Scripting_Module_12_x86_64’.
Loading repository data…
Reading installed packages…
Forcing installation of ‘libxcb1-1.10-1.21.x86_64’ from repository ‘Plain RPM files cache’.
Resolving package dependencies…
Problem: freeglut-080721-21.9.x86_64 requires libxcb-xlib.so.0()(64bit), but this requirement cannot be provided
deleted providers: xorg-x11-libxcb-7.4-1.29.1.x86_64
Solution 1: Following actions will be done:
deinstallation of freeglut-080721-21.9.x86_64
deinstallation of giflib-4.1.6-13.1.x86_64
deinstallation of gstreamer-0_10-plugins-base-0.10.35-5.15.8.x86_64
deinstallation of libgcj43-4.3.4_20091019-0.37.46.x86_64
deinstallation of libgtksourceview-2_0-0-2.8.2-0.1.195.x86_64
deinstallation of libgweather1-2.28.0-1.4.8.x86_64
deinstallation of libnotify1-0.4.4-173.29.28.1.x86_64
deinstallation of libwmf-0.2.8.4-206.27.4.x86_64
deinstallation of libxklavier15-4.0-1.5.26.x86_64
deinstallation of metacity-2.28.1-0.20.1.x86_64
deinstallation of mjpegtools-1.9.0rc3-1.33.x86_64
deinstallation of t1lib-5.1.1-100.21.1.x86_64
deinstallation of xorg-x11-libXpm-7.4-1.17.x86_64
deinstallation of gcc43-gij-4.3.4_20091019-0.37.46.x86_64
deinstallation of gstreamer-0_10-plugins-base-lang-0.10.35-5.15.8.x86_64
deinstallation of gstreamer-0_10-plugins-good-0.10.30-5.12.15.x86_64
deinstallation of gtksourceview-lang-2.8.2-0.1.195.x86_64
deinstallation of libgcj43-devel-4.3.4_20091019-0.37.46.x86_64
deinstallation of libgstapp-0_10-0-0.10.35-5.15.8.x86_64
deinstallation of libgstinterfaces-0_10-0-0.10.35-5.15.8.x86_64
deinstallation of metacity-lang-2.28.1-0.20.1.x86_64
deinstallation of gstreamer-0_10-plugins-good-lang-0.10.30-5.12.15.x86_64
deinstallation of gstreamer-0_10-plugins-base-devel-0.10.35-5.15.8.x86_64
Solution 2: do not install libxcb1-1.10-1.21.x86_64
Solution 3: break freeglut-080721-21.9.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c] (c):
I canceled , is it safe to continue with solution 3 (break) ?
dear Jens,
you are right but I did well! In fact I made a typo in my reply:
I actually copied into /usr/lib64 the file extracted by rpm2cpio into the dir ./usr/lib64 (not ./usr/lib as I wrongly typed)
[QUOTE=jmozdzen;34207]
since in /usr/lib64 there was not any libxcb.so.1.1.0 I copied there the one in ./usr/lib/
implies that the 32-bit version of the library was put into the directory for 64bit libraries, which would still break applications requesting the 64bit version… my original reply recommended to use “file” on both library copies to confirm that /usr/lib64 contains the 64bit version and /usr/lib has the 32-bit version.
no, it isn’t. (The same goes for running commands with “-f” in the first place.)
You’ve got yourself a system that has divergent requirements - some pieces of software require libxcb-xlib.so, others require libxcb1. As both in the end have the same library name, you have to decide which one of both sets (and hence which libxcb version) you want to run.
I guess that many of these programs that zypper wants to deinstall come from a non-SLES source (Packman?) - do you really need these or are these left-overs from an older install? In the latter case, let zypper uninstall these and have libxcb1.
Even if you install the lib by hand, or force installing libxcb1 by breaking other dependencies, you’ll run into an inconsistent system state. That’s why using zypper/rpm is the way to go: You’ll get warned before installing, rather than copying some lib and weeks later wonder about obscure program behavior in an seemingly unrelated back room of your system.
