From time to time, Linux booting failed on very early stage (like initrd loading). Then, the kernel panic message is showing up in text mode. Since the screen height limit, all I can see is around 40 lines of text-based kernel panic message. For diagnosing the panic reason, I would like to see the above message (like scrolling up the messages) but I don't know how to do this. Is there any good trick for this?
3 Answers
Serial port
The serial port is an old and reliable communication protocol hardware that the Linux kernel supports and most emulators emulate.
You can stream the kernel messages to a host file or console through it:
VirtualBox: How does one Capture the Entire Kernel Panic on Boot | Stack Overflow
QEMU:
- to console: How to switch to qemu monitor console when running with "-curses" | Stack Overflow
- to file: Write QEMU booting virtual machine output to a file | Super User
Here's a minimal setup to reproduce the problem: https://github.com/cirosantilli/linux-kernel-module-cheat/blob/b366bac0c5410ceef7f2b97f96d93d722c4d9ea6/kernel_module/panic.c
real hardware: the serial port is not exposed on most modern laptops, which is a shame... but on desktops it looks like this:
And on the Raspberry Pi:
More details at: https://unix.stackexchange.com/questions/307390/what-is-the-difference-between-ttys0-ttyusb0-and-ttyama0-in-linux/367882#367882
Serial alternatives
There are even fancier methods mentioned at: Determining cause of Linux kernel panic | Unix & Linux Stack Exchange
netdump: sends trace over network.
Supposes panic didn't break networking, which is more likely than the serial.
The advantages over serial are:
works for systems that don't have serial exposed such as modern laptops
serial cables have quite limited maximum wire lengths, which is problematic if you want to have all the boards of your company on a remote room to share resources across developers.
There are however serial connectors with an Ethernet server which I would recommend instead if your target exposes serial, e.g. this one:
kdump: boots a secondary Linux kernel that inspects the panicked kernel. What could possibly go wrong?
Those methods are more flexible, but less reliable.
See also: https://unix.stackexchange.com/questions/208260/how-to-scroll-up-after-a-kernel-panic/364966#364966
- 12,482
You should try using kexec kernel feature. Kexec is a feature of a secondary kernel that is stored in the RAM, especially for this kind of cases (not only), where you want to investigate the dump of another Kernel, in case of kernel panics for example. You should find quite enough info about that in google, as it can be used for different purposes. Basically you will only need to enable Kexec in the kernel config file, then add CRASHKERNEL=XXXM into your kernel arguments (passed by the bootloader). Then edit some config files, and continue with experiencing and googling till you get it working....
Good Luck :D




