Welcome to the Linux Foundation Forum!

How to Capture the Panic message?

Generate panic
Write a patch to panic the kernel. Capture panic message. generate and send the patch and dmesg output from the module to Shuah Khan skhan@linuxfoundation.org and also upload the file.

when I do sudo insmod panic.ko, kernel is getting panicked and stuck there. how to capture the panic message? Do I need to just make patch for panic.c and Makefile and send it? What do I put in the document in that case? can anybody explain it.

Welcome!

It looks like you're new here. Sign in or register to get started.
Sign In

Comments

  • Posts: 11

    Use QEMU to capture the panic message:

    1. qemu-system-x86_64 \
    2. -kernel arch/x86_64/boot/bzImage \
    3. -nographic \
    4. -append "console=ttyS0" \
    5. -initrd /path/to/initramfs.img \
    6. -m 512 \
    7. --enable-kvm \
    8. -cpu host

    Typically, BusyBox is used in the initramfs, so insmod should be available to load your kernel module, but you have to include your kernel module in the initramfs image.

    Note: You don't necessarily need to panic the kernel from a kernel module. You can do the same in init/main.c, for example.

  • Posts: 1

    At the point of a kernel panic, the kernel itself is assumed to be in a bad state, such that it would be unsafe to write to the filesystem and risk corrupting it.

    The underlying kernel mechanism you might want to read about is Kdump. Kdump addresses the problem of how you can safely write to the filesystem by keeping a crash kernel loaded in main memory:
    https://wiki.archlinux.org/title/Kdump

    Most Linux distributions configure Kdump by default. You may find a core dump somewhere like /var/log/crash/, depending on your distribution. Arch and SteamOS are exceptions in that you will have to configure it yourself.

  • Posts: 18

    @gvernon said:
    At the point of a kernel panic, the kernel itself is assumed to be in a bad state, such that it would be unsafe to write to the filesystem and risk corrupting it.

    The underlying kernel mechanism you might want to read about is Kdump. Kdump addresses the problem of how you can safely write to the filesystem by keeping a crash kernel loaded in main memory:
    https://wiki.archlinux.org/title/Kdump

    Most Linux distributions configure Kdump by default. You may find a core dump somewhere like /var/log/crash/, depending on your distribution. Arch and SteamOS are exceptions in that you will have to configure it yourself.

    Thank you for this insight! Was able to successfully configure kdump and take a look at the logs post-crash.

  • I have tried to set it up on Linux mint but unable to get any crash reports? Anyone facing the same issue?

  • @saiprasadpatil said:
    I have tried to set it up on Linux mint but unable to get any crash reports? Anyone facing the same issue?

    I case anyone is in this situation, you can check /var/lib/systemd/pstore. It has the logs saved from a previous panic.

  • @imanseyed said:
    Use QEMU to capture the panic message:

    1. qemu-system-x86_64 \
    2. -kernel arch/x86_64/boot/bzImage \
    3. -nographic \
    4. -append "console=ttyS0" \
    5. -initrd /path/to/initramfs.img \
    6. -m 512 \
    7. --enable-kvm \
    8. -cpu host

    Typically, BusyBox is used in the initramfs, so insmod should be available to load your kernel module, but you have to include your kernel module in the initramfs image.

    Note: You don't necessarily need to panic the kernel from a kernel module. You can do the same in init/main.c, for example.

    I tried to do this and qemu gets stuck with the following output

    1. No EFI environment detected.
    2. early console in extract_kernel
    3. input_data: 0x0000000002ca12c4
    4. input_len: 0x0000000000d6ff31
    5. output: 0x0000000001000000
    6. output_len: 0x00000000029c7170
    7. kernel_total_size: 0x0000000002830000
    8. needed_size: 0x0000000002a00000
    9. trampoline_32bit: 0x0000000000000000
    10. Physical KASLR using RDRAND RDTSC...
    11. Virtual KASLR using RDRAND RDTSC...
    12.  
    13. Decompressing Linux... Parsing ELF... Performing relocations... done.
    14. Booting the kernel (entry_offset: 0x0000000001255c70).
    15.  

    Command I used

    1. qemu-system-x86_64 \
    2. -kernel arch/x86/boot/bzImage \
    3. -initrd /boot/initramfs-6.15.8-200.fc42.x86_64.img \
    4. -nographic \
    5. -append "console=ttyS0 earlyprintk=serial" \
    6. -m 512 \
    7. --enable-kvm \
    8. -cpu host
    9.  

    Also I am trying to crash by adding panic() in init/main.c

  • Posts: 11

    @rajeevtapadia said:
    Command I used

    1. qemu-system-x86_64 \
    2. -kernel arch/x86/boot/bzImage \
    3. -initrd /boot/initramfs-6.15.8-200.fc42.x86_64.img \
    4. -nographic \
    5. -append "console=ttyS0 earlyprintk=serial" \
    6. -m 512 \
    7. --enable-kvm \
    8. -cpu host
    9.  

    Also I am trying to crash by adding panic() in init/main.c

    Where exactly are you trying to add panic()? I'd recommend adding it after console_init().

  • Thanks for the reply @imanseyed
    I tried a lot of stuff turns out, I had two problems
    First I had cloned the kernel on a external drive and it was causing some problems. I moved it to internal drive and recompiled. It worked.

    Where exactly are you trying to add panic()? I'd recommend adding it after console_init().

    As per your suggestion I moved panic() after console_init() and I could see the panic message on terminal.

    Thanks for the help.

Welcome!

It looks like you're new here. Sign in or register to get started.
Sign In

Welcome!

It looks like you're new here. Sign in or register to get started.
Sign In

Categories

Upcoming Training