[gelöst] softraid devices werden nach Neustart umbenannt

[r4pt0r]

Ich verzweifle seit gestern mit der Einrichtung eines Software-raid...

Ausgangspunkt sind 2x 500GB platten. /dev/sda wurde partitioniert, partitionstabelle per sfdisk auf /dev/sdb übertragen und dann die raid-devices eingerichtet:

Code: Alles auswählen

mdadm --create /dev/md0 --level=mirror --raid-devices=2 /dev/sda1 /dev/sdb1
mdadm --create /dev/md1 --level=stripe --raid-devices=2 /dev/sda2 /dev/sdb2
mdadm --create /dev/md2 --level=mirror --raid-devices=2 /dev/sda3 /dev/sdb3

md0 = boot
md1 = swap (als stripe)
md2 = LVM

Alle 3 liefen danach sauber (active) und das system wurde ohne fehler per debootstrap installiert, fstab angelegt, kernel installiert, grub2 auf sda1/2 geschrieben und durchgestartet - die Kiste bootet aber nicht durch.
Im Rettungssystem sehen dann die raid-devices folgendermaßen aus:

Code: Alles auswählen

# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty] 
md125 : active (auto-read-only) raid1 sda3[0] sdb3[1]
      479763328 blocks super 1.2 [2/2] [UU]
        resync=PENDING
      
md126 : active (auto-read-only) raid1 sda1[0] sdb1[1]
      102272 blocks super 1.2 [2/2] [UU]
      
md127 : active raid0 sda2[0] sdb2[1]
      16776192 blocks super 1.2 512k chunks
      
unused devices: <none>

Die Reihenfolge ist völlig willkürlich - ich könnte das System also nichtmal auf 125/6/7 umbiegen, da beim nächsten Start die Bezeichner wieder anders vergeben werden.

Ich habe die arrays jetzt schon zum x-ten male gestoppt, neu mit den korrekten Bezeichnungen gestartet, Einträge in der /etc/mdadm/mdadm.conf aktualisiert + update-initramfs -u

Auszug der mdadm.conf:

Code: Alles auswählen

ARRAY /dev/md/0 UUID=3b43ded8:c3413343:7f654019:edacb78c
ARRAY /dev/md/1 UUID=d0fc5cb3:4543d3e4:f6b60cb2:374e2084
ARRAY /dev/md/2 UUID=9d6f5c6f:9e594fd0:16a99873:98ad1480

mdadm --examine --scan gibt mir auch die korrekten arrays aus (auch direkt nach dem start ins rettungssystem wenn wieder auf 125/6/7 gemappt wurde!):

Code: Alles auswählen

# mdadm --examine --scan
ARRAY /dev/md/0  metadata=1.2 UUID=3b43ded8:c3413343:7f654019:edacb78c name=localhost:0
ARRAY /dev/md/1  metadata=1.2 UUID=d0fc5cb3:4543d3e4:f6b60cb2:374e2084 name=localhost:1
ARRAY /dev/md/2  metadata=1.2 UUID=9d6f5c6f:9e594fd0:16a99873:98ad1480 name=localhost:2

Trotzdem werden immer die devices md125-127 angelegt und er bootet logischerweise nicht... Die mdadm.conf wird völlig ignoriert. Ich kann die Datei komplett leeren oder die gesammelten Werke von Shakespeare reinschreiben - es gibt keine Fehlermeldungen und das System legt die Arrays bei jedem Start zufällig auf 125-127.

Die Arrays sind übrigens völlig "gesund" - md2 beinhaltet ein LVM dessen LVs korrekt erkannt werden und deren Inhalt auch intakt ist. (warum er sd[ab]3 jetzt plötzlich neu bauen will ist mir schleierhaft, ich lass ihn einfach mal...)


Hat jemand eine Idee dazu?

[mragucci]

Schuss ins Blaue: initramfs nicht neu gebaut?
Edit: etwa so:

Code: Alles auswählen

sudo update-initramfs -k all -u

[r4pt0r]

Ich habe die arrays jetzt schon zum x-ten male gestoppt, neu mit den korrekten Bezeichnungen gestartet, Einträge in der /etc/mdadm/mdadm.conf aktualisiert + update-initramfs -u?

Was mir aber noch eingefallen ist: "muss" das Rettungssystem zwangsweise die selben Bezeichner erkennen? Meinem Verständnis nach ist das doch im Superblock (?) hinterlegt, daher auch der Aufwand mit Umbenennen von Arrays auf platten, die in andere Systeme mit bestehenden Arrays verpflanzt werden.

Mal angenommen das per debootstrap/chroot installierte System würde beim booten korrekt reagieren (md0-2 anlegen) und nur das rettungssystem baut mist: Da keinerlei logs geschrieben werden scheitert der bootvorgang auf jeden fall vor/beim einbinden der Dateisysteme - fehlt dem grub evtl etwas?

device.map:

Code: Alles auswählen

(hd0)   /dev/disk/by-id/ata-ST3500418AS_5VM9PEJM
(hd1)   /dev/disk/by-id/ata-ST3500418AS_5VM9PCHN

grub.cfg:
http://nopaste.info/de115618b6.html

raid, mdraid1x und lvm werden geladen, uuids passen auch auf sda1/sdb1. Sieht für mich sauber und bootfähig aus...


