When compressed core dumps are enabled the vmcore file is generated with a .zst extension. kgdb -n seems to have problems dealing with this. # grep dump /etc/rc.conf dumpdev="AUTO" dumpon_flags="-Z" # ls -l /var/crash total 374612 -rw-r--r-- 1 root wheel 2 Jul 1 15:25 bounds -rw-r--r-- 1 root wheel 81324 Jul 1 15:26 core.txt.3 -rw------- 1 root wheel 449 Jul 1 15:25 info.3 lrwxr-xr-x 1 root wheel 6 Jul 1 15:25 info.last@ -> info.3 -rw-r--r-- 1 root wheel 5 May 24 00:12 minfree drwxr-xr-x 2 root wheel 2 May 31 21:36 procs/ -rw------- 1 root wheel 426533590 Jul 1 15:25 vmcore.3.zst lrwxr-xr-x 1 root wheel 12 Jul 1 15:25 vmcore.last.zst@ -> vmcore.3.zst # kgdb -n last kgdb: /var/crash/vmcore.last: No such file or directory # kgdb -n 3 kgdb: /var/crash/vmcore.3: No such file or directory # kgdb -n last.zst kgdb: /var/crash/info.last.zst: No such file or directory kgdb: couldn't find a suitable kernel image
Even if this issue is 3 years old I can confirm this problem. I tried to debug kernel today and compressed vmcore files with zst extension cannot be debug in an usual way
kgdb(1) now exists outside of the base system, so moving this to Ports & Packages. From what I see this is a feature request. You are expected to decompress the core before it will be usable by kgdb. As far as I'm aware, regular gdb(1) doesn't support reading from gzipped or zstd compressed core files.