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

Экземпляр Amazon EC2 не загружается: паника ядра - не синхронизируется: VFS: невозможно смонтировать корневую файловую систему на unknown-block (0,0)

Мой экземпляр работал годами и внезапно 1 июня перестал отвечать. Я пытался перезагрузить его, но он не загружался. Выдал ошибки в системном журнале: https://pastebin.com/rSxr1kLs

Версия Linux 2.6.32-642.11.1.el6.x86_64 (mockbuild@c1bm.rdu2.centos.org) (gcc версия 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)) # 1 SMP пт, 18 ноября 19:25:05 UTC 2016
Командная строка ядра: root = / dev / xvde ro LANG = en_US.UTF-8 KEYTABLE = us
VFS: не удается открыть корневое устройство "xvde" или unknown-block (0,0)
Добавьте правильный вариант загрузки "root ="; вот доступные разделы:
Паника ядра - не синхронизируется: VFS: невозможно смонтировать корневую файловую систему на unknown-block (0,0)

Я попытался отсоединить том EBS и снова прикрепить его как /dev/sda1 по документации: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html#FilesystemKernel

Однако это дало ошибку Error attaching volume: Invalid value '/dev/sda1' for unixDevice. Attachment point /dev/sda1 is already in use и я не смог его прикрепить. Я прикрепил его как /dev/sda но он все равно не загружается и по-прежнему выдает ошибку в системном журнале.

Мне удалось запустить новый экземпляр в той же зоне доступности и подключить свой том EBS как /dev/sdf. Он отображается внутри экземпляра как /dev/xvdj. Я установил это с mount /dev/xvdj /xvdj. Я вижу grub.conf файл:

[root@ip-172-31-4-249 grub]# cat /xvdj/boot/grub/grub.conf
default=0
timeout=1

