Tengo ubuntu raid5 en 4 discos de 1 tb que no tuvieron un apagado sucio ni problemas de energía. El disco de arranque es el quinto disco que no está en mdadm. También tengo XP en mi disco de arranque que acabo de iniciar hoy. XP no puede montar mdadm o no toca el disco, o eso pensé.
Desde que cerró XP, Ubuntu no arranca porque tal vez fstab lo esté bloqueando ya que no puede montar /dev/md0 después de esperar. Ahora no puedo acceder a mi instalación original de Ubuntu.
Así que eliminé a todos los miembros de mi raid, los puse a todos en mi compartimiento de disco externo e inicié ubuntu en mi macbook para realizar la recuperación.
/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)
Cuando intento fuerza de montaje:
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
de 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)
Supongo que de alguna manera el arranque de XP debe haber tocado estos miembros del disco y, por lo tanto, la magia difiere.
He visto la opción para --createuna nueva matriz, pero no estoy seguro de si se perderán datos. en segundo lugar, si se crea en un ubuntu diff, ¿se reanudará el trabajo en el otro ubuntu?
¿No existe una manera fácil de verificar la integridad y restablecer la suma de verificación para todos los miembros? Por favor recomiende. Gracias.
Respuesta1
encontréeste hilo de correo electrónico, que parece describir el mismo problema que el tuyo.
La solución para esa persona fue ejecutar este comando:
sudo mdadm -A --update=super-minor /dev/md0
Ese usuario escribió:
Lo descubrí yo mismo a través de algunas investigaciones a través de las fuentes de mdadm. Parece que mdadm borra automáticamente el archivo de mapa de bits en busca de un mapa de bits no válido cuando lee el superbloque (sin embargo, el núcleo no lo hace). Entonces, todo lo que necesita hacer es encontrar una manera para que mdadm guarde ese superbloque en el disco. El comando mágico que solucionó el problema fue:
mdadm -A --update=super-minor /dev/md0El comando --update obliga a mdadm a guardar el superbloque raid en el disco antes de intentar montar el disco y, por lo tanto, se borra el indicador de mapa de bits.
Sin embargo , ese usuario tenía una versión de metadatos 00.90.01y, según lamdadm(8)página de manual:
súper menorsólo es relevante para los metadatos v0.90
Esto significa que debes actualizar elnombrede la matriz en 1.2los superbloques de su versión más nueva en lugar delsúper menor, que no existe para los metadatos de la versión 1.
Desde la página de manual:
-U,--actualizar=
Actualice el superbloque en cada dispositivo mientras ensambla la matriz. El argumento dado a esta bandera puede ser uno desparc2.2, resúmenes,UUID,nombre,anfitrión,resincronizar,orden de bytes,tamaño del dispositivo, sin mapa de bits, osúper menor.
…
ElnombreLa opción cambiará elnombrede la matriz almacenada en el superbloque. Esto solo es compatible con superbloques de la versión 1.