Bug 324891 - forcedeth device eth0 does not seem to be present
forcedeth device eth0 does not seem to be present
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-10-09 10:01 EDT by Riku Seppala
Modified: 2009-09-17 13:49 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-15 09:56:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
lspci -vvv (28.07 KB, text/plain)
2008-02-08 03:46 EST, Riku Seppala
no flags Details
dmesg (38.98 KB, text/plain)
2008-02-08 03:47 EST, Riku Seppala
no flags Details

  None (edit)
Description Riku Seppala 2007-10-09 10:01:01 EDT
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

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
Comment 1 Jon Stanley 2007-12-30 01:21:08 EST

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.


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.
Comment 2 Jon Stanley 2008-01-07 19:01:17 EST
Closing per previous comment.  If you can provide the requested information,
please feel free to re-open this bug.
Comment 3 Riku Seppala 2008-02-06 10:51:59 EST
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
Comment 4 Riku Seppala 2008-02-08 03:46:34 EST
Created attachment 294322 [details]
lspci -vvv
Comment 5 Riku Seppala 2008-02-08 03:47:31 EST
Created attachment 294323 [details]
Comment 6 Riku Seppala 2008-02-08 03:54:49 EST
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?
Comment 7 Riku Seppala 2008-02-14 17:09:03 EST
I noticed error on shutdown,something like: 

can't remove /etc/resolv.conf.predhclient.ethX

X being the current number (changes on every boot)
Comment 8 Jon Stanley 2008-02-14 19:37:53 EST
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.
Comment 9 Riku Seppala 2008-02-15 07:52:50 EST
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. :)
Comment 10 Jon Stanley 2008-02-15 09:56:53 EST
OK, since the hsrdware is at fault, I'll close this NOTABUG.
Comment 11 plinhardt 2009-09-17 13:49:25 EDT
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


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