Linux kernel panic vfs unable to mount root fs on

Ошибка 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, если его там мало:

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

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

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

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

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

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

Читайте также:  1с включить технологический журнал linux

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:

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

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

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

Выводы

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

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.

Источник

Knowledge Base:Unable to mount root fs

When booting a freshly configured kernel, the boot fails with the following message:

  1. Detect the controller for the hard disk (a likely candidate if the message says unknown-block(0,0));
  2. Detect the partition because it does not have support for the partition type (less likely, but still possible);
  3. Mount the partition because it does not know how to access the file system (a likely candidate if the message gives a non-zero figure in the first number set, such as unknown-block(2,0));
  4. Detect the partition because the wrong device was passed in the boot loader configuration.
  • Ensure that the controller chipset has been configured in the Linux kernel (and in-kernel, not as a module);
  • Ensure that the used file systems (such as ext2, ext3, ext4, ReiserFS, Btrfs, etc.) are configured in the Linux kernel (and built into the kernel, not as a module);
  • When using root=UUID=. , an initramfs must be built when configuring the bootloader, see «Configuring the linux kernel» of the installation handbook
  • If running Gentoo as a Qemu guest, ensure that the virtio block drivers and PCI driver for virtio devices are enabled in the kernel (that is, CONFIG_VIRTIO_BLK=y and CONFIG_VIRTIO_PCI=y in the kernel configuration file).
  • When an initramfs is not used and the root filesystem specified on the kernel command line is on an MTD device (such as an NVME drive), it may be necessary to make the kernel wait for asynchronous initialization of the device by adding either rootdelay= (to timeout if the device is never detected) or rootwait (to wait without timeout).

When using an initramfs and upgrade to another kernel version, make sure the initramfs is recreated correctly in /boot for the new kernel version and that the boot loader configuration refers to the correct initramfs.

  • Эта страница в последний раз была отредактирована 7 июля 2021 в 12:41.
  • Политика конфиденциальности
  • О Gentoo Wiki
  • Отказ от ответственности

© 2001–2023 Gentoo Authors
Gentoo is a trademark of the Gentoo Foundation, Inc. The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-4.0 license. The Gentoo Name and Logo Usage Guidelines apply.

Источник

Kernel panic - unable to mount root fs after upgrade to 20.04

I got prompted to upgrade to 20.04 on my 19.10 Ubuntu machine. (Linux only, no dualboot) After upgrading, I immediately got presented a white screen saying "Oh no! Something has gone wrong - Please log out and try again" . I could not figure out how to log out so I restarted my Notebook. After restart I got the error:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) 

I also was not able to use an older kernel via grub, same white error screen appears. I just reloaded a snapshot with a live-usb. Is there a way to fix this beforehand? Is something in my current installation broken? I have a pretty basic ubuntu 19.10 installation and expected the upgrade to run smoothly. I've seen solutions like https://www.geekswarrior.com/2019/07/solved-how-to-fix-kernel-panic-on-linux.html however I did not test them yet. I wanted to use this notebook as consumer-like as possible. So is there any way I configured something wrong beforehand? Or is there any way to officially report this as a bug? Or is it really specific to my notebook-model/setup?

2 Answers 2

I had this on every or nearly every update from Ubuntu 19.10 to 20.04. No crazy old devices or anything, just plain VMs or bare metal with standard hardware. So I'm wondering why they obviously didn't even test the happy path of a normal upgrade from 19.10 to 20.04, as it HAS to work on a fresh release, no excuses. "Wait for the first point release" is an advice for the LTS to LTS upgrade.

However, leasts-pain-solution for the people without USB-Sticks at hand is:

  • Hold SHIFT during boot to get GRUB menu (it will appear after the first failed boot automatically, though)
  • Choose "Advanced options for Ubuntu"
  • Choose the older kernel in recovery mode (Linux 5.3.0-51-generic (recovery mode))
  • In the Recovery Menu, choose "dpkg - Repair broken packages"
  • After repair, reboot. Hold SHIFT again
  • Now choose "Advanced options for Ubuntu"/older Kernel again, this time WITHOUT recovery mode
  • System should now properly boot with GUI. uname -a will show the old kernel 5.3.0
  • Simply reboot again
  • System should now magically boot with GUI and the new 5.4.0 Kernel

Thank you for your answer! I just wanted to try it, and gave the update another go. and it just went through. I have no idea why. I got some weird messages on a black screen after the update-process (sorry, I don't remember :/ ) but after a forced restart everything is up and running.

So I'm wondering why they obviously didn't even test the happy path of a normal upgrade . the LTS upgrade is basically a joke. Too many broken things.

During upgrade did you get prompt to upgrade/keep grub? Normal releases aren't as stable as LTS. Ubuntu 19.10 to 20.04 isn't as stable as 18.04 to 20.04. I've done a few 19.10 jumps without issue, but I don't keep any old files during upgrade process. For all operating systems upgrade it is always best practice to wait a few months before upgrading. For Ubuntu the recommendation is wait until 20.04.1 is released (23 July).

Источник

Arch Linux in virutalbox: kernel panic-not syncing: VFS: unable to mount root fs on unknown block(0,0)

I installed Arch Linux from arch linux evolution-image to a virtual device. I tested the installation with GRUB MBR and GRUB efi. Inside virtualbox, I can see the grub menu, but when I select Arch Linux it gives me a

2 Answers 2

I had a wrong fstab generated by genfstab (as pointed out here). So the kernel (please correct me, if this is wrong) didn't find my root-partition.

I generated fstab with labels and had a partition with a space in it. In fstab this must be written with \040 . genfstab wrote garbage for the space.

Other answeres suggest to run update-initramfs -u -k version , however this command is replaced by mkinitcpio .

To get the system running I did this:

  • I ran grub-mkcofnig -o /boot/grub/grub.cfg (probably not important in this case)
  • after that I booted into grub-menu and pressed c for the grub-shell I started Arch Linux manually by entering the following commands: insmod linux insmod ext2 (this works for ext3 and ext4, too or enter your filesystem-driver) set root=(hd0, 2) (enter your partiton-number starting from 1) linux /boot/vmlinuz-linux root=/dev/sda2 (again select your partition) initrd /boot/initramfs-linux.img boot
  • correct /etc/fstab (make sure spaces are expressed as \040 )

Since you asked :). When you use an initrd, the kernel isn't what finds the root device. "unable to mount root fs on unknown block(0,0)" tends to mean an initrd wasn't (successfully) loaded when it needed to be. I wonder if you were missing an initrd at that point. If the initrd fails to find the root filesystem then it is different; the initrd tends to provide a nice little shell prompt, to see if you can do any better finding for it :). I researched this in the last section of my answer here: unix.stackexchange.com/questions/453272/…

@sourcejedi . and the initrd is found by grub (or any other bootloader), so the fstab is not read at this point. I can’t tell with this much time in between anymore. But I understand, that you say, that the error message doesn’t match with what I‘ve diagnosed.

Or just check that you wrote initrd correctly in your config file. (Yeah, this is a note for my future-self)

Источник

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