Ошибка kernel panic ubuntu

1 Question at a time per the FAQ

1. What is kernel panic?
   When the kernel can’t load properly or «freaks out» and fails to boot properly or crashes(see edit credit at the bottom).

2. Why it occurs?
   Hosed updates, failing hardware, unsupported hardware, failed or missing drive or partition (see edit credit at the bottom)

3. How can I understand kernel panic occurred?
   Watch boot prompts(turn off quiet kernel parameter) OR your machine fails to boot

4. What effect it has on system?
   Failure to boot or system crash

5. Does it only occur in Linux?
   No, all unix-like operating systems can have kernel panics. It’s the equivalent of a Windows Blue Screen of Death

6. How can I prevent it?
   It normally doesn’t happen. Test updates and troubleshoot the problem. Use stable instead of development branches.

Additional note: Kernel panic and system failure/shutdown can be directly responsible for protecting your computer from physical damage. Examples include halting before extreme overheating or disk corruption. See edit credits at the bottom for direct quote.

edits

Per B. Roland Missing or corrupted disks or volumes can cause this as well.
(Good point and I overlooked it)

Per Kees Kernel panic can also occur while running.
note: Can happen when a function fails sort of gracefully inside the kernel, but most often happens during module or kernel loading(which is usually during boot). I thought I touched on it at «during boot or system crash», but I see how my answer to (1) stated it only occurs during boot.

Per rafalcieslak direct quote — ‘There is one very important thing that must be added: The main point in the whole kernel panic is to protect your computer. The kernel freezes not only because it failed to do something, but also in order to prevent your computer from f.e. overheating, hard drives corruption, and any other hardware problems, that may occur, if some incorrect orders are executed, of a module (for example a module responsible for controlling the fan) failed to load, etc. This is why the kernel prefers to freeze, than to overcome the problem.’

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх

How to Fix Kernel Panic on Linux — Today I had a slightly tense experience when I turned on the laptop, suddenly Ubuntu couldn’t boot and I got a «kernel panic» error message. Based on my previous experience, I always fail when fixing this kernel panic problem.

But this time I did not give up and did not immediately reinstall my laptop, because of curiosity, I finally went looking for references and tutorials to solve this problem.

In this tutorial, I will try to explain the steps to fix

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

in more detail, hopefully, this can be useful, check it out!

How to Fix Kernel Panic on Ubuntu Linux

The following is a message that appears on my desktop screen when I run ubuntu Linux.

From the picture above, you can see a message stating that my Ubuntu has kernel panic problems. Please note, that the cause of the kernel panic can vary and the message displayed can be different from what I experienced.

Before going into the tutorial how to fix it, we discuss first what causes kernel panic — not syncing: VFS: Unable to mount root fs on unknown-block (0,0). The reason is that your Linux kernel lost the initramfs file. Initramfs is a scheme to load a temporary root file system into memory, which can be used as part of a linux startup process.

Then how to fix it? First, please restart your laptop, then in GRUB, select the Advanced options for Ubuntu menu, then the kernel options will appear as shown below.

After logging in and successfully booting to Ubuntu using the old kernel version, please open the terminal console, then type fdisk -l.

$ sudo fdisk -l

From the picture above, you can see that my root partition is /dev/sda2. Root partition on your computer may be different. So, please adjust it.

$ sudo mount /dev/sda2 /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

Then, you can update initramfs with the following command. 

# update-initramfs -u -k 4.15.0-54-generic

Then, update your grub with the following command

# update-grub

Please wait until the grub update process is complete, then restart your laptop. Now boot your ubuntu as usual, you should no longer have problems with kernel panic as before.

That’s the steps to fix kernel panic problems on ubuntu linux, hopefully, it is useful and thanks.

Операционная система Ubuntu

Блог о современной полнофункциональной операционной системе, основанной на ядре Linux

09 января 2017

Сбой Kernel panic в ядре Linux

Многим пользователям операционных систем типа Linux, знакомо сообщение о критической ошибке ядра «Kernel panic: …», после которой такая система не может продолжать дальнейшую работу. Причиной Kernel panic может быть как критическая аппаратная ошибка и ошибка программного обеспечения, так и сбой самого ядра.

В частности, одной из самых распространённых причин Kernel panic является невозможность найти и смонтировать корневую файловую систему. Часто это ошибка конфигурации, которая может быть исправлена при перезагрузке ядра вручную или загрузкой одной из предыдущих версий ядра. Рано или поздно, многие сталкиваются с таким сбоем, вот и у меня при загрузке системы, на экране компьютера появилось сообщение:

На скриншоте экрана видим сообщение о невозможность найти и смонтировать корневую файловую систему. Вообще, многие проблемы появились после того, как я установил Ubuntu Studio 16.04.1 Xenial Xerus LTS. В версии 14.04 такого сбоя никогда не было.

Как загрузить Ubuntu с другой версией ядра?

Дополнительные параметры для Ubuntu в GRUB2.02 позволяют выбрать версию ядра системы.

Именно последнее ядро Linux 4.4.0-57 (все три варианта) и являлось причиной сбоя системы Kernel panic, так как на ядре Linux 4.4.0-53, система загрузилась без сбоев.

Как удалить лишние ядра в Ubuntu 16.04.1?

В ситуации, когда недавно обновленное ядро операционной системы дает сбой Kernel panic, чтобы избежать постоянного выбора ядра при загрузке, необходимо его удалить. Ранее, с удалением старых ядер успешно справлялась программа Ubuntu Tweak. В настоящее время, с официального сайта Ubuntu Tweak происходит автоматическое перенаправление на сайт github.com/tualatrix/ubuntu-tweak, где я так и не нашел deb-пакет для установки на Ubuntu. Похоже, что разработчик решил закрыть проект Ubuntu Tweak и это печально, так как по информации из сети, замену ему найти трудно.

Тем не менее, Ubuntu Tweak можно установить на Ubuntu 16.04.1 Xenial Xerus LTS с помощью deb-пакета версии 0.8.7-1

xenial, загруженного с диска, или с сайта ubuntuupdates.org. Двойным щелчком откройте deb-пакет прямо в Менеджере приложений Ubuntu, чтобы установить программу. В моем случае установка прошла успешно.

Хотя, и не все функции Ubuntu Tweak сохранились в рабочем состоянии, например вкладка «Приложения» на работает, удалось удалить все старые ядра и оставить одно последнее из списка, версии Linux 4.4.0-51 про запас.

Однако, как я указывал выше, задача состояла в том, чтобы удалить, наоборот, самое новое ядро, версии Linux 4.4.0-57, и работать на предыдущем, версии 4.4.0-53. Выходит, на вкладке «Очистка», Ubuntu Tweak не отображает две последних версии ядра из-за чего я не могу удалить проблемное. Думаю, такая ситуация логична, и связана с тем, чтобы помешать пользователю случайно удалить все ядра. Хотя программа Ubuntu Tweak и не помогла мне с решением вопроса, уверен, она пригодится в будущем.

В последующем выяснилось, что очистка системы, в том числе удаление ядер, каким-то образом исправило систему и при перезагрузке компьютера уже не появлялось меню загрузчика GRUB2. При этом, в списке очистки старых ядер Ubuntu Tweak, появилось ядро версии Linux 4.4.0-53, с которого я и загружал ранее систему при сбое Kernel panic. Последнее ядро 4.4.0-57 так и не появилось. Вот такой вот глюк.

Как узнать, на каком ядре работает Ubuntu?

На изображении видно, что действительно, очистка операционной системы Ubuntu программой Ubuntu Tweak, помогла ядру версии Linux 4.4.0-57 избавиться от критической ошибки Kernel panic.

Источник

Исправление ошибки kernel panic – not syncing: Attempted to kill inint

Рассмотрим частный случай получения ошибки kernel panic – not syncing: Attempted to kill inint после перезагрузки Linux

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

1. При загрузке ОС нажимаем e, чтобы перейти к редактирования загрузчика GRUB.

Далее в строке загрузки ядра по-умолчанию добавляем в конец selinux=0 пример:

kernel /boot/vmlinuz-2.6.32-504.3.3.el6.x86_64 ro root=UUID=516101c3-00dd-4db6-b1ff-7214dc0baa03 rd_MD_UUID=62292ebf:38febd4a:2514de0f:1cc21698 rd_NO_LVM LANG=en_US.UTF-8 SYSFONT=latarcyrhercyrheb-sun16 crashkernel=auto rd_NO_LUKS KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet selinux=0

Нажимаем Enter и затем b для продолжения загрузки.

После успешной загрузки Linux редактируем файл /etc/grub.conf и во все строки загрузки ядра добавляем selinux=0, если конечно вы все ядра планируете загружать. Обычно достаточно последнее ядро и предыдущее.

Windows сервера в Европе с оплатой в рублях

Облачные Windows сервера в Германии, Голландии, Эстонии.
Мощные системы защиты.
Возможность установки любого ПО на сервер.
Полная конфиденциальность.
Оплата в рублях.
Безнал для юридических лиц.

Севера 1С в Европе по низким ценам

Сервер 1С в Европе за 2250 рублей в месяц*!

Облачные Windows VPS в Латвии.
Оплата по безналичному расчету для организаций.
Настройка необходимого для работы ПО (Office, 1C, SQL) входит в стоимость.

*Конфигурация: 1 ядро CPU, 4Гб памяти, 250Гб диск или 60Гб SSD.

Источник

Linux Kernel Panic! Что делать?

Поклонники операционной системы Linux иногда сталкиваются с таким явлением, как Kernel Panic, и часто не знают что делать в таком случае. Насколько продуманной ни была бы система, всегда остается вероятность возникновения ошибок. Kernel Panic — это особое состояние ядра операционной системы, когда оно отказывается работать из-за произошедшей в системе критической ошибки.

Пользователи операционных систем семейства Windows наверняка сталкивались с ситуацией, когда на экране на синем фоне появлялась надпись о возникновении критической ошибки (знаменитый синий экран смерти, или BSoD), причем система отказывалась реагировать на команды пользователя. Это практически то же самое, что Kernel Panic в Linux.

Ошибки такого рода являются слишком серьезными, чтобы продолжать работу, и относятся к тем компонентам системы, которые выполняют основные функции по обеспечению работоспособности ОС — к ядру и драйверам. При возникновении Kernel Panic на экран выводится сообщение об ошибке и некоторая информация, полезная для программистов.

Если такая ошибка возникла сразу после установки системы, то ответить на вопрос, что послужило ее причиной — сложно. Например, Kernel Panic может возникнуть из-за сбоев во время установки либо несовместимости какого-то драйвера с аппаратным обеспечением. В таком случае попробуйте переустановить систему с другими настройками либо воспользоваться консолью восстановления.

Если же ошибка возникла в процессе работы с Linux, то здесь могут быть две причины:

Если вы действительно недавно устанавливали какой-то сервис, драйвер или меняли ядро, то попробуйте вернуть систему в прежнее состояние и посмотреть будет ли ошибка повторяться. При обновлении ядра операционной системы, часто оставляется возможность загрузиться со сторого. Выбор этот можно сделать в меню загрузчика перед стартом системы. Попробуйте загрузиться с другого ядра, возможно ваше оборудование не корректно поддерживается в новой версии. А если такие понятия, как подключение модулей драйверов устройств для вас не знакомы, тогда вам необходимо заблокировать обновление ядра.

В операционной системе Ubuntu это можно сделать следующим образом:

На этом все. Надеюсь, статья поможет вам разобраться с такой напастью, как Kernel Panic!

Источник

У Вас на последнем фото ошибка:

Скорее всего диск с МСВС повреждён.

Подключите его в другой ПК с linux и попробуйте посмотреть какие на нём разделы. Покажите сюда что увидите.

Или используйте другой диск с МСВС, если таковой имеется.

попробуй с другими параметрами init=

Спасибо! А где взять эти параметры?

Спасибо! Увы, другого компа нет. Другого диска тоже нет.

Скорее всего диск с МСВС повреждён.

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

Нет ни картридеров, ни cd-приводов.

Эм, и даже USB нету?

Для неспециалиста в компах будет весьма сложно. Я подобные (но не совсем такие) ситуации разруливал, загружаясь с установочного диска с МСВС и делая chroot в систему на жёстком диске. Но тут надо ориентироваться в линуксе, работать в командной строке и править конфиги.

Возможно, простое решение найдётся, если уточнить задачу.

На этом жёстком диске не просто МСВС, а установлена какая-то система, которую надо реанимировать? Или данные, которые надо прочитать?

Если просто стоит задача запустить МСВС — проще её поставить заново.

Если стоит задача спасти данные — можно подключить диск к другому компу. Даже совсем необязательно, чтобы он был с линуксом, для Windows есть драйвер Ext2FSD, который читает Ext2 и Ext3.

Хуже всего, если там под МСВС установлена какая-то прикладная система со своими настройками, и которую нельзя поставить заново, но нужно, чтобы она работала…

