This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 479503 - mkdumprd produces an initrd that can't mount filesystems on LVM volumes
mkdumprd produces an initrd that can't mount filesystems on LVM volumes
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: system-config-kdump (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Neil Horman
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-09 23:53 EST by Nicholas Miell
Modified: 2009-03-23 22:14 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-23 20:53:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nicholas Miell 2009-01-09 23:53:31 EST
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 09:35:51 EST
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 15:32:15 EST
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-10 19:20:41 EST
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-10 20:23:17 EST
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 10:18:54 EDT
ping, any update here?
Comment 6 Nicholas Miell 2009-03-23 11:55:04 EDT
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-23 20:53:36 EDT
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-23 22:14:45 EDT
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.