Category Archives: Erfahrungsberichte

Erfahrungen aus dem Alltag eines Linux-Anwenders

Opensuse 11, sensors und IT8720

Posted on by

Wer sich – wie ich – ein neueres Board beschafft hat, wird u.U. feststellen, dass die HW-Sensoren ein Kernelmodul zur Unterstützung der  ITE 8720 Super IO Sensors benötigen. Opensuse 11.1 liefert für den 2.6.27-Kernel allerdings nur ein älteres IT87-Modul, das für die neueren Chipsätze nicht ausreichend ist.

Netterweise gibt es ein paar Kollegen, die sich die Mühe gemacht haben, die für den Kernel 2.6.29 bereits erstellten Module auf den älteren Kernel zurückzuportieren und entsprechende RPM-Pakete für den aktuellen Stand des SuSE-Kernels bereitzustellen.
Hier wird man im Internet fündig :

http://forums.opensuse.org/hardware/410081-sensors-ite-it8720-not-working.html

http://download.opensuse.org/repositories/home:/Akoellh/

Das erweiterte IT87-Kernelmodul funktioniert prächtig und kann nach “sensors-detect” in der Datei “/etc/sysconfig/lm_sensors” eingetragen werden – in meinem Fall lauten die Einträge:

MODULE_0=”coretemp”
MODULE_1=”it87″

Natürlich kann man unter Yast2 auch den sysconfig-Editor verwenden. Das entsprechende Startup-Skript “lm_sensors”, das diese Einträge nutzt, findet man natürlich unter “/ect/init.d”.

Vielen Dank an Akoellh !

Swap – ein paar Bytes zuviel?

Posted on by

Änderung des Beitrags am 07.06.2009:

Der nachfolgende Beitrag hat sich inzwischen in wesentlichen Punkten als haltlos entpuppt:

Ursache der Abstürze ist eindeutig ein fehlerhafter Speicherbaustein – also ein Hardware-Fehler in der betroffenen Maschine. Die unten beschriebene Verringerung des Swap-Bereiches hatte evtl. trotzdem positive Wirkung, als die Wahrscheinlichkeit, den defekten Speicherbereich zu treffen möglicherweise verringert wurde.

Es bleibt als Befund lediglich der fühlbare Geschwindigkeitsunterschied bei der Verringerung des SWAP-Bereiches und die Erkenntnis, das man bei statistisch auftretenden Fehlern der Klasse “General Protection Fault” zunächst mal den RAM auf Funktionstüchtigkeit prüfen sollte, bevor man sich in Spekulationen verliert.

********************************************

Alter Beitrag

Am letzten Wochenende musste ich mit einem Problem auseinandersetzen, dessen Ursache letztlich wohl im SWAP-Bereich lag. Das Ganze ist aber irgendwie komisch und deshalb aus meiner Sicht einen Blog-Beitrag wert. Zumal ich im Internet gefunden habe, das auch andere Leute mit verschiedenen Kernelversionen unter Opensuse 11.1 unregelmäßige Abstürze erlebt haben.

Ich hatte ein neues System mit 8GB DDR3-RAM und einem Intel Quadcore Q9550 Prozessor aufgesetzt (Opensuse 11.1 – x86_64). Das ist gleichzeitig die RAM-Grenze des Mainboards. Das System hat vier 1TB Platten in 2 Raid-1-Arrays. Da auf diesem System i.d.R. 2 VMware-Maschinen mit je 2GB Hauptspeicher und ein Samba-Server sowie Datenbank-Server laufen sollen, ist die Kalkulation des SWAP-Speichers nicht ganz einfach – zumal man hierzu im Internet durchaus unterschiedliche Philosophien finden kann.

