# [gelöst] RAID6 taucht nach Reboot als /dev/md127 auf

## Jimini

Aloha,

eins vorab: ja, ich habe die letzten Tage ausgiebig gegoogelt, Howtos gelesen und mich durch Foren gequält, ohne, dass ich bisher zu einer Lösung gelangt wäre - auch wenn das Problem scheinbar recht verbreitet ist.

Das System beinhaltet folgende Arrays:

```
md8 : active raid6 sda1[0] sdf1[5] sde1[4] sdd1[3] sdc1[2] sdb1[1]

      7814047744 blocks super 1.2 level 6, 512k chunk, algorithm 2 [6/6] [UUUUUU]

md1 : active raid1 sdg1[0] sdh1[1]

      10490304 blocks [2/2] [UU]

md2 : active raid1 sdg2[0] sdh2[1]

      112384 blocks [2/2] [UU]

md3 : active raid1 sdg3[0] sdh3[1]

      4200896 blocks [2/2] [UU]

md5 : active raid1 sdg5[1] sdh5[0]

      41953600 blocks [2/2] [UU]

md6 : active raid1 sdg6[1] sdh6[0]

      20980736 blocks [2/2] [UU]

md7 : active raid1 sdg7[1] sdh7[0]

      234830016 blocks [2/2] [UU]
```

Die Arrays werden beim Boot vom Kernel erkannt und gestartet.

Ich habe mittels mdadm --create /dev/md8 --level=6 --raid-devices=6 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 ein RAID6 aufgesetzt. Nach dem rund 8 Stunden dauernden Syncen war das Array fertig eingerichtet und ich rebootete. Nach dem Reboot tauchte das Array allerdings nicht als /dev/md8, sondern als /dev/md127 auf. Das wäre wohl nur ein kosmetisches Problem, würde das Array nicht nach einem harten Reboot (Kernel Panic) als /dev/md126 gemapped werden. Also ist das gelinde gesagt suboptimal - ich will, dass das Array als /dev/md8 gestartet wird.

Natürlich könnte ich das über einen entsprechenden Eintrag in /etc/mdadm.conf lösen - sobald aber diese Datei vorhanden ist, bekomme ich beim Shutdown den Fehler, dass /dev/md1 nicht gestoppt werden konnte, was für mich etwas ungesund aussieht. Also würde ich das ganze gerne vom Kernel alleine regeln lassen. Wie kann ich festlegen, dass das RAID6 als /dev/md8 gestartet werden soll? 

Im jeweligen Superblock scheint ja hinterlegt zu sein, dass die einzelnen Partitionen zu /dev/md8 gehören:

```
mdadm -Es /dev/sda1

ARRAY /dev/md/8 metadata=1.2 UUID=6e4ffe75:7759053a:0b299dd0:cb6a2a3d name=Atlas:8
```

MfG Jimini

----------

## slick

Ich hatte das auch schonmal mit dem /dev/md127 und habe es gelöst. Ich kann mich aber leider nicht mehr genau daran erinnern was das Problem war und kann daher nur noch mutmaßen.

Hast du die Raids mittels Boot-CD angelegt? Ich meine wenn man (zu verschiedenen Zeitpunkten) mehrere mit der gleichen Nummer anlegt und die beim Booten per Autodetect gestartet werden rutscht dann die doppelte Nummer auf 127 usw. Gab es schonmal ein anderes md8 was jetzt evt. durch den Autodetect zu einer anderen Nummer geworden ist? Ich bin mir ziemlich sicher es hing mit der Reihenfolge der Erstellung zusammen.

Du kannst mal versuchen es nach dem Start wieder zu stoppen und es via 

(aus dem Kopf geschrieben, ohne Gewähr)

```
mdadm --assemble /dev/md8 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 
```

wieder neu zusammen zu setzen. Denke aber das hilft nur für den Moment.

----------

## Jimini

Ich habe zunächst das RAID1 eingerichtet, auf dem das System läuft. Das RAID6 ist nur für NFS-Freigaben da. Es gab vorher definitiv kein md8. Ich bin mir jetzt nicht sicher, ob ich vor dem erstmaligen Erstellen des RAID6 von Hand den Device Node md8 angelegt habe. Um das auszuschließen habe ich gestern die Superblocks des Arrays genullt und das Array neu erstellt, nachdem ich md8 erstellt hatte.

