Hi, Amerigo I remember you said we only support dump to mounted fs in rhel, right?
(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.
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.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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.
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.
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?
(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.
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.
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
(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.
I agree. Lets keep the requirement that kdump partition is mounted when kdump service is launched.
Hi Joshua, thanks for your response. Since agreement has been reached, I will close this bug as NOT BUG.
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.
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