Sebastian Siebert schrieb:

Am 03.03.2016 um 10:36 schrieb Frank Jäschke:

...

Hallo Liste,

Gestern habe ich mit einem System OS132 64Bit ein Onlinebackup über yast2 gemacht. Alles was angeboten wurde, außer Kernel, bind und clam upgedatet. (Kernel, bind und clam stelle ich selbst her) Dann hat des System gemeint ich soll wegen systemd eine reboot machen. Das hatte ich nicht tun sollen. Nun startet das System nicht mehr. Mit der Installation CD kann ich des installierte System booten (der originale Kernel ist noch [neben den Eigenen] mit alle Modulen drauf) und das System läuft so recht und schlecht vor sich hin.

Meine Analyse bisher :

- Es wurden alle initrd für meine selbst erstellten Kernels und den Originalen neu gebaut (die alle bis dahin liefen)!! - es scheint das md126 - RAID auseinander gefallen zu sein, auf der Platte - nach boot von CD ist es da - Ausgabe von : mdadm --examine /dev/sd[ab] : ##################################### das ist die Umleitung von 2> : mdmon: /dev/sda is not attached to Intel(R) RAID controller. mdmon: /dev/sdb is not attached to Intel(R) RAID controller.

die Ausgabe ist dann: /dev/sda: Magic : Intel Raid ISM Cfg Sig. Version : 1.1.00 Orig Family : 50129287 Family : 50129287 Generation : 00003381 Attributes : All supported UUID : f894b0c8:8a2d9d1c:cd8c92fb:b22b9f2b Checksum : 403c2684 correct MPB Sectors : 1 Disks : 2 RAID Devices : 1

Disk01 Serial : WD-WCASY3860966 State : active Id : 00020000 Usable Size : 976767240 (465.76 GiB 500.10 GB)

[Volume0]: UUID : 5b4f87da:0cfee806:8ea08fda:ba62c573 RAID Level : 1 Members : 2 Slots : [UU] Failed disk : none This Slot : 1 Array Size : 976766976 (465.76 GiB 500.10 GB) Per Dev Size : 976767240 (465.76 GiB 500.10 GB) Sector Offset : 0 Num Stripes : 3815496 Chunk Size : 64 KiB Reserved : 0 Migrate State : idle Map State : normal Dirty State : dirty

Disk00 Serial : WD-WCASY3839900 State : active Id : 00010000 Usable Size : 976767240 (465.76 GiB 500.10 GB) /dev/sdb: Magic : Intel Raid ISM Cfg Sig. Version : 1.1.00 Orig Family : 50129287 Family : 50129287 Generation : 00003381 Attributes : All supported UUID : f894b0c8:8a2d9d1c:cd8c92fb:b22b9f2b Checksum : 403c2684 correct MPB Sectors : 1 Disks : 2 RAID Devices : 1

Disk00 Serial : WD-WCASY3839900 State : active Id : 00010000 Usable Size : 976767240 (465.76 GiB 500.10 GB)

[Volume0]: UUID : 5b4f87da:0cfee806:8ea08fda:ba62c573 RAID Level : 1 Members : 2 Slots : [UU] Failed disk : none This Slot : 0 Array Size : 976766976 (465.76 GiB 500.10 GB) Per Dev Size : 976767240 (465.76 GiB 500.10 GB) Sector Offset : 0 Num Stripes : 3815496 Chunk Size : 64 KiB Reserved : 0 Migrate State : idle Map State : normal Dirty State : dirty

Disk01 Serial : WD-WCASY3860966 State : active Id : 00020000 Usable Size : 976767240 (465.76 GiB 500.10 GB) ##############

Wie kann ich das System ohne Datenverlust wieder zusammenfügen ???

Auch ein mkinitrd für meien eigenen Kernel 4.4.3 meint :

mdmon: /dev/sda is not attached to Intel(R) RAID controller mdmon: /dev/sdb is not attached to Intel(R) RAID controller

Was wohl die Annahme des, zumindest auf der Platte, zerfallenen RAID1 bestätigt?!

Die Bootcd (NETInstall) baut das wohl beim laden des Kernel selbst zusammen ?!

Wie kann ich das Problem ohne Datenverlust lösen ? Danke schon mal vorab.

Hallo,

hm... du baust dir also den Kernel selbst. Warum eigentlich? Eine alte Angewohnheit, weil für einige Programme ohnehin die Quellen da sein müssen (füe das make) , nehme ich die Neuesten ?! Muss mit os13.* bzw Leap sicher auch nicht mehr sein aber früher (Suse 8, 9 , 10 ...) war es wegen Treibern schon mal den Zwang.

