[Gelöst] RAID/mdadm, nach Kernel update System bootet nicht

[R0nin]

Das Problem:

nach dem Kernelupdate von 2.6.38-bpo.2-amd64 auf 3.2.0-0.bpo.3-amd64 booted mein System nicht mehr. Raid1 == /dev/md0 wird anscheinend
nicht gefunden. Nachdem ich in GRUB-Menü den 3.2.0-0.bpo.3-amd64 Eintrag auswähle kommt die Meldung:

Code: Alles auswählen

mdadm: Devices UUID-7a140585:a601a93a:a6265560:0120df65 and
UUID-7a140585:a601a93a:a6265560:0120df65 have the same name: /dev/md/0
mdadm: Duplicate MD device names in conf file were found.
Gave up waiting for root device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/disk/by-uuid/c5bf7b81-f808-4bf7-b554-f7bc2d6c0479 does not exist
Dropping to shell!

Das System mit 2.6.38-bpo.2-amd64 lässt sich aber noch booten.

Verwandtes Problem habe ich hier gefunden: http://debianforum.de/forum/viewtopic.p ... +vorhanden
hilft mir leider nicht weiter (bzw. hier verstehe ich den letzten Eintrag nicht).
Eben noch das hier gefunden: http://debianforum.de/forum/viewtopic.p ... 0&start=15
Kann aber nicht auf mich zutreffen, weil ich keine SAS-Platten habe. Werde aber gleich noch mal den Befehl
"mdadm --assemble --scan && exit" ausprobieren.

Hat jemand eine Idee oder Hinweis, evtl. habe ich etwas übersehen?
MfG R0nin

P.S. weiter unten noch ein paar Angaben zu meinem System.

Angaben zum System (unter dem lauffähigen 2.6.38-bpo.2-amd64):

GRUB: 1.98+20100804-14+squeeze1

Code: Alles auswählen

lsb_release -a

LSB Version:
core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:qt4-3.1-amd64:qt4-3.1-noarch
Distributor ID: Debian
Description: Debian GNU/Linux 6.0.6 (squeeze)
Release: 6.0.6
Codename: squeeze

Code: Alles auswählen

sudo mdadm --detail --scan
ARRAY /dev/md/0 metadata=1.2 name=vdrServer:0 UUID=7a140585:a601a93a:a6265560:0120df65

Code: Alles auswählen

sudo mdadm --detail /dev/md0

/dev/md0:                                                                                     
Version : 1.2                                                                  
  Creation Time : Sat Oct 22 21:52:50 2011                                                  
Raid Level : raid1                                                                     
Array Size : 488280090 (465.66 GiB 500.00 GB)
  Used Dev Size : 488280090 (465.66 GiB 500.00 GB)   
Raid Devices : 2 
Total Devices : 2   
Persistence : Superblock is persistent
   
Update Time : Wed Oct 24 22:22:34 2012
  State : clean  
Active Devices : 2
Working Devices : 2 
Failed Devices : 0 
Spare Devices : 0
           Name : vdrServer:0  (local to host vdrServer)
           UUID : 7a140585:a601a93a:a6265560:0120df65     
   Events : 933

    Number   Major   Minor   RaidDevice State
       0       8       18        0      active sync   /dev/sdb2
       1       8        2        1      active sync   /dev/sda2

Code: Alles auswählen

/dev/disk/by-uuid$ ls -al

insgesamt 0
drwxr-xr-x 2 root root 120 5. Nov 22:20 .
drwxr-xr-x 5 root root 100 5. Nov 22:20 ..
lrwxrwxrwx 1 root root 10 5. Nov 22:20 5efaf2d5-b2a7-4aca-99cc-03933d59f72b -> ../../sdb4
lrwxrwxrwx 1 root root 10 5. Nov 22:20 75233951-7a83-40ea-a974-86f78a07c673 -> ../../sdb3
lrwxrwxrwx 1 root root 9 5. Nov 22:20 c5bf7b81-f808-4bf7-b554-f7bc2d6c0479 -> ../../md0
lrwxrwxrwx 1 root root 10 5. Nov 22:20 df19ee84-ca1c-446a-9e84-1496cba50c91 -> ../../sda3

