Seite 1 von 1
[gelöst] Webinterface stürzt ab - CentOS 5.4
Verfasst: 23.11.2009, 10:25
von sparrow
Hallo Forum,
ich habe im Augenblick das Problem, dass die Web-Managment-Umgebung des VMWare 2 Servers des öfteren abstürzt.
Das Login funktioniert noch problemlos, wenn ich dann auf der linken Seite eine virtuelle Maschine auswähle kommt es manchmal (relativ häufig, nicht immer) vor, dass sich die Anzeige nicht aktualisiert. Zwar springt die Ansicht um auf die Maske die die Details der virtuellen Maschine anzeigen würde, in den Feldern drehen sich aber nur blaue "loading"-Symbole. Eine Aktualisierung erfolgt nicht.
Die virtuellen Maschinen sind nicht betroffen, das Webinterface ist nach Neustart ( /etc/init.d/vmware-mgmt restart) erstmal wieder einsatzbereit, bis es zum nächsten Ausfall kommt.
Ich bin mir nicht sicher wo genau ich nach Fehler suchen soll, habe aber folgendes gefunden in /var/log/vmware/webAccess/proxy.log:
Code: Alles auswählen
[2009-11-23 09:59:27,539,view update thread<=>,ConfigOptionPropertyHandler] queryConfigOption failed: (0)null
[2009-11-23 09:59:27,548,waitForUpdates<=>,UpdatesErrorHandler] Updates thread error notification. PrevError=null, NewError=UnknownRemoteException, NewErrorMessage=(0)null
[2009-11-23 09:59:27,539,view update thread<=>,ConfigTargetPropertyHandler] queryTargetOption failed: (0)null
[2009-11-23 09:59:27,567,view update thread<=>,ConfigOptionPropertyHandler] queryConfigOption failed: java.net.ConnectException: Connection refused
[2009-11-23 09:59:27,569,pool-1-thread-6<=>,ConfigOptionPropertyHandler] queryConfigOption failed: java.net.ConnectException: Connection refused
[2009-11-23 09:59:27,572,pool-1-thread-5<=>,ConfigTargetPropertyHandler] queryTargetOption failed: java.net.ConnectException: Connection refused
[2009-11-23 09:59:27,594,pool-1-thread-3<=>,ConfigOptionPropertyHandler] queryConfigOption failed: java.net.ConnectException: Connection refused
[2009-11-23 10:00:17,517,pool-1-thread-7<=>,VmOverallPowerStateHandler] Dependent property VM.runtime not loaded by toolkitInformationen über das System:
Host-OS: Cent OS 5.4
VMWare:
VMware Infrastructure Web AccessVersion 2.0.0Build 128374
VMware ServerVersion 2.0.1Build 156745
Hat jemand eine Idee wo der Fehler liegen könnte oder in welchen Log-Dateien ich auf die Suche gehen kann?
Ich danke!
Sparrow
Verfasst: 23.11.2009, 11:42
von Dayworker
Steht CentOS5.4 auf der Liste der unterstützten Host-OS? Warum baust du noch auf die Version 2.01, wenn die 2.02 aktuell ist. Vielleicht ist dort dein Problem schon gefixt.
PS: Von allen aktuellen Linux-Distri's ist aufgrund diverser Kernel-Änderungen in meinen Augen
momentan abzuraten oder du probierst dein Glück mit den sogenannten Any-Any-Patches.
Verfasst: 23.11.2009, 12:16
von sparrow
CentOS 5. ist binärkompatibel zu RHEL5 und die entsprechenden Module passen problemlos in den Kernel.
Danke für den Tipp mit der neuen Version, die habe ich im Urlaub wohl übersehen. Ich werde im Laufe der Woche die neue Version entsprechend installieren und dann noch einmal Rückmeldung geben.
Vielen Dank!
Verfasst: 23.11.2009, 15:10
von Dayworker
Das CentOS die freie Version von RHEL ist, war mir bewußt. Es freut mich zu hören, daß der Server2 sich dort problemlos intallieren läßt. Kannst du bitte mal die genaue Kernel-Version posten, vielleicht hilft es ja anderen.
Verfasst: 23.11.2009, 15:59
von sparrow
Gerne:
Code: Alles auswählen
[root@zeus ~]# uname -a && lsb_release -a
Linux zeus 2.6.18-164.2.1.el5 #1 SMP Wed Sep 30 12:52:46 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: CentOS
Description: CentOS release 5.4 (Final)
Release: 5.4
Codename: Final
[root@zeus ~]# Ich hatte mich damals für CentOS auf dem Server entschieden weil sich VMWare Server 2 recht gut damit zu verstehen scheint.
Bei der Installation kommt eine Meldung die in etwa "The Module foo.RHEL5 fits perfect into running kernel". Ich glaub also schon, dass das irgendwie funktioniert
Werde gleich mal die neue Version installieren vielleicht erledigt sich das Problem dann schon.
Nochmals danke,
sparrow
Verfasst: 23.11.2009, 18:06
von Dayworker
Der Grund weshalb CentOS5.4 so gut damit läuft, liegt in meinen Augen im älteren Kernel 2.6.18 begründet. Der ist ausgereift und wurde lange Zeit erfolgreich in mehreren Distri's verwendet.
Du solltest, wenn deine HW damit vollständig erkannt wird, solange wie irgend möglich darauf aufbauen, nur die reinen Sicherheits-Patches einspielen und von allen Kernel-Upgrades lieber die Finger lassen. Getreu dem Motto: "Never change a winning system."
Verfasst: 24.11.2009, 08:31
von sparrow
Das ist ja das schöne an CentOS.
Ich glaube die Unterstützung für CentOS 5 läuft (durch den Upstream von RHEL) bis 2014. Die Hardware wird vollständig erkannt und ich muss mir erstmal keine Gedanken um eine Neuinstallation machen.
Aber mein Problem löst auch die neue Version nicht. Das Webinterface verabschiedet sich trotzdem ab und an bis recht häufig. Da dann auch kein Login darauf mehr möglich ist (der Server nimmt die Browserverbindung nicht an) scheint das an diesem Java-Server zu liegen der da mitgeliefert wird und für das Webinterface zuständig ist.
An sich hätte ich mit einem nicht funktionierenden Webinterface kein Problem, aber wenn das nicht funktioniert geht auch mein Backup nicht, da ich über vmrun die VMs schlafen lege.
Gruß
Sparrow
Verfasst: 24.11.2009, 09:33
von Dayworker
Der Server2 richtet doch nur ein Tomcat-Apachen ein. Welche Fehlermeldung steht denn im System-Log zu den VMware-Damons?
Verfasst: 24.11.2009, 10:38
von sparrow
Tomcat Apache, genau den mein ich.
So, hier mal die Log-Dateien die ich alle gefunden habe.
Neustart vom WebAccess ziemich genau 10:20 (/etc/init.d/vmware-mgmt restart)
Irgendwann zwischen 10:22 und 10:23 hat sich WebAccess aufgehängt.
/var/log/vmware/webAccess/proxy.log
Code: Alles auswählen
[2009-11-24 10:22:35,903,view update thread<=>,ConfigOptionPropertyHandler] queryConfigOption failed: (0)null
[2009-11-24 10:22:35,903,waitForUpdates<=>,UpdatesErrorHandler] Updates thread error notification. PrevError=null, NewError=UnknownRemoteException, NewErrorMessage=java.net.SocketException: Connection reset
[2009-11-24 10:22:35,907,view update thread<=>,ConfigOptionPropertyHandler] queryConfigOption failed: java.net.ConnectException: Connection refused
[2009-11-24 10:22:35,920,pool-1-thread-2<=>,ConfigOptionPropertyHandler] queryConfigOption failed: java.net.ConnectException: Connection refused
[2009-11-24 10:22:35,923,pool-1-thread-9<=>,ConfigOptionPropertyHandler] queryConfigOption failed: java.net.ConnectException: Connection refused
[2009-11-24 10:23:25,802,pool-1-thread-10<=>,VmOverallPowerStateHandler] Dependent property VM.runtime not loaded by toolkit.Code: Alles auswählen
Nov 24 10:20:09 zeus watchdog-webAccess: Terminating watchdog with PID 9223
Nov 24 10:20:09 zeus watchdog-webAccess: [9223] Signal received: exiting the watchdog
Nov 24 10:20:09 zeus /usr/lib/vmware/bin/vmware-hostd[9292]: Accepted password for user root from 127.0.0.1
Nov 24 10:20:09 zeus watchdog-webAccess: [9505] Begin '/usr/lib/vmware/webAccess/java/jre1.5.0_15/bin/webAccess -client -Xmx64m -XX:MinHeapFreeRatio=30 -XX:MaxHeapFreeRatio=30 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/common/endorsed -classpath /usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/bin/bootstrap.jar:/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/bin/commons-logging-api.jar -Dcatalina.base=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16 -Dcatalina.home=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16 -Djava.io.tmpdir=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/temp org.apache.catalina.startup.Bootstrap start', min-uptime = 30, max-quick-failures = 5, max-total-failures = 1000000
Nov 24 10:20:10 zeus watchdog-webAccess: Executing '/usr/lib/vmware/webAccess/java/jre1.5.0_15/bin/webAccess -client -Xmx64m -XX:MinHeapFreeRatio=30 -XX:MaxHeapFreeRatio=30 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/common/endorsed -classpath /usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/bin/bootstrap.jar:/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/bin/commons-logging-api.jar -Dcatalina.base=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16 -Dcatalina.home=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16 -Djava.io.tmpdir=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/temp org.apache.catalina.startup.Bootstrap start'
Nov 24 10:21:21 zeus /usr/lib/vmware/bin/vmware-hostd[9574]: Accepted password for user root from 127.0.0.1Code: Alles auswählen
[2009-11-24 10:20:09.638 'PropertyProvider' 1098959168 verbose] RecordOp ASSIGN: info, haTask--vim.ServiceInstance.retrieveContent-0
[2009-11-24 10:20:09.689 'PropertyProvider' 1098959168 verbose] RecordOp ASSIGN: info, haTask--vim.SessionManager.acquireLocalTicket-1
[2009-11-24 10:20:09.729 'Vimsvc' 1093568832 info] [Auth]: User root
[2009-11-24 10:20:09.730 'ha-eventmgr' 1093568832 info] Event 1 : User root@127.0.0.1 logged in
[2009-11-24 10:20:09.730 'PropertyProvider' 1093568832 verbose] RecordOp ASSIGN: latestEvent, ha-eventmgr
[2009-11-24 10:20:09.730 'PropertyProvider' 1093568832 verbose] RecordOp ADD: sessionList["522aa3e1-d0f1-914f-401e-f82ba18c19c0"], ha-sessionmgr
[2009-11-24 10:20:09.730 'PropertyProvider' 1093568832 verbose] RecordOp ASSIGN: info, haTask--vim.SessionManager.login-2
[2009-11-24 10:20:09.773 'InternalServiceInstance' 1089476928 info] Shutting down service
[2009-11-24 10:20:09.773 'App' 47281303775456 info] END SERVICES
[2009-11-24 10:20:09.773 'PropertyProvider' 1089476928 verbose] RecordOp ASSIGN: info, haTask--hostd.ServiceInstance.shutdown-3
[2009-11-24 10:20:09.776 'HostsvcPlugin' 47281303775456 info] Plugin stopped
[2009-11-24 10:20:09.776 'InternalsvcPlugin' 47281303775456 info] Plugin stopped
[2009-11-24 10:20:09.777 'Nfc' 47281303775456 info] Plugin stopped
[2009-11-24 10:20:09.777 'Proxysvc' 47281303775456 info] Stopped Proxy service
[2009-11-24 10:20:09.777 'Proxysvc' 47281303775456 info] Stopped Proxy service
[2009-11-24 10:20:09.777 'Proxysvc' 47281303775456 info] Proxy service stopped.
[2009-11-24 10:20:09.777 'Proxysvc' 47281303775456 info] Plugin stopped
[2009-11-24 10:20:09.778 'PropertyProvider' 47281303775456 verbose] RecordOp REMOVE: sessionList["522aa3e1-d0f1-914f-401e-f82ba18c19c0"], ha-sessionmgr
[2009-11-24 10:20:09.778 'ha-eventmgr' 47281303775456 info] Event 2 : User root logged out
[2009-11-24 10:20:09.778 'PropertyProvider' 47281303775456 verbose] RecordOp ASSIGN: latestEvent, ha-eventmgr
[2009-11-24 10:20:09.779 'Solo' 47281303775456 info] Plugin stopped
[2009-11-24 10:20:09.779 'Statssvc' 47281303775456 info] Stopping stassvc plugin
[2009-11-24 10:20:09.779 'SupportsvcPlugin' 47281303775456 info] Plugin stopped
[2009-11-24 10:20:09.779 'Vmsvc' 47281303775456 info] VM Services Plugin stopping
[2009-11-24 10:20:09.779 'Vmsvc' 47281303775456 info] VM Services Plugin stopped
[2009-11-24 10:20:09.779 'Vimsvc' 47281303775456 info] Stopping vimsvc plugin
[2009-11-24 10:20:09.780 'Memory checker' 47281303775456 info] Resource checker stopped.
[2009-11-24 10:20:09.789 'Proxysvc' 47281303775456 info] Proxy service stopped.Mehr Logdateien habe ich nicht gefunden. Fehler tauchen auch nur in der proxy.log auf.
Gruß
Sparrow
Edit: Ich glaub ich habe eine Lösung. Ich probiere und melde mich wieder. Ich wr zu sehr auf das Java-Ding eingeschossen.
Verfasst: 24.11.2009, 11:12
von sparrow
Hah, Fehler gefunden.
Es scheint sich um einen Fehler in der glibc von CentOS zu handeln. Ich habe allerdings auch Berichte gefunden, dass ein ähnliches Phänomen auch unter RHEL auftritt.
Workaround gibts hier:
http://bugs.centos.org/view.php?id=3884
Note 1 + 3 war bei mir die Lösung. Ich bin mal so frei diese zu zitieren:
http://bugs.centos.org/view.php?id=3884 hat geschrieben:Or do this before upgrading (adapted from
http://communities.vmware.com/message/1364852):
* Create the directory /usr/lib/vmware/lib/libc.so.6
* Grab /lib64/libc-2.5.so (or
/lib/libc-2.5.so in case you're running an 32 Bit host) and copy it to
into /usr/lib/vmware/lib/libc.so.6
* Rename the file libc-2.5.so within /usr/lib/vmware/lib/libc.so.6 to libc.so.6
* Open /usr/sbin/vmware-hostd and add /usr/lib/vmware/lib/libc.so.6 to the LD_LIBRARY_PATH. I just added an "export LD_LIBRARY_PATH=/usr/lib/vmware/lib/libc.so.6:$LD_LIBRARY_PATH" before the last line.
* Restart your vmware services (our just the host)
http://bugs.centos.org/view.php?id=3884 hat geschrieben:If you've already updated glibc like I have, a hybrid version of note 1 above is to do this:
mkdir /usr/lib/vmware/lib/libc.so.6
cd /tmp
mkdir tmp
cd tmp
wget
http://mirror.centos.org/centos/5.3/os/ ... x86_64.rpm [^]
rpm2cpio glibc-2.5-34.x86_64.rpm | cpio -ivd
mv lib64/libc-2.5.so /usr/lib/vmware/lib/libc.so.6/libc.so.6
Edit /usr/sbin/vmware-hostd as above.
Danke fürs Zuhören
sparrow
Verfasst: 28.12.2009, 22:52
von sparrow
Das Problem ist bisher ja hier mehrmals im Forum aufgetaucht.
Ich bin nicht gerade der Spezialist was Bash-Scripte angeht, aber das hier sollte die nötigen Veränderungen am System vornehmen:
Code: Alles auswählen
#!/bin/bash
###########################################
# This may help using the vmware-server2 #
# on a CentOS 5.4 x86_64 Host. #
# There is a problem with the the libc #
# More informations: #
# http://bugs.centos.org/view.php?id=3884 #
#-----------------------------------------#
# Version 0.1 #
# This script will get the 'old' libc #
# from the CentOS 5.3 repositories and #
# configures vmware-server2 to use this #
# The original libc (for the 5.4-system) #
# will not be replaced or touched. #
#-----------------------------------------#
# License: Do with the code whatever you #
# want. This came without any warrenty. #
###########################################
LIBC_DIR="/usr/lib/vmware/lib/libc.so.6"
TEMP_DIR="/tmp/vmw_glibc"
VMWARE_CONFIGFILE="/usr/sbin/vmware-hostd"
VMWARE_CONFIGFILE_BAK=$VMWARE_CONFIGFILE.bak
# Checking for root
if [[ $EUID -ne 0 ]]; then
echo "This script must be run as root"
exit 1
fi
# We test for the commands we need:
echo "Looking for some commands I need..."
which wget
if [ $? != 0 ]; then
echo "I can't find wget but need it to download the files. Please install."
fi
which rpm2cpio
if [ $? != 0 ]; then
echo "I can't find rpm2cpio but need it to extract Files from a .rpm-file. Please install."
fi
# Creating a directory for the 'old' glibc
mkdir -p $LIBC_DIR
if [ $? != 0 ]; then
echo "Can't create directory $LIBC_DIR"
exit 2
fi
# Removing and creating a temporary directory for the rpm,
# downloading it, extracting the old glibc and copy
# the them to our new directory
rm -rf $TEMP_DIR
mkdir -p $TEMP_DIR
if [ $? != 0 ]; then
echo "Can't create directory $TEMP_DIR"
exit 2
fi
cd $TEMP_DIR
wget http://mirror.centos.org/centos/5.3/os/x86_64/CentOS/glibc-2.5-34.x86_64.rpm
if [ $? != 0 ]; then
echo "Something was wrong while downloading"
exit 2
fi
rpm2cpio glibc-2.5-34.x86_64.rpm | cpio -ivd
mv lib64/libc-2.5.so $LIBC_DIR/libc.so.6
if [ $? != 0 ]; then
echo "Can't move the libc into directory $LIBC_DIR"
echo "Removing temporary files..."
echo -rf $TEMP_DIR
exit 2
fi
echo "The file libc-2.5.so from the centOS 5.3 rep. was saved in: $LIBC_DIR as libc.so.6"
echo "Removing temporary files..."
rm -rf $TEMP_DIR
# Now we editing the start-config of the vmware-server
echo "I must change $VMWARE_CONFIGFILE now, you will find a backup in $VMWARE_CONFIGFILE_BAK"
mv $VMWARE_CONFIGFILE $VMWARE_CONFIGFILE_BAK
cat $VMWARE_CONFIGFILE_BAK | grep -v 'eval exec "$DEBUG_CMD" "$binary" "$@"' > $VMWARE_CONFIGFILE
echo export LD_LIBRARY_PATH=$LIBC_DIR/libc.so.6:'$LD_LIBRARY_PATH' >> $VMWARE_CONFIGFILE
echo '' >> $VMWARE_CONFIGFILE
echo 'eval exec "$DEBUG_CMD" "$binary" "$@"' >> $VMWARE_CONFIGFILE
echo "Everything is done, please restart your vmware-server2"Vielleicht kann es ja jemand so unterbrignen, dass man zukünftige Nachfragen direkt darauf verweisen kann.
Gruß
Sparrow
Verfasst: 30.12.2009, 10:04
von MarkyGoldstein
Also wer Probleme mit Stabilität von vmware Server 2.0.2 unter Linux hat, sollte unbedingt diese Lösung anschauen:
http://communities.vmware.com/thread/230842
"The FIX:
yum downgrade glibc glibc-common
It will remove/revert about 22 Packages/Dependencies. I then rebooted and re-ran vmware-config and every thing functions again. Note you need to change your yum update config so that it doesnt push down the newer glibc glibc-common until this issue gets official resolved."
Verfasst: 30.12.2009, 14:38
von sparrow
Es ist absolut unnötig dafür für 22 Pakete ein Downgrade zu machen.
Alles was der vmware-server2 braucht ist eine alte Version der libc, und das erledigt bei CentOS das oben gepostete script.
Es geht eben darum nur die libc für den vmware-server bereit zu stellen, und nicht einen tiefen Eingriff in das System vorzunehmen was u. U. weitere Probleme schafft.
Gruß
Sparrow
Verfasst: 30.12.2009, 14:58
von MarkyGoldstein
Stimmt vermutlich
glibc-2.5-34 - woher nehmen, wenn die Archive fehlen?
Verfasst: 15.02.2010, 21:50
von ralfrudolph
Hallo zusammen
War ja klar, dass ich für einen neuen Server CentOS 5.4 (64 Bit) und vmware Server 2.2 kombinieren will - irgendwie habe ich ein Händchen für problematische Kombinationen. Also: Patchen. Prima, dass es diesen Thread gibt: Hurra, Problem gelöst!
Doch leider: Die Zeit schreitet voran, und CentOS 5.3 ist leider nicht mehr in den Mirrors vorhanden. Und unter vault.centos.org sind nur die Versionen bis 5.2 vorhanden. Volltreffer
Woher also nehmen? Derzeit lade ich mir ein ISO der ersten Installations-CD von CentOS 5.3 herunter, in der Hoffnung, dort glibc-2.5-34.x86_64.rpm zu finden. Das wird aber noch etwas dauern.
Gibt es eine etwas einfachere Lösung? Ich habe mir einen gegoogelt, aber keine direkte Quelle für die genannte glibc Version gefunden.
Danke für jeden Hinweis!
Viele Grüße
Ralf
Re: glibc-2.5-34 - woher nehmen, wenn die Archive fehlen?
Verfasst: 22.02.2010, 12:11
von lupfer
hi!
hast du schon was erreichen können?
Habe das gleiche Problem.
Ist ja echt fantastisch, hab hier n Server stehen, den kann ich nicht fertig machen und der Ersatzserver werkelt vor sich hin, das ist ein altes Teil und kann nicht ewig stehen bleiben...
mfg
ralfrudolph hat geschrieben:Hallo zusammen
War ja klar, dass ich für einen neuen Server CentOS 5.4 (64 Bit) und vmware Server 2.2 kombinieren will - irgendwie habe ich ein Händchen für problematische Kombinationen. Also: Patchen. Prima, dass es diesen Thread gibt: Hurra, Problem gelöst!
Doch leider: Die Zeit schreitet voran, und CentOS 5.3 ist leider nicht mehr in den Mirrors vorhanden. Und unter vault.centos.org sind nur die Versionen bis 5.2 vorhanden. Volltreffer
Woher also nehmen? Derzeit lade ich mir ein ISO der ersten Installations-CD von CentOS 5.3 herunter, in der Hoffnung, dort glibc-2.5-34.x86_64.rpm zu finden. Das wird aber noch etwas dauern.
Gibt es eine etwas einfachere Lösung? Ich habe mir einen gegoogelt, aber keine direkte Quelle für die genannte glibc Version gefunden.
Danke für jeden Hinweis!
Viele Grüße
Ralf
Re: glibc-2.5-34 - woher nehmen, wenn die Archive fehlen?
Verfasst: 22.02.2010, 12:57
von lupfer
Nachtrag:
habs von der alten Cd runna kopiert, so gehts problemlos!
lupfer hat geschrieben:hi!
hast du schon was erreichen können?
Habe das gleiche Problem.
Ist ja echt fantastisch, hab hier n Server stehen, den kann ich nicht fertig machen und der Ersatzserver werkelt vor sich hin, das ist ein altes Teil und kann nicht ewig stehen bleiben...
mfg
ralfrudolph hat geschrieben:Hallo zusammen
War ja klar, dass ich für einen neuen Server CentOS 5.4 (64 Bit) und vmware Server 2.2 kombinieren will - irgendwie habe ich ein Händchen für problematische Kombinationen. Also: Patchen. Prima, dass es diesen Thread gibt: Hurra, Problem gelöst!
Doch leider: Die Zeit schreitet voran, und CentOS 5.3 ist leider nicht mehr in den Mirrors vorhanden. Und unter vault.centos.org sind nur die Versionen bis 5.2 vorhanden. Volltreffer
Woher also nehmen? Derzeit lade ich mir ein ISO der ersten Installations-CD von CentOS 5.3 herunter, in der Hoffnung, dort glibc-2.5-34.x86_64.rpm zu finden. Das wird aber noch etwas dauern.
Gibt es eine etwas einfachere Lösung? Ich habe mir einen gegoogelt, aber keine direkte Quelle für die genannte glibc Version gefunden.
Danke für jeden Hinweis!
Viele Grüße
Ralf
Verfasst: 05.06.2010, 17:20
von guybrush82
Das script von sparrow ist super, konnte damit schon viele vmware-server wieder zum laufen kriegen!
Man darf einfach nicht vergessen, das configfile wieder ausführbar zu machen, sonst gehts nach dem upgrade wieder schief!
Am besten in seinem script vor der letzten echo-Zeile noch folgendes hinzufügen:
Code: Alles auswählen
# Ensuring the script is executable
chmod 555 $VMWARE_CONFIGFILE
Zu beachten ist weiter, dass die letzte export-Zeile machmal etwas durcheinander gebracht wird, z.B. so:
export LD_LIBRARY_PATH=/usr/lib/vmware/lib/libc.so.6/libc.so.6:$LD_LIBRARY_PATH
Dies ist falsch, denn die export Zeile muss auf das _verzeichnis_ in dem das libc.so.6-file liegt verweisen, nicht das file selbst!
So sieht die korrekte export-Zeile aus:
Code: Alles auswählen
export LD_LIBRARY_PATH=/usr/lib/vmware/lib/libc.so.6:$LD_LIBRARY_PATH