← Back to team overview

kernel-packages team mailing list archive

[Bug 1525746] [NEW] kdump results in correct-sized sparse files

 

Public bug reported:

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).

** Affects: kexec-tools (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1525746

Title:
  kdump results in correct-sized sparse files

Status in kexec-tools package in Ubuntu:
  New

Bug 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).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1525746/+subscriptions


Follow ups