2

I'm using Solus 4.0 (in a VM) and trying to make screenshots of "typical" kernel panic output ("BSOD"). The init system in Solus is systemd.

I tried the following commands in the terminal without success:

$ kill -6 1

Doesn't do anything (no echo).

$ sudo kill -SEGV 1

Also does nothing...

# echo c > /proc/sysrq-trigger

Freezes the system but it's not what I need.

Any ideas?

I'd like to see the stack calls and all. It's not about freezing the system with a fork bomb.

References used:

Improve this question
4
  • A BSOD is Windows; it's a Blue Screen Of Death. In UNIX/Linux, it is called an Oops. Have looked at opensourceforu.com/2011/01/understanding-a-kernel-oops ? Commented Apr 16, 2019 at 16:10
  • Yes, that's why I put quotation marks around it. Do you have any idea how to answer my question, though? Commented Apr 16, 2019 at 16:26
  • The link I added suggests that you could use a kernel module to generate the oops. Rather than copying someone else's work, I referred to it. Commented Apr 16, 2019 at 16:30
  • Thank you. I had considered writing a little C program but I'd like to do it via the terminal. If all else fails, I'll try your suggestion. Commented Apr 17, 2019 at 7:53

2 Answers 2

Reset to default
1

If you would like to see stack traces of the threads running on all CPUs you can

# echo l > /proc/sysrq-trigger

According to, e.g., Wikipedia this

Shows a stack backtrace for all active CPUs.

Improve this answer
4
  • Thanks, I tried lots of command keys ("c", "l", "p", etc.) but I get bash: /proc/sysrq-trigger: Permission denied The "magic SysRq key" doesn't work either. Maybe I have to head to the Solus Linux forums? Commented Apr 17, 2019 at 7:55
  • Permission denied probably means that you did not run above commands as root. Try again as root (which I meant to indicate by the "#" prompt) and it should work. However in any case it is possible that the kernel was compiled without support for magic sysrq. But OTOH I think you should not get permission denied but rather /proc/sysrq- trigger should not exist at all. Commented Apr 18, 2019 at 17:37
  • I ran all commands as root. Nothing happens. Commented Apr 23, 2019 at 6:58
  • It is possible to selectively disable some of the magic SysRq functionality at kernel compile time, using the CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE configuration parameter, or at runtime, by setting kernel.sysrq to a value that is neither 0 nor 1 in /etc/sysctl.conf, or by just echoing that value to /proc/sys/kernel/sysrq. The kernel admin guide has more info. If the stack-trace command key has been disabled, but other functions remain enabled, that might explain the "permission denied" error. Commented Aug 14, 2020 at 12:18
1

A reliable way to cause a kernel panic from userspace is to get PID 1 to exit. It's protected from signals, so you'll have to use a different approach, like a debugger: sudo gdb -ex 'call _exit(0)' --pid=1 --batch

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.