mdadm wird aufgrund eines Prüfsummenfehlers nicht geladen
587
thevikas
Ich habe Ubuntu Raid5 auf 4 Festplatten von 1 TB-Platten, die kein schmutziges Herunterfahren oder Stromproblem hatten. Die Bootdiskette ist die fünfte Platte, die sich nicht auf mdadm befindet. Ich habe auch XP auf meiner Bootdiskette, mit der ich heute angefangen habe. XP kann mdadm nicht mounten oder die Festplatte nicht berühren, dachte ich.
Seit dem Schließen von XP wird ubuntu nicht booten, weil fstab es möglicherweise blockiert, da / dev / md0 nach dem Warten nicht geladen werden kann. Jetzt kann ich nicht in meine ursprüngliche Ubuntu-Installation einsteigen.
Also entfernte ich alle meine Schlachtzugsmitglieder und legte sie alle in meinen externen Festplattenschacht und startete Ubuntu in meinem Macbook, 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 Montagekraft 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
Meine Vermutung ist irgendwie, dass der XP-Boot diese Festplattenmitglieder berührt haben muss und die Magie sich unterscheidet.
Ich habe Option für --createneues Array gesehen, aber ich bin mir nicht sicher, ob es zu Datenverlust kommen wird. Zweitens: Wenn Sie auf einem diff ubuntu erstellen, wird er auf dem anderen ubuntu weiterarbeiten?
Gibt es keine einfache Möglichkeit, die Integrität zu überprüfen und die Prüfsumme für alle Mitglieder zurückzusetzen? Bitte vorschlagen. Vielen Dank.
Die Lösung für diese Person war, diesen Befehl auszuführen:
sudo mdadm -A --update=super-minor /dev/md0
Dieser Benutzer schrieb:
Ich habe das selbst herausgefunden, als ich die Mdadm-Quellen durchging. Es scheint, dass mdadm die Bitmap-Datei automatisch für eine ungültige Bitmap löscht, wenn der Superblock gelesen wird (der Kernel jedoch nicht). Sie müssen also nur einen Weg finden, wie mdadm diesen Superblock auf die Festplatte zurückspeichert. Der magische Befehl für mich, der das Problem behoben hat, war:
mdadm -A --update=super-minor /dev/md0
Der Befehl --update zwingt mdadm, den Raid-Superblock auf der Festplatte zu speichern, bevor er versucht, die Festplatte zu mounten, und das Bitmap-Flag wird daher gelöscht.
Dieser Benutzer hatte jedoch eine Metadatenversion 00.90.01und laut mdadm(8)Manpage :
Super-Minor ist nur für v0.90-Metadaten relevant
Dies bedeutet, dass Sie den Namen des Arrays in den 1.2Superblöcken der neueren Version anstelle des Super-Minor aktualisieren sollten, der für Metadaten der Version 1 nicht vorhanden ist.
Aus der Manpage:
-U, --update =
Aktualisieren Sie den Superblock auf jedem Gerät, während Sie das Array zusammenstellen. Das Argument dieser Flag gegeben kann einer der folgenden sein sparc2.2, Zusammenfassungen, UUID, name, homehost, Resync, byteorder, device, no-Bitmap oder super-minor .
…
Der Name Option wird den ändern Name des Arrays, wie in dem Superblock gespeichert. Dies wird nur für Superblöcke der Version 1 unterstützt.
"Mdadm: --update = super-minor wird für 1.x-Metadaten nicht verstanden"
thevikas vor 6 Jahren
0
"--update = name" funktionierte und ich hatte ein aktives Schlachtzugs-Setup und ließ es auch auf meinem Orig-Rechner laufen. Vielen Dank
thevikas vor 6 Jahren
0
@thevikas: Ich habe meine Antwort korrigiert, um mich auf Metadaten Version 1.2 zu beziehen
Deltik vor 6 Jahren
0