Beim updaten des initramfs waren die korrekten Bezeichner md0-2 in der mdadm.conf hinterlegt, das chroot-system hatte diese auch korrekt auf md0-2 eingebunden und es war keine Spur von 125/6/7 zu finden. Daher *vermute* ich jetzt mal, dass im initramfs auch alles passt - daher die Idee das der grub an irgendwas scheitert...

Evtl aktiviere ich heute abend nen alten PC und stelle das mit angeschlossenem monitor nochmal nach - dann weiß ich zumindest woran es wirklich hängt. Gemäß murphy wirds dort dann sicherlich einwandfrei laufen

[mragucci]

Ich habe die arrays jetzt schon zum x-ten male gestoppt, neu mit den korrekten Bezeichnungen gestartet, Einträge in der /etc/mdadm/mdadm.conf aktualisiert + update-initramfs -u?

Ach, so versteckt zwischen den vielen Zeilen ist aber auch unfair
Hab Deine grub.cfg mit meiner verglichen, habe allerdings kein LVM am Start. Bei mir wird das

Code: Alles auswählen

set root='(mduuid/3b43ded8c34133437f654019edacb78c)' 

ohne Klammern verwendet, also

Code: Alles auswählen

set root='mduuid/3b43ded8c34133437f654019edacb78c' 

Bei mir wird auch ein anderes raidmodul geladen, und eine device.map gibt es auf meinem System auch nimma. Statt dessen werden im grub und der fstab rein uuids verwendet... Wodurch wir auch zum Thema fstab kommen: die mal gecheckt?

Ansonsten wäre eine Fehlermeldung, direkt vom Monitor abgelesen, natürlich schon gut, dann können wir die Kristallkugel wieder in die Ecke legen

[r4pt0r]

Ja, die Fehlermeldung wünsche ich mir auch - da der Server aber nicht zwingend bis datum X laufen muss möchte ich mir vorerst die 25€ für den VNC-Zugriff nur zum ablesen einer Fehlermeldung sparen
Logdateien von Grub wären nett

Installiert ist grub2:

Code: Alles auswählen

# dpkg -l | grep grub
ii  grub-common                        1.99-27+deb7u2             amd64        GRand Unified Bootloader (common files)
ii  grub-pc                            1.99-27+deb7u2             amd64        GRand Unified Bootloader, version 2 (PC/BIOS version)
ii  grub-pc-bin                        1.99-27+deb7u2             amd64        GRand Unified Bootloader, version 2 (PC/BIOS binaries)
ii  grub2                              1.99-27+deb7u2             amd64        GRand Unified Bootloader, version 2 (dummy package)
ii  grub2-common                       1.99-27+deb7u2             amd64        GRand Unified Bootloader (common files for version 2)

Die "set root" Einträge in der grub.cfg sind auf sämtlichen gerade erreichbaren Systemen ebenfalls im Format '(...)'.
Das einzige System das ebenfalls ein softraid nutzt bootet leider nicht vom softraid - war unter etch IIRC noch nicht möglich und aus der Zeit stammt das System noch (immer nur per dist-upgrade auf die nächste stable gezogen...). Kann daher nicht vergleichen ob der Eintrag mit "mmuid/..." auch anders gebaut sein könnte...

Das Rettungssystem nutzt Kernelversion 3.12.5 - installiert am System wird der aktuelle stable-kernel (3.2.0.4). Beißt sich das evtl? Habe zwar schon von Rettungs/Livemedien mit 2.6er Kernel per debootstrap debian mit 3.x Kernel installiert, aber noch nie mit neuerem Kernel ein System mit älterem...


edit:
mir ist aufgefallen, dass die UUIDs die teilweise in der grub.cfg stehen nicht zu /dev/sda1/sdb1 oder dm0 passen (3b43ded8-c341-3343-7f65-4019-edacb78c). manuell in der grub.cfg geändert -> trotzdem nichts...

[mragucci]

Das mit den UUIDs würd ich wieder rückgängig machen. Muss das lvm Modul eventuell noch geladen werden?

Code: Alles auswählen

ARRAY /dev/md/0

ist zwar auch die Ausgabe vom mdadm, ich bin aber immer gut gefahren mit

Code: Alles auswählen

ARRAY /dev/md0

Vielleicht könntest Du noch die komplette mdadm.conf posten?

LG

[r4pt0r]

So, das ganze wurde an ner VM nochmal 1:1 nachgestellt (mit systemrescuecd 4.0.1 beta, war das einzige mit 3.1x kernel das ich auf die schnelle finden konnte).

Ergebnis:






Ich werds jetzt nochmal auf dem rootserver probieren - wenns wieder nicht hinhaut kann es fast nur noch daran liegen, dass das topaktuelle Rettungssystem irgendwas baut, was grub2, lvm2 oder mdadm aus wheezy nicht mehr frisst - dann werde ich die gewünschte Installation auf ner VM einrichten und das image dann auf den Server übertragen...

[r4pt0r]

Da mir das ganze keine Ruhe gelassen hat habe ich noch etwas in einer VM getestet - des Rätsels Lösung ist der mdadm.

Wird nach dem debootstrap zuerst der Kernel und dann mdadm + lvm2 installiert, wird der mdadm auch konfiguriert - installiert man diese pakete zuerst und dann erst den kernel, bleibt mdadm unkonfiguriert und wandert dann scheinbar auch nicht ins initramfs.
Die Reihenfolge ist völlig egal wenn man einfach nochmal ein dpkg-reconfigure auf mdadm und lvm2 loslässt - danach nochmal ein grub-install --recheck und update-grub und es läuft.