Ошибка vfs unable to mount root fs on unknown block

Kernel panic not syncing: VFS: Unable to mount root fs

И много еще чего написано. Жаль, скрин сразу не сделал. Делаю ресет системе и снова вижу эту же ошибку. Тут запустилось производство кирпичей. В голове сразу же побежали мысли, что там с бэкапами. Делаться то они делаются, я даже уведомления в почте каждый день смотрю, что все в порядке. Но когда я последний раз вручную разворачивал эти бэкапы? Очень давно.

Еще один рестарт и та же ошибка. Немного запаниковал, встал, прошелся по комнате, подумал, что делать. Оценил обстановку. Больше всего испугался, что накрывается жесткий диск сервера, где куча всяких виртуалок и сайтов. Бэкапы вроде все есть, но все это настраивать, разворачивать, где-то сервак искать и т.д. В общем, думаю, примерно масштаб бедствия вы представляете.

Пошел на гипервизор, там вроде все в порядке, ошибок никаких нет. На других виртуалках тоже. С дисками, по идее, все нормально. А что же тогда тут случилось? В голову приходит мысль загрузиться на старом ядре. Выбираю старое ядро, загружаюсь — все в порядке. ОТЛЕГЛО.

Сразу стало понятно, в чем проблема. На серваке не хватало памяти. Я запустил обновление, оно отработало с ошибкой. Скорее всего не собрался initramfs для нового ядра. Загрузка старого ядра, в данном случае и было решением ошибки:

Kernel panic not syncing: VFS: Unable to mount root fs

Добавил виртуальной машине памяти, обновил ее еще раз. Теперь все прошло нормально. Перезагружаться пока не пробовал, вечером сделаю. Думаю, все в порядке будет.

Онлайн курсы по Mikrotik

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курсы по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Помимо официальной программы, в курсах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте .

Стоимость обучения весьма демократична, хорошая возможность получить новые знания в актуальной на сегодняшний день предметной области. Особенности курсов:

Знания, ориентированные на практику;
Реальные ситуации и задачи;
Лучшее из международных программ.

Выводы

Очень внимательно относитесь к обновлениям. Не запускайте их в обычном терминале по ssh. Если оборвется связь и обновление ядра не выполнится полностью, можете получить такую же проблему, как я сегодня. Обновляйтесь в screen или tmux.
Не торопитесь перезагружать сервер в случае проблем. Лучше сразу же сделать бэкап свежих данных, пока сервер еще живой. Так у вас как минимум, будут самые актуальные бэкапы, а не ночные. В принципе, я так всегда и делаю, но тут расслабился, так как сервер не сильно критичный и простой допускает.
Перед перезагрузкой убедитесь, что у вас есть доступ к терминалу. Я всегда это делаю.
И самый важный пункт — не занимайтесь обслуживанием сайтов, для которых недопустим простой. Нервы и спокойная жизнь дороже. Пусть это делает кто-то другой

Что делать с «vfs unable to mount root fs»

1. Загрузка из более старого ядра

После того, как система выдаст эту ошибку, случится Kernel Panic и компьютер перезагрузится. Вы снова окажетесь в меню загрузчика Grub. Здесь, первым делом, надо попытаться загрузиться с помощью более старого ядра. Для этого выберите пункт Дополнительные параметры и выберите одно из более старых ядер.

Если система в этом случае загрузится, то можно сделать вывод, что не работает только новое ядро. Если вы собирали его сами, то, возможно, вы не включили в него все необходимые для работы файловые системы. Если это ядро из репозиториев, и система загрузилась с более старым ядром, то можно предположить, что у вас повреждена initramfs для нового ядра. Это тоже могло произойти из-за недостатка памяти при обновлении системы. Чтобы всё исправить, вам достаточно освободить место в каталоге /boot/ и создать новую initramfs. Проверьте и освободите место в папке /boot, если его там мало:

У меня занято только 30%, если будет 100% — надо освобождать. Для создания initramfs сначала узнаем текущую версию ядра:

