| 2015-12-14 02:43:07 |
Rich |
description |
Ubuntu 15.10 amd64, kernel 4.2.0-19-generic, kexec-tools 2.0.9-1ubuntu1
kexec-tools and crashdumprecipe appear to be configured correctly - on echo c | sudo tee /proc/sysrq-trigger, it panics, saves a valid {dump,dmesg}.[datetimestamp] in /var/crash along with a [timestamp].crash, all correctly sized and containing what one would expect.
Attempting to debug an unknown panic (which was the motivation for setting up kdump in the first place), system eventually panics, kexecs, on reboot /var/crash contains {dump,dmesg}.[timestamp] files and [timestamp].crash, but all of them contain only the value 0x00 over and over again, which rather seems like the behavior when metadata but not data hits disk.
/ (and therefore /var/crash) are ext4, mounted with errors=remount-ro,barrier=1,auto_da_alloc (the latter two were added in trying to work around this issue). |
Ubuntu 15.10 amd64, kernel 4.2.0-19-generic, kexec-tools 2.0.9-1ubuntu1
kexec-tools and crashdumprecipe appear to be configured correctly - on echo c | sudo tee /proc/sysrq-trigger, it panics, saves a valid {dump,dmesg}.[datetimestamp] in /var/crash along with a [timestamp].crash, all correctly sized and containing what one would expect.
Attempting to debug an unknown panic (which was the motivation for setting up kdump in the first place), system eventually panics, kexecs, on reboot /var/crash contains {dump,dmesg}.[timestamp] files and [timestamp].crash, but all of them contain only the value 0x00 over and over again, which rather seems like the behavior when metadata but not data hits disk.
/ (and therefore /var/crash) are ext4, mounted with errors=remount-ro,data=ordered,barrier=1,auto_da_alloc (the latter two were added in trying to work around this issue). |
|