Code: Alles auswählen

blkid

/dev/sdb2: UUID="7a140585-a601-a93a-a626-55600120df65" LABEL="vdrServer:0" TYPE="linux_raid_member"
/dev/sda2: UUID="7a140585-a601-a93a-a626-55600120df65" LABEL="vdrServer:0" TYPE="linux_raid_member"
/dev/sda3: UUID="df19ee84-ca1c-446a-9e84-1496cba50c91" TYPE="ext4"
/dev/sdb3: UUID="75233951-7a83-40ea-a974-86f78a07c673" TYPE="swap"
/dev/sdb4: UUID="5efaf2d5-b2a7-4aca-99cc-03933d59f72b" TYPE="ext4"
/dev/md0: UUID="c5bf7b81-f808-4bf7-b554-f7bc2d6c0479" TYPE="ext3" 

Angaben zum System (unter dem nicht lauffähigen 3.2.0-0.bpo.3-amd64):

Code: Alles auswählen

/dev/disk/by-uuid$ ls -al

insgesamt 0
drwxr-xr-x 2 root root 120 5. Nov 22:20 .
drwxr-xr-x 5 root root 100 5. Nov 22:20 ..
lrwxrwxrwx 1 root root 10 5. Nov 22:20 5efaf2d5-b2a7-4aca-99cc-03933d59f72b -> ../../sdb4
lrwxrwxrwx 1 root root 10 5. Nov 22:20 75233951-7a83-40ea-a974-86f78a07c673 -> ../../sdb3
lrwxrwxrwx 1 root root 10 5. Nov 22:20 df19ee84-ca1c-446a-9e84-1496cba50c91 -> ../../sda3

Code: Alles auswählen

blkid

/dev/sdb2: UUID="7a140585-a601-a93a-a626-55600120df65" LABEL="vdrServer:0" TYPE="linux_raid_member"
/dev/sdb3: UUID="75233951-7a83-40ea-a974-86f78a07c673" TYPE="swap"
/dev/sdb4: UUID="5efaf2d5-b2a7-4aca-99cc-03933d59f72b" TYPE="ext4"
/dev/sda2: UUID="7a140585-a601-a93a-a626-55600120df65" LABEL="vdrServer:0" TYPE="linux_raid_member"
/dev/sda2: UUID="df19ee84-ca1c-446a-9e84-1496cba50c91" TYPE="ext4"

Fazit: hier fehlt überall der md0 Eintrag.

[Cae]

Zunaechst einmal ein Lob, ich kann die Unterueberschriften auch aus fuenf Metern Entfernung problemlos entziffern.

Dann zum Problem, falls der Kernel eine initial ramdisk (initrd, initramfs) einsetzt, kann es gut sein, dass der darin sitzende mdadm bzw. seine /etc/mdadm/mdadm.conf nix von dem RAID weiss.

Das solltest du temporaer in der Fallback-Shell beheben koennen: Zunaechst mit # cat /etc/mdadm/mdadm.conf pruefen, ob hier ein ARRAY-Eintrag auftaucht. Ich nehme an, dies ist nicht der Fall. Dann kannst du mit # mdadm --detail --scan >>/etc/mdadm/mdadm.conf die Konfiguration ergaenzen und schliessend mit # mdadm --assemble --scan das RAID starten. Dann muesstest du eigentlich schon booten koennen, dazu mit # exit die Shell verlassen und gucken, ob die Box hochfaehrt.

Sofern der Fall, schaust du nach, ob sich die ARRAY-Zeile aus der /etc/mdadm/mdadm.conf mit dem Output von # mdadm --detail --scan deckt. Dies sollte der Fall sein (nicht wundern, die mdadm.conf in der initrd und die jetzt sind nicht dieselben Dateien). Danach kannst du mit # update-initramfs -u die initrd fuer den laufenden 3.2er Kernel neu bauen und danach probebooten.