Затем вставляем полученную версию в такую команду:

Получится, например:

После завершения этой операции надо обновить конфигурацию Grub:

Если вы думаете, что проблема именно в свободном пространстве и initramfs, но загрузится с помощью более старого ядра не можете, то попробуйте другой LiveCD-дистрибутив и попытайтесь всё исправить в chroot-окружении.

2. Неверное имя корневого раздела Grub

Сейчас, в большинстве дистрибутивов, в конфигурационном файле Grub имя корневого раздела передается ядру в формате UUID. И с этим обстоятельством есть одна проблема. Если вы каким-либо образом измените корневой раздел, например, измените его размер, то UUID изменится. И если вы перезагрузитесь, не обновив конфигурацию Grub, то система больше не загрузится, потому что ядро попросту не сможет найти нужного раздела.

Но попытаться решить проблему можно. Если вы точно знаете, на каком разделе у вас находится корень, то можно прямо в меню Grub исправить конфигурацию. Для этого в меню выберете стрелками вверх и вниз нужный пункт, а затем нажмите кнопку E. Откроется редактор конфигурации. Вам нужно найти строчку, похожую на эту:

В ней надо заменить UUID=9d8d92de-74a6-4e64-8281-b8548c690e0c на обычное имя вашего корневого раздела, например, /dev/sda2. Для начала загрузки нажмите F10. Если система загрузится, значит проблема была именно в этом. В дальнейшем, можно просто обновить конфигурацию Grub:

Или даже попросить Grub больше не использовать UUID для обозначения корневого раздела:

Если ошибка исчезла, но система всё ещё не загружается, обратите внимание, что systemd всё ещё использует файл /etc/fstab для монтирования файловых систем. И если корневая файловая система (и не корневая тоже) там указана неверно, система не загрузится

Для исправления этой проблемы можно использовать режим восстановления Ubuntu. Здесь тоже надо заменить UUID на обычную запись или же на правильный UUID. Такая проблема очень часто становится причиной медленной загрузки Linux.

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

Host Operating System

NAME=Fedora
VERSION="31 (Workstation Edition)"
ID=fedora
VERSION_ID=31
VERSION_CODENAME=""
PLATFORM_ID="platform:f31"
PRETTY_NAME="Fedora 31 (Workstation Edition)"
ANSI_COLOR="0;34"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:31"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f31/system-administrators-guide/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=31
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=31
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Workstation Edition"
VARIANT_ID=workstation

Issue

I couldn’t connect to the machine, simply because the machine (VM) was having a kernel panic. So it make sense to not being able to ssh into it. However, I would expect maybe a better message, e.g. trying to first, rather than first. Anyways, here’s the kernel panic from inside the VM:

Message:

Note: use frame stepping and to see the actual message

I’ve noticed that there was no information about the disk of this VM:

virt-manager and going through the VM details:

Problematic XML says:

<disk type="file" device="disk">
  <driver name="qemu" type="qcow2" io="threads"/>
  <source file="/home/drpaneas/.crc/machines/crc/crc"/>
  <target dev="vda" bus="virtio"/>
  <address type="pci" domain="0x0000" bus="0x00" slot="0x05" function="0x0"/>
</disk>

Debugging

Digging deeper, I realised there was something wrong with the disk was allocating to the VM. See:

This happened due my custom settings:

# grep ^ /etc/libvirt/qemu.conf

security_default_confined = 0
user = "drpaneas"	# <--- put your normal user username
group = "libvirt"
dynamic_ownership = 1

After removing this configuration, then the listing was different:

-rw-------. 1 qemu     qemu     system_u:object_r:svirt_image_t:s0:c223,c1015 9973268480 Feb 16 17:41 crc

Also the was different. A and and that where missing before, they are now present:

Working XML:
<disk type="file" device="disk">
  <driver name="qemu" type="qcow2" io="threads"/>
  <source file="/home/drpaneas/.crc/machines/crc/crc"/>
  <backingStore/>
  <target dev="vda" bus="virtio"/>
  <alias name="virtio-disk0"/>
  <address type="pci" domain="0x0000" bus="0x00" slot="0x05" function="0x0"/>
