Anfangsschwierigkeiten bei dem Support für SLES auf Servern von Dell

Es scheint bei dem Support für den “SuSE Linux Enterprise Server” auf Servern von Dell zur Zeit noch einige Anfangsschwierigkeiten zu geben. In diesem Artikel schildere ich den Verlauf eines Support Request bei Dell bzw. Novell und die Probleme, die ich dabei hatte.

Nach anhaltenden Problemen mit einem Dell PowerEdge 1800 Server unter Debian 3.1 in Leipzig (der Server stürzte ca. alle 14 Tage ab und in den Logfiles war keine Ursache zu erkennen), habe ich mich entschlossen, mal wieder andere Linux Distributionen zu evaluieren. Ich hatte die Hoffnung, dass eine andere Distribution stabiler laufen würde und legte dabei mein Augenmerk besonders auf die von Dell zertifizierten Distributionen, da ich in der Vergangenheit schon oft erlebt habe, dass sich der Support von Dell bei nicht zertifizierten Linux Distributionen quer stellt. Dell hat sich z.B. schon zwei mal geweigert eine defekte Festplatte aus einem Server zu tauschen, da angeblich die “nicht zertifizierten Treiber” von Debian 3.1 das Problem verursachen können. Nach der Installation eines zertifizierten Betriebssystems hatte sich jedoch immer gezeigt, dass die Festplatte defekt war. Des weiteren war es mir besonders wichtig eine günstige Linux Distribution zu finden, da ich sehr viele Server von Dell mit Linux betreibe.

Nach einigen Recherchen auf der Webseite von Dell, Novell und RedHat stellte ich fest, dass der SLES (SuSE Linux Enterprise Server) laut Novell und RHEL (RedHat Enterprise Linux) laut RedHat zertifiziert sind. Ich entschied mich für den SLES, da dieser deutlich günstiger ist.

Nachdem ich micht für den SLES entschieden hatte, durchsuchte ich die Webseite von Oracle nach Informationen und Installationsanleitungen für Oracle unter SLES. Es war mir bekannt, dass der SLES für Oracle zertifiziert ist. Wie sich zeigte war aber nur der SLES 9 und nicht der – seit sechs Monaten erhältliche – SLES 10 zertifiziert und somit gab es auch nur eine Installationsanleitung für den SLES 9. Da der PowerEdge 1800 auch für den SLES 9 zertifiziert war und man laut unserem Lieferanten mit einer aktuellen SLES Lizenz auch ältere Versionen benutzen kann, wähnte ich mich in sicherheit und bestellte einen SLES 10 von Novell mit drei Jahren Sicherheitsupdates und 30 Tagen Standard-Support für immerhin 725,00 €.

Um optimal vorbereitet zu sein, wollte ich den SLES 9 einmal auf einem Server von Dell testen, bevor ich nach Leipzig fuhr. Dazu kam mir ein Dell PowerEdge 1600 Server gerade recht, der gerade greifbar war. Dies gelang mir jedoch nicht, da die Installation immer abstürzte. Ein Anruf beim Support von Dell ergab, dass der Server nicht für den SLES zertifiziert ist, da er schon älter ist. Es wurde mir aber versichert, dass die Installation auf einem PowerEdge 1800 ohne Probleme laufen sollte. Da meine Zeit knapp war und kein PowerEdge 1800 greifbar war, fuhr ich am 11. Oktober 2006 ohne weitere Tests nach Leipzig. Danach erlebte ich eine unglaubliche Odyssey durch die Hotlines von Dell und SuSE, die ich im folgenden chronologisch aufgelistet habe.

Mein Fazit: Der SLES läuft auf Servern von Dell nicht besser oder stabiler als Debian, auch wenn dies immer wieder gerne von dem Support bei Dell oder auf Webseiten behauptet wird und die Zertifizierungen von Novell sind mit äußerster Vorsicht zu genießen, da sie sich lediglich auf einen Server dieses Modells beziehen. Sobald Dell auch nur einen anderen Controller einbaut, läuft der Server unter Umständen nicht mehr. Des weiteren wird von Novell auch nicht getestet, ob die Management-Software OpenManage auf zertifizierten Servern läuft. Das kann sehr ärgerlich sein, wenn man auf der Suche nach einem Hardwaredefekt ist.

