Gestern um 20:00 begann ich damit, meinen Heimserver dem grössten Upgrade in seiner Geschichte zu unterziehen. Zwei Gründe bewegten mich zu diesem Entscheid: Einerseits war das Gerät längst betagt und mittlerweile äusserst schwach auf der Brust. Andererseits kämpfe ich seit dem Sommer 2009 sporadisch mit „Black Screens Of Death“, welche nur mit einem Reset zu beheben waren. Natürlich machen solche Ausfälle bei einem eigentlich 24/7 verfügbaren Server keinen Sinn. Leider brachte die Fehlersuche über Monate hinweg keine Ursache zu Tage. Vermutlich lag es an der Altersschwäche eines Bauteils.

Was hat sich in der Hardware geändert?

Server alt

• Yeong Yang YY-B0221 (spezielles Server-Gehäuse mit zwei Abteilen für Motherboard und Laufwerke)
• Intel Pentium III, 600 MHz
• Asus P3B-F
• 4x Kingston 256 MB, SDRAM, PC100 — KVR133X64C3/256
• Matrox Millennium G200, AGP
• Intel PWLA8391GT, PCI, Gigabit-Ethernet
• Adaptec AHA-2940U2W, SCSI-Controller
• 1x Fujitsu MAJ3182MP, 18.2 GB, U2W-SCSI — System
• FirmTek SeriTek/1S2, SiL 3112, SATA-Controller
• 1x Maxtor , 160 GB, SATA — /var
• 2x Promise Ultra 133 TX2
• 4x Samsung SP2514N, 250 GB, ATA-7 (RAID1+0) — Storage

Server neu

• Yeong Yang YY-B0221 (spezielles Server-Gehäuse mit zwei Abteilen für Motherboard und Laufwerke)
• Intel Core 2 Duo E5400, Dual Core 2.7 GHz, 800 MHz
• Asus P5QPL-VM-EPU, Mini-ATX
• 1x Apacer 1 GB, DDR2, 800 MHz
• Intel PWLA8391GT, PCI, Gigabit-Ethernet
• 1x Samsung HD161GJ, 160 GB, SATA-3 — System
• 2x Samsung HD154UI, 1.5 TB, SATA-3 (RAID1) — Storage

Erfahrungshäppchen

