Kernel panic linux mint

Linux Mint 20: Not starting — Kernel Panic, Cannot Open Root Device

Kernel update and forced shutdown in Linux Mint 20 (with encryption) caused an error which prevented the computer to start. The error is:

• VFS Cannot open root device «mapper»
• Kernel panic — not syncing: VFS Unable to mount root

After starting the computer was showing a blank screen for several minutes. I had to do a cold shutdown from the power button — by keeping it pressed for 12+ seconds. I didn’t have access to the terminal and the keyboard was not working.

You can check also this article which cover similar error: Linux Mint — Cannot Login (login loop)

Step 1: Start Linux Mint in advanced mode

By default after failed start Linux Mint will open menu with list of Kernels and GNU GRUB Advanced options. If this is not the case for you then do:

• Reboot
• Hold Shift — during boot
• Select: Advanced Options For Linux Mint 20 Cinnamon
• Select the latest working Kernel with Recovery mode — as the picture below:

In my case the latest kernels were not working. I had to test several before to find the best one.

Note: The Linux Mint installation was encrypted so it required the encryption password for unlock of the volume.

Step 2: Repair broken packages in Linux Mint

Once the Advanced Options are loaded you will see a window like the one below. At this step we are interested in repair of broken packages in Linux Mint 20. So you need to select — dpkg.

The available options are:

• resume — Resume normal boot
• clean — Try to make free space
• dpkg — Repair broken packages
• fsck — Check all file systems
• grup — Update grup bootloader
• network — Enable networking
• root — Drop to root shell prompt
• system-summary — System summary

Step 3: Check all file systems in Linux Mint

After fixing the broken packages in previous steps it’s a good idea to check file systems for problems. This time we can select — fsck — Check all file systems.

After this step I was able to boot normally into Linux Mint by selecting — resume — Resume normal boot.

Step 4: Identify the reason of the problem

If you like to find what is the cause of the error you can check information for the latest shutdowns and kernels by commands like:

Several kernels were installed on this system — 5.4.0-45 up to 5.4.0-52 when the error appeared.

It’s important to mention that several force shutdowns were performed which might be the root of the error. In order to check last shutdowns you can use commands like — last shutdown -x | more which will show dates and kernels:

or journalctl | grep shutdown — which is showing the logs of each shutdown:

Источник

kernel panic — not syncing(решено)

Здраствуйте! Скачал через торрент kubuntu-8.10-desktop-i386.iso .
Md5 сумму проверил — сходится. Записал на CD. Перед установкой проверил на наличие ошибок — ошибок не обнаружено. Установка прошла как по маслу.
Вытащил диск, перезагрузился. При загрузке пишет
kernel panic — not syncing: VFS: unable to mount root fs on unknown — block(0,0)
Подскажите пожалуйста что делать.

при установке изменить точку монтирования на «/»

Вообще, ошибка значит, что ядро, загрузившись, не может прочитать root file system.
Неизвестная для него файловая система, ИМХО(могу ошибаться, догадка по кофейной гуще) это проблема с диском — он исправен ? Проблема с файловой системой — до grub -а вообще доходит ? Проблема с контроллером SATA (или другим дисковым), то что она успешно поставилось не имеет значения.

Но это догадки, попробуй следующие варианты:

ну если не гугл, то фигняндекс спасёт мир:

Это:
http://forum.ubuntu.ru/index.php?topic=51611.0
За последний месяц два раза кернел паник наблюдал. Ubuntu 8.04. Решалось так:загружался с лайв сд , там в консоли sudo fsck.ext3 /dev/hda1 после этого было много ошибок, на вопрос профиксить или как? отвечал «Y». После этого две недели было спокойно, вот сегодня опять с утра сначала экран типа синего BSOD, а после перезагрузки невозможность загрузки , и чего-то-такое-на енглише. Повторил fsck, и опять в норме всё. Причину сбоев так пока и не понял, но Ubuntu жива, фс не сломалась, так что вот так.
З.Ы. /dev/hda1 это раздел с убунтой.

http://forum.ubuntu.ru/index.php?topic=22859.msg158326
Можно загрузиться с Live CD , затем
1) sudo mount /dev/sdaX /mnt //sdaХ — раздел c Linux
2) sudo chroot /mnt
Этот путь chroot я нашёл тут на форуме, лично я всегда делал немного по-другому (читай: сложнее), но надеюсь этот тоже cработает.
Итак, значит, вводим sudo chroot /mnt , ну и теперь
a)sudo update-alternatives —config usplash-artwork.so
b)sudo update-initramfs -u
Или же о просто переустановить ядро.
Добавлено позже: Так же стоит проверить диск, с которого вы ставите систему бывает иногда в этом проблема, столкнулись с подобным, потому добавил сюда.