Gruss Cae

[R0nin]

Cae, danke für die schnelle Antwort. Bin aber leider nicht weitergekommen. Hier das Ergebnis:

Code: Alles auswählen

cat /etc/mdadm/mdadm.conf
DEVICE partitions
ARRAY /dev/md/0 metadata=1.2 name=vdrServer:0 UUID=7a140585:a601a93a:a6265560:0120df65
HOMEHOST <system>
ARRAY /dev/md/0 metadata=1.2 UUID=7a140585:a601a93a:a6265560:0120df65 name=vdrServer:0

# mdadm --detail --scan >>/etc/mdadm/mdadm.conf ändert an der mdadm.conf nichts.
# mdadm --assemble --scan und #exit liefern:

Code: Alles auswählen

mdadm --assemble --scan
mdadm: Devices UUID-7a140585:a601a93a:a6265560:0120df65 and
UUID-7a140585:a601a93a:a6265560:0120df65 have the same name: /dev/md/0
mdadm: Duplicate MD device names in conf file were found.

exit
Gave up waiting for root device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/disk/by-uuid/c5bf7b81-f808-4bf7-b554-f7bc2d6c0479 does not exist
Dropping to shell!

Das system kann ich dann mit reboot neustarten. An der Fehlermeldung ändert sich aber nichts.
Zusammenfassend kann man sagen, dass die letzten beiden Einträge genau die Fehlermeldung beim Bootvorgang liefern. Hier noch meine fstab evtl. hilft das weiter:

Code: Alles auswählen

/etc$ cat fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# / was on /dev/md0 during installation
UUID=c5bf7b81-f808-4bf7-b554-f7bc2d6c0479 /               ext3    errors=remount-ro 0       1
# /data1 was on /dev/sda4 during installation
UUID=5efaf2d5-b2a7-4aca-99cc-03933d59f72b /data1          ext4    defaults        0       2
# /data2 was on /dev/sdb3 during installation
UUID=df19ee84-ca1c-446a-9e84-1496cba50c91 /data2          ext4    defaults        0       2
# swap was on /dev/sda3 during installation
UUID=75233951-7a83-40ea-a974-86f78a07c673 none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0                  
/dev/sdc1       /media/usb0     auto    rw,user,noauto  0       0

wenn ich das richtig sehe kann beim Booten die UUID=c5bf7b81-f808-4bf7-b554-f7bc2d6c0479 nicht gefunden werden.
Noch eine Idee?
MfG R0nin

[Cae]

# mdadm --detail --scan >>/etc/mdadm/mdadm.conf ändert an der mdadm.conf nichts.

Naja, immerhin beschwert er sich nun ueber duplizierte Eintraege:

Code: Alles auswählen

mdadm --assemble --scan
mdadm: Devices UUID-7a140585:a601a93a:a6265560:0120df65 and
UUID-7a140585:a601a93a:a6265560:0120df65 have the same name: /dev/md/0
mdadm: Duplicate MD device names in conf file were found.

Aber halt! Das war oben auch schon; und das ist der Fehler. Hab' ich ueberlesen. Also schnippeln wir die letzte Zeile da raus:

Code: Alles auswählen

initrd# cp /etc/mdadm/mdadm.conf mdadm.conf.tmp
initrd# head -n-1 mdadm.conf.tmp >/etc/mdadm/mdadm.conf

Es kann jetzt gut sein, dass die Syntax -n-1 eine dieser verdammten ungekennzeichneten GNU-Erweiterungen ist, denn die Live BusyBox [1] frisst das nicht. Aber einen awk hat sie, also schreiben wir anstatt der head-Zeile

Code: Alles auswählen

initrd# awk 'NR<4' mdadm.conf.tmp >/etc/mdadm/mdadm.conf

