Kernel Panic dumps no log files
To be sure that your machine generates a "core" file when a kernel failure occurs, you should confirm the "sysctl" settings of your machine.
IMO, following should be the settings (minimal) in /etc/sysctl.conf
:
kernel.core_pattern = /var/crash/core.%t.%p
kernel.panic=10
kernel.unknown_nmi_panic=1
Execute sysctl -p
after making changes in the /etc/sysctl.conf
file.
You should probably also mkdir /var/crash
if it doesn’t already exist.
You can test the above by generating a manual dump using the SysRq key (the key combination to dump core is Alt+SysRq+C).
When the kernel panics, it means something has gone wrong in the kernel. Writing log files and core dumps requires using the drivers for the block storage device (your disk) and the filesystem (space has to be allocated, and the size of the log file has to be updated). Given those services that are provided by the kernel are required in order to write files, and the kernel knows it is in a broken state, it cannot write the files or log anything, because it isn't in a safe state anymore, so doing any operation could make things worse and could damage/destroy your filesystem. So you cannot have the kernel write to the log nor dump a core dump when it panics.
Now what you can do, if you want to, is configure the system with a crash handling kernel, which is a second kernel loaded into memory that control can be transferred to if the main kernel crashes. Since that kernel has drivers and such, it would be able to save a crash dump for you. This is not a very common setup, though, and mainly used for high-end systems that require high availability and where a crash is a very serious issue that must be investigated.
See for example the crashkernel option at Kernel Crash Dump at ubuntu.com. (Note that this page says that the kernel crash dump mechanism is enabled by default, starting with Ubuntu 16.04.)
I believe that system actually saves the dump to a reserved piece of memory and then reboots, and the kernel saves the reserved memory to disk on next boot (since the newly booting kernel is in a sane state and can do that).