Bug 813354 - kdump.conf does not accept 'auto' as a filesystem type
kdump.conf does not accept 'auto' as a filesystem type
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kexec-tools (Show other bugs)
6.4
All Linux
medium Severity medium
: rc
: ---
Assigned To: Dave Young
Guangze Bai
: Documentation
Depends On:
Blocks: 840683 850466
  Show dependency treegraph
 
Reported: 2012-04-17 10:55 EDT by Gabriel Rocha
Modified: 2015-02-08 16:38 EST (History)
3 users (show)

See Also:
Fixed In Version: kexec-tools-2.0.0-246.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 813345
: 850466 (view as bug list)
Environment:
Last Closed: 2013-02-21 02:47:39 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
document the supported fs types (910 bytes, patch)
2012-07-30 05:34 EDT, Dave Young
no flags Details | Diff

  None (edit)
Description Gabriel Rocha 2012-04-17 10:55:24 EDT
+++ This bug was initially created as a clone of Bug #813345 +++

Description of problem:

the kdump.conf manpage states thus:

<fs type> <partition>
Will  mount  -t  <fs type> <partition> /mnt and copy /proc/vmcore to /mnt/var/crash/%DATE/.  NOTE: <partition> can be a device node, label or uuid.

However, mount -t auto works (it also works in fstab) and it does not work in kdump.conf with an error regarding fsck.auto which does not exist.

This becomes an issue when you have a mixed deployment of rhel5.7 and 5.8 where the default filesystem changed from ext3 to ext4 and the customer's standard kdump.conf stopped working...

Version-Release number of selected component (if applicable):

kexec-tools-1.102pre-126.el5_7.7 (rhel5.7)
kexec-tools-1.102pre-154.el5 (rhel5.8)
kexec-tools-2.0.0-209.el6_2.5.x86_64 (rhel6.2)

How reproducible:

Easily...

Steps to Reproduce:
1. In kdump.conf specify your filesystem type as 'auto'
2. service kdump restart
  
Actual results:

Stopping kdump:                                            [  OK  ]
Detected change(s) the following file(s):
  
  /etc/kdump.conf
Rebuilding /boot/initrd-2.6.18-274.14.1.el5kdump.img
/etc/kdump.conf: Unsupported type auto: fsck.auto not found
Failed to run mkdumprd
Starting kdump:                                            [FAILED]

Expected results:

The kdump service should restart normally and automagically identify between ext3/4 with the 'auto' fs option as mount does.

Additional info:

This can also be seen as a simpler documentation bug where the man page should specify that the filesystem type must exist and cannot be 'auto.' It should also explain what happens with that line and that a corresponding fsck.* executable must exist...

--- Additional comment from pm-rhel@redhat.com on 2012-04-17 10:47:16 EDT ---

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.
Comment 1 Dave Young 2012-07-30 05:34:48 EDT
Created attachment 601168 [details]
document the supported fs types
Comment 6 errata-xmlrpc 2013-02-21 02:47:39 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0281.html

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