Red Hat Bugzilla – Bug 472575
kdump is failed by nonexistent device entry in /etc/fstab
Last modified: 2013-08-05 22:54:49 EDT
Created attachment 324344 [details]
Make mkdumprd robust for nonexistent device entry in /etc/fstab
Description of problem
If there is a nonexistent device entry for swap in /etc/fstab, kdump fails.
This problem doesn't occur on RHEL5.2 so it seems a regression.
Version-Release number of selected component (if applicable)
Steps to Reproduce
1. Add a first swap entry whose device doesn't exist in /etc/fstab like below.
/dev/nonexistdev swap swap defaults 0 0
/dev/sda2 swap swap defaults 0 0
2. Configure kdump.
3. Re-generate initrd for kdump kernel by
# /etc/init.d/kdump restart
# /sbin/mkdumprd -f -d /boot/initrd-`uname -r`kdump.img
4. Execute kdump by sysrq-c or other way.
kdump system (2nd system) printed out below message and never returns (infinite looping)
Waiting for required block device discovery
Waiting for sdc...Found
Waiting for nonexistdev...
kdump is executed and reboot.
Quick hack: Solution proposal
This problem is caused by a non-existent device line of /etc/critical_disks in initrd. /init in initrd waits for that the device appears in /sys/block, but it doesn't because it doesn't exist. As a result of it, /init waits forever and kdump fails.
Attached patch adds mkdumprd check code of device existence. If a device doesn't exist, patched mkdumprd outputs warning message if -v is specified.
This is a quick hack and there might be a cleaner solution. Please consider it.
um, garbage in, garbage out? I Hardly think this is a real problem. If you don't want errors when handling /etc/fstab, don't put incorrect entries into /etc/fstab.
This bugzilla has Keywords: Regression.
Since no regressions are allowed between releases,
it is also being proposed as a blocker for this release.
Please resolve ASAP.
This is not a regression, this is a misconfiguration, it just fails differently in previous releases.
(In reply to comment #1)
> um, garbage in, garbage out? I Hardly think this is a real problem. If you
> don't want errors when handling /etc/fstab, don't put incorrect entries into
This is "garbage in, nothing out", then user cannot understand what is wrong.
(What user can know is just only that kdump never ends)
But I agree we can avoid this phenomena to put correct entries into /etc/fstab. So I agree the low priority, low severity, and not to mark this regression.
Created attachment 324660 [details]
patch to check for existance of critical disks
Can you please verify that this solves the problem as well, it seems like a simpler approach to me, one which will flag the error to the user
Created attachment 324671 [details]
patch to check for existance of critical disks (modified)
I believe the patch should be corrected as
-+ if [ ! -d sys/$i ]
++ if [ ! -d /sys/block/$i ]
Attached is corrected one.
(If this is not your intent, please correct me)
This solves the issue. I agree your approach is simpler and better.
There's been a few more patches related to this defect so I would like
to ask that FJ retest with the latest version of kexec-tools
(kexec-tools-1.102pre-56.el5) which should take care of the cciss and md
If the solution is still not acceptable, please open a new bugzilla referencing
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.