Bug 607131 - kdump should fail earlier if the fs type is not supported
Summary: kdump should fail earlier if the fs type is not supported
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kexec-tools
Version: 6.1
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Cong Wang
QA Contact: Lubos Kocman
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-23 10:32 UTC by Lubos Kocman
Modified: 2013-09-30 02:18 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2010-11-11 14:46:15 UTC


Attachments (Terms of Use)
boot log (3.18 KB, application/octet-stream)
2010-06-23 10:32 UTC, Lubos Kocman
no flags Details
proposed patch (1.43 KB, patch)
2010-06-24 06:09 UTC, Cong Wang
no flags Details | Diff

Description Lubos Kocman 2010-06-23 10:32:10 UTC
Created attachment 426223 [details]
boot log

Description of problem:

Hello,

here is the issue that I'm facing every boot


No kdump initial ramdisk found.                            [WARNING]
Rebuilding /boot/initrd-2.6.32-37.el6.x86_64kdump.img
/etc/kdump.conf: Unsupported type btrfs
Failed to run mkdumprd


BTRFS is unsupported (I can understand this)
But this fs check should be done before rebuilding ramdisk.

As I have to wait 30seconds each boot to rebuild a ramdisk, which will be most probably removed -> then next boot removed again, after detecting that I'm using btrfs. 

sudo ls -la /boot/initrd-2.6.32-37.el6.x86_64kdump.img
ls: cannot access /boot/initrd-2.6.32-37.el6.x86_64kdump.img: No such file or directory


[lkocman@stardestroyer Desktop]$ grep btrfs /etc/fstab 
/dev/mapper/rootvg-lv_root /                       btrfs   defaults        1 1
/dev/mapper/rootvg-lv_home /home                   btrfs   defaults        1 2


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

$ rpm -qa kexec-tools crash* kernel
crash-5.0.0-19.el6.x86_64
kexec-tools-2.0.0-84.el6.x86_64
crash-trace-command-1.0-3.el6.x86_64
kernel-2.6.32-37.el6.x86_64

How reproducible:


Steps to Reproduce:
1. Install latest RHEL 6 with btrfs root fs.
2. Boot the machine -> wait for rebuilding ramdisk
3. Reboot the machine -> wait for rebuilding ramdisk (again and again ...)
  
Actual results:

Ramdisk is being rebuilded each boot.

Expected results:

Ramdisk most probably shouldn't be rebuiled if the rootfs is not supported.

Comment 2 RHEL Product and Program Management 2010-06-23 11:07:16 UTC
This feature request did not get resolved in time for Feature Freeze
for the current Red Hat Enterprise Linux release and has now been
denied. It has been proposed for the next Red Hat Enterprise Linux
release. If you would still like it considered for the current
release as an exception, please make that request with your support
representative.

Comment 3 Cong Wang 2010-06-24 06:09:30 UTC
Created attachment 426458 [details]
proposed patch

Hmm, I think we should move the fs type checking earlier, so that if an fs type is not supported, mkdumprd will fail sooner.

Does this satisfy you?

Comment 4 Lubos Kocman 2010-06-24 07:54:37 UTC
Hello,

this would be perfect. Thank you.

Comment 5 Cong Wang 2010-06-24 08:25:51 UTC
Thanks, Lubos.

Cai mentioned that there is actually no /sbin/fsck.btrfs for btrfs, it is /sbin/btrfsck, so the checking code in mkdumprd is not correct for btrfs. Thus you should be able to use btrfs for kdump.

I suggest him to open another BZ for this.

Comment 7 RHEL Product and Program Management 2010-06-25 04:42:59 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 9 Lubos Kocman 2010-07-22 13:42:04 UTC
Verified on kexec-tools-2.0.0-99.el6

I believe that I can't move this to verified based on not having this issue. Actually it's not appearing due fixing that btrfsck issue.

Lubos

Comment 10 releng-rhel@redhat.com 2010-11-11 14:46:15 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.


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