</disk>

And also is reporting the size this time:

Workaround

Disable in KVM. I filling this as bug, mostly because I think you could add this to the documentation as part of the troubleshooting section. In case there is a it most likely has to do with — at least that was in my case.

2 ответа

Лучший ответ

Попробуйте добавить параметр bootwait командной строки ядра в bootargs, чтобы ядро не сразу сдавалось, а вместо этого ожидало, что корневая файловая система появится навсегда. Возможно, во время загрузки ядро не дожидалось появления SD-карты.

Serial Monkey
1 Ноя 2019 в 16:41

Возможно, вам нужно отложить, и может решить эту проблему. Тем не менее, это именно та ситуация, которую пытается решить initramfs, и это, по крайней мере, путь для отладки. Если вы создаете образ initramfs и присоединяете его к бинарному файлу Linux, вы можете использовать оболочку для проверки структуры разделов Linux и / или отложить монтирование rootfs, пока он не будет готов. В initramfs вы можете делать другие вещи, такие как добавление заставки, параллельно инфраструктуре USB, например, загрузка модулей обнаруженных устройств с монтированием rootfs. Это сделает вашу загрузку быстрее, а также даст вам инструмент для диагностики загрузки.

Также похоже, что u-boot не может видеть . Тот факт, что и u-boot, и Linux, похоже, жалуются, может указывать на то, что что-то пошло не так с генерацией раздела. Определенно полезно сравнить загрузочные журналы с известной рабочей версией, как было предложено опилками. Например, время / часы, расходные материалы или pinmux не могут быть установлены для MMC, и это может помешать распознаванию устройства. Кажется, у вас есть драйвер, но не устройство из журналов. Т.е. нет mmcblk0 ничего. Смотрите: для некоторых значений, которые вам может потребоваться определить для вашей платы. Тот факт, что Linux найден, может показаться противоречащим этому, но было бы полезно добавить записи устройства MMC, которые использует система. Я ожидаю некоторый вывод в журналах ядра. Другая возможность состоит в том, что что-то было построено как модуль и, как ожидается, загружается, чтобы сделать MMC доступной.

Получение минимального initramfs даст вам некоторые инструменты оболочки для диагностики. Вы можете использовать klibc или buildroot и т. Д. Для создания небольших initramfs, которые позволят вам осматривать узлы устройств Linux, значения proc и sysfs для диагностики. К сожалению, здесь есть много вещей, которые могут пойти не так. Однако, поскольку у вас есть загрузка Linux, добавление initramfs обычно не вызывает затруднений, даже если вы не сохраняете его для окончательной системы.

artless noise
2 Ноя 2019 в 17:29

Еще лучше — как восстановить ваш экземпляр …

После нескольких электронных писем я наконец получил ответ от службы поддержки, который позволил мне решить проблему. Помните, что вам придется что-то изменить, чтобы соответствовать вашей уникальной виртуальной машине.

Сначала сделайте снимок диска на случай, если нам понадобится откатить любое из изменений ниже. Отредактируйте свойства сломанного экземпляра, чтобы отключить этот параметр: «Удалять загрузочный диск при удалении экземпляра»
Удалите сломанный экземпляр

ВАЖНО: убедитесь, что не выбрана опция удаления загрузочного диска. В противном случае диск будет удален безвозвратно !!
Запустите новый временный экземпляр

Присоедините сломанный диск (он будет отображаться как ) к временному экземпляру Когда временный экземпляр загружен, сделайте следующее:

Во временном экземпляре:

Примечание: здесь ^^^ я отклонился от инструкций службы поддержки.

Вместо того чтобы изменять все загрузочные записи, чтобы установить , я поискал все записи, которые устанавливают , и удалил их. Я также удалил все записи, которые не устанавливали файл . В моем случае верхняя загрузочная запись с правильными параметрами оказалась 3.19.0-31-generic . Но ваш может быть другим.

