dannf@d05-3:~$ sudo apt install kdump-tools
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  crash kexec-tools makedumpfile
The following NEW packages will be installed:
  crash kdump-tools kexec-tools makedumpfile
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,291 kB of archives.
After this operation, 7,092 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://us.ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 crash 
arm64 7.1.4-1ubuntu4.1 [2,096 kB]
Get:2 http://us.ports.ubuntu.com/ubuntu-ports xenial-proposed/main arm64 
makedumpfile arm64 1:1.5.9-5ubuntu0.5 [111 kB]
Get:3 http://us.ports.ubuntu.com/ubuntu-ports xenial-proposed/main arm64 
kexec-tools arm64 1:2.0.10-1ubuntu2.3 [63.3 kB]
Get:4 http://us.ports.ubuntu.com/ubuntu-ports xenial-proposed/main arm64 
kdump-tools all 1:1.5.9-5ubuntu0.5 [20.9 kB]
Fetched 2,291 kB in 0s (21.4 MB/s)      
Preconfiguring packages ...
Selecting previously unselected package crash.
(Reading database ... 93733 files and directories currently installed.)
Preparing to unpack .../crash_7.1.4-1ubuntu4.1_arm64.deb ...
Unpacking crash (7.1.4-1ubuntu4.1) ...
Selecting previously unselected package makedumpfile.
Preparing to unpack .../makedumpfile_1%3a1.5.9-5ubuntu0.5_arm64.deb ...
Unpacking makedumpfile (1:1.5.9-5ubuntu0.5) ...
Selecting previously unselected package kexec-tools.
Preparing to unpack .../kexec-tools_1%3a2.0.10-1ubuntu2.3_arm64.deb ...
Unpacking kexec-tools (1:2.0.10-1ubuntu2.3) ...
Selecting previously unselected package kdump-tools.
Preparing to unpack .../kdump-tools_1%3a1.5.9-5ubuntu0.5_all.deb ...
Unpacking kdump-tools (1:1.5.9-5ubuntu0.5) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for systemd (229-4ubuntu19) ...
Processing triggers for ureadahead (0.100.0-19) ...
ureadahead will be reprofiled on next reboot
Setting up crash (7.1.4-1ubuntu4.1) ...
Setting up makedumpfile (1:1.5.9-5ubuntu0.5) ...
Setting up kexec-tools (1:2.0.10-1ubuntu2.3) ...
Generating /etc/default/kexec...
Generating grub configuration file ...
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23506: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23506: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23555: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23555: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23598: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23598: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23675: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23675: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23823: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 23823: 
/usr/sbin/grub-probe
Found linux image: /boot/vmlinuz-4.10.0-27-generic
Found initrd image: /boot/initrd.img-4.10.0-27-generic
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 24161: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on vgs invocation. Parent PID 24161: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[70529]) leaked on lvs invocation. Parent PID 24390: 
/bin/sh
Found Ubuntu 17.04 (17.04) on /dev/sda2
Adding boot menu entry for EFI firmware configuration
done
Setting up kdump-tools (1:1.5.9-5ubuntu0.5) ...
Processing triggers for systemd (229-4ubuntu19) ...
Processing triggers for ureadahead (0.100.0-19) ...
dannf@d05-3:~$

** Tags removed: verification-needed verification-needed-xenial
** Tags added: verification-done verification-done-xenial

-- 
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/1694859

Title:
  arm64 kernel crashdump support

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Committed
Status in linux source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Xenial:
  Fix Committed
Status in kexec-tools source package in Yakkety:
  In Progress
Status in linux source package in Yakkety:
  Won't Fix
Status in makedumpfile source package in Yakkety:
  Won't Fix
Status in kexec-tools source package in Zesty:
  Fix Committed
Status in linux source package in Zesty:
  Fix Released
Status in makedumpfile source package in Zesty:
  Fix Released

Bug description:
  Note: Updates are being staged at ppa:dannf/arm64-kdump.

  [Impact]
  It is not possible to collect a kernel crash dump from a crashed arm64 server 
for later debugging.

  [Test Case]
  sudo apt install kdump-tools
  (reboot, so crashkernel= is added to the kernel commandline)
  echo c | sudo tee /proc/sysrq-trigger

  Crash dump should occur, with artifacts collected in /var/crash.

  If you want to verify that the dump is usable, install the
  corresponding linux-image-<ver>-dbgsym package and run:

  sudo crash /usr/lib/debug/boot/vmlinux-<ver>
  /var/crash/<crash>/dump.<crash>

  crash should successfully load, placing you at a "crash>" prompt. At that 