Wenn ich das Array stoppe und von Hand als md8 starte, läuft es natürlich auch als /dev/md8. Natürlich gäbe es die Möglichkeit, sowas mit einem Eintrag in der /etc/conf.d/local.start zu machen, aber dann müsste ich noch das Mounten und das Starten von nfs da reinpacken, was ziemlich unschön wäre.

Schade ist halt, dass ich, wie es scheint, auf die mdadm.conf verzichten muss, sonst wäre das alles ja kein Thema.

MfG Jimini

----------

## schmutzfinger

Man kann dem kern beim booten sagen welche arrays man erstellen will. Das sollte dein Problem lösen aber ist vielleicht nicht wirklich schön wenn die Information doch eigentlich automatisch erkannt werden sollte. Ich habe das bei mir für mein root-raid drinne.

Probier mal sowas in dieser Art als Kernel-Parameter zu übergeben.

```
md=8,/dev/sda1,/dev/sdf1, ...
```

Das muss in die config vom bootloader also bei grub in die "kernel" Zeile.

----------

## Jimini

Ich habe die entsprechende Zeile in der grub.conf wie folgt verändert:

```
kernel (hd0,1)/vmlinuz-2.6.36-gentoo-r8 root=/dev/md1 md=8,/dev/sda1,/dev/sdb1,/dev/sdc1,/dev/sdd1,/dev/sde1,/dev/sdf1
```

Nach einem Reboot hingegen sind die Arrays wie folgt gestartet worden:

```
Personalities : [raid1] [raid6] [raid5] [raid4]                                                                                                                                                                                              

md127 : active (auto-read-only) raid6 sdc1[2] sde1[4] sdb1[1] sdd1[3] sda1[0] sdf1[5]

      7814047744 blocks super 1.2 level 6, 512k chunk, algorithm 2 [6/6] [UUUUUU]

md1 : active raid1 sdg1[0] sdh1[1]

      10490304 blocks [2/2] [UU]

md2 : active raid1 sdg2[0] sdh2[1]

      112384 blocks [2/2] [UU]

md3 : active raid1 sdg3[0] sdh3[1]

      4200896 blocks [2/2] [UU]

md5 : active raid1 sdg5[1] sdh5[0]

      41953600 blocks [2/2] [UU]

md6 : active raid1 sdg6[1] sdh6[0]

      20980736 blocks [2/2] [UU]

md7 : active raid1 sdg7[1] sdh7[0]

      234830016 blocks [2/2] [UU] 

unused devices: <none>  
```

MfG Jimini

----------

## Poison Nuke

und ich dachte schon ich sei der einzige mit dem Problem, dass einfach die ganzen Arrays aufeinmal in md127 usw umbenannt werden.

bei mir ist es die SysresCD (Kernel  2.6.35-std201-amd64), sobald ich diese auf einem System starte, sind ALLE Arrays die vorher md0 und md1 usw hießen, aufeinmal md127, md126 usw. Natürlich sehr ungünstig, weil oftmals sind die Arrays nicht über UUID in der fstab.

hängt es vllt damit zusammen, dass die aktuelle Version von mdadm den Superblock Version 1.2 und nicht 0.9 verwendet?

----------

## Jimini

Das hängt - vermute ich mal - mit der Art des Arrays zusammen. Mein RAID1 verwendet 0.90.00, das RAID6 hingegen 1.2.

MfG Jimini

----------

## Poison Nuke

die bei mir zum Einsatz kommenden RAID1 haben auch 0.90 und werden trotzdem beim hochfahren der LiveCD zu md127 umbenannt   :Crying or Very sad: 

----------

## Jimini

Ich habe mich jetzt entschieden, wie folgt vorzugehen:

- erneutes Erstellen des RAID6, allerdings ohne den Partitionstyp "linux raid autodetect"

- das Eintragen des Arrays in die mdadm.conf

Bisher hielt mich vom Nutzen der mdadm.conf ein Fehler beim Shutdown ab, laut dem /dev/md1 nicht gestoppt werden konnte (worauf / liegt). Laut Neil Brown (Quote) ist das aber ziemlich egal, da der Kernel während des Shutdowns alles ro remountet, was einem Stoppen des Arrays gleichkommt.

Die RAID1-Arrays werden beim Booten dann weiterhin vom Kernel gestartet, während das RAID6 von mdadm zusammengesetzt wird. Das Ding synct gerade, in knapp 8 Stunden weiß ich dann mehr.

