Created attachment 1009724 [details]
sosreport

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:
  nfs 192.168.4.1
  path /mnt/store/tmp/tmp
while instead this one would be expected for "kdumpctl start" to succeed:
  nfs 192.168.4.1:/mnt/store/tmp/tmp
  # 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
nfs 192.168.4.1
path /mnt/store/tmp/tmp

(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

  nfs <server>:<path>

instead of

  nfs <server>
  path <path>

as proposed in comment #3 won't be enough to support all use cases. Kdump expects configuration in the following format:

  nfs <server>:<nfsdir>
  path <path>

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

   nfs host:/a
   path: /b/c

does not behave the same as

   nfs host:/a/b
   path /c

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]
Proposed patch

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.

https://rhn.redhat.com/errata/RHBA-2016-2512.html