Проблема одновременного использование kernel raid autodetect для / на /dev/md0 и superblock v1.2 для других /dev/md, или как можно уронить (и поднять) сервер после его обновления

Спасибо, что дочитали заголовок. Это был тест.

Сегодня, после наката очередных обновления на свой любимый Gentoo сервер и профилактического reboot’a, внезапно, отвалился /dev/md1 со словами мудрого ядра: sdc1 does not have a valid v0.90 superblock, not importing!

Шок! Паника! хорошо, что не в ядре…

А в чём, собственно, дело?

Для начала расскажу о конфигурации сервера, чтобы было легче понять суть проблемы и способ её решения. Итак, ядро 3.10.7 с включённым RAID autodetect и двумя RAID1 (зеркало) дисками.

На /dev/md0 монтируется root, на /dev/md1 база данных (Percona):

db13 ~ # cat /etc/fstab | grep md /dev/md0                /               ext3            noatime         0 1 /dev/md1                /mnt/db         reiser4         noatime         0 0 

И кусочек /boot/grub/grub.conf:

title Gentoo Linux 3.10.7 md0 root (hd0,0) kernel /boot/kernel-3.10.7 root=/dev/md0 

Так вот, для успешной сборки md устройств ядром во время загрузки должно быть выполнено два условия:

1. Тип 0xFD у партиций, на которых строится RAID
2. Версия формата superblock 0.90 на устройстве /dev/md, которое создается при помощи mdadm

Если с п.1. в моей конфигурации все было хорошо, то, как оказалось, формат superblock был 1.2 Подозреваю, что /dev/md1 я создавал после того, как пришла новая версия mdadm, которая по-умолчанию использует именно этот формат. Как результат, ядро ругается страшными словами:

[    0.000000] Command line: root=/dev/md0 raid=/dev/md0 [    0.000000] Kernel command line: root=/dev/md0 raid=/dev/md0 [    1.063603] md: raid1 personality registered for level 1 [    1.266420] md: Waiting for all devices to be available before autodetect [    1.266494] md: If you don't use raid, use raid=noautodetect [    1.266781] md: Autodetecting RAID arrays. [    1.293670] md: invalid raid superblock magic on sdc1 

[    1.294210] md: sdc1 does not have a valid v0.90 superblock, not importing! [    1.312482] md: invalid raid superblock magic on sdd1 [    1.312556] md: sdd1 does not have a valid v0.90 superblock, not importing!

 [    1.312579] md: Scanned 4 and added 2 devices. [    1.312595] md: autorun ... [    1.312610] md: considering sdb3 ... [    1.312626] md:  adding sdb3 ... [    1.312641] md:  adding sda3 ... [    1.312657] md: created md0 [    1.312665] md: bind<sda3> [    1.312754] md: bind<sdb3> [    1.312770] md: running: <sdb3><sda3> [    1.313064] md/raid1:md0: active with 2 out of 2 mirrors [    1.313166] md0: detected capacity change from 0 to 7984840704 [    1.313262] md: ... autorun DONE. [    1.320413]  md0: unknown partition table [    1.338528] EXT3-fs (md0): mounted filesystem with ordered data mode [    2.581420] systemd-udevd[861]: starting version 208 [    3.122748] md: bind<sdc1> [    4.896331] EXT3-fs (md0): using internal journal 

Когда не помогает Google

Выбор совсем небольшой — либо отключать автоопределение массивов в ядре (перекомпиляция и правки в grub.conf), либо изменять формат суперблока (полный бэкап данных и убийство зеркала с последующим его восстановлением). Оба варианта «не вариант», так как по сути своей деструктивны и могут привести к потери данных, да и времени могут занять немало (как выяснилось в процессе поиска решения kernel autodetect is depricated feature)

К слову сказать, после старта севрера /dev/md1 прекрасно запускается при помощи команды

mdadm --manage /dev/md1 --run

. Конечно, можно было бы прописать эту строчку куда-нибудь в rc-скрипты, но, согласитесь, это как-то не спортивно.

Эврика!

Решение пришло не сразу, хотя лежало на поверхности — всё, что нужно сделать, это убрать тип 0xFD (заменить на 0х83) у дисков в /dev/md1 и тогда ядро перестанет безуспешно пытаться собрать этот массив, мешая пр этом udevd делать свою работу. И действительно, после применения fdisk для изменения типа партиций на обеих зеркалах и перезагрузки сервера, все чудесным образом завелось:

 [    0.000000] Command line: root=/dev/md0 raid=/dev/md0 [    0.000000] Kernel command line: root=/dev/md0 raid=/dev/md0 [    1.063924] md: raid1 personality registered for level 1 [    1.248078] md: Waiting for all devices to be available before autodetect [    1.248201] md: If you don't use raid, use raid=noautodetect [    1.248504] md: Autodetecting RAID arrays. [    1.265058] md: Scanned 2 and added 2 devices. [    1.265243] md: autorun ... [    1.265258] md: considering sda3 ... [    1.265274] md:  adding sda3 ... [    1.265290] md:  adding sdb3 ... [    1.265305] md: created md0 [    1.265321] md: bind<sdb3> [    1.265331] md: bind<sda3> [    1.265428] md: running: <sda3><sdb3> [    1.265865] md/raid1:md0: active with 2 out of 2 mirrors [    1.265891] md0: detected capacity change from 0 to 7984840704 [    1.266068] md: ... autorun DONE. [    1.276627]  md0: unknown partition table [    1.294892] EXT3-fs (md0): mounted filesystem with ordered data mode 

[    2.713383] systemd-udevd[860]: starting version 208 [    3.128295] md: bind<sdc1> [    3.159107] md: bind<sdd1> [    3.170320] md/raid1:md1: active with 2 out of 2 mirrors [    3.170333] md1: detected capacity change from 0 to 17170300928 [    3.178113]  md1: unknown partition table [    4.911712] EXT3-fs (md0): using internal journal [    5.027077] reiser4: md1: found disk format 4.0.0. 

Буду рад, если Google, найдя этот текст, покажет его моим коллегам по цеху, попавшим в похожую ситуацию.