Update (15.11.2006): Nachdem ich mich – nach drei Wochen erfolgloser Versuche mein Problem zu lösen – bei Novell und Dell beschwert hatte, zeigten sich beide Firmen sehr bemüht das Problem zulösen. In der letzten Woche riefen mich fast täglich Supporter beider Firmen an. Beide Firmen sagten zu, den Support für den Novell SLES auf Server von Dell zukünftig zu verbessern. Des weiteren gibt es inzwischen eine Oracle 10 Version, die für den SLES 10 zertifiziert ist.

• 11. Oktober 2006
  • 14:00 UhrVersuch einer Installation von SLES 9 auf einem PowerEdge 1800. Die Installationseinstellungen lassen sich Problemlos tätigen. Die Platte läßt sich jedoch nicht formatieren. Der Server fängt dabei laut an zupiepen und friert völlig ein. Man kommt nicht mal mehr auf die Konsole mit den Fehlermeldungen.
  • 14:30 Uhr
    Anruf bei Dell: nach ca. 20 Minuten der Rückruf eines Technikers. DasProblem ist bekannt. Das Kernelmodul für den Adaptec-Controller hateinen Fehler. Für Redhat gibt es auf der Webseite von Dell ein funktionierendes Kernelmodul und für Debian/Ubuntu eine ausfühliche Anleitung. Bei dem SLES soll laut Dell Novell für den Support und Updates verantwortlich sein.
  • ca. 15:25 Uhr
    Anruf bei SuSE: Es ist kein deutscher sondern nur ein amerikanischer Supporter erreichbar. Ich schildere das Problem und erwähne zusätzlich noch, dass ich in einer anderen Niderlassung bin. Dabei weise ich auch darauf hin, dass mein Problem mit dem RAID-Controller bekannt zu seien scheint und es von Dell nur ein Update für Redhat gibt. Ich gebe auch an, dass der Support von Dell für ein Update auf Novell verweist. Darauf wird mir versichert, dass sich noch am selbern Tag jemand bei mir per Telefon meldet. Vorher muss ich allerdings nach telefonischer Anleitung 20 Minuten lang ein Webformular ausfüllen, da der amerikanische Supporter meine Lizenz noch nicht auf seinem Bildschirm sehen kann (ich habe diese erst vor 60 Minuten aktiviert). In dem Webformular erläutere ich meine Probleme mit dem RAID-Controller und gebe eine genaue Fehlerbeschreibung wieder.
  • ca. 17:45 Uhr
    Erneuter Anruf nach ca. 2 Stunden. Ein Supporter erklärt mir es könne bis zum nächsten Tag dauern. Ich fahre ins Hotel.

