NVidia Kernel Modul zerschossen.

Wenn man mit gewallt seinen Kernel neu installiert kann es passieren, dass danach das Kenrel-Modul nvidia nicht mehr geladen werden kann. Man sollte dann prüfen ob die linux-header-daten desaktuellen kernel installiert sind, da diese zum bauen der Treiber benötigt werden. Anschließend kann man mittels folgendem Befehl die Treiber neu bauen:

sudo aptitude reinstall nvidia-current

Opera und das Importieren von Open-SSL Zertifikaten

Wer seine eigene kleine CA betreibt und dem Opera sein eigenes Root-Zertifikat unter jubeln will, wird mit einer sehr aussagekräftigen Fehlermeldung belohnt: „Importieren Fehlgeschlagen“ wohingegen der Firefox das gleiche Zertifikat ohne Anstalten importiert und verarbeitet.

Der „Fehler“ liegt darin, das Opera nur das reine Zertifikat haben will, ohne irgendwelchen Meta-Daten. OpenSSL speichert in den PEM-Dateien jedoch noch jede Menge Meta-Daten. Diese einfach per TextEditor raus löschen und das Zertifikat lässt sich laden.

Ubuntu und Fake-Raids

Ich nutze nun seit gut 1 1/2 Jahren Ubuntu in zusammenhing mit einem FAKE-Raid-Controler (INTEL ICH10R) und habe allerlei „lustige“ Erfahrungen gemacht. Die ich hier kundtun will. Eins vorweg, beim Einsatz eines FAKE-Raids gilt wie bei alles anderen RAIDs auch: Der RAID schützt nur vor Festplatten-Ausfall, nicht vor Dummheit, Bugs oder sonstigen Fehlern. Ein Backup (jeh nach Anwendungsfall am Besten täglich…) entspannt im Falle eines Datenverlustes doch erheblich die Situation.

Eine der versteckten Fehlerquellen ist der „RAID-Controller“ selber. Alles wird über das Betriebssystem abgefahren. Das BIOS ist nur in der Lage den RAID-Header der Platten auszulesen und zu interpretieren. Das hat drei Konsequenzen:

  • Bei einem irregulären Reboot kann es zu inkonsistent RAID Verbünden kommen. Sobald mehr als ein Stripe auf verschiedene Platten geschrieben werden muss, kann es passieren, dass nur ein Teil geschrieben wird…
  • Die Konsistenz der RAIDs ist vom Betriebssystem abhängig. Die Platten werden weiterhin an das Betriebssystem exportiert. Soll heißen man kann unter Umgehung des „RAIDS“ auf die einzelnen Platten direkt zugreifen und Daten verändern. Das ist eine erhebliche Fehlerquelle, besonders für Anfänger.
  • Da die ganze „RAID-Sache“ in Software abgearbeitet wird, können die Platten ohne weiteres an einen anderen FAKE-Raid-Controler angeschossen und dort ausgelesen werden. Der Linux Treiber ist in der Lage Controller-Unabhängig alle Header auszulesen und die RAID-Units zu betreiben. Unter Windows hat man leider nicht diesen Komfort.

Den ersten Punkt kann man bedingt durch eine USV/UPS (unabhängige Stromversorgung/uninterruptible power supply) eindämmen. So hat man nur noch Reboots zu fürchten die man selber verursacht und die kann man, wie Punkt zwei nur durch eigene Disziplin verhindern.

Gesteuert wird der FAKE-Raid immer über das dm-raid Kommando. Den aktuellen Status kann man über die folgenden Befehle abfragen.

sudo dmraid -s #zeigt den Status aller RAID-Units an
sudo dmraid -r #zeigt den Status aller RAID-Devices an

Vorsicht jedoch mit dem Status „OK“. Aktuell wird bei dem ICH10R z.B. bei einem Rebuild sofort von DEGRADE auf OK gewechselt obwohl der eigentliche Rebuild noch nicht abgeschlossen ist. Wo wir beim Rebuild selber sind. Der aktuelle Treiber erkennt aktuell scheinbar keine Statuswechsel. Ergo, wenn ein RAID in den Status degrade geht, passiert erstmal nichts, auch wenn eine Hot-Spare Einheit zur Verfügung steht. Ein Rebuild muss immer manuell gestartet werden.

sudo dmraid -R  /dev/sdX # Fügt ein Device der RAID-Unit hinzu und startet einen Rebuild.
sudo dmraid -f  -S -M /dev/sdX #markiert das ein Device als "HotSpare"
sudo dmraid -R  #startet eine Rebuild.