Meine Vermutung

ist, dass der RAID-Treiber "md" aus der Initial-Ramdisk deines "Vanilla"-Kernel raus geflogen ist? Warum auch immer.

Genau so ist es, nach dem ich aus einem Backup die initrd wieder draufgespielt habe, läuft die Kiste wieder mit dem Kernel auf den Platten. Das Problem : mdmon: /dev/sda is not attached to Intel(R) RAID controller. mdmon: /dev/sdb is not attached to Intel(R) RAID controller. bleibt aber ?! Und alle Verzeichnisse /dev/md126p* sind ordentlich gemountet !??

Jetzt wäre der richtige Zeitpunkt ein Backup davon zu machen, falls nicht schon geschehen.

Ich würde z.B. mit SystemRescueCD die nachfolgende Operation durchführen.

Was sagt denn? # cat /proc/mdstat

Personalities : [raid1] md126 : active raid1 sdb[1] sda[0] 488383488 blocks super external:/md127/0 [2/2] [UU] md127 : inactive sdb[1](S) sda[0](S) 5928 blocks super external:imsm unused devices: <none>

Dann aus der o.g. Auflistung mal mit dem entsprechendem Device ersetzen und wie folgt aufrufen: # mdadm --detail /dev/md0

mdadm --detail /dev/md126 : /dev/md126: Container : /dev/md/imsm0, member 0 Raid Level : raid1 Array Size : 488383488 (465.76 GiB 500.10 GB) Used Dev Size : 488383620 (465.76 GiB 500.10 GB) Raid Devices : 2 Total Devices : 2 State : active Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 UUID : 5b4f87da:0cfee806:8ea08fda:ba62c573 Number Major Minor RaidDevice State 1 8 16 0 active sync /dev/sdb 0 8 0 1 active sync /dev/sda #################################################################### mdadm --detail /dev/md127 : /dev/md127: Version : imsm Raid Level : container Total Devices : 2 Working Devices : 2 Member Arrays : /dev/md/Volume0_0 Number Major Minor RaidDevice 0 8 0 - /dev/sda 1 8 16 - /dev/sdb

Wenn überhaupt kein /dev/md* existiert, dann würde ich die beiden Platten mal versuchen wieder im Array zusammenzuführen.

# mdadm --assemble --scan

Kann da was mit den Daten passieren ?

Dann schaue nach, ob /dev/md0 existiert und lass nochmal /proc/mdstat bzw. "mdadm --detail /dev/md0" den Status des RAID ausgeben.

Sollte der Sync abgeschlossen sein, kannst du /dev/md0 mounten und in das System chrooten. Gibt es auch eine /etc/mdadm.conf?

Ja, die ist auch noch aus dem Vorjahr, also unangetastet. DEVICE containers partitions ARRAY metadata=imsm UUID=f894b0c8:8a2d9d1c:cd8c92fb:b22b9f2b ARRAY /dev/md/Volume0_0 container=f894b0c8:8a2d9d1c:cd8c92fb:b22b9f2b member=0 UUID=5b4f87da:0cfee806:8ea08fda:ba62c573 Dann lasse nochmal zur Sicherheit

per mkinitrd eine neue Initial-Ramdisk neu bauen und die Ausgabe genau beobachten.

Auch hier noch der/die Fehler : *** Including module: mdraid *** mdmon: /dev/sdb is not attached to Intel(R) RAID controller. mdmon: /dev/sdb is not attached to Intel(R) RAID controller. mdmon: /dev/sda is not attached to Intel(R) RAID controller. mdmon: /dev/sda is not attached to Intel(R) RAID controller. Skipping udev rule: 64-md-raid.rules

Viel Glück bei der Spurensuche. Danke

MfG Frank Jäschke -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Sebastian Siebert schrieb:

Am 08.03.2016 um 09:28 schrieb Frank Jäschke:

...

Sebastian Siebert schrieb:

...

Am 03.03.2016 um 10:36 schrieb Frank Jäschke:

[...]

...

...

Meine Vermutung ist, dass der RAID-Treiber "md" aus der Initial-Ramdisk deines "Vanilla"-Kernel raus geflogen ist? Warum auch immer.

Genau so ist es, nach dem ich aus einem Backup die initrd wieder draufgespielt habe, läuft die Kiste wieder mit dem Kernel auf den Platten. Das Problem :