• 12. Oktober 2006
  • ca. 09:30 Uhr
    Es hat sich kein Techniker gemeldet und ich frage bei derHotline nach ob es denn heute etwas wird. Es meldet sich eine netteAmerikanerin und sagt ich solle in 10 Minuten noch mal anrufen, weil inEuropa keiner erreichbar ist.
  • ca. 10:00 Uhr
    Ich rufe erneut an und bekomme jemanden, der deutschkann!!! Erfreut beschreibe ich erneut mein Problem. Auf deutsch kann ich solche Problembeschreibungen natürlich schneller und genauer abgeben. Es heißt jedoch nur, ich werde von einem Techniker angerufen, der dann besser verstehen würde was ich meine. Auf meine Nachfrage wie lange es dauern wird bekomme ich dieAntwort, dass dies schnell gehen werde, weil die freundliche Amerikanerinschon vermerkt hätte, dass ich in einer anderen Niederlassung bin undnicht zu lange bleiben möchte.
  • 10:39 Uhr
    Ich bekomme eine Email, in der ein Techniker mir mitteilt, ich müsse den Fehler genauer beschreiben, Logfiles schicken sowie genaue Informationen über die Hardware.
  • 10:45 Uhr
    Ich rufe erneut den Support an und sage das ich keine Logdateien oder Fehlermeldungen schicken kann, weil der Server einfriert. Des weiteren gebe ich noch mal zu bedenken, dass ich eingentlich nur wissen möchte, wie ich den SLES auf einem Server von Dell zum laufen bekomme, es gerade schon bei dem zweiten Modell versuche und die Installation gleich am Anfang fehl schlägt, obwohl der Server zertifiziert ist. Ich sage außerdem, dass ich eigentlich mehr auf der Suche nach genauen Anleitungen und Treibern bin, da mir inzwischen klar ist, dass ich SLES 9 mit dem mitgelieferten Treibern nicht zum laufen bekomme. Es heißt erneut, dass mich jamand anrufen wird.
  • 13:32 Uhr
    Ich bekomme endlich einen Rückruf von Novell und es heißt ich solle von der CD des Servicepack 3 booten und installieren. Auf dieser sei ein funktionierendes Kernelmodul. Des weiteren erfahre ich, dass der SLES 9 sehr schlechte SATA-Treiber hat und man am besten gleich den SLES10 nimmt. Ich lade mir also ein Image für die CD (mit dem Servicepack 3) aus dem Internet, brenne es auf eine CD und probiere erneut zu installieren. Diesmal kommt die Installation immerhin fast bis zum Ende. Nachdem 99% der Dateien kopiert wurden friert die Installation ein und der Server fängt an zu piepen.
  • 14:00 Uhr
    Ich muss noch zurück nach Hamburg und habe am nächsten Tag noch einige andere Sachen zu erledigen, auf die ich mich vorbereiten muss. Ich gebe also entnervt auf und packe den Server ein, um in den nächsten Tagen in Ruhe weiter zu testen. Da der Support von Oracle mir bis jetzt auch immer bei nicht lizensierten Linux-Distributionen geholfen hat, plane ich auch es jetzt gleich mit dem SLES 10 zu versuchen.
• 13. Oktober 2006
  • ca. 10:00 Uhr
    Es ist der letzte Tag vor meinem Urlaub und ich habe noch sehr viele Sachen zu erledigen. Ich habe deshalb nicht sonderlich viel Zeit für das Problem mit  dem SLES und versuche nur mal schnell den SLES 10 zu installieren, um zu sehen ob zumindest der läuft. Bei den beiden ersten Installationsversuche stürzen an unterschiedlicher Stelle ab. Der dritter Versuch funktionierte, ohne das ich irgend etwas anders gemacht habe. Durch dieses eigenartige Verhalten vermute ich, dass ein Defekt der Hardware für die Probleme verantwortlich ist. Ich beschließe den Server während meines Urlaubes (7 Tage) laufen zu lassen, um zu sehen ob er abstürzt.
• 16. Oktober 2006
  • ca. 11:00 Uhr
    Der Support von Novell hat mir inzwischen geschrieben und will mehr Informationen über mein Problem mit dem SLES9 wissen. Ich schreibe nur kurz zurück, dass ich einen Hardwaredefekt als Ursache vermute und keine Infos zu dem Problem mit SLES 9 mehr liefern kann, weil ich inzwischen den SLES 10 teste.
• 25. Oktober 2006
  • ca. 10:00 Uhr
    Während meinem Urlaub ist der Server abgestürzt. Ich starte ihn neu und schaue kurz in die wichtigsten Log-Dateien. Es gibt jedoch keine Fehlermeldung. Er scheint wieder einfach nur eingefroren zu sein.
• 27. Oktober 2006
  • ca. 15:00 Uhr
    Der Server ist wieder abgestürzt und es gibt wieder keine Fehlermeldung in den Logfiles. Ich bin mir jetzt sehr sicher das es ein Hardwaredefekt ist.
  • ca. 16:00 Uhr
    Ich rufe bei Dell an und schildere meine Probleme. Mit telefonischer Hilfe installiere ich die Software Dell Open Manage Server Administrator Managed Node 5.1 und Dell PowerEdge Diagnostics 2.7 auf dem Server. Die Diagnosesoftware kann kein Hardwareproblem finden und OpenManage kann nicht gestartet werden. Bei jedem Versuch OpenManage zu starten gibt das Kernelmodul ipmi_si die Fehlermeldung ‘Unable to find any System Interface’ aus. Der Supporter von Dell weiß erst mal nicht mehr weiter und will sich wieder melden.
