# SLES 11 SP3 upgrade - Dependencies hell **URL:** \ **Category:** SLES Updates\ **Created:** [September 8, 2014, 9:20am UTC](https://forums.suse.com/t/sles-11-sp3-upgrade-dependencies-hell/26052 "2014-09-08T09:20:45Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![DCAT](https://avatars.discourse-cdn.com/v4/letter/d/df705f/32.png) [@DCAT](https://forums.suse.com/u/DCAT)\ **Post date:** [September 8, 2014, 9:20am UTC](https://forums.suse.com/t/sles-11-sp3-upgrade-dependencies-hell/26052/1 "2014-09-08T09:20:45Z")
Hello, as per subject I’m working on a SLESS 11 for VMware machine which has been upgraded from SLES11 SP1 to SLES 11 SP3, as I ws not the one who performed the upgrade I’m not sure what or how it has been performed. The server is running kernel version 3.0.101-0.8-default which I would need to upgrade to 3.0.101-0.31-default and on top of this I see there are couple of more updates to installed Software that need be updated, when I issue a zypper update command I get the following : [CODE]Loading repository data… Reading installed packages… The following package updates will NOT be installed: The following product updates will NOT be installed: The following NEW packages are going to be installed: libopenobex1 perl-Module-Build perl-Test-Simple python-m2crypto subscription-tools The following NEW product is going to be installed: SUSE Linux Enterprise Server 11 SP3 for VMware The following package is going to be REMOVED: openobex The following product is going to be REMOVED: SUSE Linux Enterprise Server 11 SP1 for VMware The following packages are going to be upgraded: MozillaFirefox MozillaFirefox-translations PackageKit SLES-for-VMware-release SLES-for-VMware-release-DVD a2ps apache2 apache2-devel apache2-prefork apache2-utils augeas-lenses autoyast2 autoyast2-installation bind-libs bind-utils binutils checkmedia crash crash-sial ctags curl docbook-xsl-stylesheets file fontconfig fontconfig-32bit gdb gfxboot-branding-SLES glib2 glib2-devel glib2-lang glibc glibc-32bit glibc-devel glibc-i18ndata glibc-info glibc-locale hal hplip-hpijs hwinfo java-1\_6\_0-ibm kdump kernel-default kernel-default-base kernel-default-devel kernel-source kpartx libMagickCore1 libapr1 libapr1-devel libaugeas0 libblkid1 libcurl-devel libcurl4 libdrm libexpat-devel libfreebl3 libgcc\_s1 libgcc\_s1-32bit libgio-2\_0-0 libgio-2\_0-0-32bit libgio-fam libglib-2\_0-0 libglib-2\_0-0-32bit libgmodule-2\_0-0 libgmodule-2\_0-0-32bit libgnutls26 libgobject-2\_0-0 libgobject-2\_0-0-32bit libgomp1 libgthread-2\_0-0 libgthread-2\_0-0-32bit libldap-2\_4-2 libldap-2\_4-2-32bit libldb1 libmysqlclient\_r15 libpng12-0 libpng12-0-32bit libpoppler-glib4 libpoppler5 libpython2\_6-1\_0 libpython2\_6-1\_0-32bit libqdialogsolver1 libqt4 libqt4-qt3support libqt4-sql libqt4-sql-mysql libqt4-x11 libsmbclient0 libsnmp15 libsoftokn3 libstdc++6 libstdc++6-32bit libtalloc2 libtalloc2-32bit libtdb1 libtdb1-32bit libtevent0 libtevent0-32bit libudev0 libuuid1 libuuid1-32bit libwbclient0 libwbclient0-32bit libxml2 libxml2-32bit libxml2-python libzypp linux-kernel-headers logrotate makedumpfile man-pages mdadm microcode\_ctl mkinitrd mozilla-nspr mozilla-nss multipath-tools mutt nscd obex-data-server openldap2-client openldap2-devel openssh openssh-askpass openssl-certs pam pam-doc perl poppler-tools puppet python python-base python-pywbem python-tk python-xml release-notes-SLES-for-VMware rpcbind ruby samba samba-client samba-client-32bit satsolver-tools sg3\_utils sle-sdk-release sle-sdk-release-SDK sles-admin\_en-pdf sles-deployment\_en-pdf sles-installquick\_en-pdf sles-manuals\_en sles-security\_en-pdf sles-storage\_en-pdf smis-providers smt-client snmp-mibs star sudo supportutils suse-build-key tcsh timezone udev util-linux util-linux-lang uuid-runtime wget x11-input-wacom xinetd xorg-x11-libs xorg-x11-libs-32bit yast2 yast2-add-on yast2-firewall yast2-installation yast2-iscsi-client yast2-libyui yast2-ncurses yast2-ncurses-pkg yast2-network yast2-nfs-client yast2-online-update yast2-packager yast2-perl-bindings yast2-pkg-bindings yast2-python-bindings yast2-qt yast2-qt-pkg yast2-registration yast2-samba-client yast2-slp-server yast2-storage yast2-storage-lib yast2-update yast2-wagon yast2-ycp-ui-bindings zlib zlib-devel zsh zypper The following product is going to be upgraded: SUSE Linux Enterprise Software Development Kit 11 SP3 The following package needs additional customer contract to get support: libmysqlclient\_r15 The following packages are not supported by their vendor: apache2 apache2-devel apache2-prefork apache2-utils crash docbook-xsl-stylesheets gfxboot-branding-SLES glib2-devel glibc-info java-1\_6\_0-ibm libapr1 libapr1-devel libcurl-devel libexpat-devel libgio-fam libopenobex1 libqdialogsolver1 libudev0 makedumpfile obex-data-server openldap2-devel poppler-tools python-m2crypto python-tk release-notes-SLES-for-VMware sle-sdk-release sle-sdk-release-SDK x11-input-wacom yast2-python-bindings yast2-slp-server zlib-devel 198 packages to upgrade, 5 new, 1 to remove. Overall download size: 428.6 MiB. After the operation, additional 58.8 MiB will be used[/CODE] What I cannot understand is why SUSE Linux Enterprise Server 11 SP1 for VMware is in there, in all the other SP3 machines that I’ve personally upgraded this never came up so I’m a bit puzzled, what also I cannot understand is the last message The following packages are not supported by their vendor: what does that mean? I’m more of a RH guy and in many years never seen such a message so I’m double puzzled 🙂 If I proceed with the update it seems to run smoothly but at the end of it if I try to run zypper update (or lr) or many other commands I cnanot recall at the moment I get the following: ` zypper update zypper: /lib64/libz.so.1: no version information available (required by /usr/lib64/libxml2.so.2) zypper: /lib64/libz.so.1: no version information available (required by /usr/lib64/libxml2.so.2) zypper: /lib64/liblzma.so.5: no version information available (required by /usr/lib64/libxml2.so.2) zypper: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /usr/lib64/libxml2.so.2) zypper: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by /usr/lib64/libxml2.so.2)` Message per se is pretty clear but I confirmed all required libraries/files are indeed where they should be, I’ve also tried to manually update these files to the latest available release but problem is exactly the same. Honestly I ran out of ideas and find myself stuck with this system that needs updates but cannot deploy them, does anyone have an idea what the issue could be or what I could do? Thanks in advance for any help which would highly appreciated ---
**Author:** ![smflood](https://sea2.discourse-cdn.com/flex022/user_avatar/forums.suse.com/smflood/32/10576_2.png) [@smflood](https://forums.suse.com/u/smflood)\ **Post date:** [September 8, 2014, 1:15pm UTC](https://forums.suse.com/t/sles-11-sp3-upgrade-dependencies-hell/26052/2 "2014-09-08T13:15:09Z")
On 08/09/2014 07:24, DCAT wrote: [color=blue] > as per subject I’m working on a SLESS 11 for VMware machine which has > been upgraded from SLES11 SP1 to SLES 11 SP3, as I ws not the one who > performed the upgrade I’m not sure what or how it has been performed. > > The server is running kernel version 3.0.101-0.8-default which I would > need to upgrade to 3.0.101-0.31-default and on top of this I see there > are couple of more updates to installed Software that need be updated, > when I issue a zypper update command I get the following : > > ## Code: > > ``` > Loading repository data... > > ``` > > Reading installed packages… > > The following package updates will NOT be installed: > > The following product updates will NOT be installed: > > The following NEW packages are going to be installed: > libopenobex1 perl-Module-Build perl-Test-Simple python-m2crypto > subscription-tools > > The following NEW product is going to be installed: > SUSE Linux Enterprise Server 11 SP3 for VMware > > THE FOLLOWING PACKAGE IS GOING TO BE REMOVED: > OPENOBEX > > THE FOLLOWING PRODUCT IS GOING TO BE REMOVED: > SUSE LINUX ENTERPRISE SERVER 11 SP1 FOR VMWARE > > The following packages are going to be upgraded: > MozillaFirefox MozillaFirefox-translations PackageKit SLES-for-VMware-release > SLES-for-VMware-release-DVD a2ps apache2 apache2-devel apache2-prefork > apache2-utils augeas-lenses autoyast2 autoyast2-installation bind-libs > bind-utils binutils checkmedia crash crash-sial ctags curl > docbook-xsl-stylesheets file fontconfig fontconfig-32bit gdb > gfxboot-branding-SLES glib2 glib2-devel glib2-lang glibc glibc-32bit > glibc-devel glibc-i18ndata glibc-info glibc-locale hal hplip-hpijs hwinfo > java-1\_6\_0-ibm kdump kernel-default kernel-default-base kernel-default-devel > kernel-source kpartx libMagickCore1 libapr1 libapr1-devel libaugeas0 > libblkid1 libcurl-devel libcurl4 libdrm libexpat-devel libfreebl3 libgcc\_s1 > libgcc\_s1-32bit libgio-2\_0-0 libgio-2\_0-0-32bit libgio-fam libglib-2\_0-0 > libglib-2\_0-0-32bit libgmodule-2\_0-0 libgmodule-2\_0-0-32bit libgnutls26 > libgobject-2\_0-0 libgobject-2\_0-0-32bit libgomp1 libgthread-2\_0-0 > libgthread-2\_0-0-32bit libldap-2\_4-2 libldap-2\_4-2-32bit libldb1 > libmysqlclient\_r15 libpng12-0 libpng12-0-32bit libpoppler-glib4 libpoppler5 > libpython2\_6-1\_0 libpython2\_6-1\_0-32bit libqdialogsolver1 libqt4 > libqt4-qt3support libqt4-sql libqt4-sql-mysql libqt4-x11 libsmbclient0 > libsnmp15 libsoftokn3 libstdc++6 libstdc++6-32bit libtalloc2 libtalloc2-32bit > libtdb1 libtdb1-32bit libtevent0 libtevent0-32bit libudev0 libuuid1 > libuuid1-32bit libwbclient0 libwbclient0-32bit libxml2 libxml2-32bit > libxml2-python libzypp linux-kernel-headers logrotate makedumpfile man-pages > mdadm microcode\_ctl mkinitrd mozilla-nspr mozilla-nss multipath-tools mutt > nscd obex-data-server openldap2-client openldap2-devel openssh > openssh-askpass openssl-certs pam pam-doc perl poppler-tools puppet python > python-base python-pywbem python-tk python-xml release-notes-SLES-for-VMware > rpcbind ruby samba samba-client samba-client-32bit satsolver-tools sg3\_utils > sle-sdk-release sle-sdk-release-SDK sles-admin\_en-pdf sles-deployment\_en-pdf > sles-installquick\_en-pdf sles-manuals\_en sles-security\_en-pdf > sles-storage\_en-pdf smis-providers smt-client snmp-mibs star sudo > supportutils suse-build-key tcsh timezone udev util-linux util-linux-lang > uuid-runtime wget x11-input-wacom xinetd xorg-x11-libs xorg-x11-libs-32bit > yast2 yast2-add-on yast2-firewall yast2-installation yast2-iscsi-client > yast2-libyui yast2-ncurses yast2-ncurses-pkg yast2-network yast2-nfs-client > yast2-online-update yast2-packager yast2-perl-bindings yast2-pkg-bindings > yast2-python-bindings yast2-qt yast2-qt-pkg yast2-registration > yast2-samba-client yast2-slp-server yast2-storage yast2-storage-lib > yast2-update yast2-wagon yast2-ycp-ui-bindings zlib zlib-devel zsh zypper > > The following product is going to be upgraded: > SUSE Linux Enterprise Software Development Kit 11 SP3 > > The following package needs additional customer contract to get support: > libmysqlclient\_r15 > > The following packages are not supported by their vendor: > apache2 apache2-devel apache2-prefork apache2-utils crash > docbook-xsl-stylesheets gfxboot-branding-SLES glib2-devel glibc-info > java-1\_6\_0-ibm libapr1 libapr1-devel libcurl-devel libexpat-devel libgio-fam > libopenobex1 libqdialogsolver1 libudev0 makedumpfile obex-data-server > openldap2-devel poppler-tools python-m2crypto python-tk > release-notes-SLES-for-VMware sle-sdk-release sle-sdk-release-SDK > x11-input-wacom yast2-python-bindings yast2-slp-server zlib-devel > > ## 198 packages to upgrade, 5 new, 1 to remove. Overall download size: 428.6 MiB. After the operation, additional 58.8 MiB will be used > > What I cannot understand is why -SUSE Linux Enterprise Server 11 SP1 for > VMware- is in there, in all the other SP3 machines that I’ve personally > upgraded this never came up so I’m a bit puzzled, what also I cannot > understand is the last message -The following packages are not supported > by their vendor:- what does that mean? I’m more of a RH guy and in many > years never seen such a message so I’m double puzzled 🙂 > > If I proceed with the update it seems to run smoothly but at the end of > it if I try to run zypper update (or lr) or many other commands I cnanot > recall at the moment I get the following: > > ## Code: > > ``` > zypper update > > ``` > > ## zypper: /lib64/libz.so.1: no version information available (required by /usr/lib64/libxml2.so.2) zypper: /lib64/libz.so.1: no version information available (required by /usr/lib64/libxml2.so.2) zypper: /lib64/liblzma.so.5: no version information available (required by /usr/lib64/libxml2.so.2) zypper: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /usr/lib64/libxml2.so.2) zypper: /lib64/libc.so.6: version `GLIBC\_2.15’ not found (required by /usr/lib64/libxml2.so.2) > > Message per se is pretty clear but I confirmed all required > libraries/files are indeed where they should be, I’ve also tried to > manually update these files to the latest available release but problem > is exactly the same. > > Honestly I ran out of ideas and find myself stuck with this system that > needs updates but cannot deploy them, does anyone have an idea what the > issue could be or what I could do? > > Thanks in advance for any help which would highly appreciated[/color] Firstly, not knowing how the server was upgraded doesn’t help. Let’s try and establish what version of SLES the server thinks it is running and which repositories it has access to - what do “cat /etc/\*release” and “zypper lr” produce? ## HTH. Simon SUSE Knowledge Partner * * * ## If you find this post helpful and are logged into the web interface, please show your appreciation and click on the star below. Thanks. ---
**Author:** ![DCAT](https://avatars.discourse-cdn.com/v4/letter/d/df705f/32.png) [@DCAT](https://forums.suse.com/u/DCAT)\ **Post date:** [September 8, 2014, 5:28pm UTC](https://forums.suse.com/t/sles-11-sp3-upgrade-dependencies-hell/26052/3 "2014-09-08T17:28:25Z")
Hi Simon, yes does not help and unfortunaltely know who did upgrade it make things even worse (I know my chickens…) it was not clear in my post but according to the release file the machine is indeed SP3: SUSE Linux Enterprise Server 11 (x86\_64) VERSION = 11 PATCHLEVEL = 3 As for Zypper lr it reports the standard repositories we’re using, I forgot to mention we have SMT in place, so I think they’re of little help in any case : `# | Alias | Name | Enabled | Refresh --+---------------------------+---------------------------+---------+-------- 1 | SLE11-SDK-SP3-Pool | SLE11-SDK-SP3-Pool | Yes | No 2 | SLE11-SDK-SP3-Updates | SLE11-SDK-SP3-Updates | Yes | No 3 | SLES11-SP3 | SLES11-SP3 | Yes | No 4 | SLES11-SP3-VMware-Updates | SLES11-SP3-VMware-Updates | Yes | No ` A small update, I was able to narrow down the error a bit locking the following package libcc\_s now produces this reduced version of the error: `zypper: /lib64/liblzma.so.5: no version information available (required by /usr/lib64/libxml2.so.2) zypper: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /usr/lib64/libxml2.so.2) zypper: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by /usr/lib64/libxml2.so.2)` Now I need to hunt down the package for liblzma.so.5 and the two GLIBC\_2.1\* errors and I’m done 🙂 Please let me know if there is any further output I can paste, in the mentime I’ll continue with my trial and error. ---
**Author:** ![Jens-U](https://avatars.discourse-cdn.com/v4/letter/j/d78d45/32.png) [@Jens-U](https://forums.suse.com/u/Jens-U)\ **Post date:** [September 8, 2014, 5:58pm UTC](https://forums.suse.com/t/sles-11-sp3-upgrade-dependencies-hell/26052/4 "2014-09-08T17:58:59Z")
Hi DCAT, you might want to have a look at the corresponding RPM database packet entries for the RPM containing those files (/usr/lib64/libxml2.so.2, /lib64/liblzma.so.5, /lib64/libc.so.6), to see from where they were installed, and when… and if any of those look suspicious, get the current version from your SMT server and install it manually. Once you have zypper working again, things will be easier. Regards, Jens ---
**Author:** ![smflood](https://sea2.discourse-cdn.com/flex022/user_avatar/forums.suse.com/smflood/32/10576_2.png) [@smflood](https://forums.suse.com/u/smflood)\ **Post date:** [September 8, 2014, 6:50pm UTC](https://forums.suse.com/t/sles-11-sp3-upgrade-dependencies-hell/26052/5 "2014-09-08T18:50:26Z")
On 08/09/2014 15:34, DCAT wrote: [color=blue] > yes does not help and unfortunaltely know who did upgrade it make things > even worse (I know my chickens…) it was not clear in my post but > according to the release file the machine is indeed SP3:[/color] Do you know whether it was upgraded directly from SLES11 SP1 (for VMware) to SLES11 SP3 or via SLES11 SP2, the latter being the supported route? [color=blue] > SUSE Linux Enterprise Server 11 (x86\_64) > VERSION = 11 > PATCHLEVEL = 3[/color] Okay so it think it is SLES11 SP3 but is it the “for VMware” flavour. Since /etc/issue could’ve been changed what does “ls /etc/products.d/” produce? [color=blue] > As for Zypper lr it reports the standard repositories we’re using, I > forgot to mention we have SMT in place, so I think they’re of little > help in any case : > > ## Code: > > ``` > # | Alias | Name | Enabled | Refresh > > ``` > > –±--------------------------±--------------------------±--------±------- > 1 | SLE11-SDK-SP3-Pool | SLE11-SDK-SP3-Pool | Yes | No > 2 | SLE11-SDK-SP3-Updates | SLE11-SDK-SP3-Updates | Yes | No > 3 | SLES11-SP3 | SLES11-SP3 | Yes | No > 4 | SLES11-SP3-VMware-Updates | SLES11-SP3-VMware-Updates | Yes | No > > --------------------[/color] What/where does SLES11-SP3 point to? SLES11 SP3 or SLES11 SP3 for VMware? Media or -Pool repository? What does “zypper lr -u” report? (Feel free to change the server name bit of output to server to hide your SMT name) [color=blue] > A small update, I was able to narrow down the error a bit locking the > following package -libcc\_s - now produces this reduced version of the > error:[/color] Unsurprising you’ve reduced errors by locking a problem package but that just means the problem package will still remain a problem. [color=blue] > ## Code: > > ``` > zypper: /lib64/liblzma.so.5: no version information available (required by /usr/lib64/libxml2.so.2) > > ``` > > ## zypper: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /usr/lib64/libxml2.so.2) zypper: /lib64/libc.so.6: version `GLIBC\_2.15’ not found (required by /usr/lib64/libxml2.so.2) > > Now I need to hunt down the package for liblzma.so.5 and the two > GLIBC\_2.1\* errors and I’m done 🙂 > > Please let me know if there is any further output I can paste, in the > mentime I’ll continue with my trial and error.[/color] Is the server a virtual machine? If so, I’d suggest taking a snapshot before tinkering too much. ## HTH. Simon SUSE Knowledge Partner * * * ## If you find this post helpful and are logged into the web interface, please show your appreciation and click on the star below. Thanks. ---
**Author:** ![DCAT](https://avatars.discourse-cdn.com/v4/letter/d/df705f/32.png) [@DCAT](https://forums.suse.com/u/DCAT)\ **Post date:** [September 8, 2014, 9:36pm UTC](https://forums.suse.com/t/sles-11-sp3-upgrade-dependencies-hell/26052/6 "2014-09-08T21:36:12Z")
[QUOTE]Do you know whether it was upgraded directly from SLES11 SP1 (for VMware) to SLES11 SP3 or via SLES11 SP2, the latter being the supported route? [/QUOTE] Well my instructions on this point were rather clear so I assume SP1 → SP2 → SP3 path has been followed but I would not swear on this, at this point all could be. [QUOTE] What/where does SLES11-SP3 point to? SLES11 SP3 or SLES11 SP3 for VMware? Media or -Pool repository? What does “zypper lr -u” report? (Feel free to change the server name bit of output to server to hide your SMT name)[/QUOTE] Here’s the output: `# | Alias | Name | Enabled | Refresh | URI --+---------------------------+---------------------------+---------+---------+-------------------------------------------------------------------------- 1 | SLE11-SDK-SP3-Pool | SLE11-SDK-SP3-Pool | Yes | No | http://192.168.XX.XX/repo/$RCE/SLE11-SDK-SP3-Pool/sle-11-x86_64 2 | SLE11-SDK-SP3-Updates | SLE11-SDK-SP3-Updates | Yes | No | http://192.168.XX.XX/repo/$RCE//SLE11-SDK-SP3-Updates/sle-11-x86_64 3 | SLES11-SP3 | SLES11-SP3 | Yes | No | http://192.168.XX.XX/instsource/SLES11SP3_Vmware 4 | SLES11-SP3-VMware-Updates | SLES11-SP3-VMware-Updates | Yes | No | http://192.168.XX.XX/repo/$RCE//SLES11-SP3-VMware-Updates/sle-11-x86_64/ ` These same repositories are configured for other SP3 machines which have been correctly upgraded from SP1 to SP3 `Unsurprising you've reduced errors by locking a problem package but that just means the problem package will still remain a problem.` Yep you’re right, and all in all I start to think it would be just faster to rebuild the machine but you know I would prefer to solve this for good as I have other machines with similar configuration and would like to avoid bad surprises. `Is the server a virtual machine? If so, I'd suggest taking a snapshot before tinkering too much.` Oh no worries I’m not that crazy to work on a live machine 🙂 This is a clone of the production machine with an active snapshop so I can mess up freely without worrying too much aout getting to the poiunt of no return. What I start to think is that resposities have been messed/mixed up, my gut feeling is that who configured the machine used at some point OpenSuse repositories for some packages hence the GLIBC error, I’m netioning this as I’ve see it happening with a CentOS machine a while back and mixing up package repositories/RPMs was the root cause of the problem, maybe not the same on this server but I’ve tried to exclude any GLIB package without success I start to think something similar could have happened. Thanks a lot for your help and if something else comes to mind I’m more than glad to hear: -) Daniele. ---
**Author:** ![smflood](https://sea2.discourse-cdn.com/flex022/user_avatar/forums.suse.com/smflood/32/10576_2.png) [@smflood](https://forums.suse.com/u/smflood)\ **Post date:** [September 9, 2014, 1:26pm UTC](https://forums.suse.com/t/sles-11-sp3-upgrade-dependencies-hell/26052/7 "2014-09-09T13:26:26Z")
On 08/09/2014 19:44, DCAT wrote: [color=blue] > Well my instructions on this point were rather clear so I assume SP1 → > SP2 → SP3 path has been followed but I would not swear on this, at > this point all could be.[/color] Whilst upgrading directly from SP1 to SP3 should be okay it’s not supported (and I’m aware that there have been some issues). [color=blue] > Here’s the output: > > ## Code: > > ``` > # | Alias | Name | Enabled | Refresh | URI > > ``` > > –±--------------------------±--------------------------±--------±--------±------------------------------------------------------------------------- > 1 | SLE11-SDK-SP3-Pool | SLE11-SDK-SP3-Pool | Yes | No | [http://192.168.XX.XX/repo/$RCE/SLE11-SDK-SP3-Pool/sle-11-x86\_64](http://192.168.XX.XX/repo/$RCE/SLE11-SDK-SP3-Pool/sle-11-x86_64) > 2 | SLE11-SDK-SP3-Updates | SLE11-SDK-SP3-Updates | Yes | No | [http://192.168.XX.XX/repo/$RCE//SLE11-SDK-SP3-Updates/sle-11-x86\_64](http://192.168.XX.XX/repo/$RCE//SLE11-SDK-SP3-Updates/sle-11-x86_64) > 3 | SLES11-SP3 | SLES11-SP3 | Yes | No | [http://192.168.XX.XX/instsource/SLES11SP3\_Vmware](http://192.168.XX.XX/instsource/SLES11SP3_Vmware) > 4 | SLES11-SP3-VMware-Updates | SLES11-SP3-VMware-Updates | Yes | No | [http://192.168.XX.XX/repo/$RCE//SLES11-SP3-VMware-Updates/sle-11-x86\_64/](http://192.168.XX.XX/repo/$RCE//SLES11-SP3-VMware-Updates/sle-11-x86_64/) > > --------------------[/color] Okay so despite the name, SLES11-SP3 is actually pointing at an install source for SLES11 SP3 for VMware. That’s good as it matches the SLES11-SP3-VMware-Updates repository thus rules out a possible problem of mismatched OS and Updates. [color=blue] > These same repositories are configured for other SP3 machines which have > been correctly upgraded from SP1 to SP3[/color] Good and is as I’d now expect (knowing that SLES11-SP3 is the “for VMware” version). [color=blue] > Yep you’re right, and all in all I start to think it would be just > faster to rebuild the machine but you know I would prefer to solve this > for good as I have other machines with similar configuration and would > like to avoid bad surprises.[/color] Yes it’s always good to understand why something doesn’t work even if you can’t always fix it! [color=blue] > Oh no worries I’m not that crazy to work on a live machine 🙂 This is a > clone of the production machine with an active snapshop so I can mess up > freely without worrying too much aout getting to the poiunt of no > return.[/color] 🙂 [color=blue] > What I start to think is that resposities have been messed/mixed up, my > gut feeling is that who configured the machine used at some point > OpenSuse repositories for some packages hence the GLIBC error, I’m > netioning this as I’ve see it happening with a CentOS machine a while > back and mixing up package repositories/RPMs was the root cause of the > problem, maybe not the same on this server but I’ve tried to exclude any > GLIB package without success I start to think something similar could > have happened.[/color] Having aired this possibility it’s possible to check where installed packages were installed from. The following command will identify any packages that were installed either from downloaded RPMs or from now missing repos: zypper se -is --sort-by-repo | grep “(System Packages)” What it does is use zypper’s search command to check installed packages then sort by repo. Since you have 4 valid and expected repos we want to know those are identified as System Packages as opposed to a repo name. If this command doesn’t return anything it would be worth replacing the grep pipe with less and checking nothing odd in returned list. [color=blue] > Thanks a lot for your help and if something else comes to mind I’m more > than glad to hear: -)[/color] ## HTH. Simon SUSE Knowledge Partner * * * ## If you find this post helpful and are logged into the web interface, please show your appreciation and click on the star below. Thanks.