[gelöst] Webinterface stürzt ab - CentOS 5.4

[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 toolkit

Informationen ü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

[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.

[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!

[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.

[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

[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."

[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

[Dayworker]

Der Server2 richtet doch nur ein Tomcat-Apachen ein. Welche Fehlermeldung steht denn im System-Log zu den VMware-Damons?

[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.

/var/log/messages

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.1

/var/log/vmware/hostd.log

Code: 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.

[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:

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)

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

[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

[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."

[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

[MarkyGoldstein]

Stimmt vermutlich

[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

wget http://mirror.centos.org/centos/5.3/os/ ... x86_64.rpm

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

[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

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

wget http://mirror.centos.org/centos/5.3/os/ ... x86_64.rpm

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

[lupfer]

Nachtrag:
habs von der alten Cd runna kopiert, so gehts problemlos!

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

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

wget http://mirror.centos.org/centos/5.3/os/ ... x86_64.rpm

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

[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