Еще один способ вызвать кернел паник
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 же. Что же еще?
Палишься, видимо 😀
не работает на асусе к40ин :З
плохой баг нашел
Хм, интересно. Тогда жду, пока кто-нибудь с подобным нетбуком не появится.
моей дочке нравятся мигающие кнопочки на ноуте, собственно этот баг она уже протестила на двух ноутах еще раньше. баг не обнаружен.
Хм.. у меня тоже самое на арче на EeePC 1000 — несколько раз выключал и включал вай-фай (Fn+F2) и 3 раза ловил кернел паник (именно кернел паник). Но было это месяц-два назад. Щас проверил — не воспроизводиться.
А оно когда как, иногда срабатывает, а иногда нет.
hp mini 311 хватает 3х раз обычно.. только не кернел паник, а полное зависание с тишиной в логах(((
Только что проверил — раз 20-30 понажимал — не роботает. Arch 2.6.38, Дрова пропиетарные, ибо синезуб нужен.
30 раз нажал, ничего не произогло
eMashines D520, Wifi от Atheros
>Ни разу в жизни не видел настоящей CP
[петросян]Вам в i2p.[/петросян]
Спасибо, Евгений Ваганович, но я не любитель этой гадости.
Апдейты — это зло.
тоже arch тоже 2.6.38 дрова broadcom-wl. Действия описанные тут https://wiki.archlinux.org/index.php/HP_Mini_311c выполнял. и один фиг((
Не работает. Asus EEE PC T91, Kubuntu 11.04
Нетбуки мне кажется похожие.
> Еще один способ вызвать кернел паник
У вас archlinux.
> полное зависание с тишиной в логах
У меня во время этого зависания на экран вываливается длинный текст, похожий на тот, что бывает при панике. В логах да, конечно же, ничего нет.
попробуй поставить на свой комп MacOSX, да не хакерскую сборочку, а самому. Навидаешься по нехочу.
текста нет, на экране застывает последнее изображение до зависания. печаль в общем(((
Кстати, оказывается этот баг уже зарепорчен давно:
Если это конечно оно. Но по симптомам похоже.
Lenovo thinkpad edge не помню какой, тот что с интелом двухядерным и небольшим экраном (не люблю большие ноуты таскать) — после обновлений рандомно что то отваливается, после сна через раз kernel panic — так что не удивил.
тем не менее, тебе сейчас фанатики админчики localhost накричат фразочки заученные «УМВР ЧЯДНТ», но они либо пользуют десктоп с ethernet картой и не кладут свой ящичек в сон, либо . ну фанатики ж.
У меня ещё бывает биос в панику выпадает (загораются все лампочки, а экран нет) при просыпании, после этого часы начинают ровно на 30000 секунд отставать, мистика вообщем.
Источник
Доступ к сообщениям журнала ядра при переходе ядра Linux в режим паники
Часто встречающаяся ситуация: виртуальный или аппаратный сервер завис и не отвечает. Заходите на него с помощью инструмента удаленного управления IPMI или консоли VNC, видите только черный экран и ничего кроме. Скорее всего, ядро Linux вошло в режим паники (Kernel Panic), который вызван сбоем одного из модулей ядра, ошибкой в самом ядре, критической аппаратной ошибкой.
Вы перезагружаете сервер, ищите журналы на предмет релевантных сообщений, а в ответ пустота — ничего криминального нет. На самом деле, сообщения сопровождающую возникшую ошибку были, но они не дошли до файла журнала. Связано это с тем, что, когда ядро Linux сталкивается с критической ситуацией, особенно, если она связана с файловой системой, то ему не удается использовать модули файловых систем, чтобы записать данные в файл журнала. Как результат, записи, сопровождающие ошибку теряются.
В лучшем случае, вы сможете увидеть сообщение об ошибке на экране монитора и сделать снимок экрана, но часто вы не видите даже этого.
В этой статье мы познакомимся с методом, который позволяет решить проблему журналирования сообщений ядра при возникновении ситуации паники ядра Linux.
Для решения этой задачи мы воспользуемся специальным модулем ядра Netconsole, который позволяет отправить предсмертные сообщения ядра на удаленный сервер syslog.
Метод не очень широко известен, но чрезвычайно полезен для полноценной диагностики серверов Linux, когда их ядро сталкивается с ситуациями, последствием которых является переход в режим паники с остановкой всех сервисов.
Все примеры в данной статье будут приводиться для серверов, работающих под управлением Ubuntu Linux, однако, для других дистрибутивов настройка практически полностью повторяется.
В рамках инструкции будем использовать два сервера:
- panic с ip: 10.0.0.2;
- monitor с ip: 10.0.0.1.
На сервере panic мы настроим netconsole и будем имитировать ситуацию паники ядра. На сервере monitor мы настроим rsyslogd для поддержки удаленного журналирования по протоколу udp. Начнем с настройки узла monitor.
Настройка Rsyslog на узле monitor
Мы ограничимся минимальной настройкой, решающей задачу. В случае, если журналирование используется для многих серверов, рекомендуется настроить организацию журналов по имени сервера. Для того, чтобы сервис Rsyslog мог принимать сообщения от удаленных серверов, в файле /etc/rsyslog.conf необходимо раскомментировать строки, отвечающие за активацию модуля, обрабатывающего внешние события, приходящие по протоколу UDP:
Сохраните файл и перезапустите rsyslogd:
убедимся, что rsyslog слушает порт 514 по протоколу UDP:
Настройка практически завершена, однако, так как при использовании удаленного журналирования отсутствуют встроенные механизмы верификации источника данных, подходящие при использовании netconsole, мы будем использовать iptables для ограничения трафика от неизвестных источников.
Настройка Iptables на узле monitor
Разрешим доступ к rsyslogd только с хоста 10.0.0.2 с порта 10002, откуда будут отправляться сообщения при возникновении критической ситуации ядра.
Установим пакет 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 можно увидеть, что модуль принимает следующие настройки:
разберем каждую из них:
- + — netconsole будет использовать “extended” режим, при котором передаются метаданные, помимо самих сообщений, а также не-ASCII символы;
- src-port — порт на локальном сервере с которого будут отправляться сообщения, по умолчанию 6665;
- src-ip — ip4 или ip6 адрес, принадлежащий серверу, с которого будут отправляться сообщения;
- dev — имя локального сетевого устройства, в которое будут отправляться сообщения;
- tgt-port — порт сервера syslog или другого приложения, принимающего сообщения, по умолчанию 6666;
- tgt-ip — ip4, ip6 адрес сервера, который будет принимать сообщения;
- tgt-macaddr — mac-адрес сервера, который принимает сообщения.
как можно видеть, параметры, кроме tgt-ip опциональны, но мы зададим их все для большей ясности.
Модуль netconsole может работать в двух режимах — статической конфигурации и динамической конфигурации, когда вы можете добавлять дополнительные цели отправки сообщений через /sys. У нас такой задачи нет, поэтому мы будем использовать статическую конфигурацию. За подробностями настройки netconsole в режиме динамической конфигурации обратитесь к документации модуля.
Настройка модуля заключается в правке двух файлов — /etc/modules и /etc/modprobe.d/netconsole.conf (замените MAC AA:BB:CC:DD:EE:FF на реальный MAC сервера monitor, которому соответствует IP 10.0.0.1):
После выполнения этих операций загрузим модуль в память:
Если вывод похож на приведенный выше, значит модуль правильно настроен. Попробуйте перезагрузить сервер и найти сообщения netconsole после загрузки:
На этом настройка модуля завершена. Убедимся в том, что он работает. Для этого смоделируем событие паники ядра. Сначала запустим отслеживание событий syslog в режиме реального времени на сервере monitor:
Сначала убедимся, что сообщения поступают в syslog с помощью команды ‘w’ триггера sysrq:
В журнале вы должны увидеть строку, похожую на эту:
Если вы ее видите, значит, сообщения доходят. Теперь посмотрим, что мы увидем в логах при возникновении паники на сервере panic с помощью другой команды триггера sysrq:
На этом месте сервер panic зависнет без возможности восстановления без перезагрузки, а в журнале syslog появится трассировка сообщений событий, приведших к панике.
Если вы видите такой вывод, значит настройка успешна и при возникновении исключительных событий ядра, вы сможете видеть их в журнале syslog на удаленном сервере.
Заключение
В этом руководстве вы научились использовать модуль netconsole для удаленной отправки критических сообщений ядра с момента возникновения нештатной ситуации до перехода ядра в режим паники.
Данный способ может не подойти при возникновении ошибок в сетевых модулях ядра, связанных с сетевой картой, используемой для отправки сообщений. В этом случае, ошибки ядра могут находиться в журналах файловой системы, а еще возможно использовать терминал на последовательном порту (/dev/ttyS*). Приведенный метод успешно зарекомендовал себя в средах, где часто встречаются ошибки файловых систем — наиболее сложных компонентах операционных систем.
Источник
