It is not possible to configure kdump via NFS with RHEL 7.1.
The configuration with the GUI does not work and a manual configuration also doesn't work.
The command "mkdumprd" reports always the error message:
Dump target ... is probably not mounted.
although the filesystem is mounted via NFS.
A sosreport is attached.
Below you find the output of the commands.
[root@js-rx300s8 etc]# df -HT
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/rhel-root xfs 44G 5.2G 39G 12% /
devtmpfs devtmpfs 17G 0 17G 0% /dev
tmpfs tmpfs 17G 144k 17G 1% /dev/shm
tmpfs tmpfs 17G 9.8M 17G 1% /run
tmpfs tmpfs 17G 0 17G 0% /sys/fs/cgroup
/dev/sda1 xfs 518M 130M 388M 26% /boot
/dev/mapper/rhel-home xfs 22G 34M 22G 1% /home
172.17.132.10:/data nfs4 295G 233G 48G 83% /mnt
[root@js-rx300s8 etc]# mkdumprd -f /boot/initramfs-3.10.0-229.el7.x86_64kdump.img 3.10.0-229.el7.x86_64
Dump target 172.17.132.10:/data/netdump is probably not mounted
Created attachment 1009724 [details]
I have reproduced this on rhel7.0 and 7.1. Looks similiar to bz1121590 .
The issue seems to be that system-config-kdump creates these entries in kdump.conf:
while instead this one would be expected for "kdumpctl start" to succeed:
# path /mnt/store/tmp/tmp (it has to be commented out/not set)
(In reply to Christian Horn from comment #3)
> I have reproduced this on rhel7.0 and 7.1. Looks similiar to bz1121590 .
Ah, actually not similiar. In bz1121590 we still look for a proper solution for the required nfs mount. Here we have that, and despite that the system-config-kdump generates a config which kdumpctl can not cope with.
Status? is this going to be fixed in 7.2, or 7.1.z?
According to the KBase https://access.redhat.com/solutions/1222233 and comment #3, it should be possible to configure kdump by hand-editing /etc/kdump.conf, and modifying it as indicated.
The "resolution" text of the KB doesn't really clarify that the user has to hand-edit kdump.conf according to comment #3, though.
@assignee: How are our chances to get this fixed in 7.2? We offer the graphical tool, having it working for the most common scenario would be good.
@Martin: Once we have a patch, we could technically apply for 7.1.z, but since manual config as fallback works to my understanding, this would probably not qualify for an accelerated fix.
> The "resolution" text of the KB doesn't really clarify that the user
> has to hand-edit kdump.conf according to comment #3, though.
Thanks for the suggestion.
The kbase had the correct entries "as example", I am modifying this now into "please ensure this syntax in kdump.conf".
In the resolution part its mentioned that system-config-kdump fails to deploy this scenario correctly.
Thank you for the report! As far as I know, system-config-kdump is not scheduled to be updated in 7.2. I can post patch if it helps anything.
Indeed, I do not spot it on the approved components list either.
With a patch we can then decide to apply for accelerated fix (maybe fasttrack) or wait for 7.3 .
A fix for in 7.2 or fasttrak would be appreciated, but it is not mandatory as we have a proven workaround.
Please add a note in the KB article explaining how to hand-edit kdump.conf after running system-config-kdump as explained in comment #3.
(In reply to Martin Wilck from comment #10)
> Please add a note in the KB article explaining how to hand-edit kdump.conf
> after running system-config-kdump as explained in comment #3.
I had already provided an example for a working config.
I have now also added an example for the broken config from system-config-kdump - I refrained from doing this as it pins down, I fear if someone manages to get a different config from system-config-kdump which does not fit that scheme, he might find the kbase not applicable.
If you have suggestions for improvements, please let us know the details.
> A fix for in 7.2 or fasttrak would be appreciated, but it is not
> mandatory as we have a proven workaround.
I agree. As soon as we have a patch, if we should apply for fasttrack, we can open a customer center case and start the procedure.
(In reply to Christian Horn from comment #11)
> If you have suggestions for improvements, please let us know the details.
You may want to add a warning comment in the bad example, like this:
# CAUTION - this configuration is BROKEN and DOES NOT WORK
# See correct example below
(In reply to Martin Wilck from comment #12)
> # CAUTION - this configuration is BROKEN and DOES NOT WORK
> # See correct example below
ACK, implemented. Thanks for the feedback.
It looks like simply generating
as proposed in comment #3 won't be enough to support all use cases. Kdump expects configuration in the following format:
and saves the dump to <server>:<nfsdir>/<path> (<path> defaults to /var/crash/%HOST-%DATE if not set in kdump.conf). So far so good. However it requires <server>:<nfsdir> to be mounted somewhere during the service startup. I.e. the <nfsdir> must exactly match that in the mtab, parent directory cannot be used. This means that
does not behave the same as
even though the kdump would be stored in the same location.
My proposal is to change the label that currently reads "Server name:" to something like "Target (host:share):" and eventually validate that the value has the correct format. Would that be acceptable?
(In reply to Martin Milata from comment #14)
> My proposal is to change the label that currently reads "Server name:" to
> something like "Target (host:share):" and eventually validate that the value
> has the correct format. Would that be acceptable?
For me, yes. Not sure if Red Hat's usability team will agree :-)
Created attachment 1104398 [details]
Attached patch that changes the NFS server inputbox label from "Server name:" to "Export (host:path):" and raises an error when user tries to use wrong format (e.g. no path) for the NFS server value.
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.