title CentOS (2.6.32-642.11.1.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-642.11.1.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
title CentOS (2.6.32-504.30.3.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-504.30.3.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
        initrd /boot/initramfs-2.6.32-504.30.3.el6.x86_64.img
title CentOS (2.6.32-504.3.3.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-504.3.3.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
        initrd /boot/initramfs-2.6.32-504.3.3.el6.x86_64.img
title CentOS (2.6.32-504.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-504.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
        initrd /boot/initramfs-2.6.32-504.el6.x86_64.img
title CentOS (2.6.32-431.29.2.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-431.29.2.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
        initrd /boot/initramfs-2.6.32-431.29.2.el6.x86_64.img
title CentOS (2.6.32-431.23.3.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-431.23.3.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
        initrd /boot/initramfs-2.6.32-431.23.3.el6.x86_64.img

Это по сравнению с grub.conf работающего экземпляра:

[root@ip-172-31-4-249 grub]# cat /boot/grub/grub.conf
default=0
timeout=1

title CentOS-6-x86_64-20130527-03 2.6.32-358.6.2.el6.x86_64
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-358.6.2.el6.x86_64 root=/dev/xvde ro
        initrd /boot/initramfs-2.6.32-358.6.2.el6.x86_64.img

Имеет ли значение, что в нем нет initrd строка в первом варианте?

Я попытался подключить том EBS к новому экземпляру с помощью /dev/sda, но он все равно не загружается с той же ошибкой Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0).

CentOS 6

Я создал новый экземпляр, перейдя в «Изображения»> «AMI»> «Частные изображения»> «Выбор изображения, с которого был запущен экземпляр»> «Запустить». Я запускал точно в той же зоне доступности, не только в США или регионе, но 2a, 2b, 2c также должны совпадать. Остановил новый экземпляр. Я отключил том EBS от старого экземпляра. Я повторно подключил том EBS к новому экземпляру в /dev/sdf. Завел новый экземпляр. Том EBS отображается внутри экземпляра как /dev/xvdj поэтому я установил его с mkdir /xvdj; mount /dev/xvdj /xvdj. Я редактировал /xvdj/boot/grub/grub.conf и изменил default=0 к default=1. Я сохранил файл, остановил новый экземпляр, повторно подключил том EBS к старому экземпляру, и он запустился. Я побежал yum update в старом экземпляре и перепроверил /boot/grub/grub.conf и дважды проверил, что он перезагружается.

Я также нашел это относительно обновлений ядра CentOS: grub.conf отсутствует путь initrd после обновления ядра

Я заметил после того, как побежал yum update У меня теперь было 2 записи в grub.conf без initrd. Бег # yum reinstall kernel.x86_64 работает, чтобы исправить это.

У меня была такая же проблема несколько раз, и мне приходилось решать ее, восстанавливая экземпляр из резервных копий моментальных снимков EBS. Сегодня у меня была такая же проблема, и я решил решить ее без восстановления из резервных копий. Я сделал следующее:

  1. Отсоедините корневой том от отказавшего экземпляра / dev / sda1.
  2. Присоедините том к рабочему экземпляру и смонтируйте том (например, mount /dev/xvdh /xvdhmount)
  3. Сделайте резервную копию загрузочной папки: mv /xvdhmount/boot /xvdhmount/boot-backup
  4. Из рабочего экземпляра с той же версией ОС в моем случае RHEL 7.4 скопируйте все содержимое папки / boot через SCP или WinScp в / xvdhmount /.
  5. Отсоедините том от рабочего экземпляра и снова подключите его к отказавшему экземпляру.
  6. Запустите неудачный экземпляр .... экземпляр загрузился, и я могу войти в систему.

Надеюсь, это поможет!

У меня была аналогичная проблема с экземпляром CentOS. Эта статья службы поддержки AWS дает неплохой обзор. Вот как мне и удалось решить свою проблему:

  • Выключите исходный экземпляр EC2, а затем отсоедините /dev/sda1 диск
  • Запустите новый временный экземпляр EC2 и подключите диск как /dev/sdp к новому экземпляру EC2
  • SSH в новый экземпляр EC2 и смонтировать /dev/sdp к /data

Затем я хотел вернуться к предыдущему ядру. Инструкции на CentOS вики были полезны:

  • Перечислить все записи Grub с помощью grep "^menuentry" /data/boot/grub2/grub.cfg | cut -d "'" -f2
  • Выбрал второй сверху, в моем случае это был CentOS Linux (3.10.0-957.12.1.el7.x86_64) 7 (Core)
  • Настройте загрузку по умолчанию с помощью grub2-set-default --boot-directory /data/boot/ 'CentOS Linux (3.10.0-957.12.1.el7.x86_64) 7 (Core)'

Затем выключите новый экземпляр EC2, отсоедините том, снова подключите его к исходному экземпляру (чтобы /dev/sda1) и загрузите начальный экземпляр.

Я столкнулся с аналогичной проблемой, и оказалось, что значения по умолчанию AWS EC2 отличаются для запуска экземпляра и создания AMI: в первом случае по умолчанию используется аппаратная виртуализация (HVM), но для создания образов по умолчанию используется паравиртуальная (PV).

Я наткнулся на это, когда попытался переместить экземпляр EC2 между зонами доступности, сделав снимок его тома EBS и создав новый AMI, и это несоответствие в настройках (на которое я тоже не обратил внимания) потратило для меня час.

tl; dr: просто выберите HVM при запуске из настроенного AMI, и ваш экземпляр должен загрузиться нормально.

Мне кажется, что ваше ядро ​​было обновлено таким образом, что оно больше не понимает вашу корневую файловую систему. Лучше всего создать новый узел и смонтировать том EBS из старого. как некорневой / не загрузочный устройство и передать важные данные.

Я тоже!

Основная причина была прервана yum upgrade и младший сотрудник, выполняющий работу, снова подключился и побежал yum-complete-transactions доделать все.

Однако что-то не записало файл в /boot/initrd....newver.... что, вероятно, было связано с последней записью ядра в grub2.cfg отсутствует его initrd=/.... линия полностью.

Быстрое решение заключалось в том, чтобы повторно подключить том загрузочного диска к другому экземпляру, смонтировать его и отредактировать. /mountpoint/etc/grub2.cfg так что экземпляр запускает старую версию ядра. Затем снова отключите и снова подключите к /dev/sda1 оригинального экземпляра.

ПРИМЕЧАНИЕ. В последнее время было трудно подключить загрузочный том centos к другой машине centos, потому что UUID на корневом томе такой же. Обходной путь - использовать другую ОС в качестве временной машины, например Debian для исправлений диска CentOS.

Как только вы снова войдете, бегите yum reinstall kernel* повторить пропущенные шаги и по завершении перезагрузить компьютер снова, чтобы убедиться, что на этот раз он правильно перезагружается с использованием новейшего ядра.