Можно попробовать угадать. Я сейчас только догадки строю, но как мне видится в те далёкие времена, когда этот динозавр был актуален, на компьютерах обычно было по два разъёма IDE с возможностью подключить максимум два диска, а на каждом диске лишь максимум четыре первичных раздела. Так что наихудший сценарий – 16 вариантов, но на самом деле раздел точно не менялся, так что остаётся только четыре возможности.

Так что попробуй в первую очередь выяснить, какие параметры загрузчик передаёт ядру. Это можно сделать, ежели нажать на Tab как написано на первой фотографии с винчестером. Далее надо отредактировать параметр root= (я думаю там написано root=/dev/hdc1), твой диск ядро распознаёт как /dev/hda, соответственно и параметр должен быть root=/dev/hda1. Может быть с единицей я и ошибаюсь, но скорее всего нет.

Источник

Kdump — диагностика и анализ причин сбоев ядра

Хотя в современных Linux-системах ядро отличается достаточно высоким уровнем стабильности, вероятность серьезных системных ошибок, тем не менее, имеется всегда. Когда происходит неисправимая ошибка, имеет место состояние, называемое паникой ядра (kernel panic): стандартный обработчик выводит на экран информацию, которая должна помочь в устранении неисправности, и входит в бесконечный цикл.

Для диагностики и анализа причин сбоев ядра разработчиками компании RedHat был разработан специализированный инструмент — kdump. Принцип его работы можно кратко описать следующим образом. Создается два ядра: основное и аварийное (именно оно используется для сбора дампа памяти). При загрузке основного ядра под аварийное ядро выделяется определенный размер памяти. При помощи kexec во время паники основного ядра загружается аварийное и собирает дамп.

В этой статье мы подробно расскажем о том, как конфигурировать kdump и анализировать с его помощью системные ошибки. Мы рассмотрим особенности работы с kdump в OC Ubuntu; в других дистрибутивах процедуры настройки и конфигурирования kdump существенно отличаются.

Установка и настройка kdump

Установим kdump с помощью команды

Настройки kdump хранятся в конфигурационном файле /etc/default/kdump-tools

Установив все необходимые параметры, выполним команду update-grub и выберем install the package maintainer’s version.

Затем перезагрузим систему и убедимся в том, что kdump готов к работе:

Для того, чтобы мы могли анализировать дамп с помощью утилиты crash, нам понадобится также файл vmlinux, содержащий отладочную информацию:

По завершении установки еще раз проверим статус kdump:

Если kdump находится в рабочем состоянии, на консоль будет выведено следующее сообщение:

Тестируем kdump

Вызовем панику ядра при помощи следующих команд:

В результате их выполнения система «зависнет».

После этого в течение нескольких минут будет создан дамп, который будет доступен в директории /var/crash после перезагрузки.

Информацию о сбое ядра можно просмотреть с помощью утилиты crash:

На основе приведенного вывода мы можем заключить, что системному сбою предшествовало событие «Oops: 0002 [#1] SMP», произошедшее на CPU2 при выполнении команды tee.
Утилита crash обладает также широким спектром возможностей для диагностики причин краха ядра. Рассмотрим их более подробно.

Диагностика причин сбоя с помощью утилиты crash

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

В утилите crash имеется свой набор команд:

Для каждой этой команды можно вызвать краткий мануал, например:

Все команды мы описывать не будем (с детальной информацией можно ознакомиться в официальном руководстве пользователя от компании RedHat), а расскажем лишь о наиболее важных из них.

В первую очередь следует обратить внимание на команду bt (аббревиатура от backtrace — обратная трассировка). С ее помощью можно посмотреть детальную информацию о содержании памяти ядра (подробности и примеры использования см. здесь). Однако во многих случаях для определения причины системного сбоя бывает вполне достаточно команды log, выводящее на экран содержимое буфера сообщений ядра в хронологическом порядке.

Приведем фрагмент ее вывода:

В одной из строк вывода будет указано событие, вызвавшее системную ошибку:

С помощью команды ps можно вывести на экран список процессов, которые были запущены на момент сбоя:

Для просмотра информации об использовании виртуальной памяти используется команда vm:

Команда swap выведет на консоль информацию об использовании области подкачки:

Информацию о прерываниях CPU можно просмотреть с помощью команды irq:

Вывести на консоль список файлов, открытых на момент сбоя, можно с помощью команды files:

Наконец, получить в сжатом виде информацию об общем состоянии системы можно с помощью команды sys:

Заключение

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

Читателей, которые не могут оставлять комментарии здесь, приглашаем к нам в блог.

Источник

Поклонники операционной системы Linux иногда сталкиваются с таким явлением, как Kernel Panic, и часто не знают что делать в таком случае. Насколько продуманной ни была бы система, всегда остается вероятность возникновения ошибок. Kernel Panic — это особое состояние ядра операционной системы, когда оно отказывается работать из-за произошедшей в системе критической ошибки. Кстати, при желании отвлечься, обратите внимание champion casino можно найти по ссылке.

Пользователи операционных систем семейства Windows наверняка сталкивались с ситуацией, когда на экране на синем фоне появлялась надпись о возникновении критической ошибки (знаменитый синий экран смерти, или BSoD), причем система отказывалась реагировать на команды пользователя. Это практически то же самое, что Kernel Panic в Linux.

Ошибки такого рода являются слишком серьезными, чтобы продолжать работу, и относятся к тем компонентам системы, которые выполняют основные функции по обеспечению работоспособности ОС — к ядру и драйверам. При возникновении Kernel Panic на экран выводится сообщение об ошибке и некоторая информация, полезная для программистов.

Если такая ошибка возникла сразу после установки системы, то ответить на вопрос, что послужило ее причиной — сложно. Например, Kernel Panic может возникнуть из-за сбоев во время установки либо несовместимости какого-то драйвера с аппаратным обеспечением. В таком случае попробуйте переустановить систему с другими настройками либо воспользоваться консолью восстановления.

Если же ошибка возникла в процессе работы с Linux, то здесь могут быть две причины:

1. либо в системе возникла особая ситуация, при которой в ядре или каком-то из драйверов произошла ошибка;
2. либо какой-то из недавно установленных компонентов системы работает некорректно.

Если вы действительно недавно устанавливали какой-то сервис, драйвер или меняли ядро, то попробуйте вернуть систему в прежнее состояние и посмотреть будет ли ошибка повторяться. При обновлении ядра операционной системы, часто оставляется возможность загрузиться со сторого. Выбор этот можно сделать в меню загрузчика перед стартом системы. Попробуйте загрузиться с другого ядра, возможно ваше оборудование не корректно поддерживается в новой версии. А если такие понятия, как подключение модулей драйверов устройств для вас не знакомы, тогда вам необходимо заблокировать обновление ядра.

В операционной системе Ubuntu это можно сделать следующим образом:

1. откройте менеджер пакетов Synaptic;
2. заблокируйте обновления для следующих пакетов. Пункт меню «Пакет» — «Заблокировать версию».

linux-generic
linux-libc-dev
linux-restricted-modules-common
linux-restricted-modules-generic

На этом все. Надеюсь, статья поможет вам разобраться с такой напастью, как Kernel Panic!

Linux is used everywhere in the IT world. You’ve probably used Linux today, even if you didn’t realize it. If you have learned anything about Linux, then you know it is indeed a kernel. The kernel is the primary unit of the Linux operating system (OS) and is responsible for communications between a computer’s hardware and its processes.

In this article, you will learn about one situation related to the Linux kernel: The kernel panic. The term itself can make you panic, but if you have the proper knowledge, then you can remain calm. Every system admin faces this issue at least once in their career, but reinstalling the system is not the first solution you should turn to.

What is a kernel panic?

A kernel panic is one of several Linux boot issues. In basic terms, it is a situation when the kernel can’t load properly and therefore the system fails to boot. During the boot process, the kernel doesn’t load directly. Instead, initramfs loads in RAM, then it points to the kernel (vmlinuz), and then the operating system boots. If initramfs gets corrupted or deleted at this stage because of recent OS patching, updates, or other causes, then we face a kernel panic.

If we dig into the boot process more, then we encounter the Linux «chicken/egg problem.»

[ Readers also liked: Terminals, shells, consoles, and command lines ]

When a Linux system boot process starts after the Master Boot Record (MBR) step, GRUB is loaded. The kernel needs to be loaded into RAM to start the OS, but the kernel is situated on the hard disk (/boot/vmlinuz), and the hard disk is not yet mounted on /. Without mounting, no files can be accessed, even the kernel. To overcome this, first initramfs/initrd loads in RAM directly and mounts the /boot partition in read-only mode. Next, it mounts the hard disk on the / partition, and the process continues.

# ls -lrth /boot/

This process emphasizes the importance of initramfs/initrd in the Linux boot process.

Why do kernel panics occur?

Kernel panics occur:

1. If the initramfs file gets corrupted.
2. If initramfs is not created properly for the specified kernel. Every kernel version has its own corresponding initramfs.
3. If the installed kernel is not supported or not installed correctly.
4. If recent patches have some flaws.
5. If a module has been installed from online or another source, but the initrd image is not created with the latest installed module.

How to troubleshoot?

The first thing to do after seeing a kernel panic error is not to panic ,because now you are aware of the image file related to the error.

Step 1: Boot the system normally with your given kernel version.

Then you may see this error:

Press Enter or any key, and then you will see the following:

This is your kernel panic situation.

Step 2: Reboot your machine again and select the rescue prompt.

In RHEL 6 or earlier versions, we do not have this option, but in RHEL 7 and onwards, we have a built-in rescue image.

This image boots your OS normally.

Step 2.1: Go to /boot and list all files. Here you will see there is no initramfs file for your kernel, but there is an initramfs file for rescue by which you have booted your system, and another is for kdump.

The initramfs for the kernel is missing.

Step 3: You will need to create a new initramfs file that corresponds to your kernel version.

Step 3.1: First check your kernel version:

#uname -r

Step 3.2: Next, run the dracut command:

#dracut -f <initrd-image> <kernal-version>

3.3) List the /boot directory contents again. The initramfs file for the kernel is now created.

