Kernel Panic не выдает никаких файлов журнала

Я играл в Steam, и внезапно у меня появилась паника. Я вручную отключил компьютер и загрузился обратно в Linux Mint 17.1 (Cinnamon) 64-bit, и пошел проверять мои файлы журналов в /var/log/ , но я не мог найти никаких ссылок или каких-либо сообщений, связанных к панике ядра, которое произошло.

Странно, почему он никогда не сбрасывал ядро ​​или даже не упоминал об этом в файлах журнала. Как я могу убедиться, что ядро ​​всегда сбрасывается, если произойдет паника ядра? Не имеет никакого смысла, почему ничего не было зарегистрировано, когда произошла паника ядра. Оглядываясь на Google, люди советуют читать /var/log/dmesg , /var/log/syslog , /var/log/kern.log , /var/log/Xorg.log т. Д., Но ничего. Даже в .Xsession-errors .

Вот несколько фотографий экрана:
Ядро Паника (image2) Kernel Panic (image1)

Я всегда мог сделать снимок экрана, когда и если это произойдет снова, но я просто хочу убедиться, что я могу заставить его сбросить ядро ​​и создать файл журнала при панике ядра.

  • Как исправить графические проблемы с приложениями Qt? (дельфин: 14635): Gdk-WARNING **: ошибка shmget: ошибка 28 (на устройстве не осталось места)
  • Почему неправильно отображается апплет уведомлений?
  • Почему Mac может монтировать определенное оборудование, которое не может использовать мой Linux Mint?
  • dpkg: error: дублировать запрос запуска файла для имени файла `/ usr / lib / gio / modules 'и пакета` libglib2.0-0'
  • Расширение переменной не произошло в / etc / environment
  • Является ли мой процессор перегрева моего процессора (Dual Core i5) или графическим процессором (Nvidia 320M), и могу ли я исправить его в Linux Mint?
  • Не удалось подключиться к Wi-Fi на Linux Mint
  • Низкое время автономной работы под Linux Mint 18 Cinnamon 'Sarah'
  • 2 Solutions collect form web for “Kernel Panic не выдает никаких файлов журнала”

    Чтобы убедиться, что ваш компьютер генерирует «основной» файл при сбое ядра, вы должны подтвердить настройки «sysctl» вашего аппарата.

    IMO, следующие должны быть настройки (минимальные) в /etc/sysctl.conf :

     kernel.core_pattern = /var/crash/core.%t.%p kernel.panic=10 kernel.unknown_nmi_panic=1 

    Выполните sysctl -p после внесения изменений в /etc/sysctl.conf . Вероятно, вы также должны mkdir /var/crash если он еще не существует.

    Вы можете проверить это, создав ручной дамп, используя ключ SysRq (комбинация клавиш для ядра дампа – Alt + SysRq + C ).

    Когда ядро ​​панически, это означает, что в ядре что-то пошло не так. Для записи файлов журналов и дампов ядра необходимо использовать драйверы для устройства хранения блоков (ваш диск) и файловой системы (пространство должно быть выделено, а размер файла журнала должен быть обновлен). Учитывая, что сервисы, предоставляемые ядром, необходимы для записи файлов, и ядро ​​знает, что оно находится в неисправном состоянии, оно не может записывать файлы или записывать что-либо, потому что оно больше не находится в безопасном состоянии, поэтому любая операция может ухудшить ситуацию и может повредить / уничтожить вашу файловую систему. Таким образом, вы не можете записывать ядро ​​в журнал и не выгружать дамп ядра, когда он паникует.

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

    См. Например, параметр crashkernel на Kernel Crash Dump на ubuntu.com. (Обратите внимание, что на этой странице указано, что механизм дампа ядра отключен по умолчанию, начиная с Ubuntu 16.04.)

    Я считаю, что система фактически сохраняет дамп в зарезервированную часть памяти, а затем перезагружается, а ядро ​​сохраняет зарезервированную память на диске при следующей загрузке (поскольку новое загрузочное ядро ​​находится в нормальном состоянии и может это сделать).

    Linux и Unix - лучшая ОС в мире.