Bug 472575 - kdump is failed by nonexistent device entry in /etc/fstab
kdump is failed by nonexistent device entry in /etc/fstab
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kexec-tools (Show other bugs)
5.3
All Linux
low Severity low
: rc
: ---
Assigned To: Neil Horman
Martin Jenner
:
Depends On:
Blocks: 468087
  Show dependency treegraph
 
Reported: 2008-11-21 15:51 EST by Munehiro IKEDA
Modified: 2013-08-05 22:54 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 16:00:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Make mkdumprd robust for nonexistent device entry in /etc/fstab (2.02 KB, patch)
2008-11-21 15:51 EST, Munehiro IKEDA
no flags Details | Diff
patch to check for existance of critical disks (987 bytes, patch)
2008-11-25 15:18 EST, Neil Horman
no flags Details | Diff
patch to check for existance of critical disks (modified) (802 bytes, patch)
2008-11-25 16:13 EST, Munehiro IKEDA
no flags Details | Diff

  None (edit)
Description Munehiro IKEDA 2008-11-21 15:51:38 EST
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.
Comment 1 Neil Horman 2008-11-23 15:42:05 EST
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.
Comment 2 RHEL Product and Program Management 2008-11-24 15:11:37 EST
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.
Comment 3 Neil Horman 2008-11-24 15:24:46 EST
This is not a regression, this is a misconfiguration, it just fails differently in previous releases.
Comment 4 Munehiro IKEDA 2008-11-24 19:46:43 EST
(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.
Comment 5 Neil Horman 2008-11-25 15:18:20 EST
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
Comment 6 Munehiro IKEDA 2008-11-25 16:13:25 EST
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!
Comment 14 Larry Troan 2008-12-10 09:19:11 EST
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.
Comment 16 errata-xmlrpc 2009-01-20 16:00:43 EST
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

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