kernel-packages team mailing list archive

[Terry Wang <828731@xxxxxxxxxxxxxxxxxx>]

Is this really fixed on Ububuntu 14.04 LTS?

I've just tested triggering a crash dump and it didn't work. A Google
search pointed me to this bug. When I see /boot on a separate partition,
I just realized it is the damn case! Others like dbgsym kernel from
ddeb, kdump-tools, linux-crashdump all installed and properly
configured.

The VMs use LVM so they all have a separate /boot partition, that's why
kdump was not able to dump the /proc/vmcore.

After using the workaround (umount /boot and use the /boot on /), it
worked!

However, there is no 0_dump file under /usr/share/initramfs-
tools/scripts/init-bottom/ WTF? So what is causing the problem in Ubuntu
14.04 with a separate /boot partition?

A separate bug needed?

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

Title:
  kdump functionality not working as expected when /boot is a separate
  partition

Status in “kexec-tools” package in Ubuntu:
  Fix Released
Status in “kexec-tools” source package in Lucid:
  Fix Released
Status in “kexec-tools” source package in Maverick:
  Fix Released
Status in “kexec-tools” source package in Natty:
  Fix Released
Status in “kexec-tools” source package in Oneiric:
  Fix Released

Bug description:
  SRU Request for Lucid/Maverick/Natty/Oneiric:

  [Impact] - When a server is configured with the /boot as a separate
  partition, which is the default configuration when LVM installation is
  selected, the kdump mechanism fails systematically.

  [Development/Stable Fix] - This has been fixed in the development
  version with the addition of the following:

    * Backport changes to fix kdump functionality. LP: #828731.
      - debian/kdump.initramfs: call /usr/bin/makedumpfile via a chroot command,
        so that if makedumpfile is statically linked, we get proper library
        resolution.  Thanks to Louis Bouchard <louis.bouchard@xxxxxxxxxxxxx> for
        the patch.  LP: #785425.
      - debian/kdump.initramfs: handle the possibility that /usr, /boot, or
        /var is on a separate filesystem and needs to be manually mounted before
        calling makedumpfile.  LP: #828731.
      - Depend on makedumpfile, without which the initramfs script doesn't work.
      - Fix an unnecessary bashism.
      - Only install the kdump initramfs script and depend on makedumpfile on
        architectures that makedumpfile supports.

  
  [Test Case] - See 'how to reproduce' below.
  [Regression Potential] - Need to ensure kdump works correctly in backported versions.

  --

  Description : Ubuntu 10.04.2
  Release : 10.04

  When a server is configured with the /boot as a separate partition,
  which is the default configuration when LVM installation is selected,
  the kdump mechanism fails systematically.

  This is caused by the fact that the ./scripts/init-bottom/0_kdump
  script that is loaded into the initrd.img file make the assumption
  that /boot is _ALWAYS_ a directory which contains the vmcoreinfo-$KVER
  file. The bug is contained within the following code :

     KVER="`uname -r`"
     INFO="$rootmnt/boot/vmcoreinfo-$KVER"
     CRASHFILE="$rootmnt/var/crash/vmcore"
     MAKEDUMPFILE="$rootmnt/usr/bin/makedumpfile"
     LOG="$rootmnt/var/crash/vmcore.log"
     VMCORE="/proc/vmcore"

     # Check that this is a kexec kernel.
     grep -q kdump_needed /proc/cmdline || exit 0

     # Do NOT exit the script after this point, or the system will start
     # booting inside the crash kernel.

     . ./scripts/functions

     # Make sure makedumpfile assumptions are satisfied.
     while ! test -e "$INFO"; do
             panic "kdump: Missing $INFO"
     done
     while ! test -x "$MAKEDUMPFILE"; do
             panic "kdump: Missing $MAKEDUMPFILE"
     done

  The test 'while !test -e "$INFO";do' fails if /boot is a separate
  partition.

  Reproducible: 100%

  How to Reproduce :

  Pre-requisite : a system or VM installed with LVM and /boot as a
  separate partition (default option for LVM installation)

  1) install the linux-crashdump package & dependancies
  2) Increase the crashkernel= parameter to 128M if the RAM is below 2048M (LP Bug#785394) in /etc/grub.d/10_linux
  3) Run sudo update-grub
  4) Reboot the system
  5) Force a panic with "echo c > /proc/sysrq-trigger

  The system will reboot to the kexec kernel with complete network
  access enabled :

   # cat /proc/cmdline
   BOOT_IMAGE=/vmlinuz-2.6.32-28-server root=/dev/mapper/Lucid--lvmS-root ro kdump_needed maxcpus=1 irqpoll reset_devices memmap=exactmap memmap=640K@0K memmap=130412K@33408K elfcorehdr=163820K

  Workaround:
  Copy the content of the /boot partition into the /boot directory. This is only valid until the next upgrade of the "linux-image-{version}" package.

  How to workaround :

  6) Reboot the system
  7) Copy the content of the /boot partition into the /boot directory
     # df /boot
     Filesystem           1K-blocks      Used Available Use% Mounted on
     /dev/vda1               233191     17563    203187   8% /boot
     # sudo umount /boot
     # sudo mount /dev/vda1 /mnt
     # sudo cp -pr /mnt/* /boot
     # sudo umount /mnt
     # sudo mount -a
     # sudo echo c > /proc/sysrq-tgrigger

  The system will correctly generate a crash dump
     # find /var/crash
      /var/crash
      /var/crash/linux-image-2.6.32-28-server.0.crash

  ProblemType: Bug
  DistroRelease: Ubuntu 10.04.02
  Package: kexec-tools-1-2.0.1-1ubuntu3
  Uname: Linux 2.6.32-28-server x86_64
  Architecture: amd64

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