Bug 823646 - Revert delay on kdump bridge
Revert delay on kdump bridge
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ovirt-node (Show other bugs)
6.4
Unspecified Unspecified
unspecified Severity high
: beta
: ---
Assigned To: Joey Boggs
Virtualization Bugs
:
Depends On: 812865 817157
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-21 15:14 EDT by Mike Burns
Modified: 2016-04-26 09:48 EDT (History)
11 users (show)

See Also:
Fixed In Version: ovirt-node-2.5.0-3.el6
Doc Type: Bug Fix
Doc Text:
After kdump was configured with a remote NFS server, the dump file was not created in the NFS directory, so kdump did not work. The link_delay option, which was introduced to fix a prior issue, has now been removed, so kdump on a biosdevname interface with a bridge works as expected.
Story Points: ---
Clone Of: 812865
Environment:
Last Closed: 2013-02-28 11:31:03 EST
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)

  None (edit)
Description Mike Burns 2012-05-21 15:14:57 EDT
+++ This bug was initially created as a clone of Bug #812865 +++

Original fix for the below problem was to add Delay=60 to the kdump bridge.  This can be reverted when bug 817157 is fixed.



Description of problem:
 Kdump doesn't work after configure the remote nfs server


 Version-Release number of selected component (if applicable):
 rhev-hypervisor6-6.3-20120411.1

 How reproducible:
 100%

 Steps to Reproduce:
 1. Install rhevh on local host
 2. Configure network
 3. Scroll down to Kernel Dump, choose setup nfs configuration
 4. Enter the nfs server address, and confirm the input address;[attachment RemoteNFS.png]
 5. Change to shell mode, and input "echo c > /proc/sysrq-trigger", to make the system coredump;
 6. After the system reboot, check the dump file on the remote nfs input before.

 Actual results:
 There is folder nfs:/path/var/crash in the nfs directory.
 But there is no dump file named with the dump time.
 [attachment NoDumpFile.png]

 Expected results:
 There is dump file named with the dump time in the nfs:/path/var/crash.

 Additional info:
 This a regression test.
Comment 1 Mike Burns 2012-05-21 15:18:55 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Without the fix to bug 817157, kdump on a biosdevname interface with a bridge will not function correctly.
Comment 2 RHEL Product and Program Management 2012-07-10 04:22:56 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 3 RHEL Product and Program Management 2012-07-10 21:48:46 EDT
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Comment 4 Mike Burns 2012-07-13 16:17:47 EDT
delay on bridge is not needed,  bug 817157 was fixed in 6.3 GA.
Comment 7 Ying Cui 2012-11-05 03:03:21 EST
Verified this bug on build rhev-hypervisor6-6.4-20121031.0.el6, kdump on a biosdevname interface with a bridge works good after configure the remote nfs server.

Test steps:
 1. Install rhevh on local host
 2. Configure network(biosdevname interface with a bridge)
 3. Scroll down to Kernel Dump, choose setup nfs configuration
 4. Enter the nfs server address, and confirm the input address;
 5. Change to shell mode, and input "echo c > /proc/sysrq-trigger", to make the system coredump;
 6. After the system reboot, check the dump file on the remote nfs input before.

Test results:
There is dump file named with the dump time in the nfs:/path/var/crash.

So the bug is fixed, change bug status to VERIFIED.
Comment 10 errata-xmlrpc 2013-02-28 11:31:03 EST
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.

http://rhn.redhat.com/errata/RHBA-2013-0556.html

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