Ядро паники - не синхронизируется: VFS: невозможно смонтировать root fs на unknown-block (0,0)

Начните с livecd, откройте терминал

sudo fdisk -l
sudo mount /dev/sdax /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /dev/pts /mnt/dev/pts
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt 

, и теперь вы можете сделать update-initramfs и update-grub без ошибок.

update-initramfs -u -k 2.6.38-8-generic (or your version)

Если вы не знаю твоей версии. Используйте:

dpkg --list | grep linux-image

И просто обновите Grub.

update-grub2

Перезагрузите систему.

ನನ್ನ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಸಮಸ್ಯೆ / ಬೂಟ್ 100% ಸಾಮರ್ಥ್ಯದಲ್ಲಿದೆ, ಆದ್ದರಿಂದ ಕೊನೆಯ 2 ಕರ್ನಲ್ ನವೀಕರಣಗಳು ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಂಡಿಲ್ಲ, ಆದ್ದರಿಂದ ರೀಬೂಟ್ ಮಾಡುವಾಗ GRUB2 ಇತ್ತೀಚಿನ ಕರ್ನಲ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದೆ, ಅದು ವಿಫಲವಾಗಿದೆ.

ಸ್ಥಾಪಿಸಲಾದ ಹಳೆಯ ಕರ್ನಲ್ಗೆ ಬೂಟ್ ಮಾಡುವ ಮೂಲಕ ಮತ್ತು ಆಪ್ಟಿಟ್ಯೂಡ್ ಬಳಸಿ ಕೆಲವು ಬಳಕೆಯಾಗದ ಕರ್ನಲ್ಗಳನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ ನಾನು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದೆ. ಆಪ್ಟಿಟ್ಯೂಡ್ ಅನ್ನು ಬಳಸುವ ಮೂಲಕ, ಅಸ್ಥಾಪನೆಯು ಸಂಭವಿಸಿದ ನಂತರ, ಡಿಪಿಕೆಜಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮುರಿದ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿತು, ಮತ್ತು ಈ ಸಮಯದಲ್ಲಿ ಅದು ಯಶಸ್ವಿಯಾಯಿತು.

В случае, если это произошло после прерванного обновления ядра (например, сбой системы при aptitude safe-upgrade ),

1. загрузка с более старым ядром и
2. запуск dpkg --configure -a .

Это завершит обновление, включая настройку параметров загрузки, как psusi объясняет .

Вы также можете загрузить сервер в режиме восстановления и переустановить только grub

http: //info.w3calculator .com / free-code / linux / recovery-from-correpted-boot-image /

У меня возникла эта проблема из-за того, что мой раздел / boot был заполнен, поэтому обновления ядра не удались. Мне удалось это исправить, загрузившись со старого ядра в меню GRUB.

Когда мне удалось загрузиться, я начал очищать старые ядра, но мне удалось получить некоторые проблемы с зависимостями, поэтому сначала мне пришлось удалить пакет linux-server

apt-get remove linux-server
apt-get update
apt-get -f install
apt-get upgrade

Затем я перезагрузился, и все заработало!

В дополнение к инструкциям Томеу, перед chroot мне нужно было:

sudo mount --bind /dev /mnt/dev

Дополнительно, после chroot:

cp -r /usr/lib/i386-linux-gnu/pango /usr/lib/

(Получил это отсюда. )

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

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

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

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

