Linux вызвать kernel panic

Обновлено: 06.07.2024

1) Берем ноутбук (в моем случае EeePC 1000H)
2) Много раз подряд нажимаем кнопку включения/выключения Wi-Fi (в моем случае Fn+F2)
3) Любуемся.

PS: а еще после очередного обновления у меня перестал работать гибернейт.


Что сказать то хотел?

Там не обнуляется счётчик включений и на 4294967296-ом нажатии он падает с ошибкой?

Нет, достаточно нажать всего раз пять.


Ну запости в багтрекер, чо


> PS: а еще после очередного обновления у меня перестал работать гибернейт.


а на винде, такое работает?


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


судя по звездам он тут давно ))


Смех смехом, но у меня такая лажа была на 3945 под вендой когда-то. А сейчас нет под Линуксом.


Что побудило тебя много раз подряд нажимать на кнопку включения вафли?


Желание написать нытик-тред на ЛОР, это же очевидно. С бабами, видимо, всё хорошо или наоборот никак, чтобы было что про них писать.

> Что побудило тебя много раз подряд нажимать на кнопку включения вафли?

Показалось, что не сработало с первого раза, нажал второй. Оказалось, что сработало с первого, пришлось нажать еще. Трех раз тогда хватило.

> Ну запости в багтрекер, чо

Да как бы уже пишу (:


Видимо сеё работает исключительно в в школьном поделии арчика.немудренно. P.S в убунте и дебияне УМВР


И где вы их находите? Ни разу в жизни не видел настоящей CP ('VFS not syncing', говорят, не считается).

> судя по звездам
ЛОРовская астрология :-)

Кстати не уверен, паник это или просто какой-нибудь oops, но система ни на что не реагирует после этого.

>И где вы их находите? Ни разу в жизни не видел настоящей CP ('VFS not syncing', говорят, не считается).


> Кстати не уверен, паник это или просто какой-нибудь oops, но система ни на что не реагирует после этого.

В панике система должна светодиодами клавиатурными моргать по идее.


Лицоладонь. Правда, я подозревал, что сокращение CP может быть истолковано неоднозначно :)

Так а что ты имел ввиду? Cernel Panic?


Охтыж. Выходит, да. Хорошо ступил %)


Child pr0n же. Что же еще?

Палишься, видимо :D

не работает на асусе к40ин :З

плохой баг нашел

Хм, интересно. Тогда жду, пока кто-нибудь с подобным нетбуком не появится.


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

Хм.. у меня тоже самое на арче на EeePC 1000 - несколько раз выключал и включал вай-фай (Fn+F2) и 3 раза ловил кернел паник (именно кернел паник). Но было это месяц-два назад. Щас проверил - не воспроизводиться.

А оно когда как, иногда срабатывает, а иногда нет.


