From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0 The ethernet card (an ne2000 compatible card) didn't work after a complete install. Comparison with log files saved from Redhat6.2 suggests the line "alias eth0 ne" was missing from /etc/modules.conf. Adding this line fixed the problem. Reproducible: Didn't try
did you ftp/http install?
Yes, I installed using ftp (without problems once I had found the drivers disk).
We (Red Hat) should really fix this before next release
This looks like Bug# 25774.
There are certainly similarities with bug 25774. I do have an ISA card (I am not sure of the make), but in my case PnP is turned off (due to other OSs on the same machine), and it has a fixed io setting which I entered during install (io=0x300). Also I used dhcp throughout (atlhough the IP address is actually static). The modules.conf file had only two lines after install "options ne io=0x300" and "alias parport_lowlevel parport_pc".
Brock do we have any ne2000 like cards to test. This sounds like a kernel issue.
I have one of these cards, and it works fine here with 'linux expert' install and a driver disk with an FTP installation. I think the thing here is that you always used to have to install in expert mode to get the card detected (the driver used to be on the main disk). So I just did that, knowing that I wanted my network card to work.
Respectfully, I would disagree that this is a kernel issue, although I think it may be related. Look at what we know: 1) Adding the missing "alias eth0 ne" line fixes the problem; 2) The Expert install with driver disk works properly; 3) A non-PnP card has the same issue; 4) A normal install produces a half-written /etc/modules.conf -- the options line is there, but the alias line is not, even on a card that was explicitly configured. My SWAG would be that the installer isn't writing the modules.conf file properly in this case, with the cause of that behavior being unknown. It would make more sense to me if nothing was written to the /etc/modules.conf, but the interface was configured during installation.
This goes for the following cards using both a text install as well as graphical install. realtek 8139 Manually updating /etc/modules.conf is the fix
If I understand correctly, in a non-expert install you are prompted to select the NIC type because kudzu cannot detect it. You enter the proper type, the install works, and then on reboot the modules.conf is incorrect so networking fails. If you do a expert install, specify the card, yada yada, then reboot, it works fine?
I had a blank partition just big enough for a minimal install, so I have been doing some testing. In my tests even an expert install dosen't necessarily add the "alias eth0 ne" line, which was the case when I didn't try to add any extra drivers when given the option. If I did try to add extra drivers from the drivers disk, the ne1000/2000 compatible option wasn't listed, but when I pressed the back button, it had auto-detected the card, and after the install the "alias eth0 ne" had been added. It is almost as if it needed to be reminded what drivers it knew about. Incidentally, I don't know if it is relevant, but my PC only has 32Mb memory.
With the expert install there is an extra screen: the 'Do you want to add extra device drivers' one, with 'NE2000' already there. I think that's the difference.
The problem is that for ftp/http/hd installs, the install forgets about drivers it loads at the beginning (saves real space on the disk), so it also forgets to write those items to /etc/modules.conf (for the same reason it doesn't write things like nfs.o and sunrpc.o out; ne.o and 8390.o look the same to it then; it doesn't even know ne.o is a networking module in fact). It doesn't affect pci cards because kudzu puts things back for us using the same probing code, but it does affect cards that aren't probed. This is a pretty big fix.
I found a nice fix for this.