Step 4: Now, when you boot normally, your machine starts without a kernel panic error.

Step 5: There might be a situation that occurs when you boot your system with a rescue image with creating a new initramfs file where you couldn’t make a new file because it was already present.

At this point, we need to create an initramfs image with the mkinitrd command or dracut command.

Step 5.1: Check your kernel version first using the uname -r command.

Step 5.2: Run the mkinitrd command with the --force option and your kernel specification:

#mkinitrd --force <initrd-Image> <Kernel-Version>

Your initramfs file is regenerated by these short steps, and you can now start your OS without any errors.

[ Free ebook: Manage your Linux environment for success ]

Wrapping up

Now, anytime you see a kernel panic error, you will definitely not panic because you know why this error occurred and how to resolve it. This article covers one of the common Linux boot problems: kernel panic. There are so many other potential boot problems that can occur in Linux, but resolving those issues will become much less of a panic when you gain some advanced knowledge of your system.

Суть и причины проблемы

Проблем с синим экраном были почти у каждого. Будет полезно знать с чем мы имеем дело. А еще интересно, есть подобная проблема в Ubuntu, как в Windows?

Причины появления синего экрана смерти Windows

Ошибка происходит вследствие выявления некорректного кода в режиме ядра. Сбой в работе кода (а следственно и появление экрана смерти) происходит при:

• выходе из строя аппаратной части компьютера (жесткого диска, оперативной памяти, видеокарты, блока питания и т.д.);
• конфликте устройств компьютера;
• несовместимости оборудования с операционной системой;
• перегреве устройств ПК;
• неподходящем драйвере;
• конфликте драйверов;
• несовместимости драйвера с операционной системой;
• неправильных настройках BIOS;
• нехватке свободного места на жестком диске;
• заражении всевозможными вредоносными программами (вирусами);
• разгоне процессора и оперативной памяти.

Сведения, содерж­­ащиеся в Blue Screen of Death

Синий экран смерти содержит в себе следующую информацию:

1. Название ошибки (важная информация);
2. Рекомендации по её устранению (является стандартным текстом для определенных групп ошибок);
3. Шестнадцатеричный код ошибки;
4. Параметры ошибки (для некоторых ошибок является важной информацией);
5. Название драйвера, вызвавший ошибку (важная информация указывается не всегда);
6. Адрес места, в котором возникла ошибка (указывается не всегда).

Подобная ошибка в Ubuntu — kernel oops

Что делать, когда вы встречаете Kernel panic

Когда вы встречаете kernel panic или BSOD, есть большое количество вещей, которые вы можете сделать вместо того, чтобы перезагрузить компьютер и вернуться обратно к своей работе.

Проверить оперативную память: если вы обновляли оперативную память в своем компьютере, то первый шаг — это проверить то, что она корректно установлена. Если проблема продолжается, удалите оперативную память, добавленную недавно. Если это решит проблему, возможно, проблема в блоке оперативной памяти, поэтому свяжитесь с продавцом для возможной замены или возврата.

Используйте восстановление системы — если вы сделали множество изменений в вашей системе, подумайте об использовании Восстановления системы или Time Machine, чтобы вернуться к моменту до того, как стали появляться крахи системы.

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