Ich hatte auf der einen Partition eine SWAP-Partition von 4GB eingerichtet, auf der anderen einen Bereich von 8GB – letzteres nur testweise. Mein Motiv war, einfach mal auszuprobieren, ob im Alltag überhaupt Unterschiede feststellbar wären. (Generell glaube ich, dass bei 8GB Hauptspeicher selbst 4GB Swap völlig überdimensioniert sind, da ausgelagerte Bereiche komprimiert werden. In der Praxis zeigte sich, dass der Swap-Bereich lediglich beim parallelen Handtieren mit mehreren großen Dateioperationen eine Rolle spielte).

Egal:Zuletzt hatte ich den 8GB Swap Bereich mit “swapon” aktiv auf swap eingehängt. Im Zuge diverser anderer Ereignisse hatte ich dies aber vergessen und danach die Maschine mit dieser Einstellung produktiv benutzt.

Dann kam es zu unregelmäßigen, nicht nachvollziehbaren Abstürzen oder einem Einfrieren des ganzen Systems. Dies war für mich insofern erschütternd, als mir alle wesentlichen Einstellungen identisch mit einer fast gleich konfigurierten Maschine erschienen, die sich seit Wochen fehlerfrei im Dauerbetrieb befindet. Die Abstürze geschahen vor allem dann, wenn ich viele Dateien kopierte – ob unter VMware oder unter Linux.

Nach einer Beobachtung und Auswertung von /var/log/messages kam ich dann dahinter, dass die meisten der Abstürze an einen “General Protection Fault” gebunden waren. Dies versetzte mich bereits in gehörige Unruhe.

Als nächstes tauchten bei der Installation eines Programmpaktes plötzlich Meldungen auf, dass das System auf illegale Speicherbereiche jenseits der Parttionsgrenzen zugreifen wolle. Nun dachte ich an Speicherfehler – und ließ memcheck mal über mehrere Stunden laufen – ohne Fehlermeldungen.
Noch schlimmer wurde es, als ich danach einen systematischen Test der mehr als 10 Partitionen des Systems mit fsck durchführte – Fehler über Fehler trotz Recovery Journal des Ext3-Systems. Hier rächte sich übrigens die Aktivierung des Write-Cachings auf dem Raid Controller bitter. Der hat mehrere hundert MByte Caching Speicher. Bei den festgestellten Abstürzen findet hier kein sync des Writecaches mehr auf die Platten statt – das Filesystem kann deshalb nach dem Hochfahren auch über das Journaling Fehler ggf. nicht mehr ausbügeln – und man
merkt es nicht einmal !

Merke: Nach Abstürzen und aktiviertem Write-Caching trotzdem fsck-Prüfungen fahren !

Nun erklärt das aber nicht die Ursache der Abstürze – es macht höchstens ein systematisches Anwachsen der Filesystem-Probleme plausibel, wenn fsck nicht angewendet wird. Ich bereinigte also die Filesysteme über “fsck -f” . Danach prüfte ich alles Mögliche und verglich die Konfiguration meiner Maschinen – ergebnislos.Ich installierte einen älteren Kernel, deinstallierte überflüssige Pakete – alles vergebliche Mühe.

Durch Kopieren großer Dateimengen konnte ich den Fehler inzwischen systematisch provozieren. Und irgendwannmal gelang es mir nach einem Protection fault die Maschine noch weitgehend geordnet herunterzufahren. Dabei fiel mir auf, dass die Swap-Partiton nicht mehr freigegeben werden konnte. Nun erinnerte ich mich wieder an meine eigentlich “testweisen” SWAP-Einstellungen und aktivierte die kleinere SWAP-Partition statt der großen. 4GB SWAP waren übrigens auch auf dem Vergleichsystem eingestellt !

Und siehe da, das System lief danach

1. fehlerfrei

2. deutlich schneller als zuvor.

Kann Opensuse 11.1 mit dem aktuellen Kerne 2.6.27 nun einfach nicht mit 8GB SWAP arbeiten ? Ich weiss es nicht – komisch ist die Sache schon.

Interessant ist auch, dass der “testweise” Swap-Bereich minimal gößer als 8GB war. Zusammen mit den 8GB Ram wurde also evtl. ein irgendwo existierendes 16GB-Limit überschritten.