• Grundsätzlich sei wieder einmal zu erwähnen, dass man ein solch tiefgreifendes Hardware-Update unter Windows schlichtwegs hätte vergessen können; um eine Neuinstallation wäre man auf Grund der komplett anderen Hardware nicht herumgekommen. Ich lobe mir deshalb Debian GNU/Linux, welches — zwar auch mit einiger (selbstverursachter) Müh und Not — nach einigen Anpassungen anstandslos unter der neuen Hardware bootete.
• Durch die Vereinfachung der Storage-Infrastruktur (Wegfall von 3 Platten und 4 Controllern) sank die Stromaufnahme um 5 %, obwohl anzunehmen ist, dass CPU und Motherboard mehr Energie benötigen als die Komponenten des alten Servers.
• Dass im Server-Gehäuse nun nur noch 3 statt 6 Festplatten hängen, erlaubt mir, diese deutlich effizienter zu kühlen. Auch das Betriebsgeräusch des Servers ist aus meiner Empfindung etwas leiser geworden.
• Das Motherboard weist einen sog. EATXPWR-Connector auf. Auf den ersten Blick befürchtete ich, am Sonntag noch ein neues Netzteil kaufen zu können. Steckt man den Stromstecker eines normalen ATX-Netzteils ein, sind vier Pins des neuen Steckers nicht belegt. Das Board startet trotzdem — wenn man den zusätzlichen 4-pin 12V-Anschluss in der Nähe des Prozessors mit dem entsprechenden Kabel des Netzteils bestückt. Der Betrieb ist also durchaus möglich — entweder mit 20-pin ATX + 4-pin ATX 12V oder 24-pin EATXPWR.
• Aus ISO-Images von Ubuntu einen bootbaren USB-Stick zu bauen, ist unter Mac OS X nicht möglich. Es wird vielerorts empfohlen, stattdessen die IMG-Datei des Ubuntu Netbook Remix herunterzuladen, ohne aber auf eine solche Datei zu verlinken. Diese gibt es nämlich nur für das ältere Ubuntu 9.04 (aktuell: 9.10); bspw. auf dem SWITCH-Mirror: ubuntu-9.04-netbook-remix-i386.img. Mit diesem Image soll es anschliessend gemäss Anleitungen im Netz möglich sein, unter Mac OS X mit dem Terminal den Stick mit Ubuntu bootbar zu machen.
• Da der Download dieser Datei ein gute Stunde dauerte, habe ich schlussendlich einen alten DVD-Brenner im Server verbaut und den Server von CD gebootet.
• Bei der Partitionierung der neuen 160 GB-Systemplatte mit fdisk unter Ubuntu Live-CD habe ich bei der Grössenangabe für die einzelnen Partitionen vergessen, ein + voranzustellen (Bspw. +512M für eine Partition mit 512 MB Platz). Deshalb ist meine /boot-Partition nun nicht 512 MB gross, sondern 3.1 GB *autsch*
• Um den Swap-Space zu initialisieren, benutzte ich mkswap, was beim ersten Anlauf aber enorm viel CPU-Resourcen benötigte und nicht vor dem Ende meiner Geduld abgeschlossen werden konnte. Indem ich dieses Executable ohne den Paramenter -c (für „check“) aufrief, rauschte die SWAP-Formatierung wie im Schnellzugstempo durch.
• Nachdem ich die Daten von der alten SCSI-Systemplatte auf die SATA-Systemplatte kopiert hatte (der Adaptec AHA-2940U2W SCSI-Controller und die daran hängende Platte wurde vom Board und Ubuntu problemlos erkannt), startete der Rechner nicht, weil GRUB einen „Error 2“ meldete. Ich war mir ganz sicher, dass ich den Bootsektor in die richtige Platte geschrieben und mit hd(0,0) auch garantiert die richtige Platte konfiguriert hatte. Wo also lag das Problem? Dank eines Blog-Artikels GRUB „Error 2“ May Mean Incompatible stage1.5, stage2, and ext2 kam ich darauf, dass ich die Platte mit einem brandneuen mkfs.ext3 formatiert, dann aber die GRUB-Stages 1.5 und 2 datierend aus dem 2007 von der alten Platte in den Bootsektor geschrieben hatte. Glücklicherweise fanden sich unter /usr/lib/grub/i386-pc/ neuere Dateien im leicht grösseren Umfang und aus dem Jahr 2009. Nachdem ich diese Dateien über /boot/grub kopiert und den MBR neu geschrieben hatte, funktionierte der Bootvorgang dann endlich wie geschmiert.
• Nachdem das System zum ersten Mal in der neuen Konfiguration ohne fremde Hilfe hochgekommen war (nicht vergessen: /etc/fstab und /boot/grub/menu.list müssen zwingend angepasst werden!), ging es nun darum, /var von der alten SATA-Platte rüberzukopieren. Wie bei allen Kopieraktionen verwende ich dazu # rsync -av . /mnt/sda1 oder dergleichen. Bricht der Kopiervorgang aus unerfindlichen Gründen ab, stellt man mit rsync sicher, dass nur diejenigen Dateien kopiert werden, die auf dem Zielsystem noch nicht identisch vorhanden sind. Auch werden die Benutzer und Rechte auf jeden Fall mitkopiert.
• Die Daten vom RAID1+0 kopierte ich heute Sonntag-Nachmittag auf das neu erstellte RAID1. Damit ich die Daten nicht über das langsame Ethernet-Netzwerk kopieren musste, suchte ich mir zwei exteren USB-Festplattengehäuse und wählte dann zwei Festplatten des RAID-Verbundes aus. Wichtig ist bei RAID1+0 natürlich, dass man die zwei komplementären Platten nimmt, die im Degraded-Modus das ganze Volume herstellen. Damit mdadm die Platten erkannte, musste ich in /etc/mdadm/mdadm.conf einige Ergänzungen vornehmen, weil der verschachtelte RAID-Verbund nicht automatisch erkannt wurde. Kernstück waren dabei folgende Zeilen:

  ...
  DEVICE partitions
  ...
  ARRAY /dev/md10 metadata=0.90 UUID=8b74168f:921d62ec:197e72a9:dcc396dd
  ARRAY /dev/md11 metadata=0.90 UUID=c7acb783:7d200806:ba3b0bb9:fba14ed1
  ARRAY /dev/md1 metadata=0.90 UUID=0b0b49d4:63eada39:e2d889b1:01493278

  Die UUIDs waren glücklicherweise in der alten mdadm.conf hinterlegt. Sie sind unbedingt zu notieren und an einem sicheren Ort aufzubewahren. Anschliessend klappte es problemlos, die RAID-Arrays mittels # mdadm --assemble /dev/md0 etc. zu starten (natürlich in der richtigen Reihenfolge, d.h. /dev/md1 am Schluss, wenn die RAIDs der beiden USB-Platten gestartet wurden. Ob metadata=0.90 wirklich nötig ist, weiss ich nicht. Als ein Array nur im auto-read-only-Modus gestartet wurde, führte ich folgenden Befehl aus, um auch Schreibvorgänge zu ermöglichen (im Grund ja unnötig, da wir nur Daten ab der Platte kopieren wollen):

  # mdadm --readwrite /dev/md10

• Der anschliessende Kopiervorgang war einerseits ein Burn-In-Test für die verschiedenen Bussysteme des neuen Servers (USB, SATA), andererseits zeigte er die Performance der neuen Hardware:

  sent 460359385722 bytes  received 762070 bytes  38412962.39 bytes/sec
  total size is 460300401834  speedup is 1.00

  — 38 MB/Sekunde sind kein schlechter Wert für ATA-7 über USB auf SATA.

• Da das neue Board nur noch die Pins für einen LPT-Anschluss mitbringt, musste ich meinen HP Laserjet 1300 neu über USB an den Server anschliessen. Leider wurde dabei aber /dev/usb/lp0 nicht automatisch erstellt. Nach einem # apt-get dist-upgrade erschien dieses Device plötzlich in der Dateiliste. Nur noch /etc/printcap anpassen (statt /dev/lp0 ist es neu /dev/usb/lp0 — fertig!). Auf jeden Fall lud der Kernel alle benötigten Module (usblp, usbcore und uhci_hcd). Dass der Drucker auch wirklich da ist, erkennt man mit dem Befehl:

  # lsusb
  ...
  Bus 002 Device 002: ID 03f0:1017 Hewlett-Packard LaserJet 1300
  ...

  Dieser Befehl findet sich im Paket usbutils

• Bei Aufräumarbeiten in meinem IT-Ersatzteillager fand ich zufälligerweise ein Slotblech, welches zwei serielle Ports (COM1 & COM2) bereitstellte. Da das neue Board Pins für eine COM-Schnittstelle mitbringt, konnte ich so die ältere USV (APC 1400VA) wieder am Server anschliessen.

Dieser Eintrag wurde am Sonntag, 13. Dezember 2009 um 20:41 aufgeschaltet und ist unter den Labels IT, Linux abgelegt. Du kannst das Blog auch über RSS 2.0 abonnieren. Du kannst einen Kommentar oder einen Trackback hinterlassen.