При попытке обновления с 10.10 до 11.04 все, казалось, шло хорошо до перезагрузки. Появляется это сообщение об ошибке:
Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)Как нам это исправить?
Вам не хватает initramfs для этого ядра. Выберите другое ядро в меню GRUB в разделе Дополнительные параметры для Ubuntu и бежать sudo update-initramfs -u -k version чтобы сгенерировать initrd для version (заменить version со строкой версии ядра, такой как 4.15.0-36-generic) затем sudo update-grub.
Начните с livecd, откройте терминал a
sudo fdisk -lsudo mount /dev/sdax /mntsudo mount --bind /dev /mnt/devsudo mount --bind /dev/pts /mnt/dev/ptssudo mount --bind /proc /mnt/procsudo mount --bind /sys /mnt/syssudo 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Перезагрузите свою систему.
В случае, если это произошло после прерванного обновления ядра (например, сбой системы во время aptitude safe-upgrade),
- загрузитесь с более старым ядром и
- бежать
dpkg --configure -a.
Это завершит обновление, включая настройку параметров загрузки следующим образом psusi объясняет.
В моей ситуации проблема заключалась в том, что /boot была на 100% загружена, поэтому последние 2 обновления ядра не завершились успешно, следовательно, при перезагрузке, когда GRUB2 выбрано последнее ядро, оно завершилось неудачей.
Я решил проблему, загрузившись в самое старое установленное ядро и удалив некоторые неиспользуемые ядра с помощью aptitude. С помощью склонность, после того , как произошла деинсталляция, dpkg автоматически попытался настроить поврежденные пакеты, и на этот раз это удалось.
Полная процедура диагностики на основе сообщений ядра
Но используя это Настройка эмуляции QEMU Я попытался привести минимальные примеры всех возможных типов сбоев, чтобы помочь вам отладить вашу проблему.
В этой простой настройке QEMU эмулирует систему с:
- один виртуальный диск, который представляет собой жесткий диск или SDD реального оборудования
- на этом диске virtio есть необработанный неразделенный образ ext4. При нормальной работе это устройство будет отображаться под
/dev/vda(vявляется индикаторной буквой для virtio, если бы он был разделен на разделы, разделы были бы/dev/vda1,/dev/vda2и т.д.)
Возможные ошибки, которые вы могли бы получить, следующие:
-
Linux не может считывать байты с диска.
Это может быть либо потому, что диск поврежден, либо потому, что вы не настроили Linux с возможностью чтения с этого типа оборудования.
В моем случае с QEMU я могу воспроизвести это, удалив ключевые параметры, которые позволяют ядру считывать этот виртуальный диск:
CONFIG_VIRTIO_BLK=yCONFIG_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:он выдает список разделов, которые он мог бы прочитать.Однако в нашем случае список пуст, поскольку следующая строка совершенно не связана.
-
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. -
Вы сдали не тот
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.
В моем случае:
Это было вызвано сбоем во время обновления до LTS 20.04.
dpkg --configure -aснова открыл меню восстановления, поэтому пакеты не были (повторно) настроены.-
Так что мне пришлось перечислите установленные ядра
dpkg --list | grep linux-kernel | more -
и настройте конкретно ядро, которое было недавно установлено:
dpkg --configure linux-kernel-5.20.0-52-generic
В связи с этим следует отметить, что причинами сбоя обновления могут быть:
-
При установке не хватило места на томе с ядрами:
dpkg --purge remove linux-kernel-<someOldVersion>Я бы не пошел с "удалите все старые ядра"сразу же, потому что вы хотите, чтобы некоторые загружались, если новейшая версия сломана.
Ваш диск изнашивается во время работы
smartctl --health --allиe2fsck ...Какой-то драйвер привел к зависанию всей ОС - у меня это происходит с драйвером nVidia при воспроизведении фильма 4K на экране 4K.
Я столкнулся с этой проблемой, так как заголовки 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-genericProcessing 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-genericFound initrd image: /boot/initrd.img-4.15.0-76-genericFound linux image: /boot/vmlinuz-4.15.0-74-genericFound initrd image: /boot/initrd.img-4.15.0-74-genericFound linux image: /boot/vmlinuz-4.15.0-72-genericFound initrd image: /boot/initrd.img-4.15.0-72-genericFound memtest86+ image: /boot/memtest86+.elfFound memtest86+ image: /boot/memtest86+.binFound Windows 7 on /dev/sda1doneи вуаля, новый пакет, который был загружен, но не настроен, работает.
У меня возникла эта проблема из-за того, что мой раздел / boot был заполнен, поэтому мои обновления ядра завершились неудачей. Мне удалось исправить это, загрузившись со старого ядра в меню GRUB.
Когда мне удалось загрузиться, я начал очищать старые ядра, но у меня возникли некоторые проблемы с зависимостями, поэтому сначала мне пришлось удалить пакет linux-server
apt-get remove linux-serverapt-get updateapt-get -f installapt-get upgradeЗатем я перезагрузился, и все работало нормально!
В дополнение к инструкциям Tomeu, перед chroot мне нужно было:
sudo mount --bind /dev /mnt/dev
Кроме того, после того, как chroot:
cp -r /usr/lib/i386-linux-gnu/pango /usr/lib/
Вы также можете загрузить сервер в режиме восстановления и переустановить только grub
http://info.w3calculator.com/free-code/linux/recover-from-corrupted-boot-image/
Ваши проблемы, возможно, не имеют ничего общего с вашей основной системой, а скорее с вашим установочным носителем (USB-накопителем)… ➪ смотрите здесь: http://askubuntu.com/a/632636/479118
Я не могу опубликовать ответ, так как у меня недостаточно репутации, но когда я столкнулся с этой проблемой, я решил ее, загрузившись с USB-накопителя, установив разделы main и EFI, включение сети и запустив sudo apt-get install linux-image-generic для обновления до последней версии ядра.
На этот вопрос слишком много ответов, но не то, что мне было нужно:
dpkg --configure linux-kernel-<version>-generic - не с помощью -a, потому что это снова вызвало меню восстановления. Подробнее смотрите в моем ответе.