Bug 1208191 - Kdump over NFS does not work with RHEL 7.1
Summary: Kdump over NFS does not work with RHEL 7.1
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: system-config-kdump   
(Show other bugs)
Version: 7.1
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: rc
: 7.1
Assignee: Martin Milata
QA Contact: Emma Wu
Marie Dolezelova
URL:
Whiteboard:
Keywords: Patch
Depends On:
Blocks: 1203710 1313485 1104057 1245518 1295829 1364088
TreeView+ depends on / blocked
 
Reported: 2015-04-01 15:16 UTC by Peter Pols
Modified: 2017-06-27 05:31 UTC (History)
8 users (show)

Fixed In Version: system-config-kdump-2.0.13-14.el7
Doc Type: Bug Fix
Doc Text:
Configuring *kdump* to an NFS target destination is now possible in the Kernel Dump Configuration GUI Previously, the input box for NFS target destination in the Kernel Dump Configuration GUI did not indicate that an export path needs to be entered. Consequently, users were not able to configure the *kdump* feature to a NFS target destination when using this GUI. With this update, the input box label has been changed to indicate that an export path is required, and users are able to configure *kdump* in the described situation.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-04 07:47:43 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sosreport (6.09 MB, application/x-xz)
2015-04-01 15:18 UTC, Peter Pols
no flags Details
Proposed patch (3.24 KB, patch)
2015-12-10 15:40 UTC, Martin Milata
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2512 normal SHIPPED_LIVE system-config-kdump bug fix update 2016-11-03 14:14:09 UTC
Red Hat Knowledge Base (Solution) 1222233 None None None Never

Description Peter Pols 2015-04-01 15:16:50 UTC
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

Comment 1 Peter Pols 2015-04-01 15:18:27 UTC
Created attachment 1009724 [details]
sosreport

Comment 3 Christian Horn 2015-04-02 07:38:14 UTC
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)

Comment 4 Christian Horn 2015-04-02 07:43:58 UTC
(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.

Comment 5 Martin Wilck 2015-06-30 08:55:04 UTC
Status? is this going to be fixed in 7.2, or 7.1.z?

Comment 6 Martin Wilck 2015-06-30 09:05:28 UTC
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.

Comment 7 Christian Horn 2015-06-30 09:12:38 UTC
@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.

Comment 8 Martin Milata 2015-06-30 10:50:35 UTC
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.

Comment 9 Christian Horn 2015-06-30 11:07:10 UTC
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 .

Comment 10 Martin Wilck 2015-06-30 15:36:16 UTC
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.

Comment 11 Christian Horn 2015-06-30 18:55:24 UTC
(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.

Comment 12 Martin Wilck 2015-07-01 13:01:20 UTC
(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

Comment 13 Christian Horn 2015-07-01 13:35:11 UTC
(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.

Comment 14 Martin Milata 2015-10-21 16:30:33 UTC
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?

Comment 15 Martin Wilck 2015-10-22 06:47:45 UTC
(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 :-)

Comment 16 Martin Milata 2015-12-10 15:40 UTC
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.

Comment 23 errata-xmlrpc 2016-11-04 07:47:43 UTC
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


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