• 30. Oktober 2006
  • 9:45 Uhr
    Ich versuche die Firmware des Servers von Dell zu aktualisieren, da ich auf der Webseite neuere entdeckt habe. Die Firmware des Server läßt sich ohne Problem aktualisieren. Die Installation der neuen Firmware für den SATA-RAID-Controllers behauptet immer erfolgreich gewesen zu sein. Nach einem Neustart ist aber immer noch die alte Firmware im Controller. Ich rufe den Support von Dell an und schildere mein erneutes Problem.
  • 10:47 Uhr
    Dell möchte einige Logfiles per Email geschickt bekommen, um das Problem lösen zu können.
  • 11:28 Uhr
    Novell teilt mir in einer Email mit, dass der Service Request geschlossen wurde und sie davon ausgehen, dass ich das Problem gelößt habe.
  • 12:53 Uhr
    Ich antworte auf die Mail von Novell, dass der Fall in meinen Augen noch nicht gelößt ist. Dabei beschreibe ich auch meine bisherigen Bemühungen.
  • 14:42
    Ich bekomme eine CD von Dell mit einem Linux Kernel und einer Software zum auslesen des IPMI-Funktionen, die man booten kann. Die Software läßt sich ohne Probleme benutzen. Es gibt auch keinerlei Probleme, bei dem laden des ipmi_si Kernelmodules. Ich teile dies dem Techniker bei Dell mit. Dieser hat keine weiteren Ideen mehr für die Fehlersuche. Er will sich mit anderen Technikern beraten und sich danach wieder melden.
  • 15:30 Uhr
    Ich schaue in das Webinterface für die Service Requests bei Novell und stelle fest, dass mein Service Request noch immer geschlossen ist. Meine Email mit der Bitte weitere Bearbeitung ist jedoch bereits zu sehen. Ich schreibe also einen weiteren Eintrag über das Webinterface. In diesem weise ich erneut darauf hin, dass der Servie Request noch nicht geklärt ist und bitte um baldigen, telefonischen Rückruf, um noch einige Einzelheiten zu dem Fall zu besprechen.
  • 16:40 Uhr
    Ich schaue erneut in das Webinterface für die Service Requests bei Novell. Es zeigt sich, dass der Service Request immer noch geschlossen ist. Ich entdecke einen Hinweis, dass man Anrufen soll, um den Service Request erneut zu öffnen. Ich bin mir deshalb nicht sicher, ob meine Email und mein Eintrag über das Webinterface ausgereicht haben. Ich rufe also zur Sicherheit bei dem Support von Novell an und frage warum der Service Request immer noch geschlossen ist. Ich weise auch darauf hin, dass ich von einem Techniker zurück gerufen werden möchte. Es heißt, dass sich ein Techniker melden wird.
  • 16:53 Uhr
    Ich schicke dem Support von Dell die gewünschten Logdateien.
  • 16:54 Uhr
    Dell bittet mich den Server mit der “DELL Open Manage Installation and Server Management 5.1 CD” nocheinmal neu aufzusetzen.