(Evtl. elegantere, aber schreibaufwaendigere Alternative [2].) Bitte vorher nochmal mit # wc -l mdadm.conf.tmp kontrollieren, ob die Datei gerade tatsaechlich vier Zeilen hat. Falls nicht, die 4 durch die entsprechende Zahl ersetzen.

Anschliessend sollte dir # cat /etc/mdadm/mdadm.conf nur die eine ARRAY-Zeile liefern. Dann kannst du wieder das --assemble anstrossen und schauen, ob nach exit die Meldung mit duplizierten Device-Namen bleibt (sollte sie nicht). Sofern das System dann bootet, ggf. wie oben beschrieben die "richtige" mdadm.conf fixen und update-initramfs fahren.

Gruss Cae

[1] http://busybox.net/live_bbox/live_bbox.html
[2] andere Idee:

Code: Alles auswählen

# awk '/^ARRAY/{if(i++)exit}{print}' mdadm.conf.tmp >/etc/mdadm/mdadm.conf

Das ignoriert alle weiteren Zeilen mit dem zweiten Auftreten von ARRAY am Zeilenanfang.

[R0nin]

Habe folgendes durchgeführt:

#cp /etc/mdadm/mdadm.conf mdadm.conf.tmp
#awk 'NR<4' mdadm.conf.tmp >/etc/mdadm/mdadm.conf

Die Datei /etc/mdadm/mdadm.conf enthält die letzte Zeile nicht mehr
dann...

#mdadm --assemble --scan
mdadm: /dev/md/0 has been started with 2 drives.
#exit
INIT: version 2.88 booting
....

System bootet
Da meine "richtige" mdadm.conf den doppelten Eintrag nicht hatte, habe ich noch

#update-initramfs -vu

ausgeführt und siehe da - das System lässt sich jetzt normal booten.
@Cae: An der Stelle noch mal vielen Dank für die exakten Anweisungen und sehr gute Beschreibungen.


MfG R0nin

[DebianWithCrunch]

Auch wenn der Beitrag schon ein paar Tage alt ist, wollte ich mal DANKE sagen!
Cae für die vielen Anregungen und besonders R0nin das Problem gehabt zu haben (sonst wäre ich ja nicht hier gelandet) und vor allem dafür, dass Du ganz genau aufgeschrieben hast, was Du von den Lösungsvorschlägen von Cae eingegeben hast!

Ich hatte so etwas ähnliches, nachdem ich ein verschlüsseltes crunchbang11 mit SoftwareRAID1, LUKS und 2x Swap aufgesetzt habe.
Nach dem Setup hatte ich ebenfalls ein doppeltes /dev/md0 (vielleicht war es auch md1). Irgendwie hat er die beiden Swap-Partitionen ebenfalls als RAID1 interpretiert und mal eben einen vorhandenen Eintrag benutzt. (Konnte das Problem im Nachhinein auch an einer VM hervorrufen.)

Als absoluter LinuxRookie hatte ich natürlich erstmal überhaupt keinen Plan.
Es hat auch ungefähr eine Stunde gedauert, bis ich mehr oder weniger nachvollziehen konnte, was ihr so gemacht habt und wie es bei mir aussieht.
Eine weitere Stunde habe ich dann mit awk 'gekämpft', bis ich es endlich so hinbekommen habe, wie ich es brauchte. Spalten und Zeilen wollten nicht so ganz wie ich.

Aber, wieder eine Menge dazugelernt!
Herzlich Dank also noch mal.

[tuxedo]

Hallo zusammen

Ich hole diesen Thread nochmals hoch weil ich seit dem Kernelupdate auf 3.16.0-4-amd64 auch das Problem habe dass die Arrays nicht mehr zusammengesetzt werden.
System ist Debian 8 (Jessie).
Unter dem Vorgänger Kernel "3.16.0-0.bpo.4-amd64" lief / läuft das Assemblen beim booten immer noch wie es soll.
So wie ich das schreibe wundere ich mich doch gerade etwas, der Kernel scheint noch aus Wheezy-Backports zu stammen wenn ich das richtig sehe?!
Das System war früher auch mal ein Wheezy (auch bereits Update), wurde aber bereits vor einiger Zeit auf Jessie aktualisiert.

Ich hatte in Vergangenheit mit dem Update auf Debian 6 bereits mal Probleme und mir damals damit geholfen im initramfs local-top ein Script zu erstellen welches die Arrays zusammenbaut. Ich meine ich konnte das dann mit einem weiteren Update aber wieder deaktivieren.

Dieses musste ich nun wieder aktivieren um erfolgreich booten zu können:

Code: Alles auswählen

mdadm -A /dev/md0 /dev/sda1 /dev/sdb1
mdadm -A /dev/md1 /dev/sda2 /dev/sdb2
mdadm -A /dev/md2 /dev/sda3 /dev/sdb3

Andenfalls lande ich in der initramfs Konsole und muss von Hand die Arrays zusammenbauen.

# mdadm --assemble --scan

tut bei mir gar nichts, ich muss die Arrays spezifisch angeben. Einmal zusammengebaut bekomme ich mit
# mdadm --detail --scan
auch die Ausgabe mit ARRAY ...., identisch mit den Einträge in der aktiven mdadm.conf unter initramfs.

Das initramfs neu zu bauen (update-initramfs) habe ich auch schon mehrfach versucht (musste ich sowieso für das Script in local-top zu akti/deaktivieren), bleibt beim selben.

mdadm ist in Version 3.3.2-5+deb8u1 installiert.

/etc/apt/sources.list

Code: Alles auswählen

deb http://mirror.switch.ch/ftp/mirror/debian/ jessie main non-free contrib
deb-src http://mirror.switch.ch/ftp/mirror/debian/ jessie main non-free contrib
deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free

Weiter sind die backports noch aktiviert

Code: Alles auswählen

deb http://mirror.switch.ch/ftp/mirror/debian jessie-backports main contrib non-free

Hat jemand eine Idee? Sonst lass ich das mit dem Hilfsscript - funktionieren tut es damit ja tadellos

Danke & Grüsse

[whiizy]

Hat jemand eine Idee? Sonst lass ich das mit dem Hilfsscript - funktionieren tut es damit ja tadellos

Leider nein, ich kann aktuell nur einen Erfahrungswert beisteuern. Ich habe gestern versucht, Jessie amd64 auf einem Softraid (RAID1) aus zwei USB-Sticks zu installieren. Im "expert mode" läuft die Installation auch durch (wenn auch schleppend wg. Schreib-Speed). Beim ersten Boot des neuen Systems meckert dann aber der mdadm, weil offenbar das raid-array mit dem rootfs nicht (oder nicht rechtzeitig?) zur Verfügung steht. Ich lande dann schließlich am Prompt der initramfs und müsste vermutlich manuelle Schritte ausführen, wie Du sie dokumentiert hast.

Zum Paket mdadm gibt es momentan einige bugs und so vermute ich einfach mal, daß dies der Grund ist. Vielleicht versuche ich zunächst mal eine Gegenprobe mit Wheezy anstatt Jessie.

[NAB]

Was steht denn in der /etc/default/mdadm?

[whiizy]

Was steht denn in der /etc/default/mdadm?

Kann ich leider nicht mehr feststellen, da bei einem weiteren Installationsversuch bereits überschrieben. Das Schreiben des RAID1 auf USB-Basis ist recht zeitintensiv und ich konnte einen neuen Anlauf noch nicht zuendebringen. Wenn ein während der Installation von Jessie angelegtes software RAID1 vom frisch installierten grub gefunden, aber nicht als rootfs eingehängt wird, ist das schon etwas Gravierendes IMHO. Sollte ich echte Fakten habe, werde ich mich nochmal melden. Danke.

