4
Md: invalid raid superblock magic on sdd1
Moin,
ich hatte gestern viele Stunden Spaß mit mdadm.
Nach Plattentausch auf Grund von vielen I/O-Errors auf sdd ging die neue Platte nicht mehr ins Raid.
Kernelmeldungen:
Nach mehrstündiger Suche und vielen Versuchen, die alle fehlschlugen hat das Überschreiben des Superblocks mit Nullen geholfen.
Neue Platte noch mal glätten.
Alles löschen! und mit wq raus.
Dann das Partitionsschema von einer Bestandsplatte auf die Neue kopieren:
Jetzt den "nicht validen Superblock" überschreiben
Und die Platte wieder ins Raid bringen
Und endlich wurde die Platte dem Raid hinzugefügt.
Ich hoffe es hilft mal Jemandem.
ich hatte gestern viele Stunden Spaß mit mdadm.
Nach Plattentausch auf Grund von vielen I/O-Errors auf sdd ging die neue Platte nicht mehr ins Raid.
Kernelmeldungen:
md: invalid raid superblock magic on sdd1
md: sdd1 does not have a valid v1.2 superblock, not importing!Nach mehrstündiger Suche und vielen Versuchen, die alle fehlschlugen hat das Überschreiben des Superblocks mit Nullen geholfen.
Neue Platte noch mal glätten.
fdisk /dev/sddDann das Partitionsschema von einer Bestandsplatte auf die Neue kopieren:
sfdisk -d /dev/sdc | sfdisk -f /dev/sddJetzt den "nicht validen Superblock" überschreiben
mdadm --zero-superblock /dev/sdd1Und die Platte wieder ins Raid bringen
mdadm --add /dev/md0 --add /dev/sdd1Und endlich wurde die Platte dem Raid hinzugefügt.
Ich hoffe es hilft mal Jemandem.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 668754
Url: https://administrator.de/contentid/668754
Ausgedruckt am: 16.10.2024 um 00:10 Uhr
4 Kommentare
Neuester Kommentar
Moin,
Vermutlich lag es daran, daß Du keine neue leere HDD/SSD benutzt hast, sondern eine schon einmal benutzte Platte. Da ist es normal, das Daten an Stellen stehen, wo sie auch mal stören können. Deswegen löschen z.B. gparted und Co. die "Metadaten", wenn diese nicht zum Partitionstyp passen.
Bei solchen Szenarien ist es dajher meist eine gute Idee vorher benutzte Platten immer zu "Nullen", um genau solche Probleme zu vermeiden.
lks
PS: Auch "neue" Platten können manchmal solche Daten enthalten, wenn der Vorbesitzer einen Diagnoselauf gemacht hat oder irgendetwas anderes mal zwischendurch drauf kopiert hatte, weswegen ich auch bei neuen Platten ein "Nullen" durchführen.
Vermutlich lag es daran, daß Du keine neue leere HDD/SSD benutzt hast, sondern eine schon einmal benutzte Platte. Da ist es normal, das Daten an Stellen stehen, wo sie auch mal stören können. Deswegen löschen z.B. gparted und Co. die "Metadaten", wenn diese nicht zum Partitionstyp passen.
Bei solchen Szenarien ist es dajher meist eine gute Idee vorher benutzte Platten immer zu "Nullen", um genau solche Probleme zu vermeiden.
lks
PS: Auch "neue" Platten können manchmal solche Daten enthalten, wenn der Vorbesitzer einen Diagnoselauf gemacht hat oder irgendetwas anderes mal zwischendurch drauf kopiert hatte, weswegen ich auch bei neuen Platten ein "Nullen" durchführen.
Moin,
stimmt, es war keine neue Platte.
Die Platte wurde vorher komplett mit shred behandelt und dann im Laufe des ganzen Geschehens mehrmals mit fdisk und dd.
Ich sehe da trotzdem Verbesserungsbedarf. Gern direkt über mdadm.
Wenn dort solche Fehler erkannt werden, kann man dort auch fragen ob's gleich behoben werden soll.
Der entscheidende Befehl ist ja:
Gruß Hucklebuck
stimmt, es war keine neue Platte.
Die Platte wurde vorher komplett mit shred behandelt und dann im Laufe des ganzen Geschehens mehrmals mit fdisk und dd.
Ich sehe da trotzdem Verbesserungsbedarf. Gern direkt über mdadm.
Wenn dort solche Fehler erkannt werden, kann man dort auch fragen ob's gleich behoben werden soll.
Der entscheidende Befehl ist ja:
mdadm --zero-superblock /dev/sdd1Gruß Hucklebuck
Zitat von @Hucklebuck:
Moin,
stimmt, es war keine neue Platte.
Die Platte wurde vorher komplett mit shred behandelt und dann im Laufe des ganzen Geschehens mehrmals mit fdisk und dd.
Moin,
stimmt, es war keine neue Platte.
Die Platte wurde vorher komplett mit shred behandelt und dann im Laufe des ganzen Geschehens mehrmals mit fdisk und dd.
Naja weder shred noch fdisk nullen die Datenbereiche und dd nur dann, wenn man aus /dev/zero dumped.
Ich sehe da trotzdem Verbesserungsbedarf. Gern direkt über mdadm.
Da mdadm open source ist steht es jedem frei, die Abfrage einzubauen, was aber bisher keiner gemacht hat und Du warst sicher nicht der erste, der auf dieses Problem gelaufen ist. Ich habe das vor ca. 25 Jahren zum ersten Mal erlebt.
Wenn dort solche Fehler erkannt werden, kann man dort auch fragen ob's gleich behoben werden soll.
Da kann man geteilter Meinung sein. Wenn die Abfrage eingebaut ist, sagen zu viele Leute zu schnell "beheben" ohne groß nachzudenken. Und wenn man nicht das richtige device erwischt hat, sondern eines das man eigentlich noch forensisch untersuchen will, ist die Gefahr eines Datenverlustes sehr hoch. Dann lieber die Leute nachdenken lassen und das explizit machen lassen. Und genau dafür sind Manager da, damit man weiß, wie man solche Probleme beheben kann.
Der entscheidende Befehl ist ja:
mdadm --zero-superblock /dev/sdd1Klar, steht im Manual.
Bloß liest die heutzutage kaum jemand.
lks
Bloß liest die heutzutage kaum jemand. face-sad
Wundert mich nicht wirklich. Bei 1374 Zeilen und man eigentlich nicht weiß wonach man suchen soll bei der Fehlermeldung. xD
Nachrtrag: Dass sollte die Platte doch mit Nullen "glattziehen": Shred