• 31. Oktober 2006
  • 10:10 Uhr
    Ich versuche den Server mit der “DELL Open Manage Installation and Server Management 5.1 CD” nocheinmal neu aufzusetzen. Nachdem ich die CD geladen habe, muss ich für die Installation einige Fragen beantworten. Dabei kommt auf einmal die Frage, ob ich Windows oder RHEL installieren möchte.
  • 10:40 Uhr
    Ich rufe den Support bei Dell an und frage, warum ich bei der Installation keinen SLES auswählen kann. Der Supporter ist überfragt und muss selber jemanden Fragen. Ich hänge für einige Minuten in der Warteschleife. Danach erfahre ich das es auch funktionieren soll, wenn man angiebt RHEL installieren zu wollen.
  • 10:55 Uhr
    Ich erhalte eine Email von einem Supporter bei Novell, der mir mitteilt, dass er den Service Request übernommen hat, weil sein Kollege für einige Tage nicht im Hause ist. Er verlangt erneut weitere Informationen über den Fehler bei der Installation von SLES 9 und teilt mir mit, dass es sich sicherlich um ein Problem mit der Hardware handelt. Zusätzlich möchte er auch noch weitere Informationen über die Hardware haben.
  • 11:00 Uhr
    Ich gebe bei der Installation an, dass ich einen RHEL installieren will. Die “DELL Open Manage Installation and Server Management 5.1 CD” formatiert alle Festplatten und überschreibt damit meine Installation. Danach wird meine SLES CD nicht akzeptiert. Die Installation will unbedingt eine RHEL CD haben, die ich nicht besitze.
  • 11:20 Uhr
    Ich rufe erneut bei dem Support von Dell an und teile mit, dass meine SLES CD nicht installiert wird. Der Supporter ist relativ sprachlos. Er kann sich das alles nicht erklären, will sich erneut mit anderen besprechen und danach zurück rufen. Ich werde langsam etwas sauer und gebe zu bedenken, dass ich den SLES nur wegen Supportern von Dell gekauft habe, die mir andauernd erzählen, dass lizensierte Linux Distributionen auf Dell Servern nich so viele Probleme machen. Zusätzlich wende ich ein, dass ich mit meinem “nicht lizensierten” Debian 3.1 schon nach ca. 2 Stunden auf dem gleichen Stand war, wie jetzt nach zwei Wochen.
  • 13:00 Uhr
    Ich werde von einem weiteren Supporter von Dell angerufen. Er stellt sich als Spezialist für Linux vor, der den Fall von seinem Kollegen übernommen hat. Er bittet mich SLES 10 noch mal ohne die “DELL Open Manage Installation and Server Management 5.1 CD” zu installieren und danach Treiber und Firmware von einer PowerEdge Update CD zu aktualisieren.
  • 13:33 Uhr
    Ich antworte auf die Email (die mir Novell um 10:55 Uhr schrieb). Ich schreibe, dass ich auch von einem Defekt der Hardware ausgehe, sich jedoch mit den Tools von Dell keine Hardwareprobleme finden lassen. Ich schildere auch, dass OpenManage und das Update der Firmware des RAID-Controllers unter dem SLES 10 nicht funktionieren und schicke die gewünschten Informationen über die Hardware. Des weiteren beschwere ich mich über die Reaktionszeiten bei dem Support von Novell und schicke umfangreiche Informationen über den bisherigen Verlauf des Servie Request bei Dell bzw. Novell. Dabei bezeichne ich die Hilfe von Novell als unzureichend. Dies begründe ich damit, dass ich mehrmals nicht von einem Techniker zurück gerufen wurde, obwohl es mir zugesagt wurde. Der Supporter bei Novell gibt meine Probleme an SuSE in Nürnberg weiter und meine Beschwerde an seinen Vorgesetzten.
  • 14:00 Uhr
    Nach einer erneuten Installation des SLES 10 versuche ich die PowerEdge Update CD zu installieren. Treiber sind dadrauf nicht zu finden aber immerhin einige Firmware-Updates. Es ändert sich jedoch nicht viel. Das Mainborad von dem Server hat ja schon die aktuelle Firmaware, das Update von dem RAID-Crontroller funktioniert genau so wenig wie vorher aber immerhin wird die Firmware von dem Bandlaufwerk aktualisiert. Das habe ich vorher aber auch noch nicht versucht.
  • 14:55 Uhr
    Ich schreibe per Email an den Support von Dell, dass die PowerEdge Update CD auch nicht viel gebracht hat.
  • 15:26 Uhr
    Dell bittet mich mit dem Dell System Extraction Tool (DSET) einen Report zu erstellen und diesen an den Support zu senden. Ich erledige dies umgehend.
  • 16:11 Uhr
    Der Supporter von Dell schreibt mir per Email, dass er aus dem Report nicht viel sehen konnte, da das Tool für Redhat entwickelt wurde und bei SuSE nicht richtig funktioniert. Er hat aber die Vermutung, dass Dell OpenManage nicht läuft, weil der gcc nicht installiert ist. Ich installiere den gcc. Dell OpenManage läuft aber immer noch nicht.
