[solved] fsck failed auf SW raid (MDADM)

[framp]

Gestern habe ich auf meinem lokalen Server openSuSE 11.4 installiert. Dabei musste ich eine RAID1 Platte aus einem 2er Verbund abklemmen, damit ich das CD Laufwerk zum Installieren anschliessen konnte. Nach der Installation habe ich sie wieder angeschlossen und ein

mdadm -a /dev/md1 /dev/sdc

angestossen damit die 2te Platte wieder ins Raid reinkommt. Ich weiss --ra-add wäre besser gewesen - aber leider ist das nicht der gravierende Fehler: Ich habe /dev/sdc anstatt /dev/sdc1 genommen. Nachdem der add erfolgreich beendet war habe ich den Server abgeschaltet. Heute bekomme ich ihn nicht hoch, das beim Booten ein inkonsistentes filesystem auf /dev/md1 gefunden wird. Daraufhin habe ich die zweite Platte wieder aus dem RAID entfernt - aber leider immer noch das Problem :-(
fsck /dev/md1 liefert

fsck from util-linux 2.19
e2fsck 1.41.14 (22-Dec-2010)
The filesystem size (according to the superblock) is 78142160 blocks
The physical size of the device is 78142144 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes

idefix:~ # cat /proc/mdstat
Personalities : [raid1] 
md1 : active raid1 sda1[0]
      312568576 blocks [2/1] [U_]
      
unused devices: <none>

idefix:/ # mdadm --query --detail /dev/md1
/dev/md1:
        Version : 0.90
  Creation Time : Wed Jun 30 19:16:02 2010
     Raid Level : raid1
     Array Size : 312568576 (298.09 GiB 320.07 GB)
  Used Dev Size : 312568576 (298.09 GiB 320.07 GB)
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Sat Apr 23 20:27:02 2011
          State : clean, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           UUID : 9f095ff8:2904f6fc:d66856da:8e136666 (local to host idefix)
         Events : 0.256

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       0        0        1      removed

idefix:/ # fdisk -l /dev/sda /dev/sdc

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63   625137344   312568641   fd  Linux raid autodetect

Disk /dev/sdc: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sdc doesn't contain a valid partition table

Merkwürdigerweise kann ich auf die verbliebene Platte (/dev/sda1) im RAID zugreifen und sehe auch Daten. Ich tendiere dazu jetzt alle Daten von der Platte erst zu sichern und dann zu versuchen das RAID und seine Daten wieder zu reparieren.

Folgende Fragen habe ich nun:
1) Kann ich auf das etwas korrupte RAID zugreifen und die Daten kopieren und retten ohne was zu zerstören? Die Daten sind leider wichtig ... deshalb ja auch ein RAID1.
2) Weiss jemand was da genau passiert ist? Liegt das am /dev/sdc anstatt /dev/sdc1? Ich kann auch noch weitere Infos liefern falls nötig
3) Wie kann ich das FS der Platte wieder hinbekommen? Ich könnte sicherlich alle Daten erst einmal sichern und dann das RAID wieder neu aufsetzen - sofern das geht (Siehe Frage 1). Besser wäre noch wenn ich das wieder reparieren kann.

Ich hoffe ich bekomme von Euch ein ja zu 1 zu hören ... oder wenigstens zu 3 eine rettende Antwort ...

 

[spoensche]

/dev/sda1 ist in Ordnung, dein /dev/sdc hat den Schaden. Auf /dev/sdc ist keine Partition mehr vorhanden, weil du /dev/sdc statt /dev/sdc1 verwendet hast.

Du könntest dir ein Image von /dev/sdc ziehen, und in einer VM oder deinem Laptop die Daten zu holen. Du musst /dev/sdc neu partitionieren und dann kannst du sie wieder im RAID einfügen.

 

[framp]

/dev/sda1 ist in Ordnung, dein /dev/sdc hat den Schaden. Auf /dev/sdc ist keine Partition mehr vorhanden, weil du /dev/sdc statt /dev/sdc1 verwendet hast.

Ja, aber ich habe ja die /dev/sdc aus dem Raid rausgenommen. Deshalb sollte sie ja kein Problem mehr machen. Aber trotzdem ist das FS auf /dev/md1 inkonsistent.

...Du könntest dir ein Image von /dev/sdc ziehen, und in einer VM oder deinem Laptop die Daten zu holen.

Die meinst auf der /dev/sdc stehen die Daten auch noch lesbar?

Du musst /dev/sdc neu partitionieren und dann kannst du sie wieder im RAID einfügen.

Das wäre dann meine Aktion am Ende. Aber vorerst möchte ich die alten Daten sichern. Zerstöre ich was auf /dev/sda wenn ich das Raid nur lesend mounte? Ich denke nicht - will das aber lieber genau wissen :???:

 

[spoensche]

...Du könntest dir ein Image von /dev/sdc ziehen, und in einer VM oder deinem Laptop die Daten zu holen.

Die meinst auf der /dev/sdc stehen die Daten auch noch lesbar?

Möglich wäre es. Wenn du noch einen Tower hast könntest du die Platte mal dort mal anschließen und mounten. Ich würde es versuchen.

Aber vorerst möchte ich die alten Daten sichern. Zerstöre ich was auf /dev/sda wenn ich das Raid nur lesend mounte? Ich denke nicht - will das aber lieber genau wissen :???:

Zerstören kannst du mit ro mounten nichts. Wenn dein /var etc. auf dem md1 liegt wirst allerdings Fehlermeldungen erhalten, weil nichts nach /var geschrieben werden kann. Wenn ich mich nicht irre, dann müsstest du /dev/sda1 auch ohne weiteres wie eine normale Partition mounten können.

 

[framp]

...Zerstören kannst du mit ro mounten nichts. Wenn dein /var etc. auf dem md1 liegt wirst allerdings Fehlermeldungen erhalten, weil nichts nach /var geschrieben werden kann. Wenn ich mich nicht irre, dann müsstest du /dev/sda1 auch ohne weiteres wie eine normale Partition mounten können.

Ich habe jetzt die /dev/md1 mit den /dev/sda1 ro gemountet und kopiere alle Daten auf eine andere Platte. Da brauche ich nichts HWmäßig umzubauen. Wenn es da Probleme gegen sollte muss ich mir die /dev/sdc vornehmen.

 

[Anonymous]

• * raid Read-only mounten,
  * Daten runterziehen,
  * Raid komplett tot machen indem du die Raid Superblöcke von sda1 und die eventuelle Konfiguration aus /etc/mdadm.conf löschen, aber alles erst wenn sicher ist, das das Backup auch wirklich funktioniert hat.
  * Dann Raid neu anlegen, kannst du erst mal mit nur mit sda1 und einer "missing" machen, dann hast du die sdc vorläufig noch als eiserne Reserve.
  * dann Daten wieder drauf,
  * Ist alles ok, dann die sdc tot machen (Raid Superblocke löschen), neu und richtig partitionieren und dieses mal richtig dazufügen.
  * zur Sicherheit nochmal die initrd neu erstellen, möglich das dort die alte Konfiguration aus der mdadm.conf mit drin stand.

Was ist passiert.

The filesystem size (according to the superblock) is 78142160 blocks
The physical size of the device is 78142144 blocks

Dadurch das du sdc anstatt sdc1 zum Raid dazugefügt hast, ist irgendwas in der RAID-Größe oder im Filesystemsuperblock durcheinander gekommen. Ist etwa sdc insgesamt kleiner als sda1? laut der Ausgabe von fdisk sollte das nicht so sein. Irgendwie ist dein Filesystem der Meinung dass es 16 Blöcke größer ist als das gesamte RAID. Egal was da genau passiert ist, sowas trägt Gefahrenpotential wenn man das nur irgendwie übergeht und einfach ausbügelt, desshalb das Raid komplett entfernen und neu aufsetzten und Filesystem neu anlegen.

Apropos fdisk, ich nehme aufgrund der Version von fsck 1.41.14 an es ist das ein 11.4 . Das habe ich noch nicht installiert. Aber.

255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes

entweder du hast das unmögliche geschafft oder die haben an fdisk irgendwas gedreht, die normale Ausgabe und Einteilung die ich bei fdisk erwartet hätte, wäre hier eine Unitsgröße von 16065 × 512 = 8225280 Bytes wie das auch über 600 Mal im LC zu finden ist. Was du hier anzeigst hätte ich bei "fdisk -ul" erwartet und nicht bei "fdisk -l". Na vielleicht sind sie ja endlich mal schlau geworden und haben sich meine Warnungen und Ausschweifungen mal zu Herzen genommen.

robi

 

[framp]

Alle Daten konnte ich von /dev/md1 lesen und sichern [tief Luft hol]. jetzt bau ich das RAID wieder neu von scratch auf.

Danke für Eure Tips & Beistand

...* Ist alles ok, dann die sdc tot machen (Raid Superblocke löschen), neu und richtig partitionieren und dieses mal richtig dazufügen. ...

genau den Beitrag habe ich benutzt um mein RAID aufzusetzen Richtig partitioniert hatte ich ja - nur leider die 1 beim add vergessen ps:

Was ist passiert.

The filesystem size (according to the superblock) is 78142160 blocks
The physical size of the device is 78142144 blocks

Dadurch das du sdc anstatt sdc1 zum Raid dazugefügt hast, ist irgendwas in der RAID-Größe oder im Filesystemsuperblock durcheinander gekommen. Ist etwa sdc insgesamt kleiner als sda1? laut der Ausgabe von fdisk sollte das nicht so sein.

Die beiden Platten sind absolut baugleich

Irgendwie ist dein Filesystem der Meinung dass es 16 Blöcke größer ist als das gesamte RAID. Egal was da genau passiert ist, sowas trägt Gefahrenpotential wenn man das nur irgendwie übergeht und einfach ausbügelt, desshalb das Raid komplett entfernen und neu aufsetzten und Filesystem neu anlegen.

Das RAID setze ich neu auf. Würde mich nur interessieren warum das passiert ist. Ist ja schon ziemlich unangenehm, dass man durch so einen Typo gleich sein ganzes RAID durch den Wind bringt.

... Na vielleicht sind sie ja endlich mal schlau geworden und haben sich meine Warnungen und Ausschweifungen mal zu Herzen genommen.

Es ist ein frisches openSUSE 11.4. Offensichtlich hat man Dich erhört

Könnte man eigentlich die Daten auf /dev/sdc noch irgendwie lesen? Ich brauche sie zwar nicht mehr aber es interessiert mich doch ob es geht.

 

[Anonymous]

Könnte man eigentlich die Daten auf /dev/sdc noch irgendwie lesen? Ich brauche sie zwar nicht mehr aber es interessiert mich doch ob es geht.

hast mal probiert

mount -o ro /dev/sdc /mnt

kann das jetzt nicht nachstellen, aber genau so simple wurde ich das bei Metadata Version 0.90 erwarten.

robi

 

[framp]

Könnte man eigentlich die Daten auf /dev/sdc noch irgendwie lesen? Ich brauche sie zwar nicht mehr aber es interessiert mich doch ob es geht.

hast mal probiert

mount -o ro /dev/sdc /mnt

kann das jetzt nicht nachstellen, aber genau so simple wurde ich das bei Metadata Version 0.90 erwarten.

robi

Das war genau mein Ansatz - aber leider kam nur eine Fehlermeldung, dass die Platte vom Typ fd (RAID) sei. Offensichtlich kann man sie nur indirekt über ein anderes RAID wieder einbinden.

 

[Anonymous]

was sagt denn dann

file -s /dev/sdc

das alte Raid über diese Platte wieder aufsetzen solange die sda1 im Rechner ist, würde ich jedenfalls vermeiden.
Ein bisschen Angst kann nicht schaden.
Notfalls über ein Image kommt man immer wieder an solche Daten, bei "-o loop" kann man ein "offset" angeben wenn sich der Filesystemsuperblock nicht am Anfang des Images befinden sollte.

Müsste man sich die ersten paar Blöcke mal unter hexdump anschauen, um zu sehen was er da genau macht wenn man ein komplettes Device anstatt einer Partition verwendet. Wenn's heute nicht notwendig ist, machen wir das dann wenn es dem nächsten passiert
ist heute gerade so schönes Wetter.


robi

 

[framp]

was sagt denn dann

file -s /dev/sdc

das alte Raid über diese Platte wieder aufsetzen solange die sda1 im Rechner ist, würde ich jedenfalls vermeiden.
Ein bisschen Angst kann nicht schaden.
Notfalls über ein Image kommt man immer wieder an solche Daten, bei "-o loop" kann man ein "offset" angeben wenn sich der Filesystemsuperblock nicht am Anfang des Images befinden sollte.

