画面にメッセージを生成せずにカーネルが起動しない問題を解決する方法

画面にメッセージを生成せずにカーネルが起動しない問題を解決する方法

Ingo Molnarのリタイムパッチを適用しようとしましたが、何もメッセージなしで黒い画面しか表示されません。つまり、カーネルパニックやその他の状況。

カーネル、特にライブパッチをよりよく理解したい場合は、この状態で何が間違っているかについての情報を得るために従うことができる一連の方法がありますか?

ディスクを他のLinuxシステムに接続して研究できるログはどこに記録されていますか?それとも、カーネルをより冗長にし、一種のアーティファクトを生成したり、メモリダンプを生成する方法を生成したりできるカーネル設定オプションはありますか?

実際、カーネル開発者はカーネルをテストし、問題を解決するためにどのような方法を使用しますか?

助けてくれてありがとう!

答え1

カーネルのメッセージが失われないようにする1つの方法は、仮想マシンでデバッグすることです。

たとえば、次のスクリプトはqemuカスタムカーネルを使用して仮想マシンを起動します。

qemu-system-x86_64\
    -kernel arch/x86/boot/bzImage\
    -drive file=/home/lgeorget/VM/image.qcow2,if=virtio\
    -append "root=/dev/vda1"\
    -netdev user,id=mynet0 -device e1000,netdev=mynet0\
    -enable-kvm\
    -S

ここで重要なオプションは、-SqemuがGDBサーバーを起動して起動する前にデバッガが準備されるのを待つことです。

別のコンソールでカスタムカーネルをコンパイルしたLinux開発ツリーに移動し、そこでGDBを起動してgdb vmlinuxカーネルシンボルをロードします。次に、プロンプトで次のように入力します。

target remote :1234

これにより、qemuが起動したgdbサーバー(localhost、デフォルトポート1234)に接続します。その後、ほとんどすべてのプログラムのようにデバッガを使用したり、ブレークポイントを設定したり、コマンドを使用して実行を続行したりするcontinueなどのタスクを実行できます。メモリをスキャンしてダンプできる必要があり、分析したい場合はログをコピーできる必要があります。これはカーネルの冗長性を増加させないことに注意してください。

インターネットには公式文書だけでなく、多くのチュートリアルがあります。

https://stackoverflow.com/questions/11408041/how-to-debug-the-linux-kernel-with-gdb-and-qemu http://wiki.osdev.org/Kernel_Debugging http://elinux.org/Debugging_The_Linux_Kernel_Using_Gdb

関連情報