спасибо за помощь. Нужно было всего то точку монтирования при установке сделать слэшем /

человек, пришедший в гости подсказал =) А почему он решил -не знаю.

проверьте еще параметр ядра root= в загрузчике

Источник

Kernel panic linux mint

24 окт 2020, 03:21

М.б. ошибся с разделом в котором необходимо задать данный вопрос.

При длительной (именно длительной) работе (6-8- часов и более) при выключении или перезагрузке системы перестает полностью отрабатываться команда shutdown. В сообщении на экране запись ссылается на libuninstring.so.2 Однако сама библиотека присутствует по пути /usr/lib/x86_64-linux-gnu При не слишком продолжительной работе такого явления не возникает.

60Hz
OpenGL: renderer: Mesa Intel HD Graphics 500 (APL 2) v: 4.6 Mesa 20.0.8
direct render: Yes
Audio:
Device-1: Intel Celeron N3350/Pentium N4200/Atom E3900 Series Audio Cluster vendor: ASRock driver: snd_hda_intel v: kernel bus ID: 00:0e.0
Sound Server: ALSA v: k5.4.0-52-generic
Network:
Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
vendor: ASRock driver: r8169 v: kernel port: e000 bus ID: 02:00.0
IF: enp2s0 state: up speed: 100 Mbps duplex: full mac:
Drives:
Local Storage: total: 465.76 GiB used: 283.60 GiB (60.9%)
ID-1: /dev/sda vendor: Toshiba model: MQ01ABD050 size: 465.76 GiB
Partition:
ID-1: / size: 457.42 GiB used: 283.59 GiB (62.0%) fs: ext4 dev: /dev/sda2
Sensors:
System Temperatures: cpu: 58.0 C mobo: N/A
Fan Speeds (RPM): N/A
Info:
Processes: 173 Uptime: 34m Memory: 3.51 GiB used: 1000.7 MiB (27.8%)
Init: systemd runlevel: 5 Compilers: gcc: 9.3.0 Shell: bash v: 5.0.17
inxi: 3.0.38

Вроде бы не только в 4-ой сессии встречается, но если дело доходит до дампа — значит явный косяк. Влияет или нет — тут только проверочным отключением проверять. Клиент для вот этого https://www.pcloud.com/ru/eu чудит, я так понял.

Второй момент: Universe@Home отключить попробуйте тоже. Хоть оно ошибок не сыпет — зато может грузить машину по самые уши «в свободное время» провоцируя проявление косяка. Если после отключения симптомы пропадут — значит большая нагрузка железке/системе не дается.

Kernel panic при выключении или перезагрузке

24 окт 2020, 13:45

намекает на то, что проблема скорее всего завязана на железо. (Большая часть «плавающих» неисправностей на него завязана). Потому начинать диагностику надо с тестов памяти и диска, IMHO. А далее — можно попробовать замену ядра, может несовместимость с железом присутствует. И неплохо было бы глянуть полный вывод journalctl за всю длинную сессию, которая закончилась проявлением проблемы — возможно там что-то отмечается.

Чтобы получить лог сессии в файл: journalctl -b -1 > session.txt где «-1» — насколько предыдущих сессий отмотать назад. Т.е. просто -b без второго ключа — текущая сессия, -1 — предыдущая, -10 — десять загрузок назад.

Kernel panic при выключении или перезагрузке

24 окт 2020, 16:26

Kernel panic при выключении или перезагрузке

24 окт 2020, 17:49

Kernel panic при выключении или перезагрузке

24 окт 2020, 18:28

Kernel panic при выключении или перезагрузке

24 окт 2020, 19:22

Вроде бы не только в 4-ой сессии встречается, но если дело доходит до дампа — значит явный косяк. Влияет или нет — тут только проверочным отключением проверять. Клиент для вот этого https://www.pcloud.com/ru/eu чудит, я так понял.

Второй момент: Universe@Home отключить попробуйте тоже. Хоть оно ошибок не сыпет — зато может грузить машину по самые уши «в свободное время» провоцируя проявление косяка. Если после отключения симптомы пропадут — значит большая нагрузка железке/системе не дается.

Kernel panic при выключении или перезагрузке

24 окт 2020, 19:26

Kernel panic при выключении или перезагрузке

24 окт 2020, 19:39

Kernel panic при выключении или перезагрузке

24 окт 2020, 19:50

Kernel panic при выключении или перезагрузке

24 окт 2020, 20:19

Kernel panic при выключении или перезагрузке

24 окт 2020, 20:38

