Bug 164913

Need an lspci for this machine... 

Some more info on this problem...

Anaconda install does not work via dhcp or by setting a static IP.  This we
knew.  But, if I do a cd install and then bring the network up after the install
it works fine.  

Also, if we turn spanning tree off on the port we can install via the network
with no problems.

So this definatly seems like an Anaconda bug to me.

I'll attach the lspci info as well

Created attachment 118872 [details]
lspci info

Reassigning to "anaconda" component based on comment #2.

Having spanning tree enabled _CAN NOT WORK_ without imposing delays of
approximately a minute on all users on all network bringups.  This is not
acceptable.  If you are using spanning tree, then portfast *MUST* be enabled on
the port.

Let me explain some more details since I don't know network details at this
level very well.

With portfast on Anaconda fails, with portfast off Anaconda succeeds. 
Using the same network port with another machine it works (portfast on).

I wonder if this is related to bug 167674, then.  Definitely sounds more like a
driver bug than instaler

Dumping back into Linville's lap.

I'm planning a forcedeth driver update for RHEL3.  The update includes the 
patch from bug 167674.  Test kernels are available here: 
 
   http://people.redhat.com/linville/kernels/rhel3/ 
 
Jeremy, will Bill be able to use my test kernels to get far enough w/ anaconda 
to know whether or not things are working?  Can you advise?  Thanks! 

Not without a tree -- the module will need to be loaded and as its in the initrd
and not the vmlinuz, that gets tricky.

Just tried installing with the tree Jeremy mentioned above.  I get these errors.

/tmp/forcedeth.o: unresolved symbol dev_activate
/tmp/forcedeth.o: unresolved symbol dev_deactivate
failed to insert /tmp/forcedeth.o

I'm terribly sorry.  You are the victim of a recently added (and apparently 
busted) patch.  I have revamped the patch and rebuilt.  I have new test 
kernels available now.  Thanks again! 

ummm..  I'm still getting the same error on boot.

These are the initrd.img and vmlinuz I'm using...

[root@rhts-results pxeboot]# ls -l
/mnt/porkchop/redhat/devel/katzj/i386/i386/images/pxeboot
total 3380
-rw-r--r--  6 root root 2544159 Sep 20 20:44 initrd.img
-rw-r--r--  2 root root     288 Sep 20 20:44 README
-rw-r--r--  6 root root  900757 Sep 20 20:44 vmlinuz

Apparently there was a problem w/ rebuilding Jeremy's tree.  So, your second 
test was actually the same kernel as before. :-( 
 
Hopefully Jeremy will get a chance to spin another tree for us before too 
long... :-) 

yeah.. I spoke to jeremy this morning..  last build he tried failed to generate
a vmlinuz because of the size.

Jeremy did build a new tree, he just didn't post anything here.

I tried that tree and it does load the driver now but I'm still stuck with no
dhcp working.  Here is the output from console 2:

* need to set up networking
* going to pick interface
* going to do getNetConfig
* waiting for link...
* 0 seconds.
* pump told us: No DHCP reply received
* waiting for link...
* 0 seconds.
* pump told us: No DHCP reply received

I tried to get an address twice.

I'm going to attach console3 output as a picture since its a lot of information.


I also assigned it its address statically and that allows me to go to the nfs
server page but it won't mount the nfs server, and pinging the static address
shows its not up.

Created attachment 119297 [details]
screenshot of console3

What does the "0 seconds" represent?  I hope it is waiting longer than that  
for the DHCP reply...?  
  
Why do we still use pump for the installer, anyway?  
  
Comment 23 suggests that the forcedeth driver is not working for you at all.   
Is that so?  Wasn't it working previously at least "if we turn spanning tree 
off on the port we can install via the network with no problems"? 

0 seconds is the amount of time that we waited for the ethernet adapter to
report that it had a valid link (via ethtool or mii, whichever is supported).

We still use pump in the installer because there is _NOTHING_ else which is a
library and a library is pretty much required for the statically linked, no
external binaries loader :-)

I've tried the following installs:

nightly/rawhide-20050927/i386
nightly/RHEL4-U2-re0926.nightly/x86_64/x86_64-AS
jeremy's rhel3 build above (i386)

All of the above fail to get dhcp.

I have rhel4 x86_64 installed on the machine (When it was in jeff burkes cube it
installed over the network fine).  When I boot that distro up it brings the
network up correctly everytime it boots.  This is using the same network cable
and port which fails for the above installs.

If networking works after install it should work for install.

Comment #25 - if we turn off fast port then anaconda brings the interface up. 
Which seems odd since Jeremy states it needs to be on for spanning tree.

That sounds more like a portfast problem to me.  I would have to agree with 
Jeremy, turning portfast off as a solution sounds counter-intuitive. 
 
Do you have access to the statistics for that individual switch port?  Can you 
observe those statistics while anaconda attempts to bring-up the port?  I'd be 
interested to know if they are getting through to the port.  Similarly, 
watching for the requests at the server might be useful as well. 

Closed due to lack of response.  Please reopen when the requested information 
becomes available...thanks!