Ich habe Ubuntu Raid5 auf 4 1-TB-Festplatten, die weder ein Dirty Shutdown noch ein Stromproblem hatten. Die Bootdiskette ist die 5. Festplatte, die nicht auf mdadm läuft. Ich habe auch XP auf meiner Bootdiskette, die ich heute erst gestartet habe. XP kann mdadm nicht mounten oder berührt die Festplatte nicht, dachte ich zumindest.
Seit dem Schließen von XP bootet Ubuntu nicht mehr, weil es vielleicht von fstab blockiert wird, da es /dev/md0 nach dem Warten nicht mounten kann. Jetzt kann ich nicht mehr in meine ursprüngliche Ubuntu-Installation gelangen.
Also habe ich alle meine RAID-Mitglieder entfernt und sie alle in meinen externen Festplattenschacht gesteckt und Ubuntu auf meinem MacBook gestartet, um die Wiederherstellung durchzuführen.
/dev/sdh:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 05143452:9d98ca6b:c59a91b5:fda8b846
Name : vikas-VirtualBox:0
Creation Time : Sat Dec 31 17:31:47 2016
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 1953263024 (931.39 GiB 1000.07 GB)
Array Size : 2929889280 (2794.16 GiB 3000.21 GB)
Used Dev Size : 1953259520 (931.39 GiB 1000.07 GB)
Data Offset : 259072 sectors
Super Offset : 8 sectors
Unused Space : before=258984 sectors, after=6576 sectors
State : clean
Device UUID : b0cc00bc:b20c2671:1eb062bc:28eb229b
Internal Bitmap : 8 sectors from superblock
Update Time : Fri Aug 11 17:08:49 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 846ac784 - correct
Events : 18840
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
===============================
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 05143452:9d98ca6b:c59a91b5:fda8b846
Name : vikas-VirtualBox:0
Creation Time : Sat Dec 31 17:31:47 2016
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 1953259520 (931.39 GiB 1000.07 GB)
Array Size : 2929889280 (2794.16 GiB 3000.21 GB)
Data Offset : 259072 sectors
Super Offset : 8 sectors
Unused Space : before=258984 sectors, after=3072 sectors
State : clean
Device UUID : a36f72c1:d4ec55f0:e4a4ff8a:19a0d659
Update Time : Fri Aug 11 17:08:49 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 965ce69e - expected 965ce69d
Events : 18840
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
===============================
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 05143452:9d98ca6b:c59a91b5:fda8b846
Name : vikas-VirtualBox:0
Creation Time : Sat Dec 31 17:31:47 2016
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 1953259520 (931.39 GiB 1000.07 GB)
Array Size : 2929889280 (2794.16 GiB 3000.21 GB)
Data Offset : 259072 sectors
Super Offset : 8 sectors
Unused Space : before=258984 sectors, after=3072 sectors
State : clean
Device UUID : 04920971:8ce054dc:4756516d:07eedc84
Update Time : Fri Aug 11 17:08:49 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 3f4afc07 - expected 3f4afc06
Events : 18840
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
===============================
/dev/sdi:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 05143452:9d98ca6b:c59a91b5:fda8b846
Name : vikas-VirtualBox:0
Creation Time : Sat Dec 31 17:31:47 2016
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 1953263024 (931.39 GiB 1000.07 GB)
Array Size : 2929889280 (2794.16 GiB 3000.21 GB)
Used Dev Size : 1953259520 (931.39 GiB 1000.07 GB)
Data Offset : 259072 sectors
Super Offset : 8 sectors
Unused Space : before=258984 sectors, after=6576 sectors
State : clean
Device UUID : 426c61e9:ea61c2f3:cf27167c:09807918
Internal Bitmap : 8 sectors from superblock
Update Time : Fri Aug 11 17:08:49 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 7171c8e1 - correct
Events : 18840
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 3
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
Wenn ich Assemblerkraft versuche:
sudo mdadm --assemble /dev/md0 --verbose --force --run /dev/sde1 /dev/sdf1 /dev/sdh /dev/sdi
mdadm: looking for devices for /dev/md0
mdadm: /dev/sde1 is identified as a member of /dev/md0, slot 0.
mdadm: /dev/sdf1 is identified as a member of /dev/md0, slot 1.
mdadm: /dev/sdh is identified as a member of /dev/md0, slot 2.
mdadm: /dev/sdi is identified as a member of /dev/md0, slot 3.
mdadm: added /dev/sdf1 to /dev/md0 as 1
mdadm: added /dev/sdh to /dev/md0 as 2
mdadm: added /dev/sdi to /dev/md0 as 3
mdadm: added /dev/sde1 to /dev/md0 as 0
mdadm: failed to RUN_ARRAY /dev/md0: Invalid argument
von dmesg:
[ 2208.363750] RAID conf printout:
[ 2208.363752] --- level:5 rd:4 wd:4
[ 2208.363755] disk 0, o:1, dev:sde1
[ 2208.363758] disk 1, o:1, dev:sdf1
[ 2208.363760] disk 2, o:1, dev:sdh
[ 2208.363763] disk 3, o:1, dev:sdi
[ 2208.363994] md0: invalid bitmap file superblock: bad magic
[ 2208.363997] md0: bitmap file superblock:
[ 2208.364000] magic: ff88ffff
[ 2208.364002] version: 11
[ 2208.364005] uuid: 00000000.00000000.00000000.00000000
[ 2208.364007] events: 0
[ 2208.364009] events cleared: 0
[ 2208.364012] state: 00000000
[ 2208.364014] chunksize: 0 B
[ 2208.364016] daemon sleep: 0s
[ 2208.364018] sync size: 0 KB
[ 2208.364020] max write behind: 0
[ 2208.364023] md0: failed to create bitmap (-22)
Ich vermute, dass diese Datenträgerelemente beim Booten von XP irgendwie berührt worden sein müssen und die Magie daher anders funktioniert.
Ich habe die Option für --createein neues Array gesehen, bin mir aber nicht sicher, ob es dabei zu Datenverlust kommt. Und zweitens: Wird die Erstellung auf einem anderen Ubuntu fortgesetzt, wenn es auf dem anderen Ubuntu erstellt wird?
Gibt es keine einfache Möglichkeit, die Integrität zu überprüfen und die Prüfsumme für alle Mitglieder zurückzusetzen? Bitte machen Sie Vorschläge. Danke.
Antwort1
ich fanddieser E-Mail-Thread, das scheint dasselbe Problem zu beschreiben wie Ihres.
Die Lösung für diese Person bestand darin, diesen Befehl auszuführen:
sudo mdadm -A --update=super-minor /dev/md0
Dieser Benutzer schrieb:
Ich habe das selbst herausgefunden, indem ich die mdadm-Quellen durchforstet habe. Es scheint, dass mdadm die Bitmap-Datei automatisch von ungültigen Bitmaps befreit, wenn es den Superblock liest (der Kernel tut das jedoch nicht). Sie müssen also nur einen Weg finden, wie mdadm diesen Superblock wieder auf der Festplatte speichern kann. Der magische Befehl, der das Problem für mich behoben hat, war:
mdadm -A --update=super-minor /dev/md0Der Befehl --update zwingt mdadm, den RAID-Superblock wieder auf der Festplatte zu speichern, bevor es versucht, die Festplatte zu mounten. Dadurch wird das Bitmap-Flag gelöscht.
Dieser Benutzer hatte jedoch die Metadatenversion 00.90.01und lautmdadm(8)manpage:
Super-Mollist nur für v0.90 Metadaten relevant
Das bedeutet, Sie sollten dieNamedes Arrays in Ihren neueren Version 1.2Superblöcke anstelle derSuper-Moll, die für Metadaten der Version 1 nicht existiert.
Aus der Manpage:
-U,--update=
Aktualisieren Sie den Superblock auf jedem Gerät, während Sie das Array zusammenstellen. Das Argument für dieses Flag kann eines der folgenden sein:sparc2.2, Zusammenfassungen,UUID,Name,Gastgeber,erneut synchronisieren,Bytereihenfolge,Gerätegröße, kein Bitmap, oderSuper-Moll.
…
DerNameOption ändert dieNamedes Arrays, wie es im Superblock gespeichert ist. Dies wird nur für Superblöcke der Version 1 unterstützt.