• 11. November 2006
  Es passiert weder bei Novell noch bei Dell etwas. Liegt das an den Nachwehen von Halloween oder ist bei den Supportern ein Feiertag? Ich freue mich jedenfalls, dass ich auch mal ein paar andere Sachen erledigen kann und nicht nur mit SLES auf Servern von Dell beschäftigt bin.
• 2. November 2006
  • 9:10 Uhr
    Ich habe inzwischen mehrere Emails von dem Supporter von Novell erhalten, in denen er mich auf dem Stand hält. Zumindest die Kommunikation funktioniert jetzt. Auf eine Nachfrage von mir, ob das daran liegt, dass ich jetzt Emails schreibe, wird mir bestätigt, dass der deutsche Support von Novell Emails bevorzugt. Es wird aber behauptet, dass es auch telefonisch geht.
  • 10:10 Uhr
    Ich bekomme eine Email von dem Supporter von Dell. In der Email entschuldigt er sich dafür, dass er am Vortag nicht telefonisch erreichbar gewesen ist, weil er in einem Training war. Des weiteren möchte er Logdateien per Email bekommen.
  • 11:08 Uhr
    Ich antworte auf die Email des Supporters von Dell, die er mir um 10:10 Uhr geschrieben hat. Ich schreibe, dass ich die Logdateien doch bereits am 30. Oktober um 16:53 Uhr an Dell geschickt habe. Zusätzlich kopiere ich die intessanten Fehlermeldungen aus den Logdateien in die Email und hebe diese besonders hervor.
  • 11:26 Uhr
    Der Supporter von Dell hat eine Lösung für das Problem mit ipmi in einem Debian-Forum entdeckt. Es wird durch einen Fehler im Kernel verursacht und es gibt bei http://www.kernel.org auch bereits einen Patch. Mann kann das Problem auch umgehen, indem man die Option ‘pnpacpi=off’ beim booten des Kernels angibt. Ich bedanke mich bei ihm und teile ihm mit, dass ich das erst am nächsten Tag ausprobieren werde, da ich mich zur Zeit gerade in einer anderen Niederlassung befinde und keinen Zugriff auf den Server habe.
  • 12:06 Uhr
    Der Supporter von Dell bittet mich per Email, mit OpenManage einen Test der einzelnen Festplatten zu machen.
  • 12:16 Uhr
    Ich schreibe dem Supporter von Novell die Informationen, die ich inzwischen von Dell bekommen habe, damit dieser den Fehler und die Lösung der Entwicklung melden kann.
  • 16:57 Uhr
    Ich erhalte eine Email von dem Supporter von Novell. Er schreibt mir, dass der Server zwar zertifiziert ist, aber nicht der RAID-Controller. Er geht aber auch davon aus, dass wir den SLES trotzdem zu laufen bekommen. Dazu soll ich einen anderen RAID-Controller kaufen, oder den RAID-Controller abschalten und ein Software-RAID aufsetzen. Des weiteren schreibt er mir zu dem Problem mit dem ipmi.’Mein Kollege bat mich, Sie zu bitten, einen zusaetzlichen Service Request zu oeffnen. Mit dieser Vorgehensweise folgen wir lediglich einer Standarprozedur, da es sich bei den Themen “Installation” und “Hardware Test” ja um zwei voellig verschiedene Topics handelt. Im Falle der Open Manage 5.1 Software koennten wir dann zumindest einen Feature Request oeffnen oder sogar einen Bug Report, dieses muesste dann ggf. noch genauer erlauetert werden.’ Im Klartext heißt das für mich: Der Server ist doch nicht zertifiziert, obwohl dies auf der Webseite von Novell steht (dort steht nichts davon, dass man einige RAID-Controller nicht verwenden darf) und ich soll schon wieder so ein Webformular ausfüllen, da es nicht reicht einen Fehler im Kernel inklusive Lösung per Email zu melden! Auf der Webseite mit den Informationen zu der Zertifizierung von Novell heißt es übrigens: ‘The standard Baseboard Management Controller (BMC) with Serial or network access and IPMI 1.5 compliance, along with the optional Remote Server Management PCI card (DRAC4/P) are designed to minimize downtime by making the server easier to deploy, service and manage remotely.’ Mich würde jetzt ja mal interessieren, wie die zu dieser Aussage kommen, wenn ipmi mit dem Standard-Kernel des SLES 10 nicht läuft!
