RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1709894 - kdump: Unable to use NFS configuration easily
Summary: kdump: Unable to use NFS configuration easily
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kexec-tools
Version: 7.7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: kdump-bugs
QA Contact: Emma Wu
URL:
Whiteboard:
: 1724164 (view as bug list)
Depends On:
Blocks: 1724107
TreeView+ depends on / blocked
 
Reported: 2019-05-14 13:52 UTC by Jan Ščotka
Modified: 2019-08-13 05:59 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-13 05:03:25 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Jan Ščotka 2019-05-14 13:52:01 UTC 
Seems that although cockpit support scenario to use NFS shares for kdump,
it is not easy to use it.

according to article: 
https://access.redhat.com/solutions/1197493
and 
https://fedoraproject.org/wiki/QA:Testcase_Kdump_Func_NFS

it is not enough to just add NFS configuration to kdump.conf file.

but there are another 2. steps what has to be done:

 1. you have to mount (ideally add to fstab) that mount to /var/crash directory.
    Without that, service start fails, (because it is unable to regenerate initramdisc)

 2. on that mount point there have to be directory structure /var/crash too, means that when it is mounted, it contains: /var/crash/var/crash
 (it is also configurable, but default configuration, contains that) and also as I've asked someone, some older version of kdump created this directory structure, but newer version does not do that.

So actually without deep knowledge of kdump configuration for NFS, non-experienced user is not able to make it working via cockpit

Possible solution:
 * document it, and when start kdump, show message that it is not mounted and show how to do it via cockpit
 * do it via cockpit storage NFS implicitly
 * discuss it with kdump maintainer, what is best solution and what has to be setup and what is just optional for NFS. 

setup steps to make it working (snip from python code):
    share = "/nfsfileshare"
    exporttab = """
{}    *(rw,sync,no_root_squash)
    """.format(share)
    export_file = '/etc/exports'

    def requirements(self):
        execs = [
            "sudo yum install -y nfs-utils || true",
            "sudo mkdir -p {}/var/crash".format(self.share),
            "sudo chmod a+rwx {}".format(self.share),
            "echo '{}' | sudo tee {}".format(self.exporttab, self.export_file),
            "sudo systemctl start nfs-server rpcbind",
            "sudo exportfs -r"
            "sudo mount localhost:{} /var/crash"
        ]
        for exe in execs:
            self.machine.execute(exe)
Comment 2 Martin Pitt 2019-08-01 08:54:19 UTC 
*** Bug 1724164 has been marked as a duplicate of this bug. ***
Comment 3 Martin Pitt 2019-08-01 09:04:25 UTC 
I'm reassigning this to kdump, for the following reasons:

 * It's pointless to offer an NFS configuration in kdump.conf for "NFS server:/path", and then expecting the user to set up the mounting of that NFS volume to /var/crash/ themselves. Then this is just the same case of a local directory, except that it may affect the boot ordering a bit.
 * https://fedoraproject.org/wiki/QA:Testcase_Kdump_Func_NFS does not actually document that the target must be mounted, and https://access.redhat.com/solutions/1197493 indicates that this was a bug, not intended behaviour.
 * "on that mount point there have to be directory structure /var/crash too" → this seems like another bug in kdump -- if the configuration says to place the dumps in server:/path/, then it should use that path, not some subdirectory -- or create these subdirectories by itself.
 * Cockpit is not the place to add such workarounds -- they make assumptions about the implementation details of services, are prone to get out of date with newer kdump version (and that would already happen, as this is apparently fixed in Fedora?), and also affects users who configure kdump.conf outside of cockpit.

Can the newer behaviour that the user does not need to manually mount the NFS share be backported to RHEL 7.7?

We can discuss the wanted behaviour here, and reassign back to cockpit for a hackish workaround if there are good reasons for the current behaviour (I don't claim to understand all details of it).
Comment 4 Dave Young 2019-08-13 05:03:25 UTC 
Hi,

This is the expected behavior, one needs mount the nfs share if he needs to use nfs for kdump.  Otherwise there is a way as we introduced in the referred bz to use the dracut_args, but then we will not do the sanity check and one need to do a test first to ensure it works.

But yes, there are something can be improved, for example, use "path" is enough for fs dump including nfs. One do not need to specify ext4 or nfs.  Just a path will be good.  We planned to improve this in the future.

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