kernel-packages team mailing list archive
-
kernel-packages team
-
Mailing list archive
-
Message #71687
[Bug 828731] Re: kdump functionality not working as expected when /boot is a separate partition
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.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