• 3. November 2006
  • 10:30 Uhr
    Nachdem ich die Option ‘pnpacpi=off’ beim booten des Linux-Kernels verwende, läuft Dell OpenMange 5.1 ohne Probleme. Der normale Test findet immer noch keine defekte Hardware. Ich wähle – wie von dem Supporter bei Dell gewünscht – die einzelnen Festplatten aus und lasse diese testen. Daraufhin läuft ein viel intensiverer Test, wie man schon an der Dauer bemerkt. Er läuft über zwei Stunden. Dabei stellt sich heraus, dass zwei Festplatten defekt sind. Noch bevor der Test durchgelaufen ist, ruft der Supporter von Dell an und erkundigt sich nach dem Stand. Ich schicke ihm kurz danach die Ergebnisse des Tests.
  • 13:40 Uhr
    Der Supporter von Dell ruft wieder an. Er erzählt das sogar drei Festplatten defekt sind und Dell sicherheitshalber alle vier tauschen wird. Da ich noch viele andere Sachen zu erledigen habe, bitte ich ihn die Reperatur erst am Montag zu veranlassen. Das ist kein Problem. Kurze Zeit danach ruft mich ein Disponent an und vereinbart einen genauen Termin für den Montag.
  • 17:10 Uhr
    Ich eröffne bei Novell einen zusaetzlichen Service Request über das Webinterface. Ich gebe dort, wie von dem Supporter bei Novell gewünscht, erneut die Informationen über den Fehler im Kernel und die Lösung ein.
  • 18:17 Uhr
    Ich bekomme eine Email von einem amerikanischen Supporter von Novell. Er schreibt mir, dass er meine deutsche Email leider nicht verstanden hat. Zusätzlich bittet er mich die Email noch mal in Englisch zu schreiben.
  • 20:43 Uhr
    Ich antworte dem amerikanischen Supporter von Novell per Email. Ich schreibe ihm dabei, dass ich schon einen Service Request am laufen habe (ich gebe natürlich auch die Nummer dazu an) und teile ihm mit, dass ich den neuen Service Request nur eröffne, weil mich der deutsche Supporter von Novell darum gebeten hat. Ich teile ihm auch mit, dass der Service Request nicht eilig ist und er ihn doch einfach wieder nach Deutschland schicken soll.
• 6. November 2006
  • 09:10 Uhr
    Der Supporter von Dell meldet sich und klärt noch einige Einzelheiten für den Tausch der Festplatten.
  • 09:19 Uhr
    Der Supporter von Novell schreibt mir er freue sich zu hören, dass wir das Problem nun lokalisieren konnten, und es – wie Novell von Anfang an vermutet hatte – ein Hardwareproblem zu sein scheint. Dabei biezieht er sich auf diesen Blog. Die kommunikation über das Internet funktioniert also sehr gut bei Novell! Weiterhin fragt er, ob er den Service Request jetzt schließen kann.
  • 09:46 Uhr
    Ich schreibe an den Supporter von Novell, dass ich ihm bescheid gebe, wenn sich zeigt, dass der Server nach einem tausch der Festplatten stabil läuft.
  • 10:01 Uhr
    Der Supporter von Novell fragt mich, ob ich lediglich die Bootoption”pnpascpi=off” mit uebergeben habe, um OpenManage zum Laufen zu bekommen.
  • 10:53 Uhr
    Ich schreibe an den Supporter von Novell, dass dies – soweit ich das verstanden habe – den Fehler im Kernel nur umgeht und schicke erneut den Link zu dem Patch von www.kernel.org, der den Fehler behebt.
  • 14:53 Uhr
    Der Supporter von Novell schreibt mir, dass er jetzt ein “technical information documents” und einen Bug report für den Fehler erstellen will.