hp mini 311 хватает 3х раз обычно.. только не кернел паник, а полное зависание с тишиной в логах(((


Только что проверил - раз 20-30 понажимал - не роботает. Arch 2.6.38, Дрова пропиетарные, ибо синезуб нужен.


30 раз нажал, ничего не произогло

eMashines D520, Wifi от Atheros


>Ни разу в жизни не видел настоящей CP


Спасибо, Евгений Ваганович, но я не любитель этой гадости.

Апдейты - это зло.


Не работает. Asus EEE PC T91, Kubuntu 11.04

Нетбуки мне кажется похожие.

> Еще один способ вызвать кернел паник

У вас archlinux.

> полное зависание с тишиной в логах

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


попробуй поставить на свой комп MacOSX, да не хакерскую сборочку, а самому. Навидаешься по нехочу.


текста нет, на экране застывает последнее изображение до зависания. печаль в общем(((

Кстати, оказывается этот баг уже зарепорчен давно:

Если это конечно оно. Но по симптомам похоже.

Lenovo thinkpad edge не помню какой, тот что с интелом двухядерным и небольшим экраном (не люблю большие ноуты таскать) - после обновлений рандомно что то отваливается, после сна через раз kernel panic - так что не удивил.


У меня ещё бывает биос в панику выпадает (загораются все лампочки, а экран нет) при просыпании, после этого часы начинают ровно на 30000 секунд отставать, мистика вообщем.


Часто встречающаяся ситуация: виртуальный или аппаратный сервер завис и не отвечает. Заходите на него с помощью инструмента удаленного управления IPMI или консоли VNC, видите только черный экран и ничего кроме. Скорее всего, ядро Linux вошло в режим паники (Kernel Panic), который вызван сбоем одного из модулей ядра, ошибкой в самом ядре, критической аппаратной ошибкой.

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

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

В рамках инструкции будем использовать два сервера:

На сервере panic мы настроим netconsole и будем имитировать ситуацию паники ядра. На сервере monitor мы настроим rsyslogd для поддержки удаленного журналирования по протоколу udp. Начнем с настройки узла monitor.

Настройка Rsyslog на узле monitor

Сохраните файл и перезапустите rsyslogd:

убедимся, что rsyslog слушает порт 514 по протоколу UDP:

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

Настройка Iptables на узле monitor

Установим пакет iptables-persistent.

Если вы предпочитаете для настройки использовать UFW, можете использовать этот инструмент. Мы подразумеваем, что используются настройки iptables, по умолчанию пропускающие весь трафик, поэтому будем использовать запрещающие правила.

Добавим сохранение правил в iptables-persistent:

Если вы используете приложения, которые добавляют свои правила, например, fail2ban или docker, удалите правила этих приложений из созданных файлов /etc/iptables/rules.v4, /etc/iptables/rules.v6. Например, для fail2ban необходимо удалить правила:

Для проверки корректности настроек перезагрузите сервер monitor и после завершения загрузки проверьте наличие в iptables всех нужных правил с помощью команд iptables-save и ip6tables-save:

На этом настройку хоста monitor считаем законченной. Перейдем к настройке хоста panic.

Настройка модуля netconsole на узле panic

В документации ядра Linux к модулю netconsole можно увидеть, что модуль принимает следующие настройки:

разберем каждую из них:

как можно видеть, параметры, кроме tgt-ip опциональны, но мы зададим их все для большей ясности.

После выполнения этих операций загрузим модуль в память:

На этом настройка модуля завершена. Убедимся в том, что он работает. Для этого смоделируем событие паники ядра. Сначала запустим отслеживание событий syslog в режиме реального времени на сервере monitor:

В журнале вы должны увидеть строку, похожую на эту:

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

Заключение

kernel panic

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

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

Что такое Kernel Panic?

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

Но, как насчет Kernel Panic? Вы слышали это имя раньше?

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

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

паника ядра

Возможные причины для Kernel Panic

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

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

Вывод

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.


Что­бы выпол­нить все задуман­ное, нам понадо­бят­ся сле­дующие ути­литы:

  • GCC — ком­пилятор C, что­бы ком­пилиро­вать ядро;
  • GDB — отладчик, который нам при­годит­ся, что­бы отла­живать ядро;
  • BC — будет нужен для сбор­ки ядра;
  • Make — обра­бот­чик рецеп­тов сбор­ки ядра;
  • Python — интер­пре­татор язы­ка Python, он будет исполь­зовать­ся модуля­ми GDB;
  • pacstrap или debootstrap — скрип­ты для раз­вер­тки сис­темы. Будут нуж­ны, что­бы соб­рать rootfs;
  • лю­бой тек­сто­вый редак­тор (подой­дет Vim или nano), что­бы написать модуль и рецепт к нему;
  • qemu-system-x86_64 — вир­туаль­ная машина, с помощью которой мы будем запус­кать ядро.

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

В целях экспе­римен­та нам понадо­бит­ся ядро Linux, которое при­дет­ся самос­тоятель­но соб­рать.

Конфигурация

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

Су­щес­тву­ет нес­коль­ко спо­собов задать пра­виль­ную кон­фигура­цию, но мы выберем menuconfig . Он удо­бен и нет­ребова­телен к GUI. Выпол­няем коман­ду make menuconfig и наб­люда­ем сле­дующую кар­тину.

Главное меню menuconfig

Глав­ное меню menuconfig

Для того что­бы у нас появи­лись отла­доч­ные сим­волы, идем в сек­цию Kernel hacking → Compile-time checks and compiler options. Тут надо будет выб­рать Compile the kernel with debug info и Provide GDB scripts for kernel debugging. Кро­ме отла­доч­ных сим­волов, мы получим очень полез­ный скрипт vmlinux-gdb. py . Это модуль для GDB, который поможет нам в опре­деле­нии таких вещей, как базовый адрес модуля в памяти ядра.

Включение символов отладки и vmlinux-gdb.py

Вклю­чение сим­волов отладки и vmlinux-gdb.py

Те­перь надо убрать про­тек­тор сте­ка, что­бы наш модуль был экс­плу­ати­руем. Для это­го воз­вра­щаем­ся на глав­ный экран кон­фигура­ции, заходим в раз­дел General architecture-dependent options и отклю­чаем фун­кцию Stack Protector buffer overflow detection.

Отключение стековой канарейки

От­клю­чение сте­ковой канарей­ки

Мож­но нажать на кноп­ку Save и выходить из окна нас­трой­ки. Что дела­ет эта нас­трой­ка, мы уви­дим далее.

Сборка ядра

Тут сов­сем ничего слож­ного. Выпол­няем коман­ду make -j< threads> , где threads — это количес­тво потоков, которые мы хотим исполь­зовать для сбор­ки ядра, и нас­лажда­емся про­цес­сом ком­пиляции.

Компиляция ядра

Ком­пиляция ядра

Ско­рость сбор­ки зависит от про­цес­сора: око­ло пяти минут она зай­мет на мощ­ном компь­юте­ре и нам­ного доль­ше — на сла­бом. Можешь не ждать окон­чания ком­пиляции и про­дол­жать читать статью.

Модуль ядра

В ядре Linux есть такое понятие, как character device. По‑прос­тому, это некото­рое устрой­ство, с которым мож­но делать такие эле­мен­тарные опе­рации, как чте­ние из него и запись. Но иног­да, как ни парадок­саль­но, это­го устрой­ства в нашем компь­юте­ре нет. Нап­ример, сущес­тву­ет некий девайс, име­ющий путь / dev/ zero , и, если мы будем читать из это­го устрой­ства, мы получим нули (нуль‑бай­ты или \ x00 , если записы­вать в нотации C). Такие устрой­ства называ­ются вир­туаль­ными, и в ядре есть спе­циаль­ные обра­бот­чики на чте­ние и запись для них. Мы же напишем модуль ядра, который будет пре­дос­тавлять нам запись в устрой­ство. Назовем его / dev/ vuln , а фун­кция записи в это устрой­ство, которая вызыва­ется при сис­темном вызове write , будет содер­жать уяз­вимость перепол­нения буфера.

Код модуля и пояснения

Соз­дадим в пап­ке с исходным кодом ядра вло­жен­ную пап­ку с име­нем vuln , где будет находить­ся модуль, и помес­тим там файл vuln. c вот с таким кон­тентом:

Читайте также: