[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debian: sdc1 fehlt in /dev/ nach Upgrade auf Squeeze


Hallo,

On 15.02.2011, at 08:17, Markus Hochholdinger wrote:

> Hallo,
> 
> Am 15.02.2011 um 07:44 Uhr schrieb Peter Mueller <peter.o.mueller@xxxxxx>:
> [..]
>>> damit ist Dein RAID1-Verbund inkonsistent!
> 
> das bestaetigt sich nun, siehe unten!
> 
> [..]
>> Mdadm.conf
> [..]
>> # definitions of existing MD arrays
>> ARRAY /dev/md0 UUID=bdedd91a:6dd172b3:bd1ac19b:fae98e89
>> ARRAY /dev/md0 UUID=e2d804f1:d66b3dd1:4b3e927c:18479999
> 
> Du hast damit zweimal /dev/md0 definiert, allerdings mit unterschiedlicher 
> UUID! Der erste gewinnt!?
> 
> 
>>> Ausserdem mal den Output von folgenden Befehlen:
> 
> Ich denke mein Verdacht bestaetigt sich hiermit. Du siehst den Unterschied 
> zwischen sdb und sdc? sdc hat einen Superblock (fuer die ganze Platte) waehrend 
> sdb dies nicht hat! bei sdb steht der Superblock in der ersten Partition 
> sdb1.
> 
> 
>>> mdadm -E /dev/sdb
>> mdadm -E /dev/sdb
>> mdadm: No md superblock detected on /dev/sdb.
> 
> Das war zu erwarten.
> 
> 
>>> mdadm -E /dev/sdb1
>> mdadm -E /dev/sdb1
>> /dev/sdb1:
>>          Magic : a92b4efc
>>        Version : 0.90.00
>>           UUID : e2d804f1:d66b3dd1:4b3e927c:18479999
> 
> Das scheint das zweite definierte md0 zu sein!?
> 
> 
>>> mdadm -E /dev/sdc
>> mdadm -E /dev/sdc
> 
> Ich haette es wirklich nicht geglaubt, aber die Indizien sprachen dafuer! Du 
> hast irgendwie sdc (und nicht sdc1) in einen RAID-Verbund genommen!
> 
> 
>> /dev/sdc:
>>          Magic : a92b4efc
>>        Version : 0.90.00
>>           UUID : bdedd91a:6dd172b3:bd1ac19b:fae98e89
> 
> Die erste Definition von md0!
> 
> 
>>> mdadm -E /dev/sdc1
>> mdadm: cannot open /dev/sdc1: No such file or directory
> 
> OK, ohne Device-Node gibt es fuer mdadm bei sdc1 nichts zum anfassen.
> 
> 
>>> mdadm -D /dev/md0
>> mdadm -D /dev/md0
>> mdadm: md device /dev/md0 does not appear to be active.
> 
> Ich vermute hier sehr stark Sicherungsmassnahmen von mdadm bzw. dem 
> Linux-Software-RAID.
> 
> Er scheint zu erkennen dass hier etwas komisches passiert und laesst es einfach 
> sein. Sowieso besser so, da Du auch schonmal manuel gemountet hast!
> 
> Ich vermute was auch immer auf sdc war ist nun Datenmuell.
> Ich vermute Deine Nutzdaten sind noch auf sdb1 korrekt erhalten.
> 
> Was ich nun machen wuerde (mir root-Rechten):
> * Wenn Dir die Daten wichtig sind, Kopiere sdc mit dd irgendwo hin, z.B. auf
>  eine andere Platte. (Wer weiss, vielleicht liege ich falsch und alle Daten
>  waren auf sdc korrekt anstatt sdb1!)
> * Entferne in der Konfiguration alles was auf die uuid
>  bdedd91a:6dd172b3:bd1ac19b:fae98e89 verweist (sdc).
> * "Reset" von sdc:
>    mdadm --zero-superblock /dev/sdc # Superblock auf sdc loeschen
>    fdisk /dev/sdc #Partition neu erstellen, evtl. Neustart danach?
>    mdadm --zero-superblock /dev/sdc1 # Superblock auf sdc1 loeschen
> * md0 starten:
>    mdadm --assemble /dev/md0 /dev/sdb1 # evtl. mit forcce nachhelfen!?
> * RAID1-Rebuild durchfuehren:
>    mdadm --add /dev/md0 /dev/sdc1
> 
> Mit obigen Schritten bleiben die Daten auf sdb1 erhalten, waehrend ALLES was 
> auf sdc ist wird ueberschrieben! Verwenden darfst Du nach dem letzten Befehl 
> aber nurnoch /dev/md0 zum mounten (siehe Deine fstab, welche korrekt 
> ausschaut).
> 


danke fuer all die Antworten. Inzwischen laeuft der Abgleich der beiden Platten wieder.
Da habe ich wohl nochmal Glueck gehabt.

 cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 sdc1[2] sdb1[0]
      244195904 blocks [2/1] [U_]
      [======>..............]  recovery = 30.4% (74422016/244195904) finish=201.2min speed=14062K/sec
      



Gruss,
Peter Mueller


-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/