Allerdings wird nach Aussage von NeddySeagoon das Starten von Arrays durch den Kernel wohl eines Tages nicht mehr unterstützt werden, wenn ich ihn richtig verstanden habe. Was bedeuten würde, dass der ganze Kram in eine initrd wandern wird, sofern man das System auf dem Array liegen hat.

@ Poison Nuke: was sagt denn ein mdadm -E /dev/sd* | grep 'Preferred Minor'?

MfG Jimini

Nachtrag: ich habe auf den beim RAID6 beteiligten Festplatten jetzt mal gar keine Partitionen erstellt - das eigentlich auch funktionieren. Nur zeigt mir /proc/mdstat jetzt eine Resync-Restdauer von gut 1000 Minuten ab.....hurra. ;)

----------

## Poison Nuke

sehr eigenartig, das eine ist 0, das andere 126 und das dritte 2 bei Prefrerred minor

jetzt verstehe ich gar nix mehr.

edit: warum eigentlich Raid6 in Software? Das ist doch viel zu Rechenlastig und habe auch nicht wirklich Vertrauen in die Stabilität wenn ich ehrlich bin, da hab ich lieber einen schönen 3ware Controller. Bei sovielen Platten macht der den Preis nun auch nicht wirklich fett

----------

## Jimini

 *Poison Nuke wrote:*   

> sehr eigenartig, das eine ist 0, das andere 126 und das dritte 2 bei Prefrerred minor
> 
> jetzt verstehe ich gar nix mehr.

 

Du kannst mal versuchen, die Minor-Nummer zu ändern:

 *man mdadm wrote:*   

> -U, --update=
> 
>     Update the superblock on each device while assembling the array. The argument given to this flag can be one of sparc2.2, summaries, uuid, name, homehost, resync, byteorder, or super-minor.
> 
> [...]
> ...

 

Allerdings weiß ich nicht, ob das Auswirkungen auf den Datenbestand auf den Platten hat. Du kannst es ja erstmal mit einem weniger heiklen Array (/boot oder swap) testen.

 *Quote:*   

> edit: warum eigentlich Raid6 in Software? Das ist doch viel zu Rechenlastig und habe auch nicht wirklich Vertrauen in die Stabilität wenn ich ehrlich bin, da hab ich lieber einen schönen 3ware Controller. Bei sovielen Platten macht der den Preis nun auch nicht wirklich fett

 

Die bei der Paritätenberechnung anfallende CPU-Last kann man heutzutage definitiv vernachlässigen. In dem System steckt ein Athlon II X2 240e, der die meiste Zeit auf 800 MHz idlet. Die 6 Platten haben knapp 400 € gekostet, die Controllerpreise fangen bei etwa 350 € an. Soviel Geld hatte ich dann doch nicht über ;)

Zudem stehe ich mehr drauf, wenn ich ein RAID selber verwalten kann. Wenn dann was kaputtgeht, bin höchstwahrscheinlich ich dafür verantwortlich und nicht irgendwas im Controller, was ich nicht nachvollziehen kann.

MfG Jimini

----------

## Poison Nuke

naja, aber jedesmal das Array reassemblen ist ja auch nicht Sinn, ich hab ein paar mehr Server wo meist ein RAID1 läuft und sobald man dann die aktuelle SysresCD bootet kommt dann alles durcheinander, und da man an einigen Stellen nicht mit UUIDs arbeiten kann, ist das immer recht viel Fummelei. 

Wäre irgendwie schöner wenn man die Ursache herausfinden könnte, um zu verhindern dass es überhaupt erst passiert.

----------

## Jimini

Wenn es dir weiterhilft, kann ich später mal meinen alten Fileserver mit der SysResc-CD booten. Dort laufen ein paar gespiegelte Arrays, das Setup ist deinem also recht ähnlich.

MfG Jimini

----------

## root_tux_linux

Das hatten wir schon mal, einfach den Superblock updaten.

```

mdadm --update=super-minor /dev/md0 /dev/sda1 /dev/sdb1 usw usf.

```

----------

## Jimini

 *root_tux_linux wrote:*   

> Das hatten wir schon mal, einfach den Superblock updaten.
> 
> ```
> mdadm --update=super-minor /dev/md0 /dev/sda1 /dev/sdb1 usw usf.
> ```
> ...

 

Um das auszuschließen, habe ich das gerade nochmal gemacht (allerdings fehlte bei dir noch ein -A) - ohne Erfolg. Ich habe das Array in die mdadm.conf eingetragen:

