VMware-Server verweigert den Dienst

© Nikita Sobolkov, 123RF

Lost in Update

Ein Administrator gerät bei einer Linux-Distribution mit Paket-Updates in eine Falle, aus der er sich mit Geschick wieder befreien kann. Ein Einblick in einen Unfall und seine praktische Lösung.
Strom sparender Computereinsatz hilft nicht zuletzt auch Kosten zu senken. ADMIN 02/2011 geht der Frage nach, was Administratoren tun können, damit ihre ... (mehr)

Gerade im heimischen Umfeld sind Linux-Distributionen mit tagesaktuellem Update-Stand keine Seltenheit. Die Updates sind höchstwahrscheinlich sogar automatisiert und der Benutzer bemerkt davon nichts – es sei denn, eine Applikation verweigert anschließend ihren Dienst.

Prinzipiell gibt es dann verschiedene Ansätze, um das Problem zu lösen. Der vorliegende Artikel erläutert diese am konkreten Beispiel – hier versagte der VMware-Server 2.0 seinen Dienst, nachdem der Administrator das darunterliegende OS von Fedora 13 auf Fedora 14 aktualisiert hatte.

Vorgeschichte

Ausgangspunkt war ein funktionierender Vmware-Server [1] unter einem 64-Bit-Fedora 13 (inklusive aller vorhandenen Updates) [2]. Neben den verschiedensten Gästen für Test-Zwecke laufen dort zwei quasi-produktive virtuelle Maschinen, auf die der Autor nur für einen begrenzten Zeitraum verzichten kann. Fedora 14 war gerade frisch erschienen und die ersten Erfahrungen auf anderen Rechnern stimmten positiv auf ein vollständiges Upgrade der heimischen Linux-Welt. Also flugs die neuen Paket-Repositories einbinden und den Paketverwalter Yum [3] anwerfen.

Dank eines schmalen OS-Images und schneller Internet-Anbindung schmückte den Server einige Minuten und einen Reboot später ein taufrisches Fedora 14. Nur irgendwie funktionierte die Verbindung zur Vmware-Anwendung nicht mehr. Ein Blick in die Datei »/var/log/messages« offenbarte das zugrunde liegende Problem (Listing 1) – der Prozess »vmware-hostd« hatte sich mit einem sogenannten Segmentation Fault verabschiedet, er hat also versucht, auf einen Speicherbereich zuzugreifen, der vor einem solchen Zugriff geschützt ist.

Listing 1

Segmentation Fault bei vmware-hostd

01 Dec  6 13:30:08 virtual kernel: [  175.894212] vmware-hostd[3870]: segfault at 2100001c4f ip 0000003c0cb32ad0 sp 00007f3889e9cb88 error 4 in libc-2.12.90.so[3c0ca00000+19a000]

Ein erste Analyse zeigte, dass sich die Vmware-Anwendung nicht mit der neueren Version der glibc von Fedora 14 verträgt. Gibt es eine neuere Version des VMware-Servers? Nein, denn VMware entwickelt dieses Produkt nicht mehr weiter [4]. Die Alternative wäre das ESXi-Produkt [5]. Leider ist die vorhandene Hardware nicht kompatibel, also scheidet dieser Ansatz als kurzfristige Lösung aus. Ein Blick auf den Fedora-Update-Server zeigt, dass es auch keine neuere Version des Glibc-Paketes gibt. Ein OS-Update als Lösungsmöglichkeit entfällt somit auch.

Bleiben nur noch zwei Wege, um des Problems Herr zu werden: ein Fallback der Änderung am System oder ein eigener Fix oder Workaround. Der Fallback entspricht praktisch dem Downgrade von Fedora 14 auf Fedora 13. Ohne entsprechende Vorbereitungen wie Dateisystem- oder Volume-Snapshots ist dies keine triviale Angelegenheit. Außerdem ist das Problem der Unverträglichkeit von Applikationen mit neueren Glibc-Version nicht unbekannt und für bestimmte Anwendungen recht einfach zu beheben.

Notbehelf

Der Workaround in diesem Fall ist die Parallel-Installation einer älteren Variante der Bibliothek und die anschließende Modifikation der Applikations-Umgebung, um die "richtigen" Bibliotheken zu verwenden. Was sich einfach anhört, kann im konkreten Fall ziemlich aufwendig sein und hier führte der erste Versuch leider gar nicht zum Erfolg. Inzwischen war ein ganzer Tag vergangen und der Verlust der zwei oben erwähnten virtuellen Server begann so richtig zu schmerzen. Eine Lösung musste her – also doch der Downgrade (Listing 2).

Listing 2

Handarbeit vor dem Downgrade

01 rpm -e libmount --nodeps
02 yum downgrade util-linux-ng libblkid libuuid
03 rpm -e upstart-sysvinit --nodeps
04 yum downgrade upstart
05 rpm -Uvh gdbm-1.8.0-33.fc12.i686.rpm --nodeps --force
06 yum downgrade perl\*
07 rpm -e man-db
08 rpm -e pam_ldap --nodeps
09 yum downgrade nss_ldap
10 ...

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Support-Ende von SMBv1

Mit dem aktuellen Update für Windows 10 und Windows Server 2016 steht eine Änderung ins Haus, die gerade für Benutzer älterer Linux-Distributionen große Auswirkungen hat. Nachdem Microsoft es über viele Jahre schon angekündigt hat, entfernt der Konzern mit dem aktuellen Update-Release den Support für das SMB-Protokoll 1. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Linux-Backup

Welche Backup-Lösung setzen Sie für Linux im professionellen Umfeld ein?

  • keine
  • eigene Scripts
  • rsnapshot
  • rdiff-backup
  • Bacula
  • Bareos
  • Borg
  • Duplicity
  • Amanda
  • Burp
  • Clonezilla
  • Acronis
  • Arkeia
  • SEP sesam
  • Veeam
  • Redo Backup
  • Relax-and-Recover
  • andere kommerzielle Software
  • andere Open-Source-Software

Google+

Ausgabe /2018

Microsite