не синхронизируется vfs, невозможно смонтировать root fs на unknown-block (0 0)

Есть и третья причина, которая оказалась моей проблемой:

Обычно в каждом пункте меню grub есть строка 'linux...' и строка 'initrd....'.

Поскольку у меня не хватило места в /boot, я удалил файл initrd...., запустил update -initramfs для другой версии ядра, но забыл запустить update -grub, который будет обновлять соответствующие записи.

Я исправил это, вручную добавив строку в меню загрузки во время последовательности загрузки, затем сделал ее постоянной после входа в систему и смог запустить обновление -grub.

Существуют различные факторы, которые могут вызвать такую ​​панику ядра. Поскольку вы используете grub2, я настоятельно рекомендую запускать команды оболочки grub вручную (. Вы всегда можете обратиться к командам в файле /boot/grub/grub.cfg )Обычно у вас есть такие команды, как:

    set prefix=...
    set root=...
    # you can test if values above are set correctly by simply run `ls` here
    # and see whether errors show up
    linux /...
    initrd /...

запускайте приведенные выше команды одну за другой, и если что-то пойдет не так, возвращенное сообщение об ошибке даст вам подсказку о том, что не так в вашей системе. Затем погуглите сообщение об ошибке, чтобы найти решение.

У меня была такая же проблема после обновления ядра. Смонтируйте соответствующий диск ISO или CD/DVD и выполните восстановление. Например, я смонтировал DVD CentOS7 и сделал это:

mount --bind /proc /mnt/sysimage/proc
mount --bind /dev  /mnt/sysimage/dev
mount --bind /sys  /mnt/sysimage/sys
chroot /mnt/sysimage

Затем найти последние initramfs из /boot и перегенерировать их, ну в данном случае:

dracut -f /boot/initramfs-2.6.32-754.14.2.el6.x86_64.img initramfs-2.6.32-754.14.2.el6.x86_64

После перезагрузки вин все работает.

По-видимому, это может произойти, если вы также не выделили достаточно памяти для своей виртуальной машины. Я понял, что у меня установлена ​​​​память на 320 МБ, а не на 32 ГБ.

это решилось после изменения базовой памяти со 128 МБ до 2 ГБ

Только сегодня столкнулся с этой проблемой, когда принял обновление ядра.
Решил это, освободив место на диске загрузочного раздела (для тех, у кого есть раздел /boot)

. Это может работать иначе для других в зависимости от того, как они настроили свои разделы диска.
Просто освободите место, если оно заполнено там, где существуют файлы ядра, или удалите старые ядра и обновите grub

Шаги:

1. Проверьте, используется ли ваш /bootболее 90% с помощью команды терминала df -h
   
2. Перезагрузите компьютер и в меню Grub выберитеAdvanced options...
   
3. Выберите второе ядро ​​сверху списка и загрузитесь с ним. Войдите в систему и откройте терминал какroot
   
4. Введите эту команду, чтобы получить список всех ядер:dpkg --list | grep linux-image. Во втором столбце вывода указаны имена образов ядра. например linux-image-4.19.0-10-amd64или linux-image-4.19.0-10-generic. Обратите внимание на старые изображения, которые вы хотите удалить (, за исключением первых двух и последней записи в списке, согласно моему опыту ).
   
5. Используйте эту команду для очистки изображений:apt-get purge linux-image-4.19.0-5-amd64. Заменять linux-image-4.19.0-5-amd64с изображением, которое вы хотите удалить из списка. Повторите этот шаг для каждого изображения, предназначенного для очистки.
   
6. Обновление Grub с помощью команды терминала:update-grub2
   
7. Перезагрузите ПК командой терминала :reboot.
   
8. В Grub разрешите загрузку новейшего ядра Linux.
   
   Спасите день

Процедура полной диагностики на основе сообщений ядра

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

В этой простой настройке QEMU эмулирует систему с:

• один виртуальный диск, который представляет собой жесткий диск или твердотельный накопитель реального оборудования
• на этом виртуальном диске есть необработанный неразмеченный образ ext4. При нормальной работе это устройство будет отображаться под/dev/vda(v— это буква-индикатор для virtio, если бы оно было разбито на разделы, разделы были бы /dev/vda1, /dev/vda2и т. д.)

Возможные ошибки, которые вы можете получить::

1. Linux не может прочитать байты с диска.

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

   В моем случае QEMU я могу воспроизвести это, удалив ключевые параметры, которые позволяют ядру читать этот виртуальный диск:

   CONFIG_VIRTIO_BLK=y
   CONFIG_VIRTIO_PCI=y
   

   Полученное сообщение об ошибке выглядит следующим образом

   <4>[    0.541708] VFS: Cannot open root device "vda" or unknown-block(0,0): error -6
   <4>[    0.542035] Please append a correct "root=" boot option; here are the available partitions:
   <0>[    0.542562] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
   

   Итак, здесь Linux говорит нам, что вообще не может читать из vda по адресу:VFS: Cannot open root device "vda" or unknown-block(0,0): error -6.

   Затем в Please append a correct "root=" boot option; here are the available partitions:выдается список разделов, которые он может прочитать.

   Однако в нашем случае список пуст, поскольку следующая строка совершенно не связана.

