11.4.2009 von rmo.

Bei der Bestückung neuer Workstations steht man immer wieder vor der Frage, welchen Hard-Disk Controller man unter Linux einsetzen soll. Wir haben gute Erfahrungen mit Controllern von 3ware. Wir hatten bislang sowohl die Controller der 7500er-Serie als auch den 9500S-Serie mit gutem Erfolg und unter Opensuse ohne Treiber-Probleme im Einsatz.

Wir können nun berichten, dass auch folgende Kombination aus Hard- und Software hervorragend zusammenarbeitet:

• Mainboard “GA EP45 Extreme” bzw. “GA EP45T Extreme” (mit 8GB DDR2 bzw. 8GB DDR3 RAM)
• Intel Quadcore 9550
• 3ware SATAII 9650SE mit 2 Raid 1 Arrays (Samsung 1TB Platten)
• 64 Bit Opensuse 11.1 für x86_64 mit Kernel 2.6.27.19-3.2-default

Der Plattendurchsatz kann nur als sehr gut bezeichnet werden. Der mit Opensuse 11.1 und Kernel 2.6.27.19-3.2-default mitgelieferte 64Bit -Treiber ist zwar nicht auf dem allerneuesten Stand, funktioniert bei uns bislang aber ohne Probleme. (Wir müssen dazu aber einschränkend anmerken, dass wir nur Raid 1 Arrays fahren.)

Schön ist auch, dass der 9650Se Controller ehemalige Raid-Arrays des 9500S Controller anstandslos einbindet, wenn die Arrays auf SATA II Platten angelegt wurden. Das erleichtert den Transfer von Daten beim Aufbau neuer Arbeitsstationen erheblich. Zur Vorsicht lege man natürlich dennoch ein Backup aller Daten an, bevor man Platten-Arrays von einem zum aderen Controller umzieht !

Als Tools haben wir das CLI und 3DM2 aus dem 9.5.1.1 Software Kit installiert (ohne das von Opensuse gelieferte Treibermodul auszutauschen).

Ein Hinweis sei bzgl. der 3DM2-Installation angebracht :

Der von 3ware ausgelieferte Installer läuft auf einem 64Bit-System nicht, wenn 32 Bit Java-Pakete oder das “java-1_6_0-openjdk” RPM installiert sind.

Fehlermeldungen ( z.B. nach Absetzen von “./setupLinux_x64.bin -console” auf einem x-term: )

Initializing Wizard….
Launching wizard…

The wizard cannot continue because of the following error:
could not load wizard specified in /wizard.inf (104)
WARNING: could not delete temporary file
/tmp/ismp001/1535915
WARNING: could not delete temporary file
/tmp/ismp001/9361692

Lösung:

Hier hilft eine kurzzeitige Deinstallation der Java-Pakete. Nach der Deinstallation von Java installiert man dann problemfrei 3DM2. Im Anschluss reinstalliert man die Java-Pakete erneut. Es hat eine Weile gedauert, bis ich das herausgefunden habe (es gibt einen ziemlich versteckten Hinweis in der Wissensdatenbank von 3ware).

Der Support von 3ware hat mich zusätzlich auf einen noch in Entwicklung befindlichen Installer unter der Adresse http://3ware.com/support/downloadnew.asp
hingewiesen. Dieser läuft nun komplett graphisch ab und funktionierte bei mir denn auch trotz installierten Java-Paketen !

Viel Spaß weiterhin mit 3ware !

Geschrieben in Hardware, Treiber | Keine Kommentare »

3.4.2009 von rmo.

Bei mir laufen die VMware-Workstation Versionen 6.5.1 und 6.5.2 inzwischen unter Opensuse 11.1 mit KDE 4.2 auf einem x86_64 System mit Intel-Quad-Core-Prozessor ohne Probleme (Kernel-Versionen: 2.6.27.19-3.2-default und 2.6.27.21-0.1-default).

Nachdem ich dabei allerdings zum zweiten Mal auf die neuen Install- und Kompilationsmechanismen von VMware reingefallen bin, dokumentiere ich kurz, wie man mit den neuen VMware-Workstation-Versionen (> 6.5.1) nach einem Kernel-Update verfahren kann und wie man eine Rekompilation der benötigten Module erzwingt.

