Kernel panic linux как исправить

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

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

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

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

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

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

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

Чтобы активировать kdump, отредактируем этот файл и установим значение параметра USE_KDUMP=1.
Также в конфигурационном файле содержатся следующие параметры:

• KDUMP_KERNEL — полный путь к аварийному ядру;
• KDUMP_INITRD — полный путь к initrd аварийного ядра;
• KDUMP_CORE — указывает, где будет сохранен файл дампа ядра. По умолчанию дамп сохраняется в директории /var/crash (KDUMP_CORE=/var/crash);
• KDUMP_FAIL_CMD — указывает, какое действие нужно совершить в случае ошибки при сохранении дампа (по умолчанию будет выполнена команда reboot -f);
• DEBUG_KERNEL — отладочная версия работающего ядра. По умолчанию используются /usr/lib/debug/vmlinux-$. Если значение этого параметра не установлено, утилита makedumpfile создаст только дамп всех страниц памяти;
• MAKEDUMP_ARGS — содержит дополнительные аргументы, передаваемые утилите makedumpfile. По умолчанию этот параметр имеет значение ‘-c -d 31’, указывающую, что необходимо использовать сжатие и включать в дамп только используемые страницы ядра.

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

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

Обратим особое внимание на параметр crashkernel=384 -:128M. Он означает, что аварийное ядро будет использовать 128 Мб памяти при загрузке. Можно прописать в grub параметр crashkernel = auto: в этом случае память под аварийное ядро будет выделяться автоматически.

Для того, чтобы мы могли анализировать дамп с помощью утилиты 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:

Заключение

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

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

Источник

Операционная система 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 с другой версией ядра?

После появления сообщения Kernel panic ничего не остается, как перезагрузить компьютер. При перезагрузке появилось меню программы загрузчика операционной системы Ubuntu — GRUB2.02.

Дополнительные параметры для 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 загружается с последнего ядра Linux 4.4.0-57, которое чудным образом избавилось от ошибки Kernel panic. Для определения версии ядра Linux, в терминале введем команду uname -r

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

Источник

