Bug 808298 - mkdumprd failed when nfs server is not mounted.
mkdumprd failed when nfs server is not mounted.
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kexec-tools (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Baoquan He
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 808299 1093112
  Show dependency treegraph
 
Reported: 2012-03-30 01:25 EDT by WANG Chao
Modified: 2014-04-30 12:05 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 808299 1093112 (view as bug list)
Environment:
Last Closed: 2013-06-05 21:50:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 1 Dave Young 2012-03-30 01:38:05 EDT
Hi, Amerigo

I remember you said we only support dump to mounted fs in rhel, right?
Comment 2 WANG Chao 2012-03-30 22:53:57 EDT
(In reply to comment #1)
> Hi, Amerigo
> 
> I remember you said we only support dump to mounted fs in rhel, right?

That's not true, at least in rhel6, we can build kdump image and also dumping to nfs server both w/o mounting the nfs dir.
Comment 3 Américo Wang 2012-04-02 04:40:10 EDT
Dave,

I was wrong, at least we should mount it to check if we have the right permission and enough size to store the vmcore, currently we lack all of these.

Thanks.
Comment 4 Fedora Admin XMLRPC Client 2012-04-16 02:12:43 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 5 Vivek Goyal 2012-04-17 10:35:09 EDT
I am thinking that in rhel7 we should think making it a requirement that if we are dumping to a filesystem (either local or remote), it should be mounted at the time of initramfs generation.

Reason being that otherwise we need more information. That is mount options. Which is not present in kdump.conf file.

It also simplifies the handling of space checking. And amount of logic we keep in kdump is less complex.

Also it does not feel as if it is a important requirement. Is there any good example which demonstrates why it is important to support dump to a file system
which is unmounted in first kernel.
Comment 6 Vivek Goyal 2012-04-17 10:58:40 EDT
In fact kdump.conf can be simplifed a lot if we assume that filesystem is mounted. No need to differentiate between nfs/nfs4. One can just specify UUID, LABEL or /dev or just the mount point to dump to.

Anyway, I am not able to see that why to complicate the things by allowing dumping to unmounted filesystems at the time of initrd creation.
Comment 7 Vivek Goyal 2012-04-18 18:06:30 EDT
One restriction which comes with supporting only mounted filesystem is that user shall have to put the relevant entries in /etc/fstab so that after every reboot
these filesystems are mounted. If a kernel upgrade happens and initrd is regenerated after next reboot, we want to make sure our dump targets are already mounted.

I guess there is nothing wrong in asking dump filesystems ot keep in /etc/fstab?
Comment 8 Dave Young 2012-04-18 22:44:47 EDT
(In reply to comment #5)
> I am thinking that in rhel7 we should think making it a requirement that if we
> are dumping to a filesystem (either local or remote), it should be mounted at
> the time of initramfs generation.
> 
> Reason being that otherwise we need more information. That is mount options.
> Which is not present in kdump.conf file.

When I was trying to fix this problem I found the mount options is a big problem.
We can not guess or assume no options.

dracut fstab-sys did not support this as well because mount an umounted fs the mount point is probably not exist, later I sent a patch to just mkdir in ramfs to mount them. But for us kdump I think we'd better don't support this issue.
Comment 9 joshua 2012-07-13 18:57:15 EDT
I'm finding this to be a problem too.  I have an NFS share that exists for kdump'ing, but it shouldn't be mounted on any of my machines.  This means essentially that I can't do a "kdumpctl start" and ever have it return successfully because mkdumprd doesn't like unmounted NFS shares.
Comment 10 Fedora Admin XMLRPC Client 2013-02-25 03:06:14 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 11 Baoquan He 2013-05-27 23:18:14 EDT
Hi Joshua,

I think Vivek and Dave have given convincing comments to explain why mount is necessary when it's used as dump target. I am wondering why it shouldn't be mounted when the NFS exists for kdumping. Could you please help give some details?

Baoquan
Thanks
Comment 12 Vivek Goyal 2013-05-28 11:34:08 EDT
(In reply to joshua from comment #9)
> I'm finding this to be a problem too.  I have an NFS share that exists for
> kdump'ing, but it shouldn't be mounted on any of my machines.  This means
> essentially that I can't do a "kdumpctl start" and ever have it return
> successfully because mkdumprd doesn't like unmounted NFS shares.

So that share will be mounted when kdump happens anyway. So what's wrong if it
is mounted all the time by default.

In fact it is good for kdump reliability. In case server is down or there are some other issues, you will come to know about it when system boots. Otherwise if machine crashes, and then you can't mount the share, it will be too late.

Also we are looking to re-labeling selinux context on vmcore files when kdump service starts after boot and that will require that crash partition/vmcore is reachable. That's another reason that we want kdump partition mounted when system boots.

So I would really like to keep the requirement that kdump partition is mounted when kdump service is launched.
Comment 13 joshua 2013-06-05 13:16:54 EDT
I agree.  Lets keep the requirement that kdump partition is mounted when kdump service is launched.
Comment 14 Baoquan He 2013-06-05 21:50:56 EDT
Hi Joshua, thanks for your response. Since agreement has been reached, I will close this bug as NOT BUG.
Comment 15 Steven Seed 2014-04-29 20:01:48 EDT
I'm sorry, but this just doesn't make sense. What is the point of the nfs option if I need to have the path mounted first? Why would I just not use a path at that point? Regardless, this doesn't work in my environment because we use automounts. Unless I've recently accessed the path to where my crash dumps are going, the kdump service returns an error.

Before accessing my automount:

kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled)
   Active: failed (Result: exit-code) since Tue 2014-04-29 16:57:11 PDT; 13s ago
  Process: 10544 ExecStop=/usr/bin/kdumpctl stop (code=exited, status=0/SUCCESS)
  Process: 27907 ExecStart=/usr/bin/kdumpctl start (code=exited, status=1/FAILURE)
 Main PID: 27907 (code=exited, status=1/FAILURE)
Apr 29 16:57:10 cowbell.fas.fa.disney.com kdumpctl[27907]: Detected change(s) the following file(s):
Apr 29 16:57:10 cowbell.fas.fa.disney.com kdumpctl[27907]: /etc/kdump.conf
Apr 29 16:57:10 cowbell.fas.fa.disney.com kdumpctl[27907]: Rebuilding /boot/initramfs-3.10.0-121.el7.x86_64kdump.img
Apr 29 16:57:11 cowbell.fas.fa.disney.com kdumpctl[27907]: Dump target ice:/ifs/data/no_snap/NETDUMP is probably not mounted.
Apr 29 16:57:11 cowbell.fas.fa.disney.com kdumpctl[27907]: mkdumprd: failed to make kdump initrd
Apr 29 16:57:11 cowbell.fas.fa.disney.com kdumpctl[27907]: Starting kdump: [FAILED]
Apr 29 16:57:11 cowbell.fas.fa.disney.com systemd[1]: kdump.service: main process exited, code=exited, status=1/FAILURE
Apr 29 16:57:11 cowbell.fas.fa.disney.com systemd[1]: Failed to start Crash recovery kernel arming.
Apr 29 16:57:11 cowbell.fas.fa.disney.com systemd[1]: Unit kdump.service entered failed state.

After accessing my automount:

kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled)
   Active: active (exited) since Tue 2014-04-29 16:58:03 PDT; 1min 24s ago
  Process: 10544 ExecStop=/usr/bin/kdumpctl stop (code=exited, status=0/SUCCESS)
  Process: 29765 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
 Main PID: 29765 (code=exited, status=0/SUCCESS)

Apr 29 16:58:02 cowbell.fas.fa.disney.com dracut[31651]: drwxr-xr-x   3 root     root            0 Apr 29 16:57 var/lib/nfs/statd
Apr 29 16:58:02 cowbell.fas.fa.disney.com dracut[31651]: drwxr-xr-x   2 root     root            0 Apr 29 16:57 var/lib/nfs/statd/sm
Apr 29 16:58:02 cowbell.fas.fa.disney.com dracut[31651]: drwxrwx---   2 rpc      rpc             0 Apr 29 16:57 var/lib/rpcbind
Apr 29 16:58:02 cowbell.fas.fa.disney.com dracut[31651]: lrwxrwxrwx   1 root     root           11 Apr 29 16:57 var/lock -> ../run/lock
Apr 29 16:58:02 cowbell.fas.fa.disney.com dracut[31651]: lrwxrwxrwx   1 root     root           10 Apr 29 16:57 var/log -> ../run/log
Apr 29 16:58:02 cowbell.fas.fa.disney.com dracut[31651]: lrwxrwxrwx   1 root     root            6 Apr 29 16:57 var/run -> ../run
Apr 29 16:58:02 cowbell.fas.fa.disney.com dracut[31651]: ========================================================================
Apr 29 16:58:03 cowbell.fas.fa.disney.com kdumpctl[29765]: kexec: loaded kdump kernel
Apr 29 16:58:03 cowbell.fas.fa.disney.com kdumpctl[29765]: Starting kdump: [OK]
Apr 29 16:58:03 cowbell.fas.fa.disney.com systemd[1]: Started Crash recovery kernel arming.
Comment 16 Baoquan He 2014-04-29 22:54:05 EDT
Hi Steve,

You have read comments people had discussed, and still think it's not reasonable?

Btw, I would like to check why your case failed. Could you tell me what automount means and how you set it?

Thanks
Baoquan

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