Насколько я вижу — у железа проблемы с общением по data каналу. Редкие, но присутствуют. Система вынуждена периодически reset состояния делать для интерфейса винта, а это не слишком хороший признак, даже если ничего другого не проявляется. Но тут фиг поймешь где именно баг засел — это может быть как винт, так и кабель, и контроллер на материнке.

Тест же он у вас проходил только короткий. Попробуйте прогнать полный:
smartctl —test=long

Kernel panic при выключении или перезагрузке

24 окт 2020, 21:21

$
Результат упадёт в txt или я сделал неправильно?

Kernel panic при выключении или перезагрузке

24 окт 2020, 23:50

Kernel panic при выключении или перезагрузке

25 окт 2020, 02:21

Тест д.б. завершиться в 01:23, команды давал после 02 час. По самостоятельному поиску нашёл, что результат можно посмотреть командой smartctl -l selftest /dev/sda ( источник ).
Пару минут назад выполнил smartctl -a и smartctl -x
Результаты выводов в файлах 2-smartctl-a.txt, 2-smartctl-l-selftest.txt, 2-smartctl-x.txt

Смущают записи:
# 3 Extended offline Aborted by host 90% 19216 —
# 4 Extended offline Aborted by host 90% 19216 —
Глубокий тест не прошёл? Хотя по незнанию 2 раза обрывал тест. Но 3-й глубокий тест должен был пройти.

И до кучи SMART 193 — 2 среза времени, ничем кроме браузера не дёргал с 22:52 :
22:55 — 14574
00:17 — 14585

Kernel panic при выключении или перезагрузке

25 окт 2020, 15:17

Для ноутбучного диска это нормально. Они так себя защищают от передвижений ноутбука, там парковка выставлена на небольшое время, и диск на это рассчитан. (300000-500000 циклов ресурса у самых дешевых моделей — норма).

А вот гораздо неприятнее вот это:

Kernel panic при выключении или перезагрузке

25 окт 2020, 15:59

Kernel panic при выключении или перезагрузке

31 окт 2020, 13:48

Как и обещал, отписываюсь по результатам проверки.
За прошедшую неделю система все сессии отработала в штатном режиме. Причём одна из сессий имела продолжительноть более 17 часов, остальные — не менее 10-12 часов. Главный вывод – проблема комплексная, то есть программно-аппаратная.

1. Клиент pCloud. Имевший место случай являлся единичным. К тому же, клиент постоянно не работает. После старта системы с автозапуском pCloud через 10 минут клиент pCloud выключается через скрипт.

2. Universe@Home. По умолчанию в настройке клиента установлено значение «Использовать не более 100% времени ЦП». Это значение было изменено на 70%. Кроме того указано, чтобы за 3 минуты до выключения компьютера (по расписанию) служба BOINC останавливалась.
Вероятнее всего, при совпадении момента выключения системы и активного обращения Universe@Home к жёсткому диску имело место «отваливание» data канала диска. Как раз об этом и говорил slant : » . зато может грузить машину по самые уши «в свободное время» провоцируя проявление косяка «.

3. Сам винчестер, один из параметров которого » . У вас он ОЧЕНЬ сильно завышен. Т.е. полностью здоровым диск считать нельзя «.

По крайней мере, на будущее уже известны слабые места эксплуатируемого железа.

Хотелось бы ещё раз выразить признательность slant за потраченное на меня время при разбирательстве логов сессий и подробные разъяснения. Тему можно считать закрытой.

Источник

Kernel panic on Linux Mint 17.1

I have an installation of Linux Mint 17.1 on a 320 GB hard drive.

It’s a default installation, meaning that I did not do anything fancy with the partitions, just the default root and Swap partition that the Linux Mint installer created.

And it’s on an external drive, connected to the desktop computer by USB.

The system was running just fine until a few weeks ago when it suddenly suffered a kernel panic. Part of the dump on the screen was:

Dropped to the console and not sure how to proceed, my first instinct was to reboot, which I did. But the machine only rebooted into the BIOS/UEFI Setup Utility, and everything I tried failed, including pressing the Shift key.

The only option was to move the hard drive to another desktop, which also has an Intel Core i-series processor, but a different motherboard. Surprisingly, the system booted like it was supposed to and I just continued using it from the new desktop. That’s until a few hours ago when the original problem reared its ugly head again. Guess what solved the problem, at least for now?

Yep, you guessed right – moved the hard drive to the first desktop where the problem first occurred. So now that the system is running, I’ve decided to upgrade the installation of Linux Mint from Linux Mint 17.1 to Linux Mint 17.2. And I made sure to upgrade the kernel and run sudo update-grub afterwards. I think and I’m hopeful that upgrading will fix whatever was causing the kernel panic. I’ll update this post if it ever happens again.

Источник