Наконец, отсоедините жесткий диск от временного экземпляра и создайте новый экземпляр на основе фиксированного диска. Надеюсь, он загрузится.

Предполагая, что он загрузится, у вас будет много работы. Если у вас вдвое меньше неиспользуемых ядер, чем у меня, вы можете удалить неиспользуемые (тем более, что у некоторых, вероятно, отсутствует соответствующий файл initrd.img).

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

Примечание: убедитесь, что вы не очищаете ядро, с которым вы загрузились!

5 ответов

Лучший ответ

Я разобрался сам. Прошло некоторое время, но, насколько я помню, решение заключалось в том, чтобы предоставить начальный рамдиск. Вот так у меня получилось работать с аппаратным ускорением.

Включить паравирт в конфиге

Отключите сторожевой таймер NMI на HOST для использования счетчиков производительности на GUEST. Вы можете проигнорировать это.

—> см. http://kvm.et.redhat.com/page/Guest_PMU

Запуск в KVM

Путь к ядру: / home / username / compiled_kernel / bzImage Путь initrd: /home/username/compiled_kernel/initrd.img-3.2.46 Аргументы ядра: root = / dev / sda1

Надеюсь, это поможет, если у кого-то такие же проблемы.

Konstantin
12 Ноя 2014 в 15:05

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

Houcheng
30 Окт 2013 в 02:45

Это для AArch64 (arm64) на корпусе QEMU.

Я следил за этим хорошим руководством: https://ibug.io/blog/ 2019/04 / os-lab-1 /

В моем случае я получил такое сообщение об ошибке:

Я сделал в initrd.

Позже я заметил, что над этой строкой было сообщение об ошибке, означающее, что ядро не поддерживает RAM-диск. Итак, я отредактировал и установил следующие элементы:

И тогда проблема исчезла! Initrd был смонтирован на / dev / ram, и первый процесс инициализации работал нормально.

Оказывается, запуск не установил для меня эти значения по умолчанию.

Chan Kim
23 Фев 2021 в 04:55

Скорее всего, ядро не знает, с какого устройства нужно загрузиться. Вы можете указать это явно из командной строки qemu. Итак, если корень находится на разделе 2, вы можете сказать:

Обратите внимание, что я использую / dev / sda2 , хотя диск IDE. В настоящее время даже виртуальные машины используют SATA

Другие возможности заключаются в том, что, как говорит @Houcheng, ваша корневая FS повреждена или что в ядро не встроен этот конкретный тип FS. Но я думаю, что если бы это было так, вы бы получили другую ошибку.

Adrian Ratnapala
1 Ноя 2014 в 07:05

Версия QEMU

Запуск build-root 4.9.6 со следующими аргументами, которые нужно передать

Принимал только / dev / sda в качестве параметра для монтирования корневого fs (он покажет вам небольшую подсказку для параметра root fs, когда он загрузится и зависнет со следующей ошибкой):

Oleg Kokorin
10 Май 2017 в 08:53

Почему возникает ошибка «vfs unable to mount root fs»

Все ситуации, в которых может появиться сообщение «error: vfs unable to mount root fs» можно разделить на два вида:

Загрузка с жёсткого диска — вы загружаете свою основную операционную систему после внесения изменений в таблицу разделов, обновления или других действий, которые могли задеть диски;
Вы загружаете LiveCD-систему с оптического диска или флешки.

Второй вариант сразу же отбросим. Здесь исправлять нечего. Ошибка означает, что либо образ был битый, либо он был неверно записан на диск. А вот первый случай интереснее, рассмотрим основные причины, которые могут его вызывать:

Корневой раздел был переименован и теперь называется по другому;
Повреждена initramfs;
Ядро не поддерживает файловую систему корневого раздела;
Ошибка в конфигурации загрузчика, например, из-за недостаточного количества свободного места в папке /boot;
Файловая система корневого раздела повреждена.

Теперь давайте рассмотрим возможные пути решения проблемы.