kernel panic no init found что делать((?

помогите! начальник на работе ругается. нет больше компа

Ядро обновлял? initrd не собрался?

Файловая система испортилась?

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

kernel panic no init found

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

> проверил диск на наличие плохих секторов,которых нашлась куча,все исправил

т.е. диск посыпался? а исправил как — fsck просто запустил? если да — так он убитые файлы и не вернет

> проверил диск на наличие плохих секторов,которых нашлась куча,все исправил т.е. диск посыпался? а исправил как — fsck просто запустил? если да — так он убитые файлы и не вернет

проверял fsck -c. дык делать то теперь что,вроде все файлы которые нужны есть.

Re: kernel panic no init found

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

А почему ты постеснялся написать обо всём об этом в заглавном посте?

Кстати, /sbin/init и библиотеки из /lib на месте?

kernel panic

слышал что то про /etc/lilo.conf, мол как то его исправить и все будет нормуль. у меня перед тем как появляется сообщение о панике ядра,есть еще строчка о том что то ли фс не может смонтировать то ли она как то не подходит.

Re: kernel panic no init found

/sbin/init на месте, а вот с библиотеками я как то не дружу,даже не знаю что там должно быть((

Re: kernel panic

> то ли фс не может смонтировать то ли она как то не подходит

Блин. Точные сообщения, пожалуйста.

Re: kernel panic

итак: 1.при перед строчкой о панике,имеется строчка о том,что не получилось смонтировать корневую фс. 2. на диске оказались поврежденные сектора,исправил все при помощи fsck -c. 3. загрузился с live cd, проверил что /sbin/init на месте и файл lilo.conf с момента нормальной работы не изменился (помню точно),fstab тоже. 4. пробовал говорить init = /sbin/init и init= /bin/bash ничег не менялось. . что еще можно поделать?

Re: kernel panic

Поставь по быстрому Windows, иначе могут уволить!

Поставь по быстрому Windows, иначе могут уволить!

народ,давайте лучьше линух спасем,ну оч надо!(

Поставь по быстрому Windows, иначе могут уволить!

если лайв сиди загружается — проще работать на нем — ну по крайней мере до конца рабочего дня — а потом уже делать движения всякие

> если лайв сиди загружается — проще работать на нем — ну по крайней мере до конца рабочего дня — а потом уже делать движения всякие

это понятно ,а движения то какие делать,вот в чем вопрос то?

Re: > если лайв сиди загружается — проще работать на нем — ну по крайней мере до конца рабочего дня — а потом уже делать движения всякие

это понятно ,а движения то какие делать,вот в чем вопрос то?

А в конце рабочего дня, нажмёшь на иконку: Install to HDD.

>А в конце рабочего дня, нажмёшь на иконку: Install to HDD.

а если без «instal to hdd». есть способ это как то по другому решиить?

тут что проще сделать смотри — если есть куда home скопировать — то проще переставить систему, а потом восстановить хомяк (имхо если винт посыпаслся — то я бы и его сменил заодно).

а,если вообще ничего не сносить и не переустанавливатть,я вот что имею ввиду?

Расскажи хоть, какой загрузчик — lilo или grub? Как ты передавал параметр «init=»? Что вообще за дистрибутив, какая версия?

А почему никто не предложил в chroot убитую систему погонять? Как минимум должно помочь выяснить что побилось.

загрузчик лило. система мсвс- переделаный чуть чуть ред хат для военных. при загрузке нажимаешь TAB появляется приглашение типа MCBC lilo: вот туда и пишу инит=. . так что там про chroot?

• Загрузиться с livecd
• Подцепить корень системы куда-нибудь
• Сбиндить (mount —bind) /dev, /proc и /sys в соответствующие каталоги на корне пациента
• chroot /каталог/куда/смонтирован/корень/поциента
• Смотрим внимательно на что ругается.

Как минимум должен запуситься bash из убитой системы. Если он таки запуститься, то init=/bin/bash в строке ядра должно срабатывать. Если нет — что-то с ядром или initrd.

У него какая-то проблема с корнем:

перед строчкой о панике,имеется строчка о том,что не получилось смонтировать корневую фс

fsck надо запустить с ключом -a.

А как он узнал, что init на месте? o_O

Если с live-cd монтируется, то видимо действительно поломались ядро/initrd. В МСВС должно быть два пункта меню lilo — с smp и без, можно попробовать второй.

1.что значит сбиндить,можно поподробней? 2. после проверки и исправления плохих секторов fsck говорит что все clean,но при загрузке строчка о проблемах монтирования все равно есть. 3. как узнал что инит на месте: загрузился с лайф сиди, создал каталог и смонтировал туда /dev/sda1. там и посмотрел. воть.

а что такое пункт меню с smp и как мне его посмотреть?

Это при загрузке — голубой экран с надписью «МСВС», таймером и двумя пунктами меню.

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

Если /usr и /var не на sda1 их тоже нужно прицепить.

Ты пробовал другой пункт меню выбирать?

И еще покажи точное сообщение об ошибке.

Luk, use install to hdd.

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

Процесс загрузки с лило такой:

lilo грузит kernel и initrd.

ядро в initrd находит некий файл и запускает, затем запускает /sbin/init с основной системы, ПОСЛЕ загрузки ‘драйверов’ с INITRD. Это драйвера для многих вещей включая драйвера файловой системы и контроллера дисков.

Таким образом, если с initrd что-то не так kernel не сможет загрузить /sbin/init. и опция init=/что-хошь не поможет.

Если таки с инитрд всё в порядке надо проверить есть ли на винчестере в точке монтирования / файл /sbin/init. (загрузиться с livecd)

Для исправления ситуации достаточно думаю переустановить пакеты с ядром и с инитом находясь в chroot. Но потом придётся определить что ещё поломалось.

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

>остаётся переустановить систему, или основательно разобраться

очень охото разобраться,интересно! помогите если не трудно!

# mkdir /mnt/sda1
# mount /dev/sda1 /mnt/sda1
# mount —bind /dev /mnt/sda1/dev
# mount —bind /proc /mnt/sda1/proc
# mount —bind /sys /mnt/sda1/sys
# chroot /mnt/sda1

если я правильно понял,то инитрд это часть ядра? а как проверить нормальный он или нет? и как переустановить пакеты с ядром и инитом в chroot? если можно,то поподробней пожалуйсто. заранее извиниюсь за дурацкие вопросы

Источник