Главная >> Инструкции >> Ошибка vfs unable to mount root fs on unknown block

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

Сообщение об ошибке "vfs unable to mount root fs on unknown block" может встречается во время загрузки Linux. Оно означает, что ядро не может примонтировать корневую файловую систему, и, следовательно, дальнейшая загрузка невозможна. Ошибка довольно серьёзная и, не исправив её, вы не сможете полноценно работать в своей операционной системе.

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


Содержание статьи

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

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

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

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

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

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

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

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

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

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

df -h | grep boot

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

uname -r

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

sudo update-initramfs -u -k версия

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

sudo update-initramfs -u -k 4.15.0-36-generic

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

sudo update-grub

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

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

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

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

linux /boot/vmlinuz-4.15.0-36-generic root=UUID=9d8d92de-74a6-4e64-8281-b8548c690e0c ro quiet splash $vt_handoff

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

sudo update-grub

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

sudo vi /etc/default/grub

GRUB_DISABLE_LINUX_UUID=true

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

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

Выводы

В этой статье мы рассмотрели, как исправить ошибку "vfs unable to mount root fs on unknown block". Как видите, несмотря на то, что ошибка достаточно сложная, с нею достаточно просто разобраться. Надеюсь, эта информация была вам полезной.

Оцените статью

Звёзд: 1Звёзд: 2Звёзд: 3Звёзд: 4Звёзд: 5 (6 оценок, среднее: 5,00 из 5)
Загрузка...
Creative Commons License
Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .

6 комментариев к “Ошибка vfs unable to mount root fs on unknown block”

  1. В ней надо заменить UUID=9d8d92de-74a6-4e64-8281-b8548c690e0c на обычное имя вашего корневого раздела, например, /dev/sda2 - тоже не вариант.
    Делать лучше всего так:
    root@debian:[/home/robert]: 22.11.2018 Четверг 16:39
    # lsblk -f
    NAME FSTYPE LABEL UUID MOUNTPOINT
    sda
    └─sda1 ext4 51091e97-06fd-452f-b327-2e4b5dea29d8 /
    sr0
    root@debian:[/home/robert]: 22.11.2018 Четверг 16:39
    # e2label /dev/sda1 Debian
    # lsblk -f
    NAME FSTYPE LABEL UUID MOUNTPOINT
    sda
    └─sda1 ext4 Debian 51091e97-06fd-452f-b327-2e4b5dea29d8 /

    В /etc/fstab записываем следующее:
    # cat /etc/fstab-2
    #UUID=51091e97-06fd-452f-b327-2e4b5dea29d8 / ext4 errors=remount-ro 0 1
    LABEL=Debian / ext4 errors=remount-ro 0 1

    Удачи и приятной работы!

    Ответить
  2. Добрый день, на днях была такая проблема, обновлял сервер по ssh и отвалился конект) ядро новое не грузилось, благо старое работало! Под старым удалил новое, повторно обновился и все гуд)

    Ответить
  3. Всем привет!
    Есть еще один способ как решить данную ошибку.
    В загрузчике просто грузитесь из старого ядра ( который был до обновления и точно рабочий)
    И просто вызываете команду sudo dpkg --configure -a
    Он обновить все пакеты установленные в системе и новое ядро должно загрузиться.
    Вдруг кому поможет.

    Ответить
  4. Хорошая статья.
    Получилось запустить систему через старое ядро.
    Далее обнаружил, что boot заполнен на 97%.
    Удалил самые старые ядра до того, через которое запустил систему.
    Но через самое свежее ядро все равно не удавалось запустить систему, оно стояло как-то криво, не обновлялось и не удалялось.

    На другом форуме нашел решение:
    sudo apt -f install

    После этой простой команды все встало на свои места и сразу после перезагрузки система запустилась через последнее ядро.

    Ответить
  5. Я пользуюсь windows 10, через программу Unetbootin хотел установить себе Manjaro но выходит эта ошибка а все эти команды с sudo работают только в Linux похоже, как исправить?

    Ответить

Оставьте комментарий