Der Kernel ist übrigens der aktuell für Opensuse 11.1 im Update Repository angebotene 2.6.27.21-0.1-default #1 SMP x86_64 .

Wenn einer eine Idee dazu hat, was hier los war, möge er mich informieren !

Installation Windows und CS4….ein Albtraum

Posted on by

Weil Krise ist und der Bürger mehr kaufen soll, um den Binnenmarkt anzukurbeln, wollte ich in Web-Entwickung investieren und habe mir das Upgrade auf Adobe CS4 Web Premium (Windows-SW!) geleistet.

Das ist eine sehr kostspielige Investition – der Preis für das Upgrade liegt etwa beim Doppelten dessen, was ein Harz4-Empfänger im Monat bekommt. Also erwartet man wenigstens eine halbwegs funktionierende Installation. Leider wird man hier bitter entäuscht. Schlimmer noch:

Ich habe noch nie eine so albtraumartige Installation irgendeines Systems vornehmen müssen !
18 sinnlos vergeudete Stunden!

Warum schreibe ich nun in einem Linux-Blog über ein Update in der Windows-Welt ?

1. Weil bei mir Windows (XP, SP3) unter VMware auf einem Linux-Host läuft und ich bislang mit den Adobe-Tools auch Web-Applikationen entwickelt habe.

2. Weil man sich ab und zu eine Windows-SW-Installation antun muss, um wieder genau zu wissen, was die IT-Entwicklung mit Linux und Opensource erreicht und gewonnen hat. Man durchforste mal das Internet bzgl. Installationsfehlern und -Problemen mit CS4 ! Ich finde das Beispiel symptomatisch für den Verfall jeglicher Qualitätssicherung im kommerziellen SW-Bereich. Man fragt sich angesichts der riesigen Anzahl an Treffern wirklich: Warum muss man eigentlich so viel Geld für Produkte bezahlen, für die der Kunde schon bei der Installation Beta-Tester spielen muss?

Ich habe die CS4 – Installation unter folgenden Voraussetzungen begonnen:

Voraussetzungen :

Vorhandene Adobe SW: Adobe Web-Premium CS3 habe ich vor 1,5 Jahren unter Windows XP als Update zu Macromedia Studio 8 installiert. Bis vorgestern habe ich die CS3 Suite produktiv eingesetzt. Alle CS3-Komponenten und Programme sind gepflegt und auf dem neuesten Stand.

Windows XP: Mein Windows XP ist unter einer virtuellen Maschine (VMware Workstation) auf einem Linux-Host (z.Z. Opensuse 11.1) installiert. Die virtuelle Maschine wurde vor ca. 3 Wochen problemfrei auf eine neue HW-Plattform (mit Intel-Quad-Core Prozessor) umgezogen. (Vorher lief diese Maschine über 3 Jahre stabil auf einem Athlon X2-System.) Der HW-Wechsel führte zur Installation neuer Treiber unter Windows. Windows selbst musste danach neu aktiviert werden. (Die vorhanden Adobe-Produkte [CS3] interessanterweise nicht, obwohl ich auch das schon bei Kunden erlebt habe.) Die virtuelle Maschine lief seitdem auf der neuen Hardware ohne Störungen. Die VMware-Version selbst ist die aktuellste (WS 6.5.2).

Host und HardwareMein virtuelle Maschine läuft auf zwei 2,83 GHz Prozessoren (von insgesamt 4 der Quad-Core-CPU des Linux-Hosts). Windows habe ich 2 GB RAM (von insgesamt 8 GB des Hosts) zur Verfügung gestellt. Im Laufe der Installation habe ich VMware ferner 2 DVD-Laufwerke zugänglich gemacht. Beides SATA-Laufwerke, die im Linux-Host als /dev/sr0 und /dev/sr1 erschienen. Im Windows Host bilden sich die als SCSI-Laufwerke ab. Dies ist deshalb erwähnenswert, weil der BusLogic SCSI-Controller der virtuellen Maschine in dieser Situation mit dem Treiber von VMware und nicht von Microsoft betrieben werden muss, auch wenn die virtuellen Festplatten als IDE-Platten eingerichtet wurden.