2. Linux может читать байты с диска, но не понимает файловую систему, чтобы читать с него файлы.

   Обычно это происходит потому, что вы не настроили ядро ​​для чтения этого типа файловой системы.

   Я могу достичь этого случая, лишив ядро ​​возможности читать файловую систему ext4:

   CONFIG_EXT4_FS=y
   

   При удалении сообщения об ошибке:

   <4>[    0.585296] List of all partitions:
   <4>[    0.585913] fe00          524288 vda
   <4>[    0.586123]  driver: virtio_blk
   <4>[    0.586471] No filesystem could mount root, tried:
   <4>[    0.586497]  squashfs
   <4>[    0.586724]
   <0>[    0.587360] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,0)
   

   Итак, Linux сообщает нам, что ему удалось найти раздел vda, прочитав диск с помощью устройства virtio_blk.

   Но тогда он не смог прочитать этот раздел. Он попытался squashfs,это единственная другая файловая система, которую мы включили, но это не сработало, потому что у нас есть раздел ext4.

3. Вы передали неверный root=параметр командной строки ядра.

   Это просто, просто передайте правильный! Ядро даже дает вам список тех, о которых оно знает!

   Например, если мы ошиблись:

   root=/dev/vda2
   

   которой даже не существует, ядро ​​выдает ошибку вида:

   <4>[    0.608475] Please append a correct "root=" boot option; here are the available partitions:
   <4>[    0.609563] fe00          524288 vda
   <4>[    0.609723]  driver: virtio_blk
   <0>[    0.610433] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,2)
   

   поляна говорит нам, что "эй :нет vda2, но есть vda!"

   Этот пример также хорошо поясняет, что означают (0,0), (254,0)и (254,2)из предыдущих случаев:

   • (0,0):первая цифра 0 означает, что чтение с диска вообще невозможно
   • (254,2):254 — это некоторый идентификатор, присвоенный диску. 2— это раздел с этим идентификатором, как в /dev/vda2. И раздел 0означает необработанный неразделенный -раздел, как в /dev/vda.

Протестировано на Linux 5.4.3.

Думаю, я нашел другое решение.

У меня была точно такая же проблема с Debian вместо Kali. У меня была новая установка Windows 10, второй Manjaro и третий Debian. Решение находится внизу.

Как я узнал о решении:

После того, как я установил Debian, grub сменился на grub Debian вместо Manjaro, как и должно быть. Но я получил ошибку, как на картинке, опубликованной в вопросе выше.

Однако с «Super Grub2 Disk» на USB я смог загрузиться в Manjaro.

Когда я загружаюсь с "Super Grub2 Disk", он показывает мне записи старого Manjaro и нового меню grub Debian. Использование старой записи Manjaro в личинке Manjaro все еще работает. Так что я могу загрузиться в Manjaro вот так.

Я также могу просмотреть каждую запись и отредактировать ее. Я посмотрел запись Manjaro в обеих личинках. Они кажутся совершенно разными, но команды UUID и root, а также определение типа файла выглядят одинаково (. Насколько я могу судить, я не являюсь экспертом или продвинутым пользователем ).

«Super Grub2 Disk» говорит мне, что у меня есть один grub на sda5 и один на sda6, что кажется правильным, потому что sda5 — это Manjaro, а sda6 — Debian.

Похоже, что личинка Debian (и, возможно, Kali ), к сожалению, работает неправильно. (Мне правда интересно, почему)

Итак, решение для меня состояло в том, чтобы загрузить Manjaro (через "Super Grub2 Disk" )и запустить sudo grub-install /dev/sda5, чтобы просто вернуть версию Manjaro grub. и используйте sudo update-grub, чтобы он обновлялся, чтобы также отображать Debian в качестве загрузочной записи.(sda5можно заменить правильным разделом Manjaro, так что это может бытьsda1sdb1или что-то в этом роде)

(на всякий случай, если у кого-то возникнет такая же проблема, запустите команду в Debian без установленного sudo. Используйтеsu -(вместо типичного su), чтобы использовать команды без sudo. Я не уверен, что это делает, но похоже, что вы, как пользователь, получаете привилегии root.)

У меня был диск, использующий MBR, и ноутбук без поддержки EFI или GPT, поэтому я не могу изменить загрузку на другой grub в BIOS. Мой другой ноутбук может сделать это. Таким образом, простой переход на старый Manjaro grub в BIOS (и обновление grub в Manjaro, как упоминалось ранее ), должны помочь.

Я бы сказал, что было бы хорошим решением сообщить MBR, какой grub использовать, и grub, какие загрузочные записи у него должны быть, путем записи в соответствующую конфигурацию, чтобы получить контроль над процессом загрузки и, наконец, предотвратить будущие ошибки. Но я еще недостаточно продвинут, чтобы сделать это.

VFS :не удалось смонтировать корневую файловую систему в неизвестном -блоке (0 0)___

1. Длительное нажатие на кнопку питания, чтобы выключить ноутбук.
2. выберите «расширенный» вариант.
3. выбрать самую раннюю версию универсального («режим восстановления»)
4. нажать «очистить» «попробовать освободить место»
5. , а затем «возобновить» «возобновить нормальную загрузку»

Реальный ответ на эту проблему (специально для людей, использующих Manjaro )из того, что я слышал, заключается в том, чтобы использовать для загрузки только версию GRUB от Manjaro. Убедитесь, что вы загружаетесь со своего раздела Manjaro, а не с раздела Kali Linux, потому что, очевидно, Manjaro использует какую-то специальную конфигурацию grub/микрокод/что-то особенное, необходимое для его загрузки.

Несколько случаев, когда ядро ​​может не справиться с загрузкой без инициализации. Отключите параметры GRUB _FORCE _PARTUUID, чтобы он загружался с initrd