Засада в mdadm’е

Не, ну почему я всё время наступаю на грабли??

На сервере, где живёт мой блог (и кучка других сайтов) немножко попортились диски. Ясное дело, диски не вечные, рано или поздно они все помирают, тем более, что тут они уже много лет работали круглосуточно. Хорошо, что я с самого начала собрал их в RAID1. Места стало вдвое меньше, но в общем хватало. Зато надёжность повысилась. Не будь там этого зеркала, сейчас бы много данных пропало.

Короче, когда это обнаружилось, я послал хостеру (Hetzner) запрос на замену первого диска. Они поставили новый буквально через пару часов.
Загрузил сервер по сети (это у Hetzner’а очень удобно организовано: на веб-сайте можно выбрать операционную систему для загрузки по сети, а также послать в сервер Ctrl-Alt-Del или аппаратный Reset, не обращаясь в службу техподдержки). Новый диск оказался на треть больше, чем старый, поэтому я решил не цеплять его к старому RAID’у, а сделать новый. Казалось бы, ничего сложного в этом нет. Создал раздел почти на весь диск, потом попробовал создать на нём новый RAID1, и тут mdadm выдал предупреждение, что его суперблоки версий 1.* не все загрузчики понимают, так что может быть стоит использовать версию 0.90. Посмотрел на старый диск, там была версия 0.90. Значит, имеющийся grub её точно понимает.

Ну и создал RAID по имени md2 с опцией --metadata=0.90, потом на нём physical volume под LVM, volume group, и пачку logical volumes, как на старых дисках, только чуть покрупнее, раз диск побольше. Отформатировал новые файловые системы, скопировал содержимое со старого диска, зашёл туда через chroot, подправил fstab и mdadm.conf, перегенерировал загрузочный образ и grub.cfg, установил grub на новый диск. Казалось бы, всё готово, должно работать. Перезагрузил сервер, а он не отзывается даже на пинги. Значит, что-то не склалось..

Загрузился снова по сети, и тут.. pvdisplay нового тома не видит, только старый. Попробовал ему явно указать на /dev/md2, а он говорит, что не может его прочитать. Запустил fdisk -l /dev/md2, а он говорит, что этот md2 нулевого размера, ни одного сектора там нет. Ну, думаю, что-то там сломалось, наверное, надо пересоздать. Запустил mdadm --remove /dev/md2, а он внезапно заявляет, что mdadm: error opening /dev/md2: No such file or directory.

Посмотрел в /dev/, есть там md2, но mdadm его почему-то в упор не видит. Что тут делать? Разве что попробовать пересобрать этот RAID. И вот тут mdadm --assemble --scan выдал:
mdadm: WARNING /dev/sda1 and /dev/sda appear to have very similar superblocks.
If they are really different, please --zero the superblock on one
If they are the same or overlap, please remove one from the
DEVICE list in mdadm.conf.

Запустил mdadm --examine /dev/sda1 и mdadm --examine /dev/sda, в натуре, показывают совершенно одинаковые суперблоки.. Как такое может быть?? Видать, один и тот же суперблок почему-то читается и с sda, и с sda1. Попробовал его обнулить на /dev/sda, а он пропал и с /dev/sda1. Значит, и вправду один и тот же был.

Пошёл по второму кругу, создал RAID заново, вроде как всё выглядит нормально: суперблок читается только с sda1, md2 вполне доступен, pvcreate на нём сработал, pvdisplay видит. Перегрузил машину, и опять та же фигня: одинаковый суперблок читается с обоих устройств, поэтому /dev/md2 хоть и есть, но ни к чему не прицеплен.

Погуглил, оказалось, что это дефект суперблока версии 0.90. Хотя я решительно не понимаю, как такое может быть.. Разница в каких-то байтиках внутри блока, а он из-за этого почему-то читается не только с раздела, а ещё и с целого диска. Ну, может эти версии ещё и в разных местах пишутся, но на старых дисках та же версия 0.90, а такой засады там не возникало.

Что тут поделать.. Пересоздал RAID в очередной раз, не указывая –metadata. Суперблок получился версии 1.2, но и после перезагрузки обнаруживался только на sda1, как положено. Пересоздал логические тома, отформатировал, заново скопировал данные со старого диска (а это примерно 2 часа, хоть и копировал через dump | restore), установил grub, перегрузил машину, она успешно загрузилась, но.. со старого диска!

Оказалось, что я забыл перегенерировать загрузочный образ и grub.cfg, и grub всё честно загрузил со старых файловых систем.

Сгенерировал новый grub.cfg, перегрузил машину, не работает.. Пошёл смотреть, оказалось, что в новом grub.cfg пропали все insmod. И вместо UUID’ов везде ссылки только на /dev/mapper/, которые в grub’е вряд ли имеют смысл. Попробовал переделать это всё вручную, чтоб было, как в старом grub.cfg, но с новыми UUID’ами , всё равно не помогло.

Похоже, дефекты в grub.cfg возникли из-за того, что он генерировался хоть и из-под chroot’а, но в загруженном по сети линуксе. А он в Hetzner’е очень свежий, там ядро уже 4 версии, и всё остальное, видимо, тоже поновее.

В конце концов я эту проблему решил, система успешно загрузилась с нового диска, после чего я послал заявку на замену второго диска, его поменяли буквально через 15 минут, я его добавил в этот md2, и теперь он потихоньку синхронизируется. А вот КАК я это сделал, оставлю задачкой для системных администраторов.

Но всё равно это хождение по граблям заняло почти сутки, что для такой простой задачи сильно много :(


You can read this post at LiveJournal.
This entry was posted in Uncategorized and tagged , , , , , , . Bookmark the permalink.

One Response to Засада в mdadm’е

  1. Pingback: Засада в mdadm’е | Linux Reports

Leave a Reply