Bug 717779

Summary: Reboot nfs test does not reliably grab an ip address causing the test to fail
Product: [Retired] Red Hat Hardware Certification Program Reporter: Gregg Shick <gregg.shick>
Component: Test Suite (tests)Assignee: Greg Nichols <gnichols>
Status: CLOSED ERRATA QA Contact: Guangze Bai <gbai>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.1CC: czhang, dwa, gbai, rlandry, ykun, yshao
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
In v7 1.3, reboot nfs test might fail to grab an IP address when kexec kernel is trying to dump vmcore to an NFS server due to link_delay value not set in kdump.conf. This issue has been fixed in v7 1.4, now kdump (originally reboot) test will set link_delay value to 60s to make sure kexec kernel can wait for enough time to obtain an IP address before dumping vmcore to NFS server. Note that if user has ever set link_delay value in kdump.conf, kdump test won't override it. So please make sure the value of link_delay is correct before running the test.
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-08 15:42:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
sosreport
none
kdump test patch setting link_delay to 60 sec if not present none

Description Gregg Shick 2011-06-29 20:24:26 UTC
Description of problem: Reboot nfs fails to grab an IP address from dhcp much more than it succeeds.  


Version-Release number of selected component (if applicable): RH 6.1 GA / v7-1-3-46


How reproducible: 75+% of the attempts


Steps to Reproduce:
1.Install RH6.1 x64
2.Install v71-3-46 testkit and supporting rpms
3.Execute v7 reboot nfs test. 
  
Actual results:
When it kicks out to the console screen where it should grab an IP and write the dump file to the remote test server, dhcp fails to acquire an address and the test fails.  

below is approximately the error message seen:

Mapping eth0 to eth0
Sending discovery (tries 4 times)
Unable to get DHCP address
Eth0 failed to come up.  

Expected results:

DHCP should work.

Additional info:

This is being tested on a DL385 G7.  All nics connected, all dhcp.  I see no dhcp lease issues outside of the kdump request.  

I attempted to set static on the nic, but it still tries using dhcp.

Comment 1 Gregg Shick 2011-06-30 15:35:53 UTC
I have added the link_delay=60 option to kdump.conf.  With this option, it appears to be grabbing an IP much more reliably.

Comment 2 Gregg Shick 2011-06-30 15:47:25 UTC
Created attachment 510707 [details]
sosreport

Comment 3 Gregg Shick 2011-07-07 16:11:06 UTC
We have retested this on a different system (360 G7, same broadcom 5709)on a separate and completely isolated network. Seeing the same failure to grab an IP.  link_delay 60 fixes the problem in this case as well.

Comment 4 Greg Nichols 2011-07-20 13:19:47 UTC
Created attachment 514004 [details]
kdump test patch setting link_delay to 60 sec if not present

if link_delay is already set, the kdump test will not change the setting.

Comment 10 Caspar Zhang 2011-10-21 14:23:55 UTC
    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:
In v7 1.3, reboot nfs test might fail to grab an IP address when kexec kernel is trying to dump vmcore to an NFS server due to link_delay value not set in kdump.conf. This issue has been fixed in v7 1.4, now kdump (originally reboot) test will set link_delay value to 60s to make sure kexec kernel can wait for enough time to obtain an IP address before dumping vmcore to NFS server. 

Note that if user has ever set link_delay value in kdump.conf, kdump test won't override it. So please make sure the value of link_delay is correct before running the test.

Comment 11 errata-xmlrpc 2011-11-08 15:42:26 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.

http://rhn.redhat.com/errata/RHBA-2011-1436.html

Comment 12 errata-xmlrpc 2011-11-08 18:31:14 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.

http://rhn.redhat.com/errata/RHBA-2011-1436.html