Крах системы kernel panic в linux bsod в windows nt возникает

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поклонники операционной системы 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!

Если вы пользовались компьютером какое-то время, вы, несомненно, столкнулись с «голубым экраном смерти» или паникой ядра, когда компьютер перезагружался без предупреждения , стоив вам всей вашей работы.

Что вызывает это, и есть ли что-то, что вы можете сделать, чтобы предотвратить это в будущем? Давайте взглянем.

Что такое паника ядра и что ее вызывает?

Паника ядра или ее эквивалент в мире Windows: ошибка остановки или страшный синий экран смерти (BSOD), происходит в результате неуказанной ошибки низкого уровня, которую операционная система не может восстановить.

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

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

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

Windows — синий экран смерти

В Windows вы узнаете, что это произошло, потому что весь экран станет синим, с сообщением о необходимости перезагрузки компьютера.

макинтош

На версиях OS X 10.8 и позже. компьютер просто перезагружается без какого-либо предупреждения, после чего следует краткое сообщение, объясняющее, что произошло. На 10.7 и более ранних экранах экран становится более тревожным, с сообщением о необходимости перезагрузки.

Операционная система 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:

Заключение

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

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

Источник

A Linux kernel panic is a subroutine call that the kernel executes when the kernel logic determines that a condition exists that makes continued execution of the normal logic impossible or irresponsible.

The kernel can call a panic when:

1. It detects a software error in the kernel code or stack
2. When there is a run-time condition such as out-of-memory with no killable processes
3. A CPU exception during privileged mode execution results in an oops condition

There are about 950 distinct conditions where a panic is called in the 3.X kernels. The panic subroutine first prints the kernel stack dump and CPU registers to the console. Then, if a crash kexec kernel has been configured, it boots the kexec kernel. Otherwise the panic routine busts all spinlocks and performs an emergency restart.

An oops is a subroutine called from a CPU exception handler for a CPU exception that occurs while executing in privileged (i.e kernel) mode. The exception can occur as a result of an error in kernel code, or because of a hardware failure, or as the result of an external condition that causes a specific exception. The handler for the exception prints a kernel log with CPU registers and modules list. Unlike panic calls, the kernel logic itself never calls an oops outside the context of CPU exception handlers.

If the kernel is configured for kexec, then an oops will result in the kexec kernel being booted. Otherwise, if the exception occurs while executing an interrupt handler, then the oops results in a kernel panic call. Otherwise, if the kernel is is configured with “panic on oops”, then the oops will result in a panic call. Otherwise the the kernel exits the exception handler and resumes execution. When the kernel exits the exception handler and resumes execution, the integrity of the kernel is suspect.

CPU exception handlers are architecture-specific. They are usually implemented in arch/*/kernel/traps.c, and set in the architecture-specific kernel entry code that sets up the interrupt table. See for example arch/powerpc/kernel/traps.c and arch/powerpc/kernel/head_fsl_booke.S.

Both kernel panic and oops conditions can be configured to call a kmsg_dump routine that you can use to save crash debugging information to RAM, or to flash memory unless the oops occurred in interrupt context, in which case the “kmsg_dump” routine can only be used to save to RAM, not to MTD. When saving to RAM, it is your responsibility to a) ensure that the RAM area used is not overwritten during kexec boot or emergency restart boot, and b) to harvest the memory area from the kexec kernel or from the boot loader logic.

A Linux kernel panic is a subroutine call that the kernel executes when the kernel logic determines that a condition exists that makes continued execution of the normal logic impossible or irresponsible.

The kernel can call a panic when:

1. It detects a software error in the kernel code or stack
2. When there is a run-time condition such as out-of-memory with no killable processes
3. A CPU exception during privileged mode execution results in an oops condition

There are about 950 distinct conditions where a panic is called in the 3.X kernels. The panic subroutine first prints the kernel stack dump and CPU registers to the console. Then, if a crash kexec kernel has been configured, it boots the kexec kernel. Otherwise the panic routine busts all spinlocks and performs an emergency restart.

An oops is a subroutine called from a CPU exception handler for a CPU exception that occurs while executing in privileged (i.e kernel) mode. The exception can occur as a result of an error in kernel code, or because of a hardware failure, or as the result of an external condition that causes a specific exception. The handler for the exception prints a kernel log with CPU registers and modules list. Unlike panic calls, the kernel logic itself never calls an oops outside the context of CPU exception handlers.

If the kernel is configured for kexec, then an oops will result in the kexec kernel being booted. Otherwise, if the exception occurs while executing an interrupt handler, then the oops results in a kernel panic call. Otherwise, if the kernel is is configured with “panic on oops”, then the oops will result in a panic call. Otherwise the the kernel exits the exception handler and resumes execution. When the kernel exits the exception handler and resumes execution, the integrity of the kernel is suspect.

CPU exception handlers are architecture-specific. They are usually implemented in arch/*/kernel/traps.c, and set in the architecture-specific kernel entry code that sets up the interrupt table. See for example arch/powerpc/kernel/traps.c and arch/powerpc/kernel/head_fsl_booke.S.