• 7. November 2006
  • 14:00 Uhr
    Der Supporter von Novell schreibt mir, dass das Problem mit dem Kernel-Modul aller Voraussicht nach in SP1 für SLES 10 behoben sein wird und ich dann umgehend benachrichtigt werde. Der andere Service Request wird geschlossen, weil es sich offensichtlich um einen Hardwaredefekt handelt. Auf eine Nachfrage von mir gibt mir der Supporter auch noch einige URL’s, auf welchen ich Informationen zu Oracle unter SLES 10 finden kann.
• 8. November 2006
  • 13:30 Uhr
    Nach diversen Emails und Telefonaten sind die Festplatten endlich angekommen (zwei Tage später als geplant). Ich werde wohl nie begreifen, wo das Problem bei UPS lag. Der Supporter von Dell zeigte sich aber sehr bemüht und übte massiven Druck auf UPS aus.
  • 14:00 Uhr
    Ich baue die Festplatten in den Server ein, richte das RAID neu ein, installiere die Management-Partition von Dell und den SLES 10 neu und versuche die Firmware des RAID-Controllers zu erneuern. Es funktioniert immer noch nicht! Ich schreibe also wieder eine Email an Dell.
  • 15:30 Uhr
    Ich werde erneut von dem Supporter von Dell angerufen. Ich soll erneut eine Diagnose des RAID-Controllers und der Platten durchlaufen lassen. Dazu müssen zunächst erneut Dell Open Manage Server Agent 5.1 und Dell PowerEdge Server Diagnostics 2.7 installiert werden. Der Test läuft über zwei Stunden. Deshalb verabrede ich die Ergebnisse erst am nächsten Tag an Dell zu schicken. Zusätzlich erhalte ich auch noch eine Anleitung für das erstellen eines bootfähigen USB-Sticks, um zu versuchen die Firmware über diesen zu aktualisieren.
• 9. November 2006
  • 11:00 Uhr
    Ich erstelle nach der Anleitung, die ich per Email bekommen habe, einen bootfähigen USB-Stick. Die EXE-Datei mit der neuen Firmware besteht jedoch auf zwei Disketten und läßt sich nicht auf den USB-Stick installieren. Der Test der Festplatten und des RAID-Controllers von “Dell PowerEdge Server Diagnostics 2.7” ist inzwischen ohne Fehler durchgelaufen.
  • 13:30 Uhr
    Ich bin gerade dabei eine Email an den Supporter von Dell zu schreiben, da ruft dieser auch schon an, um nach dem Stand zu fragen. Ich berichte von meinem scheitern. Er will sich etwas neues überlegen und sich wieder melden.
  • 14:00 Uhr
    Ich erhalte von dem Supporter von Dell einen neuen Link, zum runterladen einer Live-CD mit Linux. Ich soll von dieser Booten und danach über den USB-Stick die Firmware aktualisieren.
  • 15:00 Uhr
    Der Supporter von Dell ruft wieder an, um erneut nach dem Stand zu fragen. Ich habe das Update inzwischen mehrfach über Live-CD und USB-Stick versucht und bin immer gescheitert. Diesmal bricht das Update der Firmaware sogar mit einer Fehlermeldung ab und behauptet nicht funktioniert zu haben. Ich teste noch ein weiteres mal, ob das Update auch nicht funktioniert, wenn der RAID-Controller in einem anderen Slot eingebaut ist. Es geht aber auch nicht. Der Supporter von Dell bestellt einen Techniker, der am nächsten Tag vor Ort den RAID-Controller tauschen soll.
• 10. November 2006
  • 15:30 Uhr
    Der von Dell beauftragte Techniker kommt mit einem neuen RAID-Controller vorbei und verbaut diesen.
  • 16:30 Uhr
    Der Supporter von Dell ruft wieder an und erkundigt sich, ob der Server repariert wurde. Ich berichte ihm, dass alles funktioniert hat.
  • 16:45 Uhr
    Der Service Request bei Dell wird geschlossen. Nach genau einem Monat läuft der Server endlich wieder ohne Probleme! Ich werde ihn jetzt noch eine Woche testen und wieder nach Leipzig fahren.