```
DEVICE /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf

ARRAY /dev/md8 devices=/dev/sda,/dev/sdb,/dev/sdc,/dev/sdd,/dev/sde,/dev/sdf
```

Allerdings:

```
Personalities : [raid1] [raid6] [raid5] [raid4] 

md8 : inactive sde[4](S) sdd[3](S) sda[0](S)

      5860540680 blocks super 1.2
```

Wenn ich das Array stoppe und neu starte (mdadm -A /dev/md8), funktioniert alles. Ich kapier' das einfach nicht.

MfG Jimini

----------

## Jimini

@ Poison Nuke: hilft dir dieses Posting weiter?

Ich weiß nicht, woran es liegt, aber das Array scheint jetzt korrekt als md8 gestartet zu werden, auch über mehrere Reboots hinweg.

Die beteiligten Festplatten sind nicht formatiert, das Array ist in der /etc/mdadm.conf eingetragen, zusätzlich habe ich die grub.conf um einen entsprechenden Parameter ergänzt. Ich hoffe, dass das jetzt wirklich dauerhaft funktioniert und nicht dann urplötzlich Probleme auftreten, wenn das Array mit den Daten des alten Fileservers gefüttert wurde.

MfG Jimini

----------

## Poison Nuke

 *Jimini wrote:*   

> @ Poison Nuke: hilft dir dieses Posting weiter?

 

es scheint zumindest eine Erklärung zu sein, dass wohl bei einem abweichenden Hostnamen das Array umbenannt wird. Man müsste also die LiveCD in dem Fall mit dem gleichen Hostname hochfahren wie das eigentliche System das auf dem md läuft. Nur das macht sich ja natürlich etwas schwer. 

Seit wann eig. überhaupt der Hostname im array gespeichert   :Confused: 

----------

## Jimini

Der Grund ist wahrscheinlich der, dass, sobald das Array in einem (laut Hostnamen) anderen System gestartet wird, es einen freien Device Node sucht, um nicht möglicherweise vorhandene Arrays zu stören. Zudem erleichtert diese "Markierung" irgendwo sicherlich auch die Identifizierung und Zuordnung von Arrays.

MfG Jimini

----------

## Jimini

 *Jimini wrote:*   

> Ich weiß nicht, woran es liegt, aber das Array scheint jetzt korrekt als md8 gestartet zu werden, auch über mehrere Reboots hinweg.
> 
> Die beteiligten Festplatten sind nicht formatiert, das Array ist in der /etc/mdadm.conf eingetragen, zusätzlich habe ich die grub.conf um einen entsprechenden Parameter ergänzt. Ich hoffe, dass das jetzt wirklich dauerhaft funktioniert und nicht dann urplötzlich Probleme auftreten, wenn das Array mit den Daten des alten Fileservers gefüttert wurde.
> 
> MfG Jimini

 

Nach dem x-ten Neustart wurde das Array wieder nicht gestartet, da sda und sdd laut /proc/mdstat inaktiv waren. Also erstellte ich es NOCHMAL neu, diesmal allerdings nur mit vier der sechs Festplatten (um das Syncen zumindest etwas zu verkürzen), was auch nichts brachte:

```
Personalities : [raid1] [raid6] [raid5] [raid4] 

md126 : inactive sdb1[1](S) sdd1[3](S)

      3907025072 blocks super 1.2

       

md127 : inactive sdc1[2](S) sda1[0](S)

      3907025072 blocks super 1.2
```

Ich werde jetzt mal alle beteiligten sechs Festplatten mittels dd "nullen", und es dann nochmal angehen. Ist es eigentlich egal, ob die Festplatten partitioniert sind oder nicht? Ich habe da irgendwie keine einheitlichen Informationen finden können.

MfG Jimini

----------

## schmutzfinger

Ich habe jetzt nicht alles gelesen aber will trotzdem nochmal meinen Senf dazugeben. Mein Desktop hat / auf dem Raid1. Wie sich dieses Array zusammensetzt und dass es md0 sein soll steht in meiner Bootloader-Config als Kernel-Parameter. Zusätzlich stehen alle Arrays (inklusive /) in der mdadm.conf. Das mdadm init-script von gentoo bringt beim reboot oder shutdown einen Fehler weil es das / Array nicht stoppen kann. Aber das ist wie schon gesagt kein Problem und kann ignoriert werden. Alle anderen Arrays werden ordentlich angehalten. Der Partitionstyp ist bei allen meinen Arrays linux-raid-autodetect.

