Bug 160797 - Install fails; dhcp reply not recognized
Summary: Install fails; dhcp reply not recognized
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-17 11:32 UTC by Paul Tap
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-11-01 19:01:44 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
sysreport for IBM HS20 Blade - FC4 (215.57 KB, application/x-bzip)
2005-07-11 18:07 UTC, Paul Tap
no flags Details

Description Paul Tap 2005-06-17 11:32:11 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1

Description of problem:
I'm trying to install FC4 on an IBM HS20 Bladeserver. I'm doing a network install but the network connecion doesn't come up. The NIC is a broadcom, using the tg3 driver.
On the DHCP I can see the incoming request and the offer made, but the machine says it did not get an offer back. Hard setting the IP address gets me into the next screen, but then the installation server can't be found/contacted, so the network link is not ok either.
Installing RH EL4 doesn't have this problem so it's not an hardware issue, but in the installer.
I will try an PXE install as a workaround an maybe to pin down the problem a bit more.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Install FC4 using the boot.iso CD, boot options: linux nousbstorage askmethod
2. Press enter on all questions and select either eth0/eth1 to use on install
3. Choose DHCP (or fixed IP) for configuration
4a. The DHCP offer fails an returns you to the same screen
4b. The fixed IP gets you into the server identification screen but fails after this; unable to find the server
  

Actual Results:  Installation stops due to lack of network connections

Expected Results:  Networking should be up on the selected NIC and the installation server should have been found.

Additional info:

Comment 1 Paul Tap 2005-06-21 06:04:34 UTC
I've now succesfuly installed FC4 on an IBM blade (HS20) and all NICs are
working ok. So the problem is related to the installation (maybe even the
boot.iso) only.
I had to do a harddisk install since installing from CD doesn't work due to the
fact that it's usb based and only works booting with "linux nousbstorage".
I haven't found time to try the PXE install since I will have to change my DHCP
configuration. I may also try an install via disk 1, to see whether it's the
boot.iso or "all" iso images.

Comment 2 Paul Tap 2005-06-21 06:05:55 UTC
Sorry for making it a "pump" issue at first, since it isn't. As I already
mentioned it also happens without DHCP. I just got confused by all the options
on entry.

Comment 3 John W. Linville 2005-07-11 14:04:28 UTC
Please attach the results of running "sysreport"...thanks! 

Comment 4 Paul Tap 2005-07-11 18:07:53 UTC
Created attachment 116612 [details]
sysreport for IBM HS20 Blade - FC4

Installation is "minimal" plus Xen stuff. Sysreport run on Domain0.

Comment 5 John W. Linville 2005-08-18 15:14:37 UTC
Is there any chance that you have STP (i.e. 802.1d spanning tree) enabled on 
the switch port connected to your HS20?  That can introduce a delay long 
enough to cause network installations to fail. 

Comment 6 Paul Tap 2005-08-18 16:43:38 UTC
As far as I know, Spanning Tree is disabled (both switches have been reset to
factory default before installation of the Bladecenter in the datacenter). Also,
network installs with FC3 and CentOS 4 work without a problem.

Comment 7 John W. Linville 2005-09-09 14:12:22 UTC
Should check the switches for STP just to be sure -- many of the switching 
products I worked on in the past would default to having STP enabled on all 
ports as a guard against carelessly creating bridging loops. 
 
Beyond that, I would also suggest disabling auto-negotiation on that device, 
forcing the link to 1000/Full or whatever is appropriate for your network. 
 
For good measure, I would also suggest passing ethool="speed 1000 duplex 
full" (modified as appropriate for you network) on the kernel command line 
when booting the installer.  This should cause anaconda to force the link 
configuration at its end as well. 
 
Please try all of the above and post the results...thanks! 

Comment 8 Paul Tap 2005-09-19 07:12:58 UTC
I hope to have time to perform the requested tests this week. Since the system
is not "at my desk" but in a datacenter 40 km away it's not a 10 min. thing.
Besides that, one of the blades is running a production environment so I'm
restricted in what I can do with respect to changing settings etc. 
I was able to do a quick "reference" test last week and proved that for instance
a network install (incl. DHCP based IP) is no problem with CentOS 3.5. I had
similar results in the past with Fedora 3.
I'll give you updated results asap.

Comment 9 John W. Linville 2005-11-01 19:01:44 UTC
Closed due to lack of response.  Please reopen when the requested information 
becomes available...thanks! 

Comment 10 Ben Webb 2005-11-02 23:18:01 UTC
We're having similar problems on our Bladeservers. The installer will start up
(but only provided 'nousbstorage' is passed to the kernel) but cannot get an IP
address, and if one is manually assigned, the network is still nonfunctional.
RedHat 9 installed on the same nodes with no problems.

STP was enabled by default on our switch, so I disabled that, but that has not
fixed the problem.

eth0 is reported as 1000/full by the installer, so this appears to be working
correctly.

Comment 11 John W. Linville 2005-11-03 18:37:47 UTC
Ben, do the NICs work post-install? 
 
Have you tried booting with "acpi=off" or "acpi=noirq"? 

Comment 12 Ben Webb 2005-11-04 01:42:05 UTC
Yes, the NICs work just fine after installation (I tried a hard disk install).
This is using the 2.6.12-1.1456_FC4smp kernel.

Booting the installer with either "acpi=off" or "acpi=noirq" also allows it to
get an IP address, so this appears to fix the problem for us.


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