Both kernel panic and oops conditions can be configured to call a kmsg_dump routine that you can use to save crash debugging information to RAM, or to flash memory unless the oops occurred in interrupt context, in which case the “kmsg_dump” routine can only be used to save to RAM, not to MTD. When saving to RAM, it is your responsibility to a) ensure that the RAM area used is not overwritten during kexec boot or emergency restart boot, and b) to harvest the memory area from the kexec kernel or from the boot loader logic.

Kernel panic (англ. тревога, сбой в ядре , дословно паника ядра) — сообщение о критической ошибке ядра операционной системы, после которой операционная система не может продолжать дальнейшую работу [1] .

Обычно этот термин применяется в среде операционных систем типа UNIX. Её имя связано с текстом ошибки вида « Kernel panic: … » и именем функции ядра panic() из оригинальной ОС UNIX [2] .

Kernel panic возможен на Andro >[3] .

Содержание

История [ править | править код ]

История Kernel panic тесно связана с историей операционной системы UNIX, которая была разработана в конце 1960-х годов сотрудниками Bell Labs, в первую очередь Кеном Томпсоном, Деннисом Ритчи и Дугласом Макилроем.

Сообщение Kernel panic было введено в ранних версиях UNIX и представляло собой важное отличие в философии этой операционной системы от главного конкурента на то время и предшественника UNIX, Multics. Multics был разработан для работы на 36-битном мейнфрейме GE-645, в то время как UNIX разрабатывался для гораздо менее мощного 18-битного мини-компьютера PDP-7 и по этой причине операционной системе было доступно меньше ресурсов, что привело к необходимости их экономии, в том числе и при обработке ошибок. Разработчик Multics, Том ван Влек, так описывает это изменение в дискуссии с разработчиком UNIX Деннисом Ритчи [4] :

Я сказал Деннису, что примерно половина кода, который я написал для Multics, была кодом обработки ошибок. Он ответил: «Мы всё это отбросили. Если произошла ошибка, у нас есть процедура под названием panic, и если она вызвана, компьютер зависает и вы кричите: „Эй, перезапустите его!“».

Изначальная функция panic() принципиально не менялась от UNIX V5 до базирующихся на VAX систем 32V и выводила только сообщение об ошибке без дополнительной информации, после чего система переводилась в бесконечный пустой цикл. Позже, в процессе развития UNIX, функция panic() была доработана и стала выводить на терминал разнообразную информацию, необходимую для отладки.

Подобный принцип обработки критических ошибок был перенят большинством более поздних операционных систем, например Mac OS [3] или Microsoft Windows [5] .

Причины Kernel panic [ править | править код ]

Одной из самых распространённых причин kernel panic является невозможность найти и смонтировать корневую файловую систему. Часто это ошибка конфигурации, которая может быть исправлена при перезагрузке ядра вручную [6] .

В Linux возникновению паники ядра зачастую предшествует состояние под названием oops. В ряде случаев oops может приводить к такому же неработоспобному состоянию системы, как и паника ядра [1] .

В большинстве остальных случаев причиной Kernel panic является критическая аппаратная ошибка (отказ оперативной памяти, ошибка процессора, материнской платы, графической карты или другого критически важного устройства) или ошибка в самом ядре операционной системы, например, попытка обращения к ошибочному или запрещённому адресу в памяти. Также причиной для Kernel panic могут быть ошибки в драйверах периферийных устройств или ошибки в файловой системе [3] [7] . Во время финальной стадии инициализации пространства пользователя, kernel panic обычно возникает тогда, когда не удалось запустить init, так как, несмотря на запущенное и работоспособное ядро, сама система остаётся непригодной к дальнейшей работе [8] . Kernel panic может быть вызван и прикладными программами, если те некорректно работают с ядром. Так, ошибка в Google Chrome вызывала Kernel panic на Mac OS X [9] .

