Kernel Panic Linux как исправить

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

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

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

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

Ss rdx kernel panic! samsung a70

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

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

Возможные причины для kernel panic

• Отказ оперативной памяти
• Программные ошибки или вредоносное ПО
• Неисправное оборудование (например, оперативная память — если вы обновили свою RAM до неподдерживаемой частоты или она не установлена ​​должным образом);
• Несовместимые драйвера;
• Ошибка в самом ядре операционной системы
• У пользователей Windows, это чаще происходит из-за вирусов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Находим причину kernel panic

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

Чтобы просмотреть лог в Windows, возможно, вам потребуется загрузить и установить Debugging Tool для Windows. Обычно, впрочем, вам нужно просто проверить лог на несколько общих причин, чтобы понять, можно ли винить их.

Неисправность или сбои оперативной памяти (ram)

Проблемы с оперативной памятью являются одной из самых распространенных причин возникновения критических сбоев. Если вам не удается проследить зависимость появления «kernel panic» от подключения каких-либо конкретных устройств или запуска определенных процессов, стоит проверить именно оперативную память.

Для этого вы можете воспользоваться Функциональным тестом оборудования Apple (AHT) или, если ваш Mac выпущен после 2022 года, Apple Diagnostics. Если к компьютеру прилагался диск с программным обеспечением системы, вставьте его в оптический привод, выключите компьютер и нажмите клавишу D при следующем включении.

Устройства, поставлявшиеся с OS X 10.7 и выше также поддерживают запуск интернет-версии тестов. Для этого убедитесь, что ваш Mac подключён к сети Интернет и при запуске зажмите сочетание клавиш ⌥Alt D.

Для теста оперативной памяти также можно воспользоваться и сторонними утилитами, например, Rember или Memtest.

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

Некорректно работающее компоненты mac os x и расширения ядра

Компоненты Mac OS X и расширения ядра — это очень обширная тема, не только из-за того, что они уязвимы для огромного количества различных неисправностей, в числе которых повреждение данных, несовместимость оборудования, некорректная настройка прав доступа и многие другое, но и за счет своей многочисленности.

Для примера можно заглянуть в папку /System/Library/Extensions, каждый файл в которой расширяет функционал ядра Mac OS X и может оказаться причиной причиной возникновения «kernel panic». В среднем система насчитывает около 250-300 расширений ядра (и это далеко не предел), что может превратить диагностику ошибки в поиск иголки в стоге сена.

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

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

Некорректные настройки

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

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

Помимо этого может помочь запуск системы в безопасном режиме. Для этого выключите компьютер и при следующем включении зажмите клавишу ⇧Shift. Таким образом вы не только временно отключите все сторонние расширения ядра, дополнения системы и настройки, которые могут привести к сбоям, но и очистите некоторые временные файлы, которые также могут послужить причиной возникновения проблемы.

И, наконец, если у вас есть внешний носитель (флешка или внешний диск), вы можете провести чистую установку системы на него, затем перезагрузить компьютер и при включении зажать клавишу ⌥Alt/Option. В результате на экране отобразится список устройств, с которых можно осуществить загрузку системы.

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

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

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

Ошибки кэша

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

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

1. Откройте Finder и нажмите сочетание клавиш ⌘Command ⇧Shift G
2. В открывшемся окне введите /System/Library
3. Нажмите кнопку «Перейти»
4. В открывшейся папке найдите файлы с названиями «Extensions.kextcache» и «Extensions.mkext» и удалите их.
5. В этой же директории найдите папку «Caches» выделите все её содержимое и удалите.
6. Снова нажмите сочетание ⌘Command ⇧Shift G и введите в открывшемся окне /Library/Caches/
7. Снова выделите и удалите все содержимое папки.
8. Наконец, ещё раз нажмите сочетание ⌘Command ⇧Shift G и введите в открывшемся окне ~/Library/Caches
9. Удалите содержимое этой папки.
10. Перезагрузите систему и проверьте, не возникают ли критические ошибки.

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

