Created attachment 1572857 [details] log files Description of problem: Kdump file is captured in local filesystem when setting "Location" to "Remote over NFS". [root@test crash]# pwd /var/crash [root@test crash]# ls -l total 24 drwxr-xr-x. 2 root root 4096 May 23 17:35 127.0.0.1-2019-05-23-17:35:09 drwxr-xr-x. 2 root root 4096 May 23 17:37 127.0.0.1-2019-05-23-17:37:04 drwx------. 2 root root 16384 May 24 2019 lost+found Version-Release number of selected component (if applicable): RHVH-4.3-20190523.0-RHVH-x86_64-dvd1.iso cockpit-system-193-1.el7.noarch cockpit-ws-193-1.el7.x86_64 cockpit-dashboard-193-1.el7.x86_64 cockpit-193-1.el7.x86_64 cockpit-ovirt-dashboard-0.13.0-1.el7ev.noarch cockpit-machines-ovirt-193-1.el7.noarch cockpit-bridge-193-1.el7.x86_64 cockpit-storaged-193-1.el7.noarch kernel-3.10.0-957.19.1.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. Clean install RHVH-4.3-20190523.0-RHVH-x86_64-dvd1.iso 2. Launch cockpit "http://localhost:9090" 3. Set crash dump location to "Remote over NFS" 4. Test kernel dump Actual results: Kdump file is captured in local filesystem /var/crash Expected results: Kdump file should be captured in remote nfs server mount path. Additional info:
Is this within the cockpit-ovirt plugin or in the main cockpit application?
(In reply to Sandro Bonazzola from comment #1) > Is this within the cockpit-ovirt plugin or in the main cockpit application? It is in the main cockpit application, not cockpit-ovirt plugin.
Let's open a bug on upstream cockpit for this and track its resolution here for including new build with the fix.
Need to rebase on new cockpit
cockpit-195.1-1.el7 has been built and tagged for testing: https://cbs.centos.org/koji/buildinfo?buildID=26245
build landed on testing repo at https://buildlogs.centos.org/centos/7/virt/x86_64/ovirt-4.3/ and entering oVirt CI tests.
Test Version RHVH-4.3-20190620.7-RHVH-x86_64-dvd1.iso cockpit-system-195-1.el7.noarch cockpit-195-1.el7.x86_64 cockpit-bridge-195-1.el7.x86_64 cockpit-ws-195-1.el7.x86_64 cockpit-machines-ovirt-195-1.el7.noarch cockpit-dashboard-195-1.el7.x86_64 cockpit-storaged-195-1.el7.noarch cockpit-ovirt-dashboard-0.13.2-2.el7ev.noarch Test Steps: According to comment 0 Result: Verification is blocked by a new bug https://bugzilla.redhat.com/show_bug.cgi?id=1724107
I will verify this bug until the dependence bug (1724107) is fixed.
Hi Simone, I think bug 1724107 block this bug. When I retest this bug as below steps: 1. Clean install RHVH-4.3 iso 2. Launch cockpit "http://localhost:9090" 3. Set crash dump location to "Remote over NFS" --- Here bug 1724107 occur, kdump service is broken down, and the button "Crash dump test" is disabled 4. Test kernel dump --- Cannot execute this step from cockpit UI So this bug is blocked by bug 1724107. suggest to re-target it to 4.3.6.
Unlocking this bug. I did a mistake converting this to a rebase bug. Restoring original summary and pushing to 4.3.6, I'll open different bug for the rebase.
Rebase bug opened at bug #1732288
According to comment 10 and the depends bug 1724107 status, Can I move the bug status to "NEW" or "ASSIGNED"?
(In reply to Wei Wang from comment #12) > According to comment 10 and the depends bug 1724107 status, Can I move the > bug status to "NEW" or "ASSIGNED"? moved back to new.
Closing this as not a bug since "This is the expected behavior, one needs mount the nfs share if he needs to use nfs for kdump."
According to the comments from #6 to #17 of https://bugzilla.redhat.com/show_bug.cgi?id=1724107 , move this bug status to "ASSIGNED". This is related to two test cases.
Moved to oVirt 4.4.4 since CentOS 8.3 won't be available at 4.4.3 GA time.
This bug/RFE is more than 2 years old and it didn't get enough attention so far, and is now flagged as pending close. Please review if it is still relevant and provide additional details/justification/patches if you believe it should get more attention for the next oVirt release.
Failed to verify that on rhvh with cockpit-260-1.el8.x86_64, "Remote over NFS" didn't work. Martin, any idea?
Asaf: This works in our testing. Can you please send a screenshot what exactly you did, and attach the journal?
(In reply to Martin Pitt from comment #25) > Asaf: This works in our testing. Can you please send a screenshot what > exactly you did, and attach the journal? Please refer the screenshot and log files in attachment.
Wei, from the screenshot and log it seems that 10.66.9.57:/home/wangwei/nfs/var/crash does not exist? Can you create it, or specify a non-default directory in the dialog? kdumpctl[174514]: kdump: Dump path "/tmp/mkdumprd.AY3cNl/target//var/crash/" does not exist in dump target "10.66.9.57:/home/wangwei/nfs" systemd[1]: tmp-mkdumprd.AY3cNl-target.mount: Succeeded. kdumpctl[174430]: kdump: mkdumprd: failed to make kdump initrd kdumpctl[174430]: kdump: Starting kdump: [FAILED] systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: kdump.service: Failed with result 'exit-code'. (Supposedly it mounts the remote NFS to /tmp/mkdumprd.AY3cNl/target/)
I found that the default value for the directory field is "/var/crash" and cannot be empty, if I don't have the path in the NFS, the operation fails with the following error: "Unable to apply settings: Error: systemd job RestartUnit ["kdump.service","replace"] failed with result failed" It works if we add "/" as a value in the directory field or create the directories in advance.
(In reply to Martin Pitt from comment #29) > Wei, from the screenshot and log it seems that > 10.66.9.57:/home/wangwei/nfs/var/crash does not exist? Can you create it, or > specify a non-default directory in the dialog? > > kdumpctl[174514]: kdump: Dump path "/tmp/mkdumprd.AY3cNl/target//var/crash/" > does not exist in dump target "10.66.9.57:/home/wangwei/nfs" > systemd[1]: tmp-mkdumprd.AY3cNl-target.mount: Succeeded. > kdumpctl[174430]: kdump: mkdumprd: failed to make kdump initrd > kdumpctl[174430]: kdump: Starting kdump: [FAILED] > systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE > systemd[1]: kdump.service: Failed with result 'exit-code'. > > (Supposedly it mounts the remote NFS to /tmp/mkdumprd.AY3cNl/target/) Sorry, the nfs server was destroyed yesterday. I changed it to an existed one. Attach the screenshot and log file.
> if I don't have the path in the NFS, the operation fails with the following error: > It works if we add "/" as a value in the directory field or create the directories in advance. Right, what I mentioned in comment #29. That's how kdump works (a bit unfortunately).
(In reply to Martin Pitt from comment #34) > > if I don't have the path in the NFS, the operation fails with the following error: > > It works if we add "/" as a value in the directory field or create the directories in advance. > > Right, what I mentioned in comment #29. That's how kdump works (a bit > unfortunately). Is it documented somewhere? because the error message is not clear.
It's kind of implied in `man kdump.conf`. When the service fails, you can get more information in the "more details.." link. We can improve that a little bit, to show kdump.service logs right on that page when it fails. If the functionality otherwise works for you, we can re-devote this bug report to that, or you file a new one. Thanks!
(In reply to Martin Pitt from comment #36) > If the functionality otherwise works for you, we can re-devote this bug > report to that, or you file a new one. Thanks! Opened a new bug - bug 2062297.
According to discussing with dev, change it to "VERIFIED"
This bugzilla is included in oVirt 4.5.0 release, published on April 20th 2022. Since the problem described in this bug report should be resolved in oVirt 4.5.0 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.