Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 813345

Summary:	kdump.conf does not accept 'auto' as a filesystem type
Product:	Red Hat Enterprise Linux 5	Reporter:	Gabriel Rocha <grocha>
Component:	kexec-tools	Assignee:	Cong Wang <amwang>
Status:	CLOSED ERRATA	QA Contact:	Petr Beňas <pbenas>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.9	CC:	amwang, ccui, pbenas, pstehlik, rkhan, ruyang
Target Milestone:	rc	Keywords:	Documentation
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	kexec-tools-1.102pre-158.el5	Doc Type:	Bug Fix
Doc Text:	No documentation needed	Story Points:	---
Clone Of:
Clones:	813354 (view as bug list)		Environment:
Last Closed:	2013-01-08 04:09:23 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	743405

Description Gabriel Rocha 2012-04-17 14:37:18 UTC

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)

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...

Comment 1 RHEL Program Management 2012-04-17 14:47:16 UTC

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 2 Cong Wang 2012-07-02 03:15:33 UTC

Hi, Gabriel,

Kdump doesn't accept "auto" as an option in kdump.conf and it is NOT true that all fs types accepted by mount should be accepted by kdump, kdump only supports a few types of filesystem.

I probably don't understand your request, so what's the problem for the customer to change "ext3" to "ext4" in kdump.conf manually when they change their filesystem from ext3 to ext4?

Thanks!

Comment 3 Gabriel Rocha 2012-07-02 10:21:19 UTC

Cong,

No one is arguing whether kdump does/doesn't/should/shouldn't support all filesystems.

What we are saying here is that the way the kdump.conf manpage is worded, this fact is not obvious.

We would like the manpage ammended to read exactly what filesystems are supported and/or that 'auto' is not a valid option and/or that that whatever filesystem chosen must have a corresponding fsck command.

Does this make more sense?

Thanks,

Gabe

Comment 4 Cong Wang 2012-07-02 10:47:18 UTC

(In reply to comment #3)
> We would like the manpage ammended to read exactly what filesystems are
> supported and/or that 'auto' is not a valid option and/or that that whatever
> filesystem chosen must have a corresponding fsck command.
> 
> Does this make more sense?
> 

Yes, sure, I will create a patch to improve the doc.

Thanks!

Comment 6 Cong Wang 2012-07-02 11:04:11 UTC

Gabe,

Is the following change what you want?

% git diff
diff --git a/kdump.conf.5 b/kdump.conf.5
index d688bdd..10e5b89 100644
--- a/kdump.conf.5
+++ b/kdump.conf.5
@@ -45,8 +45,9 @@ server and that a fqdn is used as the server name
 .B <fs type> <partition>
 .RS
 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.
+/mnt/var/crash/%DATE/.  Currently, the supported fs types are: ext4,
+ext3, ext2, minix and xfs, other fs types like "auto" are not supported.
+NOTE: <partition> can be a device node, label or uuid.
 .RE
 
 .B path <path>

Comment 7 Gabriel Rocha 2012-07-02 12:37:31 UTC

Hi Cong,

That looks good to me. 

Thanks,

Gabe

Comment 10 Petr Beňas 2012-07-24 12:17:41 UTC

Verified in kexec-tools-1.102pre-158.el5.

Comment 12 errata-xmlrpc 2013-01-08 04:09:23 UTC

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-0012.html