カーネルパニックがログファイルをダンプしない
Steamでゲームをプレイしていたところ、突然カーネルパニックが発生しました。コンピューターを手動でシャットダウンし、Linux Mint 17.1（Cinnamon）64ビットで再起動し、/var/log/のログファイルを確認しに行ったが、関連するメッセージや参照メッセージが見つからなかった起こったカーネルパニックに。
コアをダンプしたり、ログファイルに記録したりしないのは奇妙です。カーネルパニックが再度発生した場合に備えて、コアが常にダンプされるようにするにはどうすればよいですか？カーネルパニックが発生したときに何もログに記録されなかった理由がわかりません。 Googleで周りを見回すと、人々は/var/log/dmesg、/var/log/syslog、/var/log/kern.log、/var/log/Xorg.logなどに目を通すことを勧めますが、何もしません。 .Xsession-errorsファイルにも含まれていません。
画面の写真は次のとおりです。
いつでも画面が表示される場合はいつでも写真を撮ることができますが、コアをダンプしてカーネルパニックにログファイルを作成できることを確認したいだけです。
カーネル障害が発生したときにマシンが確実に「コア」ファイルを生成するようにするには、マシンの「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）。
カーネルパニックは、カーネルに問題が発生したことを意味します。ログファイルとコアダンプを書き込むには、ブロックストレージデバイス（ディスク）とファイルシステム（スペースを割り当てる必要があり、ログファイルのサイズを更新する必要がある）のドライバーを使用する必要があります。カーネルによって提供されるこれらのサービスがファイルを書き込むために必要であり、カーネルがそれが壊れた状態であることを認識している場合、それはもはや安全な状態ではないため、ファイルを書き込んだり、ログに記録したりすることはできません。操作を行うと状況が悪化し、ファイルシステムが損傷または破壊される可能性があります。そのため、パニックが発生したときに、カーネルにログを書き込ませたり、コアダンプをダンプしたりすることはできません。
ここでできることは、メインカーネルがクラッシュした場合に制御を転送できる、メモリに読み込まれた2番目のカーネルであるクラッシュ処理カーネルでシステムを構成することです。そのカーネルにはドライバなどがあるので、クラッシュダンプを保存することができます。ただし、これはあまり一般的な設定ではありません。主に、高可用性を必要とするハイエンドシステムで使用され、クラッシュは調査が必要な非常に深刻な問題です。
たとえば、ubuntu.comの Kernel Crash Dump でcrashkernelオプションを参照してください。 （このページには、Ubuntu 16.04以降、カーネルクラッシュダンプメカニズムがデフォルトで有効になっていると記載されています。）
システムは実際にダンプを予約されたメモリに保存してから再起動し、カーネルは予約されたメモリを次回の起動時にディスクに保存すると思います（新しく起動するカーネルは正常な状態であり、それを実行できるため）。