mdmon: /dev/sda is not attached to Intel(R) RAID controller. mdmon: /dev/sdb is not attached to Intel(R) RAID controller.

bleibt aber ?! Und alle Verzeichnisse /dev/md126p* sind ordentlich gemountet !??

Hm, ist das im gechrootetem System? Hast du /dev, /proc, /sys auch eingebunden?

Nein, das System ist "ganz normal" von der Platte gebootet, nachdem ich die initrd - Dateien vom Backup wieder installiert (einfach copy vom BA) habe, ging das ja wieder und die Installations CD ist raus. Und Ja, alle genannten Systeme sind eingebunden. cat /proc/mdstat zeigt : Personalities : [raid1] md126 : active raid1 sdb[1] sda[0] 488383488 blocks super external:/md127/0 [2/2] [UU] md127 : inactive sdb[1](S) sda[0](S) 5928 blocks super external:imsm unused devices: <none>

...

...

...

Jetzt wäre der richtige Zeitpunkt ein Backup davon zu machen, falls nicht schon geschehen.

Ich würde z.B. mit SystemRescueCD die nachfolgende Operation durchführen.

Was sagt denn? # cat /proc/mdstat

[...] #################################################################### mdadm --detail /dev/md127 : /dev/md127: Version : imsm Raid Level : container Total Devices : 2

Working Devices : 2

Member Arrays : /dev/md/Volume0_0

Number Major Minor RaidDevice

0 8 0 - /dev/sda 1 8 16 - /dev/sdb

Der Volumen-Container ist nicht im Raid (md127 : inactive) eingebunden. Aktuell ist der Dirty-Status als "Dirty" markiert, in der Regel wäre der Dirty-Status auf "clean".

Ich habe ein zweites System mit ähnlicher Konfiguration (nur 2mal 1Tbyte Platten), da steht auch unter Volume 0: Dirty State : dirty ??? Und dieses System läuft ohne Probleme und Fehlermeldungen ?

...

...

Wenn überhaupt kein /dev/md* existiert, dann würde ich die beiden Platten mal versuchen wieder im Array zusammenzuführen.

# mdadm --assemble --scan

Kann da was mit den Daten passieren ?

Hast du Backup? :-)

Ja gibt es, aber das Rücksichern würde dauern, denn das ist auf Band und dann ist der Zustand sicher wie jetzt. RAID nicht OK! Denn das scheint mir nicht ein reines Softwareproblem oder ? Es scheint mir das System läuft auf seltsame Weise mit "mdadm --auto-detect" oder wie erkennt der Kernel das RAID1 ?

Auf Grund der o.g. Angaben würde ich wie folgt mit einer Live-CD vorgehen.

# mdadm --stop /dev/md126

# mdadm --stop /dev/md127

# mdadm --assemble --scan.

Das sollte alle vorhandenen Arrays wieder einbinden und den sync starten.

Schau unter /proc/mdstat bzw. "mdadm --detail /dev/md12{6,7}" nach wie der Status ist.

Ggfs. wurde eine neue Konfigurationsdatei /etc/mdadm.conf im Live-System erzeugt, bitte diesen mal wegsichern.

Sobald der Status "active sync" bei /dev/md126 und /dev/md127 erscheint, kannst du den RAID mounten und die mkinitrd neubauen. (Nicht vergessen die virtuellen Verzeichnisse (/dev, /proc, /sys) einzubinden.)

Bis hier alles im Livesystem ? Und dann reboot ?

...

...

Dann schaue nach, ob /dev/md0 existiert und lass nochmal /proc/mdstat bzw. "mdadm --detail /dev/md0" den Status des RAID ausgeben.

Sollte der Sync abgeschlossen sein, kannst du /dev/md0 mounten und in das System chrooten. Gibt es auch eine /etc/mdadm.conf?

Ja, die ist auch noch aus dem Vorjahr, also unangetastet.

DEVICE containers partitions ARRAY metadata=imsm UUID=f894b0c8:8a2d9d1c:cd8c92fb:b22b9f2b ARRAY /dev/md/Volume0_0 container=f894b0c8:8a2d9d1c:cd8c92fb:b22b9f2b member=0 UUID=5b4f87da:0cfee806:8ea08fda:ba62c573

[....]

Ich habe, aus Verzweiflung auch schon die UUID verglichen, aber auch die passen. -- Mit freundlichen Grüßen Frank Jäschke -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org