mdadm не буде монтувати через помилку контрольної суми

У мене є ubuntu raid5 на 4 дисках 1tb дисків, які не мали брудного вимкнення або харчування. Bootdisk - це п'ятий диск, який не знаходиться на mdadm. У мене також є XP на мій bootdisk, який я тільки що почав сьогодні. XP не може встановити mdadm або не торкнеться диска, або так я думав.

Оскільки закриття XP, ubuntu не буде викликати причину, можливо, fstab блокує його, оскільки він не може змонтувати / dev / md0 після очікування. Тепер я не можу потрапити в мою оригінальну установку ubuntu.

Так що я видалив всіх моїх рейдів членів і поклав їх все в моєму зовнішньому дисковому відсіку і почав ubuntu в моєму MacBook зробити відновлення.

/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)

Коли я намагаюся примусово:

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

з 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)

Я припускаю, що завантаження XP, мабуть, торкнулася цих дисків і магія відрізняється.

Я бачив варіант --create новий масив, але я не впевнений, що він матиме втрату даних. по-друге, якщо створювати на diff убунту, чи буде він відновити роботу на іншому ubuntu?

Чи не є простий спосіб просто перевірити цілісність і скинути контрольну суму для всіх членів? Будь ласка, запропонуйте. Дякую.

я знайшов цей потік електронної пошти , яка, здається, описує ту ж саму проблему, що і ваша.

Рішення для цієї особи - це запустити цю команду:

sudo mdadm -A --update=super-minor /dev/md0

Цей користувач написав:

Я зрозумів це з себе через деякий sleuthing через mdadm джерела. Здається, mdadm автоматично очищає растровий файл для недійсного растрового зображення, коли він читає суперблок (ядро, однак, не). Отже, все, що вам потрібно зробити, це знайти спосіб для mdadm, щоб зберегти назад цей суперблок на диск. Магічною командою для мене, яка вирішила проблему, було:

mdadm -A --update=super-minor /dev/md0

Команда --update змушує mdadm зберегти назад супер-блок рейду на диск, перш ніж він спробує змонтувати диск, і, отже, прапорець растрового зображення буде очищено.

Цей користувач мав версію метаданих 00.90.01хоч і відповідно до mdadm(8) сторінка людини :

супер-мінор стосується лише метаданих v0.90

Це означає, що ви повинні оновити ім'я масиву у новій версії 1.2 superblocks замість супер-мінор , що не існує для метаданих версії 1.

На сторінці man:

-U , --update =

Оновлюйте суперблок на кожному пристрої під час збирання масиву. Аргумент, наданий цьому прапору, може бути одним з sparc2.2 , резюме , uuid , ім'я , homehost , resync , byteorder , пристрою , немає бітової карти або супер-мінор .

…

The ім'я опція змінить ім'я масиву, що зберігається в суперблоку. Це підтримується лише для верхніх блоків версії-1.