Also: Windows XP ist bei mir zwar virtuell vorhanden, dafür aber sehr großzügig ausgestattet – auch für Adobe CS3-Verhältnisse, das ja mindestens ein GB RAM sehen will. Ich ging daher davon aus, dass auch CS4 nichts zu meckern haben würde.

Ziel der Installation

Ich wollte CS4 zusätzlich zum vorhandenen CS3 installieren, um bei evtl. Problemen noch auf CS3 zurückgreifen zu können. Das ist eigentlich das vorgesehene Standardverfahren – zumindest habe ich nichts
Gegenteiliges gelesen.

Problem: Die Installation von Web Premium CS4 bei vorhandenem aktuellem Web Premium CS3 funktioniert nicht oder zumindest nicht immer !

Die Installation (des Updates) funktioniert unter den oben genannten Voraussetzungen nicht! Ich möchte den Leidensweg meiner vielen Anläufe über mehr als 18 Stunden hinweg nicht im Detail beschreiben – das würde Seiten füllen. An dieser Stelle mögen Stichworte genügen:

Mehrere Installationsanläufe mit sich ändernden Fehlern / Update-Versuche der Komponenten, die installiert wurden, über das Internet mit völig unterschiedlichem Ergebnis / Crashes und Blue Screens der virtuellen Maschine (sowas habe ich zuvor über mehrere Jahre hinweg überhaupt noch nie erlebt) / Probleme mit der Adobe Acrobat Seriennummer nach Deinstallation von Acrobat.com (es lief schon fast alles ausser Acrobat) / Installation nur einzelner Komponenten von CS4 / Installation unter verschiedenen Usern / Installation von der Festplatte statt von DVD / Installation nach Deinstallation von CS3, ……… immer gab es irgendwo und irgendwann Probleme – z.T. massiver Art bis zum Absturz von Windows. Und alles auf einem bisher absolut stabilen System.

Ich behaupte mal, dass das nichts mit der VMware-Umgebung zu tun hat, sondern mit früheren regulären Updates der vorhandenen CS3-Programme und entsprechenden Registry-Einträgen, die dem CS4 nicht gefallen.

Und mit diesem Befund stehe ich weiss Gott nicht alleine da – im Internet gibt es -zig Seiten zu der völlig misratenen Installationsroutine von Adobe und zu den vielfältigsten Varianten der resultierenden Katastrophen. Typischerweise bricht die Installation bei einer oder mehreren wichtigen Programmen (Photoshop, Flash) ab. Man kann danach noch einige Reste an SW installieren. Insgesamt kommt es aber zu einem Fehler “1603”, der sich hartnäckig als irreperabel erweist. Zudem folgen u.U. eine Reihe weiterer Fehler 1714, 1907 etc., oft im Font-Bereich oder im Zusammenhang mit Acrobat, Photoshop oder Flash. Man suche mal im Internet unter CS4 und Fehler 1603 !

Die Versuche, es durch erneute Anläufe und Zugriff auf Updates aus dem Internet doch irgendwie hinzukriegen, münden nur in einen gigantischen und sinnlosen Aufwand (bei mir ca. 20 Arbeitsstunden). Das Verhalten des Installers ist dabei völlig unberechenbar und inkonsistent. Ich habe in stundenlangen Versuchen so ziemlich alles ausprobiert, was ich im Internet an Hinweisen von Leidensgenossen gefunden habe. Übrigens auch viele Ratschläge der Fa. Adobe, die bis auf einen nichts geholfen haben.

Dabei konnte ich nur deshalb halbwegs ruhig bleiben, weil ich vor dem ganzen Theater einen Clone meiner virtuellen Maschine angelegt hatte, auf den ich im Ernstfall zurückgreifen hätte können (es lebe VMware !). Ich möchte mir eine entsprechende Situation und die Gefühle von Leuten mit realen, produktiven Windows-Systemen gar nicht ausmalen! Im Internet gibt es dazu einiges zu finden.

