Назад | Перейти на главную страницу

Массив rootfs в Linux случайно не удается собрать

У меня есть машина под управлением Arch x86_64 2.6.30.

Его корень установлен в массиве raid5, автоматически монтируемом в / dev / md0.
Это делается с помощью параметров ядра следующим образом:
kernel /vmlinuz26 md=0,/dev/sda3,/dev/sdb3,/dev/sdc3 md=2,/dev/sda2,/dev/sdb2,/dev/sdc2 rootfstype=ext4 root=/dev/md0 ro

Раньше это работало нормально, но иногда не удавалось собрать массив md0.
Что происходит, так это то, что все идет нормально, ядро ​​проверяет идентификаторы блоков, находит совпадения, а затем ждет сборки массива 10 секунд.

Обычно это делается мгновенно, однако иногда он ждет 10 секунд, после чего истекает время ожидания и отключается на консоль восстановления, которую я не могу использовать, потому что она не принимает никаких вводимых данных. Я думаю, это может быть потому, что единственные доступные мне клавиатуры - это USB-клавиатуры (даже если клавиатура работает в меню GRUB).

Когда это произойдет, мне просто нужно перезагрузиться, и массив будет смонтирован нормально.

Кстати, это происходит примерно в 30% случаев.
Бывает после чистых отключений.
Это может случиться более одного раза подряд.

Поскольку он не может смонтировать rootfs, он не может писать ни в какие журналы.

Кто-нибудь видел что-нибудь подобное?
Есть идеи, почему это может происходить?

Когда вы совершаете набег на разделы, вы можете проверить, что все они помечены как разделы Linux Raid Auto-detect (Тип FD), а не как Linux (Тип 83). Если вы не меняете размер раздела, вы можете смело изменять тип с помощью выбранного редактора разделов. Если вы чувствуете себя особенно параноиком, просто делайте один раздел за раз, чтобы не уничтожить весь рейд.

Ваше ядро ​​достаточно современно, так что, если в нем есть соответствующий модуль mdadm, встроенный или поставляемый в initrd, оно будет сканировать все доступные разделы. Если он находит раздел типа FD, он проверяет наличие суперблока mdadm. Все разделы с одинаковым идентификатором raid будут автоматически повторно собраны без необходимости явно указывать его при загрузке.

Вы также можете продолжать определять его, но я бы начал с проверки всех типов разделов FD, а затем отбросил определение рейда и посмотрел, поможет ли оно.

без даже скриншота ошибки, думаю, никто не может сказать наверняка. Лучшее, что вы можете сделать, это ввести initrd в вашу систему и преобразовать процесс загрузки для использования UUID вместо имен устройств (которые могут быть изменены, например, если вы забыли свой флеш-накопитель в любом из слотов USB).

Я предполагаю, что, возможно, ваше ядро ​​просто переупорядочивает имена дисков, поскольку обычно оно просто назначает имена в порядке очереди, без чего-то вроде udev для переименования.

Я предлагаю использовать initrd, поставляемый с udev, чтобы вы могли убедиться, что диски названы правильно. Было бы еще более безопасным, если бы вы использовали udev (или что-то подобное, созданное на заказ), а затем просто смонтируете диски через / dev / disk / by-uuid /, поскольку они обычно не меняются.