Исходный код функции panic() [ править | править код ]

Исходный код функции panic() в UNIX V6 [10] :

Обработка Kernel panic [ править | править код ]

В нормальном случае при возникновении Kernel panic происходит остановка работы операционной системы с выдачей сообщений об ошибках на экран, после чего система ожидает выключения компьютера или перезагрузки. Однако, такая обработка этого события неприемлема тогда, когда простой компьютера крайне нежелателен или человека нет рядом (например на удалённых серверах или в нерабочее время) [11] .

В современных операционных системах, таких как GNU/Linux, FreeBSD или Solaris, существует возможность изменить стандартное поведение функции panic() и производить перезагрузку компьютера автоматически. В GNU/Linux данная настройка осуществляется при помощи procfs [11] :

Чтобы изменения действовали в GNU/Linux и после перезагрузки, необходимо добавить в файл /etc/sysctl.d/99-sysctl.conf строку:

Значение параметра kernel.panic — количество секунд, после которых произойдёт перезагрузка. При установке отрицательного или равного 0 значения этого параметра, автоматической перезагрузки не произойдёт [11] .

Также в системах BSD есть специальная опция в ядре. Цитата из файла /usr/src/sys/conf/NOTES [12] :

В Solaris автоматическая перезагрузка после Kernel panic является стандартным поведением системы [13] .

Перезагрузка после Kernel panic имеет и очень серьёзный недостаток, особенно если это изменение не пропадает после первой перезагрузки. В случае, если перезагрузка не устраняет ту ошибку, которая вызывает Kernel panic, система будет останавливаться и перезапускаться вновь и вновь, что может привести к аппаратным ошибкам или потерям данных [6] . В случае если такая ситуация возникла после сборки нового ядра, решением проблемы может стать загрузка сохранённой копии старого, работающего ядра. Как правило, для этого достаточно вручную указать при загрузке путь к работоспособной копии ядра [14] .

Для изучения причины паники ядра Linux может пригодиться файл System.map [15] .

Kernel panic в различных операционных системах [ править | править код ]

Изначально сообщение о Kernel panic ограничивалось коротким текстом о необходимости перезагрузки системы. В современных системах обычно выдается больше дополнительной информации.

• GNU/Linux и большинство других UNIX-совместимых операционных систем создают лог с описанием ошибки и выводят на экран сообщение об ошибке, содержащее информацию, необходимую для отладки и поиска причин этой ошибки. Этот механизм носит название Linux oops. В современных дистрибутивах Linux используется графический сервер X Window, и Kernel panic не приводит к переключению на физическую консоль, на которую выводятся диагностические сообщения. Распознать Kernel panic можно по мигающим светодиодам Caps Lock и Scroll Lock на клавиатуре [16] .
• В изначальных версиях Mac OS X (от 10.0 до 10.0.1.5) по аналогии с операционными системами, базирующимися на ядре Linux, на экран выводилась информация о произошедшей ошибке, после чего система останавливалась. Начиная с версии Mac OS X 10.2 это сообщение было упрощено и сообщает лишь о необходимости перезапустить компьютер на четырёх языках (английском, немецком, французском и японском) вне зависимости от языковой версии операционной системы [3][17] . Однако, OS X позволяет [17] заменить изображение на любое другое, что дает возможность разработчикам показывать изменённые сообщения об ошибках в различных ситуациях [17] . Благодаря этой возможности на OS X возможно даже симулировать Синий экран смерти операционной системы Windows, заменив стандартное изображение скриншотом соответствующего изображения Windows[17] .

В не-UNIX операционных системах [ править | править код ]

В то время как термин Kernel panic употребляется в основном для UNIX-совместимых операционных систем, в других операционных системах обработка критических ошибок методом остановки системы тоже прижилась и получила следующие названия:

• В большинстве версий Microsoft Windows система останавливается с выдачей голубого экрана с кратким описанием ошибки [5] , который получил название Синий экран смерти. В операционной системе Windows XP при возникновении ошибки компьютер перезагружается автоматически. Это поведение системы управляется через Панель управления Windows. Если ошибка происходит при загрузке ОС, изменить поведение системы можно через меню кнопки F8 [5] .
• В старых компьютерах Macintosh: Sad Mac ( англ. ) (аппаратная ошибка при запуске системы) [18] , Bomb ( англ. ) (для ошибок программ или операционной системы) [19] .
• На компьютерах Amiga в AmigaOS до 2.04 этот механизм назывался Guru Meditation и работал аналогично Kernel panic в Unix [20] . В последующих версиях текст «Guru meditation» был удалён из сообщения об ошибке [20] .

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

Первый способ состоит в том чтобы добавить параметр ядра panic=num_seconds в конфигурационном файле загрузчика Grub. Num_seconds — количество секунд до автоматической перезагрузки.

sudo nano /boot/grub/grub.cfg

linux /vmlinuz-3.18.7-gentoo root=/dev/sda3 ro panic=10

Можно также добавить этот параметр в шаблон конфигурации, как это сделать читайте в статье Устанавливаем параметры ядра в grub

Второй способ — указать параметр kernel.panic в файле sysctl.conf:

sudo nano /etc/sysctl.conf

sudo sysctl -p /etc/sysctl.conf

И наконец можно использовать подсистему /proc для изменения параметра panic:

sudo echo 10 > /proc/sys/kernel/panic

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

Kernel panic (англ. тревога, сбой в ядре , дословно паника ядра) — сообщение о критической ошибке ядра операционной системы, после которой операционная система не может продолжать дальнейшую работу [1] .

Обычно этот термин применяется в среде операционных систем типа UNIX. Её имя связано с текстом ошибки вида « Kernel panic: … » и именем функции ядра panic() из оригинальной ОС UNIX [2] .

Kernel panic возможен на Andro >[3] .

Содержание

История [ править | править код ]

История Kernel panic тесно связана с историей операционной системы UNIX, которая была разработана в конце 1960-х годов сотрудниками Bell Labs, в первую очередь Кеном Томпсоном, Деннисом Ритчи и Дугласом Макилроем.

Сообщение Kernel panic было введено в ранних версиях UNIX и представляло собой важное отличие в философии этой операционной системы от главного конкурента на то время и предшественника UNIX, Multics. Multics был разработан для работы на 36-битном мейнфрейме GE-645, в то время как UNIX разрабатывался для гораздо менее мощного 18-битного мини-компьютера PDP-7 и по этой причине операционной системе было доступно меньше ресурсов, что привело к необходимости их экономии, в том числе и при обработке ошибок. Разработчик Multics, Том ван Влек, так описывает это изменение в дискуссии с разработчиком UNIX Деннисом Ритчи [4] :

Я сказал Деннису, что примерно половина кода, который я написал для Multics, была кодом обработки ошибок. Он ответил: «Мы всё это отбросили. Если произошла ошибка, у нас есть процедура под названием panic, и если она вызвана, компьютер зависает и вы кричите: „Эй, перезапустите его!“».

Изначальная функция panic() принципиально не менялась от UNIX V5 до базирующихся на VAX систем 32V и выводила только сообщение об ошибке без дополнительной информации, после чего система переводилась в бесконечный пустой цикл. Позже, в процессе развития UNIX, функция panic() была доработана и стала выводить на терминал разнообразную информацию, необходимую для отладки.

Подобный принцип обработки критических ошибок был перенят большинством более поздних операционных систем, например Mac OS [3] или Microsoft Windows [5] .

Причины Kernel panic [ править | править код ]

Одной из самых распространённых причин kernel panic является невозможность найти и смонтировать корневую файловую систему. Часто это ошибка конфигурации, которая может быть исправлена при перезагрузке ядра вручную [6] .

В Linux возникновению паники ядра зачастую предшествует состояние под названием oops. В ряде случаев oops может приводить к такому же неработоспобному состоянию системы, как и паника ядра [1] .

В большинстве остальных случаев причиной Kernel panic является критическая аппаратная ошибка (отказ оперативной памяти, ошибка процессора, материнской платы, графической карты или другого критически важного устройства) или ошибка в самом ядре операционной системы, например, попытка обращения к ошибочному или запрещённому адресу в памяти. Также причиной для Kernel panic могут быть ошибки в драйверах периферийных устройств или ошибки в файловой системе [3] [7] . Во время финальной стадии инициализации пространства пользователя, kernel panic обычно возникает тогда, когда не удалось запустить init, так как, несмотря на запущенное и работоспособное ядро, сама система остаётся непригодной к дальнейшей работе [8] . Kernel panic может быть вызван и прикладными программами, если те некорректно работают с ядром. Так, ошибка в Google Chrome вызывала Kernel panic на Mac OS X [9] .