Letztlich funktionierte bei mir nur eines – nähmlich ein Vorgehen nach dem Prinzip “tabula rasa”: Man bereinige das System von allen Adobe-Einträgen und früheren Installationen und installiere erst danach CS 4 (erneut).

Meine Lösung:

Läuft die Installation nicht von Anfang an fehlerfrei durch, so erhält man durch neue Versuche (auch durch erfolgreiche Updates) offfenbar ein immer problematischer werdendes System. Man entferne deshalb schon nach dem ersten Fehlschlag systematisch alles, was sich aus früheren Installationen auf dem System befindet. In meinem Fall bedeutete das Folgendes:

  1. Systematische Entfernung von Adobe CS3
    Es reicht nicht, das über eine Windows-SW-Deinstallation zu tun. Man beschaffe sich vielmehr gleich die Tools von Adobe (http://www.adobe.com/support/contact/cs3clean.html) und benutze die mindestens auf Level 2 (ggf. 3 oder 4 – man kann dies
    einfach eingeben, wenn nach dem Level gefragt wird)
    .
  2. Reboot des Windows-Systems
  3. Beseitigung aller vorhergehenden (missglückten) Ruinen der CS4-Installation.
    Dazu setze man nach einer Deinstallation über das Windows SW-Management auch die Reinigungstools von Adobe ein (http://www.adobe.com/support/contact/cs4clean.html). Gut, dass es wenigstens diese Tools gibt.
  4. Reboot des Windows-Systems
  5. Reinigen der Oberfläche der CS4-DVDs (es gibt sehr viele Mini-Dateien zu übertragen – das DVD-Laufwerk wird in puncto häufige Positionierung sehr belastet)
  6. Installation als “administrator” – es wird wirklich der Windows “system”-Account benötigt.
  7. Abschalten des Virenscanners (rein aus Zeitgründen) – eine sinnvoll konfigurierte Personal-Firewall bereitete keine Probleme (F-Secure in meinem Fall).
  8. Zur Sicherheit: Zuordnung von nur einem Prozessor-Kern zur virtuellen Maschine. Bei SATA-DVD-Laufwerken am Host : Check, dass dem BusLogic-SCSI-Controller der virtuellen Maschine der VMware-Treiber und kein Microsofttreiber zugeordnet ist. Mit dem Microsoft-Treiber laufen die Sata-Devices, die als SCSI-Laufwerke abgebildet werden, nicht stabil genug. Den VMware-Buslogic-Treiber findet man im Downloadbereich der VMware-Website.
  9. Zuordnung zweier DVD-Laufwerke zur virtuellen Maschine und Einlegen der ersten CS3 DVD in ein Laufwerk. Dies gilt vermutlich nur,wenn CS4 als Upgrade eingespielt wird. Bei mir wurde die Seriennummer des CS4-Paketes nach der Deinstallation von CS3 und CS4 nicht mehr akzeptiert, solange der Installer nicht irgendwas von CS3 auf dem System finden konnte. Ich habe daher im zweiten Laufwerk während der ganzen Installation die CS3-DVD mitlaufen lassen.
  10. Neuinstallation von der CS4-DVD. Das lief bei mir dann anstandslos durch.
  11. Bei manchen Leuten hat es geholfen, die DVDs auf C:/ zu kopieren und dann von der Festplatte aus zu installieren. Man muss dabei aber den Namen des Verzeichnisses “Adobe CS4” jeder DVD rechtzeitig während der Installation umbenennen – der Adobe Installer sucht beim verlangten DVD-Wechsel immer nach dem gleichen Verzeichnis “Adobe CS4”. (s. auch “http://www.keptlight.com/?p=383” und die dortigen Hinweise).

Diskussionswürdige Ratschläge von Adobe im Internet

Noch etwas – einige Hinweise von Adobe selbst im Internet (http://kb.adobe.com/selfservice/viewContent.do?externalId=kb404083_ger_DE&sliceId=1)
sind für mein Gefühl letztlich eine Zumutung (obwohl sie bei dem einen oder anderen Betroffenen geholfen haben mögen):

So stimmt mich der lapidare Hinweis, es unter Abschalten aller Firewalls und Virenscanner zu versuchen, von Haus aus nicht nur missmutig sondern auch mißtrauisch. Warum sollte das erforderlich sein ? Was betreibt Adobe da auf der Maschine ? Ich habe das trotzdem probiert – genutzt hat es gar nichts. Das gleich gilt für die empfohlene Deinstallation des Google-Desktop – sowas gab und gibt es bei mir sowieso nicht.

Hinzu kommen die Aufforderungen, die Installation doch bitte mal für einen neu angelegten User zu versuchen oder gar auf einem anderen Computer. Wenn es so auch nicht ginge, solle man sich an Adobe wenden ! Ansonsten an den Hersteller des Computers.

Was denken die sich eigentlich ? Dass jeder Kunde gerade mal einen zweiten Computer für stundenlange Tests parat hat und dass kleinere Firmen es sich leisten können, im produktiven Umfeld nebenbei neue User einzurichten und dann alle erforderlichen Konfigurationseinstellungen nachzuziehen. Sinngemäß heisst das: Lieber Kunde wende dich erst an mich, wenn du meine fehlerhafte SW, deren Installation ca. 2,5 Stunden kostet, mehrfach auf verschiedenen Systemen und unter anderen Accounts ausprobiert hast. Und wenn du dabei zufällig eine Konstellation finden solltest, mit der auch wir bei der Entwicklung des
Installers gerechnet haben, dann darfst du dich wegen der vorhergehenden anderen Probleme nicht mehr an uns sondern deinen Computerhersteller wenden. Was für eine Zumutung und Arroganz – und was für ein Armutszeugnis für eine so renommierte Firma !

Dann lese man sich auch mal folgende interessanten Blog-Artikel zum persönlichen Service von Adobe im Zusammenhang mit der CS4-Installation durch:

http://www.keptlight.com/?p=382 und http://www.keptlight.com/?p=383

Dem gibt es nichts hinzuzufügen !

(Zugegebenermaßen gibt es auch bessere und sachlichere Beispiele an Adobe Ratschlägen :
http://kb.adobe.com/selfservice/viewContent.do?externalId=kb408716 – Lösung 7.

Schlechte Erfahrungen auch schon mit CS3

Auch bei der Installation von CS3 (Upgrade von Studio8) vor eineinhalb Jahren gab es bereits erhebliche Probleme, die ich damals aber umschiffen konnte. Ich hätte also gewarnt sein können. So schlimm wie bei CS4 war es aber bei weitem nicht gewesen!

Fazit und Appell:

Liebe Leute von Adobe:

Wenn ihr einfach zugeben würdet, dass die Installation bei einem vorhandenen CS3 nicht läuft und im Internet schreiben würdet, dass man von vornherein alles, was mit Adobe zu tun hat, vom System entfernen muss und zugleich die Registry mit euren Cleaner-Tools bearbeiten muss, so würdet ihr vielen Menschen weniger unproduktive und sinnlos vergeudete Zeit von ihrem Leben stehlen. Würden allein alle diejenigen Betroffenen, die zu den Installationsprobleen im Zshg. mit CS4 inzwischen etwas ins Internet gesetzt haben, für die vergeudete Zeit eine Rechnung zum Stundensatz eurer Entwickler stellen, würde das für euch sehr teuer werden. Diese Summe solltet ihr künftig in die Qualitätssicherung eurer Installationsroutinen stecken!

Bei mir hat die CS4-Installation nur dazu geführt, mich wieder intensiver im Opensource-Bereich nach Alternativen umzusehen. Was bei Flash zugegebenermaßen ein schwieriges Unterfangen ist ….