Hier noch ein paar Vermutungen:

Ich vermute mal, dass man dem Kern das autodetect per Parameter abgewöhnen kann. Damit hättest du den Partitionstyp so lassen koennen und die mdadm.conf benutzen koennen. Dann muss aber natuerlich das / Array auch mit Kernelparametern beschrieben werden.

Vielleicht hat die mdadm.conf auch Vorrang über autodetect und sorgt dafür, dass ein falsch erkanntes Array entsprechend der config zusammengesetzt wird. Ich würde sogar vermuten, dass die Array-Nummer garnicht per autodetect erkannt wird. Seid ihr euch sicher, dass die Information in den Metadaten drinne steckt?

Und dann hätte ich noch udev im Verdacht. Vielleicht erkennt der Kern das schon alles richtig und es gibt ne udev-Regel, die das Array umbenennt.

----------

## schmutzfinger

Wie schon vermutet kann man das autodetect abschalten, siehe dazu file:///usr/src/linux/Documentation/md.txt. Dort steht auch das sysfs-Interface ausführlich beschrieben. Vielleicht findet sich ja da eine Lösung für das Problem.

----------

## Jimini

Vielen Dank für deine Erläuterungen. Ich bin in der Zwickmühle, dass ich CONFIG_MD_AUTODETECT nutzen muss, da das System selbst auf 6 Mirroring-Arrays (RAID1) liegt. Und der Kernel baut darüber hinaus auch das RAID6 zusammen, egal ob ich Partitionen erstellt habe und wenn, ob diese vom Typ "Linux" oder "Linux RAID Autodetect" sind. Ich habe zuletzt alle sechs Festplatten mittels dd "genullt" und dann das Array noch einmal erstellt - ohne Erfolg. Dann aber entweder als md127 oder verteilt auf md126 UND md127:

```
When the array had finished syncing, I rebooted. /proc/mdstat contained

   md126 : inactive sde1[4](S) sdd1[3](S)

         3907025072 blocks super 1.2

   md127 : inactive sdb1[1](S) sda1[0](S) sdc1[2](S) sdf1[5](S)

         7814050144 blocks super 1.2
```

Oder auch als md8:

```
   Personalities : [raid1] [raid6] [raid5] [raid4]

   md8 : inactive sda1[0](S)

         1953512536 blocks super 1.2
```

Teilweise funktioniert aber auch alles normal, wie nach dem letzten Reboot.

So wie ich das verstehe, steckt im Superblock schon drin, unter welchem Devicenamen das Array gestartet werden soll:

```
Atlas ~ # mdadm -E /dev/sd[a,b,c,d,e,f]1 | grep Name

           Name : Atlas:8  (local to host Atlas)

           Name : Atlas:8  (local to host Atlas)

           Name : Atlas:8  (local to host Atlas)

           Name : Atlas:8  (local to host Atlas)

           Name : Atlas:8  (local to host Atlas)

           Name : Atlas:8  (local to host Atlas)
```

Etwas à la udev hatte ich auch schon im Verdacht - ich habe allerdings nur Regeln für die NICs und VirtualBox unter /etc/udev/rules.d liegen.

Ich werde es jetzt wohl so machen, dass ich mir eine initrd bastel, alle Arrays darüber starten lasse und dann die Autodetection abschalte. Ich HASSE es zwar, weil es bei mir generell Stunden dauert, so ein Ding ans Laufen zu bekommen, aber das hätte den positiven Nebeneffekt, dass ich nicht mehr auf die irgendwann wegfallende Autodetection im Kernel angewiesen bin.

Die von dir genannte Readme werde ich mir aber dennoch mal zu Gemüte führen.

MfG Jimini

P.S.: ich habe ebenfalls auf der linux-raid-Mailingliste Hilfe gesucht, bin aber auch dort noch nicht wirklich weitergekommen.

----------

## Jimini

Ich habe das Problem gestern endlich dadurch lösen können, dass ich eine initrd gebaut habe, welche alle Arrays startet. Auch wenn es letztendlich mehr Aufwand war als beispielsweise das Assemblen dem Kernel zu überlassen - die Mühe hat sich definitiv gelohnt. Die Vorgehensweise ist in diesem Thread beschrieben.

Danke an alle Vorschläge und Anregungen!

MfG Jimini

----------

