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) ============================================================= RHEL5.3 Beta kexec-tools-102pre-50.el5 How reproducible ================= Always 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 or # /sbin/mkdumprd -f -d /boot/initrd-`uname -r`kdump.img 4. Execute kdump by sysrq-c or other way. Actual results ============== 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... Expected results ================= 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 > /etc/fstab. 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. Thanks!
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 cases. If the solution is still not acceptable, please open a new bugzilla referencing this one.
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. http://rhn.redhat.com/errata/RHBA-2009-0105.html