Achtung bei dem letzten Befehl. Es kann zu unterschiedlichem Verhalten kommen:

  • Hat die RAID-Unit nicht die benötigte Anzahl an Disk-Units wird versucht eine HotSpare-Unit der RAID-Unit hinzuzufügen und anschließen der Rebuild gestartet.
  • Hat die RAID-Unit bereits alle benötigten Disk-Units wird die RAID-Unit aktiviert und der Rebuild gestartet. Hier sollte man ganz genau darauf achten warum die RAID-Unit noch „degraded“ ist. Es kann schnell passieren, dass man zwei falsche Platte zusammen verbunden hat und versucht diese zu syncen!
Hinweis:Bei meinem Board kam es zu dem Interessanten Problem, das ein Rebuild initiiert durch das BIOS zwar korrekt durchgeführt wurde, der Mirror wurde wieder hergestellt aber anschließend wurde der RAID nicht als OK markiert.

Ab und zu ist es nötig eine Festplatte aus dem RAID zu entfernen, das macht man mit folgendem Kommando:

sudo dmraid -rE /dev/sdX #entfernt einen RAID-Header von einer Platte, die Daten bleiben bei RAID1 lesbar.
Ein extrem wichtiger Hinweis: Es wird zum Tests eines Raides gerne versucht eine Platte zu ziehen und anschließend diese wieder zu stecken. Läuft das System weiter, funktioniert der RAID. MACHT DAS NICHT! Benutzt zum Rebuild eines RAIDs niemals Platten die schon mal Teil dieses RAIDS waren.

Alle mir bekannten RAID-Controller (Software, Fake oder Hardware) reagieren extrem allergisch darauf eine Platte untergejubelt zu bekommen, die sie schon kennen. Wenn zwei Platten eines RAID 0 unterschiedliche Stände aufweisen und beide als „gültig“ markiert sind, ist nicht klar welche Platte der Controller als Rebuild-Quelle wählen wird. Bei dem kleines Test, ist das nicht weiter schlimm, das Delta zwischen den Platten beträgt wenige Minuten und meist nur Logfiles, schließt man aber zum Rebuild eine Platte an, die schon einen aktiven RAID-Header und einen alten Datenbestand hat, kann das extrem unangenehm werden! Richtig bitter wird es übrigens bei RAID5/6. Dort kann eine „alte“ gesteckte Festplatte den kompletten RAID „übernehmen“, der daraufhin sofort FAILED ist, da der RAID plötzlich wieder vollständig ist, aber die Prüfsummen nicht stimmen. Festplatten sollten ergo nur mir dem oben genannten Befehl entfernt werden.

Ein anderer Stolperstein ist der oben erwähnte Direktzugriff. Wenn Programme unter Umgehung des Raides direkt auf Platten zugreifen. Meistens ist dies z.B. der GRUB-Installer. Dieser installiert sich meist nach /dev/sdX anstatt auf das /dev/mapper/<RAID-NAME> Device. Bei einem Ausfall der Platte mit dem Bootloader hat man zwar keinen Datenverlust, kann das System jedoch nicht booten. Das ist nicht weiter schlimm, kann aber extrem irritieren und Panik auslösen.[1. Man sollte immer bedenken, dass man oft unter Stress steht, wenn es zum Ausfall einer Platte kommt. Das sind nie Situationen die man erwartet. Alles was dabei nicht läuft wie man es erwartet erhöht den Druck nur und verleitet zu Fehlern] Abhilfe schafft da nur ein erneutes installieren des Bootloaders auf das richtige Device.

sudo grub-setup /dev/sdX

Um weitere Direktzugriffe zu verhindern, sollte man ganz genau aufpassen was man mountet.

Fazit nach 1 1/2 Jahren FAKE-Raid Betrieb: Ich hab noch keine wirklichen Datenverlust durch den FAKE-Raid selber gehabt. Zwei mal habe ich mich durch eigene Dummheit ins Knie geschossen, kam aber immer durch zeitnahe Backups ohne Datenverlust davon. Es kostete mich nur Zeit und Nerven. Kann ich den Einsatz eines FAKE-Raids empfehlen? Nein – mit einer Ausnahme:

  • Man braucht einen bootbaren RAID 5 und will kein Geld für einen teuren Hardware-RAID ausgeben.

Selbst bei diesem Szenario würde ich eher zu einem bootbaren (Software) RAID-1 mit nachgeschaltetem (Software) RAID 5/6 raten. Es gibt nichts, was ein Fake-Raid besser kann/macht als ein Software-RAID. Dazu kommt, dass der DM-RAID wesentlich schlechter gepflegt wird als md-raid (Software-RAID) oder LVM. Die Fake-Raides sind und bleiben ein Auswuchs der Windows-Welt wo es lange Zeit keine brauchbare Software-Raid-Lösung gab. Ich werde mit dem nächsten LTS Release meinen Server auf jeden Fall entweder auf 100% Hardware-RAID oder die jetzigen Fake-Raids auf Software-RAID umstellen.