[whiizy]

Das Problem bei mir ließ sich beheben. Das (Soft)RAID1 braucht einfach mehr Zeit zur Initialisierung. Eine Verzögerung von willkürlichen 5 Sekunden ließ es starten:

Code: Alles auswählen

/etc/default/grub
-->
GRUB_CMDLINE_LINUX="rootdelay=5"
-->
# update-grub

Die letzte Installation erfolgte zwar unter Debian Wheezy, aber unter Jessie würde es so wohl auch jetzt funktionieren.

Schönen Tag

[tuxedo]

Hallo zusammen

Was steht denn in der /etc/default/mdadm?

Bei mir steht da drin:

Code: Alles auswählen

INITRDSTART='all'
AUTOCHECK=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false

Das Problem bei mir ließ sich beheben. Das (Soft)RAID1 braucht einfach mehr Zeit zur Initialisierung. Eine Verzögerung von willkürlichen 5 Sekunden ließ es starten:

Danke für den Tipp. Teste ich gerne bei Gelegenheit wenn ich das System neu starten kann!

Danke & Grüsse

[tuxedo]

Hallo whiizy

Eben probiert rootdelay zu setzten, sogar hoch bis 20. Fehler bleibt leider der selbe.
Gewartet wird zwar wie angegeben, aber Zusammenbau vom RAID schlägt trotzdem fehl.
Der Workaround ist nun wieder aktiv.

Danke trotzdem!

Grüsse

[whiizy]

Gewartet wird zwar wie angegeben, aber Zusammenbau vom RAID schlägt trotzdem fehl.

Hallo tuxedo,

das ist schade. Ich habe gerade mein externes md-array mal testweise in ein Jessie-System eingebunden und da es funktioniert hat, liegt zumindest kein generelles Problem des Jessie-Kernel vor. Das zu wissen, hilft manchmal ja auch schon etwas. Benutzt habe ich den aktuellen Standard-Kernel:

Code: Alles auswählen

Package linux-image-3.16.0-4-amd64
 jessie (stable) (kernel): Linux 3.16 for 64-bit PCs
 3.16.7-ckt20-1+deb8u3 [security]: amd64 i386

Deine genaue Fehlermeldung wäre einmal ganz hilfreich. -
Ganz nebenbei habe ich übrigens auch etwas Unerwartetes beobachtet. Mein grub menuentry hat das Laden zweier raid-module eingetragen (insmod raid und insmod mdraid1x). Beim Booten in mein softraid meckert grub, daß er das erste mod nicht unter /boot/grub/i386-pc/raid.mod finden kann. Das stimmt auch, denn Jessie hat da jetzt anders benannte, nur unter Wheezy existierte ein raid.mod. Das mdraid1x reicht offenbar zum assemblen meines raid1 aus. Ich will das jetzt nicht zuweit ausführen, aber es hängt damit zusammen, daß mein Grundsystem auf dem Laptop ein Jessie ist, und ich per (dessen) grub wahlweise in ein externes Wheezy-Softraid einstarte.

Für Dich könnte es aber interessant sein, mal Deine grub menuentries auf die verwendeten raid-module abzuklopfen und deren Pfad /boot/grub/ oder /boot/grub/i386-pc/ zu kontrollieren.

Gruß

[tuxedo]

Hallo

Danke für deine Antwort. Auf dem System existieren in /boot/grub/i386-pc/ folgende Module mit raid im Namen:

Code: Alles auswählen

mdraid09.mod
mdraid09_be.mod
mdraid1x.mod
raid5rec.mod
raid6rec.mod

In der generierten grub.cfg stehen dann auch die Module:

Code: Alles auswählen

insmod part_msdos
insmod diskfilter
insmod mdraid1x
insmod ext2

im entsprechenden Abschnitt.

Livebilder vom fehlerhaften starten schaue ich noch zu erstellen beim nächsten regulären Reboot.

Danke & Grüsse