prompt, you can issue the 'bt' command to see a backtrace.
  Note: you need crash from zesty (7.1.8-1ubuntu1) or later.

  [Regression Risk]
  = Kernel =
  3 patches here touch code outside of arch/arm64/:

  memblock: add memblock_clear_nomap()
  This adds a new function with no callers, so regression risk is negligible.
  (A later patch adds a call to it under arch/arm64/).

  memblock: add memblock_cap_memory_range()
  This refactors some of the code in memblock_mem_limit_remove_map() into a new 
function. The only existing caller of memblock_mem_limit_remove_map() is under 
arch/arm64/, so the regression risk outside of arm64 is negligible.

  efi/libstub/arm*: Set default address and size cells values for an empty dtb
  Because this code is for EFI platforms that support device-tree, it is 
de-facto ARM-specific (as noted in the patch title).

  For arm64, we have mitigated the risk by explicit regression testing on 
several platforms:
   - Qualcomm QDF2400
   - Cavium ThunderX CRB1S
   - HP m400 (X-Gene)
   - HiSilicon D05 (Hi07)

  = kexec-tools =
  == zesty ==
  For zesty, 10 patches are required to add kdump support.

  0001-kexec-extend-the-semantics-of-kexec_iomem_for_each_l.patch:
  This modifies a function used on armhf & x86. The description explains the 
change, and why it does not impact those archs:

  -----
  The current users of kexec_iomem_for_each_line(), arm, sh and x86, will not
  be affected by this change because
  * arm
    The callback function only returns -1 or 0, and the return value of
    kexec_iomem_for_each_line() will never be used.
  * sh, x86
    The callback function may return (-1 for sh,) 0 or 1, but always returns
    1 once we have reached the maximum number of entries allowed.
    Even so the current kexec_iomem_for_each_line() counts them up.
    This change actually fixes this bug.
  -----

  0002-kexec-generalize-and-rename-get_kernel_stext_sym.patch:
  This generalizes a function that was duplicated by arm & x86 and makes it 
common so arm64 can use it.

  The remaining 8 of these only touch code in kexec/arch/arm64, so
  regression risk for other architectures is negligible.

  Finally, I have tested this update on both i386 and amd64 VMs. i386
  crashes do not currently work in zesty (filed LP: #1699874), and my
  test results show no change there. amd64 worked before, and continues
  to work with these changes.

  == yakkety ==
  Since yakkety is based on an older upstream, 6 additional patches are 
required:

  arm-fix-get_kernel_stext_sym-to-close-its-file.patch:
  This is a cleanup patch, cherry-picked because it allows later patches to 
apply w/o backporting. ARM-specific.

  kexec-add-max_size-to-memory_ranges.patch:
  Adds a new element to struct, to be used by later commits.

  kexec-add-generic-helper-to-add-to-memoryq_regions.patch,
  kexec-add-mem_regions-sorting-implementation.patch,
  kexec-add-helper-to-exlude-a-region-from-a-set-of-me.patch,
  kexec-fix-mem_regions_sort.patch:
  These patches only add new functions, which will be used by later patches.

  kexec-arch-i386-Add-support-for-KASLR-memory-randomi.patch:
  This is a bug fix or i386 that allows later patches to apply w/o backporting.
  kdump support for i386 is apparently broken for the yakkety kernel (see LP: 
#1699874) so, if this introduces a regression, it won't be detectable.
  (I checked to see if this *fixes* i386 crashdumps - it does not).

  Note that, while makedumpfile in >= zesty is new enough to work on arm64, the 
yakkety version does not. kdump-tools falls back to copying the entire vmcore, 
which is what I tested.
  As with zesty, I have tested this update on both i386 and amd64 VMs. i386 
crashes do not currently work in yakkety, and my test results show no change 
there. amd64 worked before, and continues to work with these changes.

  = xenial =
  The patchset needed for xenial is identical to the patchset for yakkety. The 
only additional change is to add arm64 to the list of archs that get a 
/etc/default/grub.d snippet (in yakkety that snippet moved over to 
kdump-tools), and that has negligible regression risk for !arm64.

  I performed the same testing as with yakkety. The only significant
  difference is that i386 worked before and after this update (for y/z/a
  it worked neither before nor after).

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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to