I have HP dv9000z series laptop with f8 test 3 x86_64 installed. 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) 03:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 01) Every time I boot I see: forcedeth device eth0 does not seem to be present,delaying.... and after that Bringing up interface eth14: Determining IP information for eth14... done. Eth14 ?? first it was eth1, every time I boot it's +1 ? This is my modprobe.conf alias eth0 forcedeth alias scsi_hostadapter libata alias scsi_hostadapter1 sata_nv alias scsi_hostadapter2 pata_amd alias eth1 forcedeth Why won't it work as etho? Dunno if this is related, but I also saw this bug when test 2 was released https://bugzilla.redhat.com/show_bug.cgi?id=290211
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the Fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug and will try and assist you in resolving it if I can. There hasn't been much activity on this bug for a while. Could you tell me if you are still having problems with the latest kernel? If the problem no longer exists then please close this bug or I'll do so in a few days if there is no additional information lodged.
Closing per previous comment. If you can provide the requested information, please feel free to re-open this bug.
Fedora 9 alpha, I still have this problem. Except now I have to manually setup network every time I log in. HP laptop + Linux = disaster
Created attachment 294322 [details] lspci -vvv
Created attachment 294323 [details] dmesg
Please take a look at this, it's really getting annoying to set up network manually every time I boot. On dmesg I can see: udev: renamed network interface eth0 to eth2 Every boot it renames one higher, why is that?
I noticed error on shutdown,something like: can't remove /etc/resolv.conf.predhclient.ethX X being the current number (changes on every boot)
Looking in your dmesg this doesn't look too promising: forcedeth 0000:00:14.0: Invalid Mac address detected: 00:00:00:00:00:00 forcedeth 0000:00:14.0: Please complain to your hardware vendor. Switching to a random MAC. forcedeth 0000:00:14.0: ifname eth0, PHY OUI 0x732 @ 1, addr 00:00:6c:cc:3c:12 forcedeth 0000:00:14.0: highdma pwrctl timirq gbit lnktim desc-v3 Not a lot that we can do about keeping things in the same order if the MAC address is changing with every boot.
Shit. Ok the ethernet is broken, I'm sending it for repair. Maybe I get lucky and all the other bugs I've seen are hardware related and goes away when they switch the motherboard. :)
OK, since the hsrdware is at fault, I'll close this NOTABUG.
I think this evaluation of the situation is not correct. This is a bug, but the bug is in the hardware firmware. It is not that the hardware is broken, it's the NIC card doesn't reliably produce a consistent MAC address. If you do a Google search on "MAC address 00:00:6C", you'll find a lot of people dealing with this issue with this vendor. What would be useful information is specific steps in the Redhat environment in how to have the boot-chain spoof the correct MAC address. For instance, this article explains it on another flavor of linux platform, but because Redhat has different system files different steps are necessary: How to fix invalid MAC address on Nforce MCP network controller http://www.besy.co.uk/debian/how_to_fix_invalid_mac_address_on_nforce_mcp_network_controllers -paul