Description of problem: Set up the kdump service and rebooted, then forced a panic. The kdump kernel loads, then just sits there after printing "Waiting for dm-..."
yeah, unfortunately this isn't likely to get fixed, since kdump is meant to be an automatic process, and dumping to an encrypted partition is by definition interactive (you need to enter the password to capture the dump). What we should probably do is fail to start the kdump service on encrypted root filesystmes, and tell the user that they have to configure kdump to write the dump elsewhere.
hey, do me a favor, attach your enctab and/or crypttab files if you would please. Thanks!
Created attachment 348739 [details] crypttab I can't find an enctab, just crypttab
Created attachment 348984 [details] patch to avoid starting kdump if dump target is encrypted Hey, can you give this patch a shot. I've not tested it yet, and its doesn't allow encrypted partitions to work, but it should stop kdump from starting if you try to dump to such a partition. Thanks!
(In reply to comment #4) The patch doesn't change anything. (My kdump.conf has nothing but comments in it. Root is on ext4, but I added ext4 to the list. Is kdump taking some kind of defaults when kdump.conf is empty?)
Created attachment 349180 [details] updated patch
Yes, if there is nothing in kdump.conf, kdump mounts the root filesystem and runs /sbin/init like a normal bootup. Thats why this patch defaults the DUMP_TARGET id to that of the / file system. Just for clarity, does the patch you updated for RHEL4 work, or does it still not detect your root file system as being encrypted. If not, could you please add a set -x to the top of your kdump initscript, and send me the output from when you attempt to start the service? That will help me figure out whats going on. Thanks
ping?
closing due to lack of response