Posted 2/28/2008
Here
is an answer to a problem on the Compaq model F750US laptop having a
flaky MAC address. Linux complains on boot about the MAC address not
being valid. Linux automatically assigns then a random valid MAC
address on boot which is different each time you boot. This causes the
ethernet node number to change and assigns a new node to it. Since
the last one was remembered in the /etc/network/interfaces file, the
next one is allocated and causes eth0 to change to eth1, then to
eth2,.. etc. This causes the system default settings to be assigned to
the new devuce node which does not allow the knetworkmanager to work
properly. This is a hardware problem.
The work around was reported back in October 2007 on the Debian forum at:
http://forums.debian.net/viewtopic.php?p=107155
This was written by Dave Hall Feb 10, 2008 and you may find the rest of his article at:
http://davehall.com.au/blog/dave/2008/02/10/flakey-bios-gigabyte-ga-m68sm-s2l-makes-mac-address-change-reboot
Flakey BIOS in Gigabyte GA-M68SM-S2L Makes MAC Address Change on Reboot
Over
the weekend I have been setting my new Mythbuntu pair, a split. back
end and front end. Everything has gone pretty smoothly.
One
issue I did hit was the onboard NIC on my Gigabyte GA-M68SM-S2L
motherboard despite what the specs say it is a "nVidia Corporation
Unknown device 054c (rev a2)" which uses the forcedeth driver.
Everytime I rebooted the box the NIC would increment its interface
number - eth0, eth1 ... eth6 and so on. Changing the "Smart LAN"
setting in the BIOS from auto to disabled just disables the NIC, not
what I wanted.
After
googling I discovered that others had experienced similar problems with
ASUS boards with nVidia NICs, changing their MAC addresses. Looks like
Gigabyte (and ASUS) have been shipping invalid MAC addresses on some of
their boards, and forcedeth isn't happy about it, so it just generates
a new (valid yet) random MAC address.
With
a little help from sysfs I was able to hack my udev config so it all
works now. My /etc/udev/rules.d/70-persistent-net.rules looks like
SUBSYSTEM=="net", DRIVERS=="forcedeth", ATTRS{vendor}=="0x10de",
➥ ATTRS{device}=="0x054c", NAME="eth0"
I grabbed the output of "cat /sys/class/net/ethX/device/{device,vendor}" to populate the relevant ATTRS entries above.
I am not sure what you do if you have 2 onboard NICs and they are both broken.
Gigabyte (and ASUS) or nVidia should look at fixing their broken kit to save people from wasting time on this.
by Dave at February 10, 2008 12:09 PM
This trick does work for the Compaq laptop. The vendor code and device are the same.
See my other wrtings on udev rules.
|
|