Возможные ошибки:

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

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

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

    CONFIG_VIRTIO_BLK = y
   CONFIG_VIRTIO_PCI = y
    

   В результате появляется следующее сообщение об ошибке

    <4> [0.541708] VFS: не удается открыть корневое устройство «vda» или unknown-block (0,0): ошибка -6
    <4> [0.542035] Добавьте правильный вариант загрузки "root =";  вот доступные разделы:
    <0> [0.542562] Паника ядра - не синхронизируется: VFS: невозможно смонтировать корневую файловую систему на неизвестном блоке (0,0)
    

   Итак, здесь Linux сообщает нам, что он вообще не может читать с vda: VFS: не удается открыть корневое устройство «vda» или unknown-block (0,0): error -6 .

   Затем на добавьте правильный параметр загрузки «root =»; вот доступные разделы: он дает список разделов, которые он может читать.

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

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

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

   Я могу достичь этого случая, исключив способность ядра к читать файловую систему ext4:

    CONFIG_EXT4_FS = y
    

   После его удаления появляется сообщение об ошибке:

    <4> [0.585296] Список всех разделов:
    <4> [0,585913] fe00 524288 vda
    <4> [0.586123] драйвер: virtio_blk
    <4> [0.586471] Ни одна файловая система не может смонтировать корень, попытка:
    <4> [0.586497] squashfs
    <4> [0,586724]
    <0> [0.587360] Паника ядра - не синхронизируется: VFS: невозможно смонтировать корневую файловую систему на неизвестном блоке (254,0)
    

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

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

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

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

   Например, если мы передадим ошибку:

    root = / dev / vda2
    

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

    <4> [0.608475] Пожалуйста, добавьте правильный параметр загрузки "root =";  вот доступные разделы:
    <4> [0.609563] fe00 524288 vda
    <4> [0.609723] драйвер: virtio_blk
    <0> [0.610433] Паника ядра - не синхронизируется: VFS: невозможно смонтировать корневую файловую систему на неизвестном блоке (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.

Я столкнулся с этой проблемой, так как заголовки linux обновлялись, а электричество пропало. Я восстановил, как показано ниже,

Перейдите в меню grub и выберите дополнительные параметры> выберите предыдущее ядро ​​и загрузитесь,

После того, как вы получите терминал, выполните команду ниже,

sudo dpkg --configure -a

здесь со страницы руководства dpkg,

--configure package...|-a|--pending
              Configure a package which has been unpacked but not yet configured.  If -a or --pending is given instead of package, all unpacked but unconfigured packages are configured.

              To reconfigure a package which has already been configured, try the dpkg-reconfigure(8) command instead.

              Configuring consists of the following steps:

              1. Unpack the conffiles, and at the same time back up the old conffiles, so that they can be restored if something goes wrong.

              2. Run postinst script, if provided by the package.

регистрирует, как показано ниже,

Setting up linux-image-4.15.0-76-generic (4.15.0-76.86) ...
Processing triggers for initramfs-tools (0.130ubuntu3.9) ...
update-initramfs: Generating /boot/initrd.img-4.15.0-74-generic
Processing triggers for linux-image-4.15.0-76-generic (4.15.0-76.86) ...
/etc/kernel/postinst.d/dkms:
 * dkms: running auto installation service for kernel 4.15.0-76-generic
   ...done.
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.15.0-76-generic
/etc/kernel/postinst.d/zz-update-grub:
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.15.0-76-generic
Found initrd image: /boot/initrd.img-4.15.0-76-generic
Found linux image: /boot/vmlinuz-4.15.0-74-generic
Found initrd image: /boot/initrd.img-4.15.0-74-generic
Found linux image: /boot/vmlinuz-4.15.0-72-generic
Found initrd image: /boot/initrd.img-4.15.0-72-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
Found Windows 7 on /dev/sda1
done

и вуаля, новый пакет, который был загружен но не настроен, работает.

В моем случае:

• Это было вызвано сбоем во время обновления до LTS 20.04.

• dpkg --configure -a снова открывал меню восстановления, поэтому пакеты не были (пере) настроены.

• Поэтому мне пришлось перечислить установленные ядра

   dpkg --list |  grep linux-kernel |  Больше
   

• и настройте конкретно только что установленное ядро:

   dpkg --configure linux-kernel-5.20.0-52-generic
   

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

• При установке закончилось место на томе с ядрами:

   dpkg --purge remove linux-kernel- 
   

  Я бы не стал сразу же использовать « удалить все старые ядра », потому что вы хотите, чтобы некоторые из них загружались, если самое новое выйдет из строя.

• Ваш диск изнашивается - запустите smartctl --health --all и e2fsck ...

• Какой-то драйвер привел к зависанию всей ОС - для меня это происходит с драйвером nVidia при воспроизведении фильма 4K на экране 4K.