Bug 479503 - mkdumprd produces an initrd that can't mount filesystems on LVM volumes
Summary: mkdumprd produces an initrd that can't mount filesystems on LVM volumes
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-kdump
Version: 10
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Neil Horman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-01-10 04:53 UTC by Nicholas Miell
Modified: 2009-03-24 02:14 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-03-24 00:53:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Nicholas Miell 2009-01-10 04:53:31 UTC
Description of problem:
mkdumprd produces an initrd that can't mount filesystems on LVM volumes

Version-Release number of selected component (if applicable):
kexec-tools-2.0.0-2.fc10.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Make a kdump initrd
2. Crash the kernel
  
Actual results:
The kdump initrd can't find the filesystem in the LVM volume

Expected results:
The kdump initrd finds the filesystem in the LVM volume

Comment 1 Neil Horman 2009-01-10 14:35:51 UTC
This works fine for me.  Please attach the console log of the kdump boot process so  I can see whats going wrong on your system

Comment 2 Nicholas Miell 2009-01-10 20:32:15 UTC
Upon further inspection, this appears to be the result of system-config-kdump not producing a good /etc/kdump.conf

Comment 3 Nicholas Miell 2009-01-11 00:20:41 UTC
OK, even when you take system-config-kdump out of the picture and create the kdump.conf yourself, the resulting initrd still can't mount LVM volumes -- the problem appears to be "findfs UUID=blah" returning something like /dev/dm-1 instead of /dev/System/Root, and there is no /dev/dm-1 device node.

Comment 4 Neil Horman 2009-01-11 01:23:17 UTC
Ok, my origional comment still stands.  A capture of your serial console output during kdump boot is what I need to figure out whats going on here.  In fact a normal kernel boot for comparison would be good, since it sounds like you might not have a standard lvm configuration as far as device naming goes.  thanks.

Comment 5 Neil Horman 2009-03-23 14:18:54 UTC
ping, any update here?

Comment 6 Nicholas Miell 2009-03-23 15:55:04 UTC
I don't have a serial console.

I modified the initrd to mount /dev/System/Root by hand and discovered that kdump/kexec will cold reboot if it is run on my system after X has ever been started.

After that I lost interest in trying to get this stuff to work.

Comment 7 Neil Horman 2009-03-24 00:53:36 UTC
What!?  Why on earth are you trying to start X from within the kdump kernel?  And what exactly do you mean when you say /dev/system/root?  I assume you mean that you're mounting the root file system, but there is no such device as /dev/system/root.

kdump's purpose is to capture a core during a crash.  The /etc/kdump.conf configuration file and init script should set everything up for you.  It sounds like you're trying to put your initramfs together by hand.  

Oh well, if you decide you want to set up serial console, and investigate further, please let me know.  Thanks.

Comment 8 Nicholas Miell 2009-03-24 02:14:45 UTC
System is my primary volume group, Root is the logical volume containing my root filesystem.

I'm not trying to start X from within the kdump kernel.

If X is currently running or ever has run in the past, attempting to induce a kdump via magic sysrq or via an actual kernel panic causes an instant reboot instead of booting into the kdump kernel and then generating a crash dump.

system-config-kdump doesn't generate usable config files, mkdumprd doesn't generate an initrd that can mount filesystems, kexec can't boot new kernels in the presence of X, and crash can't even read the crashdumps or inspect live running systems.

Clearly, none of this stuff is actually meant to be used, and I lost interest in trying to figure of it out.


Note You need to log in before you can comment on or make changes to this bug.