Müsste man sich die ersten paar Blöcke mal unter hexdump anschauen, um zu sehen was er da genau macht wenn man ein komplettes Device anstatt einer Partition verwendet. Wenn's heute nicht notwendig ist, machen wir das dann wenn es dem nächsten passiert

Ich werde villeicht mal eine VM ausetzen und das noch mal reproduzieren und dann mal ein bischen spielen. Die beiden Platten hängen schon wieder im neuen RAID und die gesicherten Daten werden auch schon wieder zurückkopiert. Die Sache ist also noch mal gut gegangen

ist heute gerade so schönes Wetter.
robi

Genau: Frohe Ostern!

 

[Anonymous]

Nur mal so zu Ergänzung und zur Info.

Apropos fdisk, ich nehme aufgrund der Version von fsck 1.41.14 an es ist das ein 11.4 . Das habe ich noch nicht installiert. Aber.

255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes

entweder du hast das unmögliche geschafft oder die haben an fdisk irgendwas gedreht, die normale Ausgabe und Einteilung die ich bei fdisk erwartet hätte, wäre hier eine Unitsgröße von 16065 × 512 = 8225280 Bytes wie das auch über 600 Mal im LC zu finden ist. Was du hier anzeigst hätte ich bei "fdisk -ul" erwartet und nicht bei "fdisk -l". Na vielleicht sind sie ja endlich mal schlau geworden und haben sich meine Warnungen und Ausschweifungen mal zu Herzen genommen.

musste jetzt doch mal genauer nachforschen, da ich den fdisk Befehl doch in einigen Scripten verbaut habe, und dieses doch enorme Auswirkungen zwischen den verschiedenen Versionen hat.

Die Änderung ist in util-linux-ng-2.18 gekommen. Wer fdisk in Scripten verwendet sollte für kompatible Ausgaben zwischen den unterschiedlichen Versionen die Option
"fdisk -lu" verwenden nicht "fdisk -l" und nicht "fdisk -ul" ( "-ul" führt in den neuen Versionen zum Fehler wegen falscher Optionen.)

robi

 

[framp]

..."fdisk -lu" verwenden nicht "fdisk -l" und nicht "fdisk -ul" ( "-ul" führt in den neuen Versionen zum Fehler wegen falscher Optionen.)...

Aus der Man page:

   fdisk -l [-u] [device...]
...
       -l     List the partition tables for the  specified  devices  and  then
              exit.   If no devices are given, those mentioned in /proc/parti‐
              tions (if that exists) are used.

       -u     When listing partition tables, give sizes in sectors instead  of
              cylinders.

Da hat es jemand sehr genau genommen ...

 

[josef-wien]

Du zitierst aus einer älteren manpage (z. B. zu fdisk (util-linux-ng 2.17.2) = openSUSE 11.3). Die aktuelle manpage zu fdisk (util-linux 2.19) = openSUSE 11.4 sieht anders aus:

-u[=unit]
When listing partition tables, show sizes in 'sectors' or in 'cylinders'. The default is to show sizes in sectors. For backward compatibility, it is possible to use the option without the <units> argument -- then the default is used. Note that the optional <unit> argument cannot be separated from the -u option by a space, the correct form is for example '-u=cylinders'.

Daher funktioniert, wie robi schon schrieb, die Parameter-Kombination -ul nicht mehr.

 

[framp]

Du zitierst aus einer älteren manpage

ps: Hast Recht. War zu faul mein openSuSE 11.4 zu booten und dachte mein Mint 10 hätte schon das aktuelle fdisk. ps:

 

[josef-wien]

Wieso "booten"? Ich kann aus meinem 11.3 auf die Dateien meiner 11.4-Probierpartition zugreifen und somit sowohl den neuen fdisk-Befehl ausführen als auch via konqueror (oder ark) auf die manpage zugreifen.

 

[framp]

Wieso "booten"? Ich kann aus meinem 11.3 auf die Dateien meiner 11.4-Probierpartition zugreifen und somit sowohl den neuen fdisk-Befehl ausführen als auch via konqueror (via ark klappt das Kopieren von Inhalten nicht) auf die manpage zugreifen.

:roll: Stimmt. Ein boot wäre nicht notwendig gewesen. Ein mount hätte es auch getan. ps:

 

[spoensche]

Oder eine Basisinstallation (es wird kein Kernel installiert) in ein Verzeichnis und per LXC booten oder einen Befehl ausführen.