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

Ошибка паники ядра

У нас есть выделенный сервер с программным RAID1, и один из дисков недавно вышел из строя. Диск был заменен, но после восстановления массива и перезагрузки сервер зависает с сообщением Kernel Panic

No filesystem could mount root, tried: reiserfs ext3 ext2 cramfs msdos vfat iso9660 romfs fuseblk xfs
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(9,1)

Файловая система на обоих дисках - ext4.

Кажется, ядро ​​не может загрузить поддержку ext4.

Есть ли способ добавить поддержку ext4 или мне нужно снова перекомпилировать новое ядро?

Интересный момент, что до замены диска все было нормально.

Ядро - стоковое ядро ​​bzImage-2.6.34.6-xxxx-grs-ipv6-64 от нашего провайдера OVH

Вот содержимое моего файла lilo.conf cat /etc/lilo.conf

lba32
boot=/dev/md1
raid-extra-boot=mbr-only
prompt
timeout=50

# Enable large memory mode.

large-memory
image=/boot/bzImage-2.6.34.6-xxxx-grs-ipv6-64
    label="Linux"
    root=/dev/md1
    read-only

Мне удалось решить проблему. После замены диска на новый диск не был установлен загрузочный код. Итак, я переустановил lilo, а затем снова перезагрузился. lilo -H -v Теперь все работает нормально.

По крайней мере, в grub2 вы можете указать загрузку нескольких модулей перед загрузкой .. см. http://grub.enbug.org/FranklinPiat/grub_modules.manpage

Использовал его для lvm. Но если вы скомпилировали ядро ​​из исходников, вы вообще компилировали поддержку ext4 ?? решение grub будет работать, только если вы скомпилировали ext4 как загружаемый модуль. если не везет ... надо перекомпилировать ...

Драйвер файловой системы также можно загрузить из файла initrd. Убедитесь, что grub (или любой другой загрузчик, который вы используете) загружает правильный initrd. Может вы загружаете старое ядро.

Если вы можете загрузиться с помощью системы восстановления, вы можете перестроить initrd.

Если бы я был там, где вы, я бы сначала попытался загрузить сервер с живого компакт-диска и посмотреть, все ли в порядке с рейдом. Если ядро ​​могло прочитать ext4 до сбоя диска, тогда оно должно иметь возможность прочитать его сейчас, поэтому я думаю, что может быть что-то еще не так, например, не удалось запустить рейд автоматически, файловая система повреждена или что-то в этом роде.

Интересно, что блочное устройство 9,1 действительно / dev / md1:

brw-r-----  1 root disk    9,     1 Feb 15 16:13 md1

Возможно ли, что устройства RAID были перенумерованы в результате аппаратного сбоя? Вы говорите, что у вас нет физического доступа к ядру, поэтому вы не можете загрузиться со съемного носителя (например, live CD), но вы опубликовали сообщение о панике ядра и предлагаете перестроить ядро, что будет сложно сделать, если вы не может поднять машину; поэтому я немного запутался в том, что вы можете и чего не можете делать, поэтому мне сложно дать вам варианты.

Вероятно, проблема не в ext4, потому что раньше он загружался из этой корневой файловой системы.

На данный момент я склонен подозревать, что текущее ядро ​​не имеет встроенной поддержки MD (не загружаемый модуль, но скомпилированный в). Сообщение, которое вы напечатаете, - это именно то, что я ожидал бы увидеть, если бы вы загрузили ядро, не поддерживающее md, но вы не говорите, что изменили это.

Итак, я должен спросить, во-первых: что вы изменили с момента последней успешной перезагрузки бокса, кроме жесткого диска? Вы упомянули "перекомпилировать новое ядро очередной раз", что заставляет меня задуматься, часто ли вы меняли ядро ​​в последнее время. Есть ли вероятность того, что вы оставили поддержку MD вне текущей? Можете ли вы предоставить нам" Поддержка нескольких устройств (RAID и LVM) "в файле конфигурации вашего текущего ядра?