Bug 472575 - kdump is failed by nonexistent device entry in /etc/fstab
Summary: kdump is failed by nonexistent device entry in /etc/fstab
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kexec-tools
Version: 5.3
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Neil Horman
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On:
Blocks: 468087
TreeView+ depends on / blocked
 
Reported: 2008-11-21 20:51 UTC by Munehiro IKEDA
Modified: 2013-08-06 02:54 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-20 21:00:43 UTC
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0105 0 normal SHIPPED_LIVE kexec-tools bug fix and enhancement update 2009-01-20 16:04:36 UTC

Description Munehiro IKEDA 2008-11-21 20:51:38 UTC
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 20:42:05 UTC
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 Program Management 2008-11-24 20:11:37 UTC
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 20:24:46 UTC
This is not a regression, this is a misconfiguration, it just fails differently in previous releases.

Comment 4 Munehiro IKEDA 2008-11-25 00:46:43 UTC
(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 20:18:20 UTC
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 21:13:25 UTC
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 14:19:11 UTC
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 21:00:43 UTC
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.