[Kernel-packages] [Bug 828731] Re: kdump functionality not working as expected when /boot is a separate partition

[Claudio Corvino]

still present in trusty! /boot in sda1 and / is on LVM

-- 
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  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 17563203187   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:

[Kernel-packages] [Bug 828731] Re: kdump functionality not working as expected when /boot is a separate partition

[vigilian]

same bug than before in trusty. 
/boot on sde5 
and / is on sdd2

can you release a fix please. I need to evaluate my kernel panic FAST!
thank you

-- 
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.bouch...@canonical.com 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 17563203187   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 

[Kernel-packages] [Bug 828731] Re: kdump functionality not working as expected when /boot is a separate partition

[Anders Kaseorg]

Nagaraj, I see no reason to think your problem is related to this bug.
This bug is specifically about a separate /boot partition, which you do
not have, and your symptoms don’t match either. You should file a new
report.

-- 
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.bouch...@canonical.com 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 17563203187   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 

[Kernel-packages] [Bug 828731] Re: kdump functionality not working as expected when /boot is a separate partition

[Louis Bouchard]

First of all, doing ponytail on a 3 year old bug is not going to bring
you much attention.

Especially since this bug pertains to a mechanism that is now only used
on Precise.  It is unfortunate though that the server guide is
misleading on how to configure kernel dump. I would suggest to open a
bug against the server guide to have  this fixed.

This  page does a pretty good job at documenting how to generate a
kernel crash dump :

 https://wiki.ubuntu.com/Kernel/CrashdumpRecipe

TL;DR : Once the linux-crashdump package has been installed  the server
rebooted you need to change the following in /etc/default/kdump-tools :

USE_KDUMP=1

Then :

 $ sudo kdump-config load

For any other visiting this bug, please refrain from adding to it, it is
no longer relevant as the kernel dump mechanism has changed

-- 
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.bouch...@canonical.com 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 

[Kernel-packages] [Bug 828731] Re: kdump functionality not working as expected when /boot is a separate partition

[Nagaraj S D]

I have a setup with Ubuntu 14.04 LTS server. The /boot is not on a
separate partition. I followed the kdump setup as mentioned in
https://help.ubuntu.com/14.04/serverguide/kernel-crash-dump.html

After triggering the kdump, system panics but system never
comeup/reboot. It get stuck at the call trace of the panic.

Some of the commands output is below it might help to understand the issue:
root@ubuntu:~# mount
/dev/mapper/350002ac01d6314e1-part1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
systemd on /sys/fs/cgroup/systemd type cgroup 
(rw,noexec,nosuid,nodev,none,name=systemd)
root@ubuntu:~#


hbauser@ubuntu:~$ ls /boot/
abi-3.13.0-24-generic grub  memtest86+.bin  
memtest86+_multiboot.bin  vmlinuz-3.13.0-24-generic
config-3.13.0-24-generic  initrd.img-3.13.0-24-generic  memtest86+.elf  
System.map-3.13.0-24-generic
hbauser@ubuntu:~$


hbauser@ubuntu:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic 
root=UUID=0503c0b3-1acd-4e11-a60a-f5f2618fdb6c ro crashkernel=384M-:128M
hbauser@ubuntu:~$ dmesg | grep -i crash
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic 
root=UUID=0503c0b3-1acd-4e11-a60a-f5f2618fdb6c ro crashkernel=384M-:128M
[0.00] Reserving 128MB of memory at 720MB for crashkernel (System RAM: 
32733MB)
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic 
root=UUID=0503c0b3-1acd-4e11-a60a-f5f2618fdb6c ro crashkernel=384M-:128M
hbauser@ubuntu:~$


In another configuration where I have installed OS with LVM and /boot on 
separate partition. The workaround suggested in this bug also didn't work. Am I 
missing something?

-- 
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.bouch...@canonical.com 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 

[Kernel-packages] [Bug 828731] Re: kdump functionality not working as expected when /boot is a separate partition

[Terry Wang]

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.bouch...@canonical.com 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