Problemsituation 1 nach Kernel-Update:
Ich hatte VMware unter Opensuse 11.1 (mit KDE 4.2) neu installiert. Die Installation und die spätere Einrichtung einer virtuellen Maschine verliefen zunächst problemfrei. Dann habe ich den Kernel upgedated. Folgt man dem von früher gewohnten Verfahren, so müsste man nun “vmware-config.pl” laufen lassen. Dieses Script sucht man ab Version 6.5.1 allerdings vergeblich. Es hilft hier aber überraschenderweise (manchmal ?), einfach einen Neustart der virtuellen Maschine zu versuchen. Wird erkannt, dass ein neuer Kernel vorliegt, so erfolgt automatisch eine Neukompilation der benötigten Module. Hilft dies nicht, so siehe das Vorgehen unter Problem 2.

Problemsituation 2:
Nach einer Neukompilation des Kernels hatte ich in einem anderen Fall zudsätzlich noch eine neue Version der Workstation über das entsprechende “bundle”-Paket installiert. D.h., es handelte sich um eine Neuinstallation über eine bereits vorhandene ältere VMware-Installation. Leider gab der graphische Installer das Installationsverhalten falsch wieder. Er teilte mir nämlich mit, dass das alte System deinstalliert und dass die nachfolgende neue Installation erfolgreich abgeschlossen wurde. Dies war in meinem Fall aber falsch: Die Installation schlug wegen nicht ladbarer Kernelmodule fehl. Dies sieht man aber erst nach einem Blick in die Datei “/var/log/vmware-installer”.

Lösung: Erzwinge Neukompilation
Die Lösung besteht darin, eine Neukompilierung zu erzwingen. Am einfachsten erreicht man dies dadurch, dass man die vorhandenen von VMware im “bundle” mitgelieferten Kernelmodule, die der Installer verwenden will, entfernt:

mv /usr/lib/vmware/modules/binary /usr/lib/vmware/modules/binary_orig

Danach startet man VMware erneut - entweder über den KDE-Menü-Punkt unter “Programme->System->Weitere Programme->VMware Workstation” oder durch den Aufruf von “vmware” in ein er Shell. Es wird dann eine Neukompilation der VMware-Kernel-Module durchgeführt. (Bei mir zumindest liefen die Neu-Kompilation und das anschließende Laden der Module erfolgreich ab.)

Ob in anderen Problemsituationen ein direktes Löschen der vmware-Kernelmodule unter “/lib/modules/KERNEL_VERSION/misc” hilft, habe ich nicht ausprobiert.

Zusätzlicher Hinweis 07.06.2009:

Vor einer kompletten Neuinstallation (z.B. des Bundles VMware-Workstation-6.5.2-156735.x86_64.bundle ) ist es übrigens ratsam, zunächst die Verzeichnisse “/usr/lib/vmware” bzw. “/etc/vmware” zu löschen. Ich hatte Schwierigkeiten, eine komplette VMware-Neuinstallation auch mit dem Kernel 2.6.27.19 durchzuführen. Der Installer lief dabei zunächst eine ganze Weile ordnungsgemäß (Deinstallation vorhandene Version, Kopieren von Files, Konfiguration Player,..), stoppte dann aber und deinstallierte die eben erst eingerichteten Dateien wieder.
Evtl. lag dies an dem Vorhandensein des früher (s.o.) erzeugten Verzeichnisses “/usr/lib/vmware/modules/binary_orig” oder an Einträgen in “/etc/vmware”, die der Installer nicht selbständig beseitigt.

Nach dem Löschen war eine VMware-Neuinstallation mit dem Kernel 2.6.27.19 jedenfalls möglich. Danach kann man dann den Kernel-Update auf spätere Versionen (z.B. auch 2.6.27.23) wir oben beschrieben durchführen.

Link:
http://communities.vmware.com/thread/185900

Geschrieben in VMware Workstation | Keine Kommentare »