☰

화면에 메시지를 생성하지 않고 커널이 부팅되지 않는 문제를 해결하는 방법

tag-icon • tag-icon kernel boot linux-kernel patch
화면에 메시지를 생성하지 않고 커널이 부팅되지 않는 문제를 해결하는 방법

Ingo Molnar의 리타임 패치를 적용하려고 했으나 아무런 메시지도 없이 검은 화면만 나옵니다. 즉, 커널 패닉 또는 기타 상황.

커널, 특히 라이브 패치를 더 잘 이해하고 싶다면 이 상태에서 무엇이 잘못되었는지에 대한 정보를 얻기 위해 따를 수 있는 일련의 방법이 있습니까?

디스크를 다른 Linux 시스템에 연결하여 연구할 수 있는 로그가 어딘가에 기록되어 있습니까? 아니면 커널을 더 장황하게 만들고 일종의 아티팩트를 생성하거나 메모리 덤프를 생성하는 방법을 생성할 수 있는 커널 구성 옵션이 있습니까?

실제로 커널 개발자는 커널을 테스트하고 문제를 해결하기 위해 어떤 방법을 사용합니까?

도와주셔서 감사합니다!

답변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

관련 정보