staging.inyokaproject.org

Hallo, ich bin noch ziemlich neu in der ganzen Angelegenheit. Zur Vorgeschichte: Anfang Mai habe ich meinen Fileserver neu aufgesetzt (Ubuntu Server 12.04) und während der Installation geführt ein RAID5 mit 3x 2TB WD20EARX eingerichtet. Dies funktionierte hervorragend, bis ich Anfang diesen Monats keinen Platz mehr hatte. Ich habe eine weitere 2TB Platte (selbes Modell) zum Verbund hinzugefügt. Nach 36 Stunden reshaping und weiteren 6 Stunden Dateisystemerweiterung habe ich rebootet. Nach dem reboot war der Server nicht mehr ansprechbar, also habe ich ihn an einen Monitor gepackt und konnte sehen, dass initramfs geladen wurde. Das Problem bestand darin, dass "md127" eine "bad partion table" hatte. Da ich dachte, ich hätte in der Partitionierung einen Fehler gemacht, wollte ich das RAID neu erstellen. Ein Backup liegt vor, also stand dem nichts im Wege...

Problem jetzt seit Anfang des Monats: ...Da am System aber viel rumgetestet wurde, habe ich gleich alles neu aufgesetzt. Allerdings habe ich nicht während der Installation das RAID erstellt, sondern danach (nach Anleitung im Wiki). Nach 13 Stunden rebuilding und einem reboot (kein FS erstellt) der selbe Fehler. Erneuter Versuch das RAID zu erstellen mit weniger Blöcken (ca. 3,8 GB hinter jeder RAID-Partition freigelassen), selber Fehler nach reboot. Jedes Mal waren die logs von mdadm einwandfrei, das heißt, das RAID war aktiv und clean, Superblock v1.2 ist persistent. Die Einträge in der mdadm.conf stimmen auch. Nun kann ich Ubuntu nur starten, wenn ich die RAID-Platten abklemme. Ansonsten bootet nur initramfs.

Nun bin ich mit meinem Latein am Ende und weiß nicht mehr weiter. Andere Forenbeiträge haben mir auch nicht weitergeholfen, genauso wenig wie google. Was mache ich falsch?

P.S. Genaue Ausgaben kann ich momentan nicht posten, da ich bei der Arbeit bin, der Server aus ist und vpn ohne Ubuntu nicht funktioniert... Wenn die Angaben zu ungenau sind, bitte bescheid geben, was genau benötigt wird.

Vielen Dank im Voraus und freundliche Grüße

Robert

Hallo Robert,

grundsätzlich sollte die Erweiterung eines RAID um eine weitere Platte incl. Reshape funktionieren. Du solltest vor einem Reboot aber unbedingt die Einträge für das RAID im initramfs aktualisieren:

sudo update-initramfs -u -k all

Falls du wieder mal in der BusyBox (die Kommandozeile "initramfs...") landest, könntest du von dort aus nachsehen, ob das RAID läuft (manchmal startet es etwas zu langsam, und der Bootvorgang bricht deshalb ab). Falls ja, könntest du mit den Befehlen

exit 

oder

continue

versuchen, den Bootvorgang fortzusetzen. Falls das RAID nicht, oder nicht richtig läuft, könntest du versuchen, es von Hand zu starten:

sudo mdadm --assemble --scan

oder

sudo mdadm --assemble /dev/mdX /dev/sd... #hier für das X den richtigen Wert und dahinter eine Aufzählung mit den beteiligten Platten in der richtigen Reihenfolge (wie beim Erstellen!) anhängen

Der letzte Befehl ist natürlich nur ein unvollständiges Beispiel, weil ich keine näheren Daten von dir habe. Ich bin mir auch gerade unsicher, ob "sudo" überhaupt nötig ist, bei seltsamen Meldungen einfach mal ohne probieren. Wenn das RAID teilweise läuft (als /dev/md127) muss es vorher gestoppt werden:

sudo mdadm --stop /dev/md127

Die Fehlermeldung mit der "bad partition table" hatte ich noch nicht. Hast du denn überhaupt Partitionen innerhalb des RAID angelegt? Das braucht (und macht) man nämlich normalerweise nicht.

Grüße,

Arno

Hallo Arno, vielen Dank für die schnelle Antwort. Den Befehl mdadm --assemble --scan sowie das manuelle einsammeln mit allen Devices habe ich bereits probiert und es funktioniert. Partitionen auf /dev/md0 bestehen natürlich nicht. Deswegen guckte ich auch so wie eine Kuh wenn es donnert. Ich denke, das Problem liegt darin, dass ich iniramfs nicht geupdated habe. Wenn ich wieder zu Hause bin, werde ich versuchen, den Bootvorgang fortzuführen und dann initramfs upzudaten. Nochmal vielen Dank für die Hilfe. Ich melde mich, wenn ich die Schritte vollzogen habe.

Gruß

Robert

So, habe gerade gebootet. Das Raid ist degraded, da die letzte Platte aus dem Verbund entfernt wurde. Ich habe das RAID neu erstellt und jetzt wird wieder rebuilded. Morgen werde ich sehen, was daraus wird. Dann sollte nach dem Update von initramfs kein Problem mehr bestehen.

Die Daten zu dem RAID:

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sde1[4] sdd1[2] sdc1[1] sdb1[0]
      5860535808 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UUU_]
      [>....................]  recovery =  0.7% (14328752/1953511936) finish=672.0min speed=48089K/sec

unused devices: <none>

sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Sun Jul  8 22:46:31 2012
     Raid Level : raid5
     Array Size : 5860535808 (5589.04 GiB 6001.19 GB)
  Used Dev Size : 1953511936 (1863.01 GiB 2000.40 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Sun Jul  8 22:46:32 2012
          State : clean, degraded, recovering
 Active Devices : 3
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 512K

 Rebuild Status : 0% complete

           Name : RDU-UBUNTU-PC:0  (local to host RDU-UBUNTU-PC)
           UUID : 5a6224b6:b7cfa305:adef93f2:68606797
         Events : 5

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       33        1      active sync   /dev/sdc1
       2       8       49        2      active sync   /dev/sdd1
       4       8       65        3      spare rebuilding   /dev/sde1

Aber um sicherzugehen: Ich habe folgendes eingeben, um das RAID zu stoppen, die Superblocks zu leeren und das RAID neu zu erstellen

sudo mdadm --stop /dev/md0
sudo mdadm --zero-superblock /dev/sdb1
sudo mdadm --zero-superblock /dev/sdc1
sudo mdadm --zero-superblock /dev/sdd1
sudo mdadm --zero-superblock /dev/sde1
sudo mdadm --create --verbose /dev/md0 --auto=yes --level=5 --raid-devices=4 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

Das heißt anschließend sollte "sudo mdadm --detail /dev/md0" auch 4 "active devices" anzeigen, oder? Denn ich habe bei der Erstellung 4 Devices angegeben.

Gruß

Robert

Wieso hast du es denn neu erstellt? Das ist ganz schön riskant, wenn du eine falsche Option erwischst wird durch den Resync alles überschrieben und damit zerstört... macht man also nicht.

Ich hatte das RAID doch sowieso Anfang diesen Monats neu erstellt. Noch sind da keine Daten drauf. Das Backupzurückspielen folgt noch. Ich möchte bloß den Anfang 100%ig haben, damit später nichts schief geht, wenn ich nochmal eine Platte anfüge. Ich habe auch keine resync- oder rebuild-Vorgänge abgebrochen. Die sind immer vollständig durchgelaufen.

Guten Abend,

das RAID ist heute sauber abgeschlossen worden und läuft an sich einwandfrei. Die Lösung meines anfänglichen Problems lag also beim

sudo update-initramfs -u -k all

Danach war das RAID wieder funktionstüchtig. Daher sehe ich dieses Problem als gelöst. Dabei sehr herzlichen Dank an ArnoW.

Trotzdem hat sich eine neue Problematik in diesem Zusammenhang entwickelt. Bei einem Reboot des Servers wird der Verbund entweder "degraded" gestartet, wenn die Option "BOOT_DEGRADED=true" in der Datei "/etc/initramfs-tools/conf.d/mdadm" aktiviert ist, oder ich lande immer in der BusyBox, wenn eben diese Option auf "false" gesetzt wird. Die physikalische Anordnung der Platten sieht wie folgt aus:

0. 2 onboard-SATA-Controller (Intel und JMicron; je 2 SATA-Ports), 1 PCIe x4 Controller (Marvell; 4 SATA-Ports)

1. Systemplatte am ersten Port des ersten onboard-Controllers (sda)

2. Erste RAID-Platte am zweiten Port des ersten onboard-Controllers (sdb)

3. Zweite RAID-Platte am ersten Port des zweiten onboard-Controllers (sdc)

4. Dritte RAID-Platte am zweiten Port des zweiten onboard-Controllers (sdd)

5. Vierte RAID-Platte am ersten Port des PCIe-Controllers (sde)

Meine Vermutung ist, dass der PCIe-Controller nicht schnell genug gestartet wird, daher ist das RAID nach einem Reboot "degraded", weil die letzte (bis jetzt) Festplatte fehlt, oder man bleibt in der BusyBox, bis man fortsetzt. Auf diesem Wege wird wie gesagt allerdings das RAID normal gestartet. Die Firmware des besagten PCIe-Controllers meldet sich auch nicht zwischen POST und Bootvorgang/GRUB, sondern wird erst im laufenden Betriebssystem angezeigt. Die Festplatte /dev/sde wird in jedem Fall nach erfolgreichem Booten erkannt. Hier die Ausgabe aus "sudo mdadm --detail /dev/md0", wenn degraded gebootet wird:

/dev/md0:
        Version : 1.2
  Creation Time : Sun Jul  8 22:46:31 2012
     Raid Level : raid5
     Array Size : 5860535808 (5589.04 GiB 6001.19 GB)
  Used Dev Size : 1953511936 (1863.01 GiB 2000.40 GB)
   Raid Devices : 4
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Mon Jul  9 13:20:01 2012
          State : clean, degraded 
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : RDU-UBUNTU-PC:0  (local to host RDU-UBUNTU-PC)
           UUID : 5a6224b6:b7cfa305:adef93f2:68606797
         Events : 46

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       33        1      active sync   /dev/sdc1
       2       8       49        2      active sync   /dev/sdd1
       3       0        0        3      removed

Ausgabe von "sudo blkid":

/dev/sda1: LABEL="System" UUID="a959513d-75b3-442c-8dde-bff574cf80fd" TYPE="ext4"
/dev/sda2: UUID="d28d5613-55f4-4ff7-9e33-5c1dc59329e1" TYPE="swap"
/dev/sdb1: UUID="5a6224b6-b7cf-a305-adef-93f268606797" UUID_SUB="bb7d0272-e35e-99a7-f542-538002a738fe" LABEL="RDU-UBUNTU-PC:0" TYPE="linux_raid_member"
/dev/sdc1: UUID="5a6224b6-b7cf-a305-adef-93f268606797" UUID_SUB="1cec27a1-6c5f-3245-4f21-efab6267cabd" LABEL="RDU-UBUNTU-PC:0" TYPE="linux_raid_member"
/dev/sdd1: UUID="5a6224b6-b7cf-a305-adef-93f268606797" UUID_SUB="1d028040-dcef-6b70-15c0-521835abd5fc" LABEL="RDU-UBUNTU-PC:0" TYPE="linux_raid_member"
/dev/md0: UUID="de4a54c1-5e26-4b6b-b1dc-6a9d6aca3279" TYPE="ext4"
/dev/sde1: UUID="5a6224b6-b7cf-a305-adef-93f268606797" UUID_SUB="4fd949d5-75a3-59a5-b9ee-e28c1611317f" LABEL="RDU-UBUNTU-PC:0" TYPE="linux_raid_member"

Mir fällt nur auf, dass /dev/md0 vor /dev/sde1 erkannt wird (daher meine o.g. Vermutung). Wenn ich das RAID stoppe und neu einsammle, ist alles wieder in Ordnung. Ist es trotzdem möglich, beim Booten eine Pause einzulegen bzw. das Laden des Kernelmoduls mdadm nach hinten zu verschieben, sodass der Controller bereit ist, wenn das RAID gestartet wird? Oder kann man das automatische Starten des RAIDs verhindern und dann per Startskript, z.B. in der Root-Crontab mit etwas ähnlichem wie "@reboot /sbin/mdadm --assemble --scan", durchführen? Meine Lösungen sind mir selbst allerdings nicht so geheuer und klingen eher nach Pfusch, den ich nicht betreiben möchte. Daher bin ich erneut dankbar für alle Antworten.

Gruß

Robert

Hallo Robert,

schwer zu sagen, was da los ist. Probeweise könntest du mal die Anschlüsse von zwei Platten tauschen, damit mal eine andere an dem Extra-Controller hängt. So kann man sehen, ob das Problem am Controller, oder an der Platte bzw. deren Inhalt liegt.

Ein ähnliches Problem hatte ich mal mit Lucid, als es ganz neu war. Da wurde auch immer wieder mal beim Booten ein RAID nicht gestartet, weil eine Komponente nicht bereit war. Nach ein paar Wochen kam dann irgendein Update, und das Problem war verschwunden.

Von irgendwelchen Spezial-Konfigurationen halte ich nichts. Ein RAID muss von allein sauber laufen, sonst erfüllt es seinen Zweck nicht. Schließlich soll es ja die Verfügbarkeit der Daten erhöhen, und nicht zusätzliche Schwierigkeiten machen.

Grüße, Arno

Hallo Arno,

ich werde morgen in Ruhe mal die Platten durchprobieren, ob sich da eine Veränderung einstellt. Ansonsten warte ich erstmal ab, ob Updates erscheinen, die das Problem beheben. Von solchen Spezialkonfigurationen möchte ich nämlich auch lieber die Finger lassen und gar nicht erst anfangen zu pfuschen. Ich berichte dann morgen Abend.

Gruß

Robert

Also falls das "degraded Raid nach einem Reboot" immer noch ein Problem ist.... Ich hatte das Problem ebenfalls, hier steht eine mögliche Lösung (funktioniert bei mir):

http://linpert.de/2012/04/30/ubuntu-12-04-ist-noch-nicht-reif-fur-meinen-desktop/

/usr/share/initramfs-tools/scripts/mdadm-functions
degraded_arrays()
{
udevadm settle --timeout=30
mdadm --misc --scan --detail --test >/dev/null 2>&1
return $((! $?))
}

sudo update-initramfs -u

Vielen Dank für den Tipp, ich werde das ausprobieren. Allerdings habe ich den Backupserver kurz nach meinem letzten Post angeschmissen und spiele gerade die Dateien zurück (seit Tagen... dank 100 MBit). Ich melde mich, sobald ich damit fertig bin.

Gruß

Robert

So, das Rollback ist vollzogen (endlich). Ich habe die von Meganon vorgeschlagene Änderung vorgenommen, allerdings mit einem Timeout von 20 Sekunden, und es funktioniert alles tadellos. Noch einmal herzlichen Dank an alle Mitwirkenden und ich hoffe, dass dieser Thread anderen Usern helfen wird.

Gruß

Robert