Yes, we committed to supporting this for HP.  It's a very hot platform for them,
and forcedeth is the built-in ethernet.

I did some digging and I don't believe this is an installer issue, not a kernel
issue.  Note that it loads the driver without error.  In fact, if I boot the
*same* installer to rescue mode it sees the ethernet controller just fine.

I added a PCI ethernet controller to my Viper and tried to boot to an NFS
install.  At the anaconda welcome screenI switched to the bash console and
attempted to bring up the forcedeth (eth0).  I got the following:

~/bin/sh-3.00# pump -i eth0
Traceback (most recent call last):
  File "/usr/bin/pump", line 30, in ?
    ns = isys.pumpNetDevice(iface, None)
  File "/usr/lib/anaconda/isys.py", line  564, in pumpNetDevice
    return _isys.pumpnetdevice(device)
SystemError: (17, 'File exists')
~/bin/sh-3.00#

In any case, the fact that the device is there and comes up in rescue mode makes
me believe this is not a kernel issue...

> I did some digging and I don't believe this is an installer issue, not a 
> kernel issue.  

So do I. 


> Note that it loads the driver without error.  In fact, if I boot the
> *same* installer to rescue mode it sees the ethernet controller just fine.

Yes, I can reproduce this behavior ... are there different modules of the
installer activated during install and rescue mode.

Additional Info:

The ethernet controller is recognized as bridge not as ethernet controller

$ lspci
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:01.0 ISA bridge: nVidia Corporation: Unknown device 0051 (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio
Controller (rev a2)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev a2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
05:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000
Controller (PHY/Link)
0a:00.0 VGA compatible controller: nVidia Corporation NV45GL [Quadro FX 3400]
(rev a2)
61:06.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X
Fusion-MPT Dual Ultra320 SCSI (rev 07)
61:06.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X
Fusion-MPT Dual Ultra320 SCSI (rev 07)
81:00.0 VGA compatible controller: nVidia Corporation NV45GL [Quadro FX 3400]
(rev a2)

will be fixed in U1.

Same problem with Fedora Core 5 test2 on x86_64: cannot perform HTTP network
installation using forcedeth driver, booting from either boot.iso or rescue.iso
CD-ROMs.  Log screens show:
   loaded forcedeth from /modules/modules.cgz
   inserted /tmp/forcedeth.ko
but the installer asks for the operator to select the driver (not found in the
list) or to use a Driver Disk.

Under RHEL4u2, lspci shows the nVidia Corporation CK8S Ethernet Controller
(10de:00df rev a2, part of the nVidia nForce3-250 chipset) as a communications
device.  Under FC5test1, lspci shows it as a Bridge, much like Comment #5. 
Ethernet works under any of {RHEL4u2, FC4, FC5test1} after installation using
CD-ROM or DVD-ROM.

The FC5test2 installer is anaconda-10.91.6.

The requisite quirk is not in the upstream (or FC5) kernels.  I can't find any 
record of it being discussed, but I vaguely recalled disinterest in this sort 
of patch upstream.  "Fix the hardware/BIOS" is usually the response to such 
things. 
 
At any rate, please open an FC5 bug if you would like to pursue this.  
However, I'm not at all confident that this patch will be accepted upstream... 
 
http://people.redhat.com/linville/kernels/rhel4/patches/jwltest-forcedeth-quirk.patch 

I can confirm this bug is still present in RHEL4 U3! 

Same behaviour as described by Udo when trying a network installation on an
nForce4 system.

The good news is, that I can't reproduce it with Fedora Core 5, here the network
card comes up. 

Problem is occuring on both x86_64 and i386 architecture. 

Can you boot an install CD in rescue mode, do a "lspci", and tell us what the
Ethernet card shows up as?

Sorry for the delay, but the machine went out of my focus for a while. Here is
the output of lspci taken from an installed RHEL4 (if you install from CDROM the
installed system works):

# lspci
00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2)
00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2)
00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2)
00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2)
00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2)
00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2)
00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:05.0 VGA compatible controller: nVidia Corporation C51 PCI Express Bridge
(rev a2)
00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev f1)
00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev f1)
00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev f1)
00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)
00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)
00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)
# lspci -s 14 -vv -n
00:14.0 Class 0680: 10de:0269 (rev a3)
        Subsystem: 1734:10c6
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0 (250ns min, 5000ns max)
        Interrupt: pin A routed to IRQ 233
        Region 0: Memory at f2207000 (32-bit, non-prefetchable) [size=4K]
        Region 1: I/O ports at 8c60 [size=8]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable+ DSel=0 DScale=0 PME-

The Classcode for the device 14 is "bridge" and not "network".

FYI: The FSC ESPRIMO E5615 and P5615 got a BIOS option where the customer can
chose if the NIC is operating as a network card or a bridge. By setting this
option to "network card" we can solve the problem. 

This issue seems to be apparent on all nvidia nForce 430 and 410 chipset boards.