mdadm не будет монтироваться из-за ошибки контрольной суммы

390
thevikas

У меня Ubuntu raid5 на 4 дисках по 1 ТБ, у которых не было грязного отключения или проблемы с питанием. Загрузочный диск - это 5-й диск, которого нет на mdadm. У меня также есть XP на моем загрузочном диске, который я только начал сегодня. 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, он возобновит работу на другой Ubuntu?

Нет ли простого способа проверить целостность и сбросить контрольную сумму для всех участников? Пожалуйста, предложите. Благодарю.

0

1 ответ на вопрос

1
Deltik

Я нашел эту ветку электронной почты, которая, кажется, описывает ту же проблему, что и ваша.

Решением для этого человека было запустить эту команду:

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

Этот пользователь написал:

Я понял это сам через некоторое время в источниках mdadm. Кажется, что mdadm очищает файл битовой карты автоматически для недопустимой битовой карты, когда он читает суперблок (однако ядро ​​этого не делает). Поэтому все, что вам нужно сделать, - это найти способ mdadm сохранить этот суперблок на диске. Волшебная команда для меня, которая исправила проблему, была:

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

Команда --update заставляет mdadm сохранить суперблок raid на диск, прежде чем он попытается смонтировать диск, и, следовательно, флаг растрового изображения будет сброшен.

У этого пользователя была версия метаданных 00.90.01, и согласно mdadm(8)справочной странице :

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

Это означает, что вы должны обновить имя массива в ваших 1.2суперблоках новой версии вместо супер-минорного, который не существует для метаданных версии-1.

Со страницы руководства:

-U, --update =

Обновите суперблок на каждом устройстве при сборке массива. Аргумент, данный этому флагу, может быть одним из следующих: sparc2.2, резюме, uuid, name, homehost, resync, byteorder, deviceize, no-bitmap или super-minor .

...

Опция name изменит имя массива, хранящееся в суперблоке. Это поддерживается только для суперблоков версии 1.

Получение `mdadm: --update = super-minor не понято для метаданных 1.x` thevikas 6 лет назад 0
`--update = name` сработало, и у меня была активная настройка raid, и она также работала на моей машине orig. Спасибо thevikas 6 лет назад 0
@thevikas: я исправил свой ответ, чтобы применить к метаданным версии 1.2 Deltik 6 лет назад 0

Похожие вопросы