Рассмотрим частный случай получения ошибки 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, если конечно вы все ядра планируете загружать. Обычно достаточно последнее ядро и предыдущее.

Сбои nvram и smc

В небольшом секторе памяти вашего компьютера под названием «энергонезависимое ОЗУ», или NVRAM, сохраняются определенные настройки, к которым OS X может быстро получить доступ.  В настройки, сохраняемые в NVRAM, могут закрасться ошибки, которые в определенных случаях могут привести к появлению kernel panic.

Для того чтобы устранить возможные ошибки памяти NVRAM стоит произвести её сброс. Для этого выключите компьютер и при следующем его включении зажмите клавиши ⌘Command ⌥Alt/Option P R и удерживайте их до тех пор, пока компьютер не перезагрузится и вы не услышите сигнал загрузки во второй раз.

На более старых компьютерах Mac подобная информация сохранялась в параметрическом ОЗУ (PRAM). Сброс NVRAM на компьютерах Mac с процессорами Intel выполняется с помощью такой же комбинации клавиш и аналогичен сбросу PRAM.

Если вы пользуетесь беспроводной клавиатурой, есть небольшая вероятность, что компьютер не будет реагировать на нажатия клавиш на ней. В этом случае стоит подключить USB клавиатуру (не имеет значения, будь то клавиатура Apple или Windows) и повторить попытку с ней.

Помимо этого на компьютерах Mac с процессором Intel установлен контроллер управления системой (SMC), который отвечает за многие низкоуровневые функции, такие как управление ресурсами аккумулятора, управление температурой, реакция на закрытие крышки портативных компьютеров и многие другие аспекты, связанные с питанием вашего Mac. В случае возникновения проблем с работой компьютера параметры SMC также стоит сбросить.

На ноутбуках с несъёмным аккумулятором:

1. Выключите компьютер.
2. Подключите адаптер питания MagSafe или USB-C к источнику питания и к компьютеру.
3. Нажмите на встроенной клавиатуре одновременно клавиши ⇧Shift Control  ⌥Alt/Option (слева) и кнопку питания.
4. Одновременно отпустите клавиши и кнопку питания.
5. Нажмите кнопку питания, чтобы включить компьютер.

На ноутбуках Mac со съемным аккумулятором:

1. Выключите компьютер.
2. Отключите адаптер питания MagSafe от компьютера, если он подключен.
3. Выньте аккумулятор.
4. Нажмите и удерживайте кнопку питания в течение пяти секунд.
5. Отпустите кнопку питания.
6. Снова подключите аккумулятор и адаптер питания MagSafe.
7. Нажмите кнопку питания, чтобы включить компьютер.

На Mac Pro, iMac, Mac mini и Xserve:

1. Выключите компьютер.
2. Отсоедините шнур питания компьютера.
3. Подождите 15 секунд.
4. Присоедините шнур питания.
5. Подождите 5 секунд, а затем нажмите кнопку питания, чтобы включить компьютер.

Сбои в работе внешних устройств (периферии)

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

В этом случае «kernel panic» могут возникать сразу при подключении устройства, при запуске системы, если устройство уже было подключено к Mac и в момент выхода компьютера из спящего режима.

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

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

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

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

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

Сбои в работе комплектующих

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

Часто подобные проблемы могут решаться простым переподключением соответствующих комплектующих. Если вы недавно делали апгрейд своего Mac (особенно, если своими силами), стоит убедиться, что все PCI, PCI Express, AirPort и прочие платы расширения корректно подключены к соответствующим разъемам.

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

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

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

Источник

Способы избежать паники ядра

Обычно Kernel Panic происходит не так часто, и на самом деле довольно редко(за исключением Windows пользователей). Чтобы избежать паники ядра, вы должны четко знать технические характеристики вашего компьютера, а не просто установить новую память с любыми частотами. А чтобы не было системной паники, вы должны постоянно обновлять свою систему

Тестируем kdump

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

Заключение

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