Исходный код функции panic() [ править | править код ]

Исходный код функции panic() в UNIX V6 [10] :

Обработка Kernel panic [ править | править код ]

В нормальном случае при возникновении Kernel panic происходит остановка работы операционной системы с выдачей сообщений об ошибках на экран, после чего система ожидает выключения компьютера или перезагрузки. Однако, такая обработка этого события неприемлема тогда, когда простой компьютера крайне нежелателен или человека нет рядом (например на удалённых серверах или в нерабочее время) [11] .

В современных операционных системах, таких как GNU/Linux, FreeBSD или Solaris, существует возможность изменить стандартное поведение функции panic() и производить перезагрузку компьютера автоматически. В GNU/Linux данная настройка осуществляется при помощи procfs [11] :

Чтобы изменения действовали в GNU/Linux и после перезагрузки, необходимо добавить в файл /etc/sysctl.d/99-sysctl.conf строку:

Значение параметра kernel.panic — количество секунд, после которых произойдёт перезагрузка. При установке отрицательного или равного 0 значения этого параметра, автоматической перезагрузки не произойдёт [11] .

Также в системах BSD есть специальная опция в ядре. Цитата из файла /usr/src/sys/conf/NOTES [12] :

В Solaris автоматическая перезагрузка после Kernel panic является стандартным поведением системы [13] .

Перезагрузка после Kernel panic имеет и очень серьёзный недостаток, особенно если это изменение не пропадает после первой перезагрузки. В случае, если перезагрузка не устраняет ту ошибку, которая вызывает Kernel panic, система будет останавливаться и перезапускаться вновь и вновь, что может привести к аппаратным ошибкам или потерям данных [6] . В случае если такая ситуация возникла после сборки нового ядра, решением проблемы может стать загрузка сохранённой копии старого, работающего ядра. Как правило, для этого достаточно вручную указать при загрузке путь к работоспособной копии ядра [14] .

Для изучения причины паники ядра Linux может пригодиться файл System.map [15] .

Kernel panic в различных операционных системах [ править | править код ]

Изначально сообщение о Kernel panic ограничивалось коротким текстом о необходимости перезагрузки системы. В современных системах обычно выдается больше дополнительной информации.

• GNU/Linux и большинство других UNIX-совместимых операционных систем создают лог с описанием ошибки и выводят на экран сообщение об ошибке, содержащее информацию, необходимую для отладки и поиска причин этой ошибки. Этот механизм носит название Linux oops. В современных дистрибутивах Linux используется графический сервер X Window, и Kernel panic не приводит к переключению на физическую консоль, на которую выводятся диагностические сообщения. Распознать Kernel panic можно по мигающим светодиодам Caps Lock и Scroll Lock на клавиатуре [16] .
• В изначальных версиях Mac OS X (от 10.0 до 10.0.1.5) по аналогии с операционными системами, базирующимися на ядре Linux, на экран выводилась информация о произошедшей ошибке, после чего система останавливалась. Начиная с версии Mac OS X 10.2 это сообщение было упрощено и сообщает лишь о необходимости перезапустить компьютер на четырёх языках (английском, немецком, французском и японском) вне зависимости от языковой версии операционной системы [3][17] . Однако, OS X позволяет [17] заменить изображение на любое другое, что дает возможность разработчикам показывать изменённые сообщения об ошибках в различных ситуациях [17] . Благодаря этой возможности на OS X возможно даже симулировать Синий экран смерти операционной системы Windows, заменив стандартное изображение скриншотом соответствующего изображения Windows[17] .

В не-UNIX операционных системах [ править | править код ]

В то время как термин Kernel panic употребляется в основном для UNIX-совместимых операционных систем, в других операционных системах обработка критических ошибок методом остановки системы тоже прижилась и получила следующие названия:

• В большинстве версий Microsoft Windows система останавливается с выдачей голубого экрана с кратким описанием ошибки [5] , который получил название Синий экран смерти. В операционной системе Windows XP при возникновении ошибки компьютер перезагружается автоматически. Это поведение системы управляется через Панель управления Windows. Если ошибка происходит при загрузке ОС, изменить поведение системы можно через меню кнопки F8 [5] .
• В старых компьютерах Macintosh: Sad Mac ( англ. ) (аппаратная ошибка при запуске системы) [18] , Bomb ( англ. ) (для ошибок программ или операционной системы) [19] .
• На компьютерах Amiga в AmigaOS до 2.04 этот механизм назывался Guru Meditation и работал аналогично Kernel panic в Unix [20] . В последующих версиях текст «Guru meditation» был удалён из сообщения об ошибке [20] .

Kernel Panics

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

Определение

Хорошее определение краха ядра можно найти в википедии, в которой говорится, что Kernel Panic — вывод системой информационного сообщения об неустранимом сбое в работе, который не позволяет дальнейшей безопасной работе всей ОС; термин во многом специфичный для Unix и Unix-подобных операционных систем. Его эквивалент в системах Microsoft Windows  — «синий экран смерти».

Что делать

В принципе, проблема в том, что операционная система не загружается корректно. Отличия поведения системы могут быть выражены, например, при вводе компьютера в суспенд, или операционная система может выдать сообщение об ошибке какого-то устройства или если не может загрузить что-либо, что ожидалось согласно настройкам(командная строка, интерфейс, модуль, драйвер или что-то еще). Устранение ошибки  потребует некоторых ваших усилий в командной строке, если вы можете загрузить её, или с загрузочного диска, если он поможет вам получит командную строку или ваш любимый интерфейс пользователя.

Поиск проблемы

Для упрощения устранения неисправностей, убедитесь, что ядро не в тихом режиме. Удалить «тихий» режим из ядра можно в GRUB, если он у вас есть. После загрузки, проверьте вывод непосредственно перед паникой, и решите, есть ли в нем какая-то полезная информация. Вероятно что есть,большинство причин паники документировано в википедии arclinux. Убедитесь что в конфигурации загрузки указано верное расположение корня системы-  «/», и что ни одно из комплектующих компьютера не повреждено. Неплохой идеей будет запустить MemTest от c установочного диска Arch / Rescue CD или другую утилиту. Если вы считаете, что в конфигурации указан неверно, попробуйте Вариант 1 для восстановления загрузчика установки. Если вы верите что паника ядра это вина самого ядра, выполните Вариант 2 для того, чтобы переустановить существующую версию или откатить ядро.

Вариант 1: Проверка кофигурации загрузчика

Одна из возможностей — это ошибка в конфигурации загрузчика (например, / Boot / GRUB / menu.lst).

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

Вариант 2: Переустановка ядра

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

Запуск с установочного CD

Первый шаг — запуск установочного CD.Когда запустите, наберите arch, тем самым вы запустите установку arch.

# arch

Chroot в нормальный корень

После загрузки вы окажитесь в минимальной, но функциональной рабочей версии GNU/Linux окружения с несколькими простыми утилитами в комплекте.Теперь примонтируйте ваш корневой раздел в директорию /mnt.

# mount /dev/sdXY /mnt

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

# mount /dev/sdXZ /mnt/boot

Новые ядра запускают ramdisk для установки окружения ядра. После переустановки ядра вы увидите что  запуск ramdisk был спровоцирован mkinitcpio. Одна из возможностей mkinitcpio’s — знать что ядро требует из модулей для своей загрузки. Для автоопределения и работы этой системы монтируем директории в наш подмененный корень (chroot) директории /dev, /sys и /proc :

# mount -t proc none /mnt/proc
# mount -t sysfs none /mnt/sys
# mount --bind /dev /mnt/dev

Теперь делаем chroot в этот диск:

# chroot /mnt

Откат ядра

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

Давайте предположим что оно у вас уже есть:

# pacman -U /var/cache/pacman/pkg/kernel26-2.6.23.xx-x.pkg.tar.gz

Конечно, убедитесь, что вы адаптировали ядро для себя

В противном случае — проверьте ваш CD на наличие пакетов с ядром. Например, в версии 2008.06 i686 компакт-диск содержит addons/core-pkgs/kernel26-2.6.25.6-1-i686.pkg.tar.gz.

Перезагрузка

Теперь время перезагрузиться и посмотреть — имел ли какой-то смысл ваши действия по предотвращению паники ядра. Если вернулись к старому рабочему ядру — не забудьте посмотреть ARCH-NEWSPAGE, чтобы проверить, что изменилось в последней версии ядра для локализации вашей проблемы.