На одном из серверов произвели замену материнской платы Supermicro и процессора на другие модели. Старые диски переставили, BIOS настроили, RAID1 на виртуальном контроллере определяется. Однако, система не загружается, мы попадаем в аварийную оболочку (initramfs). Это минимальный BusyBox-шелл, где крайне мало команд, но есть всё необходимое для диагностики и ручного запуска системы.
На старой материнской плате стоял чип Intel, поддерживающий технологию Intel RST (Rapid Storage Technology), Intel RSTe (Intel Rapid Enterprise) или Intel VROC (Virtual RAID on CPU). Мы собрали RAID массив из жёстких дисков. На новой материнской плате тоже есть поддержка Intel VROC, всё должно работать.
Проверим что диски обнаружены и являются членами RAID массива.
ls /dev/sd*
blkid | grep isw_raid_member
Видим:
/dev/sdb: TYPE="isw_raid_member"
/dev/sda: TYPE="isw_raid_member"
Видно оба диска, запись TYPE="isw_raid_member" означает, что диск является частью массива Intel Software RAID (также известного как Intel Rapid Storage Technology или IMSM). Такой тип массива также известен как Fake RAID. Это не полноценный аппаратный RAID (со своим процессором на контроллере) и не программный RAID (полностью на ОС). Это технология, встроенная в BIOS/UEFI материнских плат на чипсетах Intel. Она использует драйверы и CPU для управления массивом, но предоставляет ОС готовый логический том.
Современные дистрибутивы Linux используют mdadm для сборки таких массивов. Он полностью поддерживает формат Intel IMSM. Более старый инструмент dmraid, который сейчас считается устаревшим.
Проверим состояние массива.
cat /proc/mdstat
mdadm --detail --scan
Чаще всего, если массив не собрался, вы увидите что-то вроде md0 : inactive sda[0] sdb[1]. Это значит, что диски видны как отдельные, но не как единый массив. Однако, у меня массив собран, всё на вид прекрасно, оба диска в апе (статус [UU]).
- md126 — это и есть наш массив
- md127 — это контейнер метаданных Intel IMSM (не нужен для загрузки)
Найдём корневой раздел.
ls -la /dev/126*
Видим два раздела: /dev/md126p1 и /dev/md126p2. Посмотрим на них:
cat /proc/partitions | grep md
Можно проверить каждый найденный раздел.
blkid /dev/md126p1
blkid /dev/md126p2
Ищем раздел с TYPE="ext4" или TYPE="xfs". Однако, у нас всего два раздела с разным размером.
- md126p1 (1 ГБ) — почти наверняка это /boot
- md126p2 (~1.78 ТБ) — это корневой раздел /
Попробуем смонтировать раздел вручную.
mount /dev/md126p2 /root
И здесь мы понимаем, что проблема у нас именно в файловой системе, которая побилась. Это объясняет, почему система не загружается — она не может чисто смонтировать корневой раздел. Хорошая новость: данные скорее всего можно спасти. Плохая новость: нужно сначала восстановить файловую систему.
Демонтируем раздел.
umount /root
Запускаем проверку диска.
fsck -y /dev/md126p2
Утилита исправляет ошибки. Запустим проверку без исправлений ещё раз.
fsck /dev/md126p2
Отправляем систему в перезагрузку.
Как перезагрузиться из initramfs?
echo b > /proc/sysrq-trigger
После перезагрузки мне понадобилось запустить исправление ошибок ещё раз, после чего система заработала. Время ночное, пора собираться домой. Сервер реанимировали.
Вывод
Скорее всего, при замене материнской платы или предыдущих попытках загрузки были нештатные выключения, которые повредили файловую систему. fsck это исправил.
Источник:
Если вам понравилась статья, то ставьте 👍🏻 каналу. Пишите комментарии, задавайте вопросы, подписывайтесь.