On Tue, May 20, 2008 at 4:49 PM, Gus Wirth <[EMAIL PROTECTED]> wrote:
> Robert Donovan wrote:
>>
>> Just when I thought I had gotten udev working right. I just upgraded
>> to udev-118-1.fc8 under the 2.6.24.7-92.fc8 kernel. I have two network
>> interfaces on my box, and they were named eth0 and eth1 as per normal,
>> before I updated. After the update, none of my VMWare virtual machines
>> started without a network error saying that the bridged network device
>> on vmnet0 was down, and the iptables started dropping all packets.
>>
>> Checking /etc/sysconfig/network-scripts revealed the ifcfg-eth0 had
>> been renamed ifcfg-eth0.bak and two new files, named ifcfg-eth1 and
>> ifcfg-eth2, had been written in it's place. Checking
>> /etc/udev/rules.d/70-persistent-net.rules showed that the interface
>> names had been incremented by one. I tried removing the file and
>> rebooting, but no joy. Same problem. Tried adding a line in
>> 70-persistent-net.rules: SUBSYSTEM=="net", DRIVERS=="forcedeth",
>> NAME="eth0" This didn't work, because restarting udev just caused the
>> file to be rewritten by the /lib/udev/write net rules script. I got
>> the network working again by manually changing all the references it
>> eth0 in iptables to eth1, but doing this in VMWare is a pain. Before I
>> go poking at the udev scripts any more, does anyone have a fix already
>> concocted for this?
- - snip - -
> Part of the problem is that there is no guaranteed order to device
> assignment in the kernel. Module load order,
- - snip - -
> One thing I notice in your persistent rules is the lack of an address
> attribute for naming. For example, in my system I have a built-in 10/100
> ethernet port and an add-in PCI card for gigabit ethernet. Left on its own
> the system wants to make the built-in port eth0, but that's not what I want.
> So I use the persistent rules to force re-naming. My 70-persistent-net.rules
> file looks like this:
>
> ---------------------------------------
>
- - comments snipped - -
>
> # Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:14:2a:46:65:b7", ATTR{type}=="1", NAME="eth1"
>
>
> # PCI device 0x10ec:0x8169 (r8169)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:40:f4:eb:c6:d9", ATTR{type}=="1", NAME="eth0"
>
>
> ---------------------------------------
>
> The parts that I swapped around are the address and name. This forces a
> device with a certain MAC address to have a specified name.
Since this was an experimental box, I decided to do some
experimenting. I reinstalled fedora 8 with the stock kernel and the
stock udev version that come out of the box. the
70-persistent-net.rules file showed this right after the install:
------------------------------------------
# Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit
Ethernet controller
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:19:d1:af:41:f2", ATTR{type}=="1", NAME="eth1"
# Broadcom Corporation NetXtreme BCM5705 Gigabit Ethernet
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:10:18:0d:60:01", ATTR{type}=="1", NAME="eth0"
------------------------------------------
/sbin/ifconfig |grep hwaddr for eth0 showed 00:10:18:0d:60:01, which
is correct for eth0. .
I then updated the kernel to 2.6.24.7-92.fc8 and rebooted to it.
70-persistent-net.rules was unchanged. So far, so good. Could just
have gotten lucky with the kernel identifying the hardware as Gus
suggests.
I opened a separate command shell window and ran udevmonitor. I left
it running with the terminal window open, and installed VMWare 1.0.5.
During the last part of the install, udevmonitor showed two new
devices being added and then immediately removed. The same thing
happened, showing one device added and immediately removed when I
created each of two virtual machines. In both cases,
70-persistent-net.rules remained unchanged. All the virtual machines
booted with no errors and were able to get to the internet. All the
virtual machines are bridged to eth0 on vmnet0.
I updated udev to udev-118-1.fc8, and neither the host, nor any of the
virtual machines could get to the Internet. The
70-persistent-net.rules file now read:
------------------------------------------
# Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit
Ethernet controller
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:19:d1:af:41:f2", ATTR{type}=="1", NAME="eth2"
# Broadcom Corporation NetXtreme BCM5705 Gigabit Ethernet
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:10:18:0d:60:01", ATTR{type}=="1", NAME="eth1"
------------------------------------------
and all the symptoms I described above returned, no Internet,
"interface down" warnings upon starting up the virtual machines.
I removed the 70-persistent-net.rules file, and rebooted the machine.
The newly generated 70-persistent-net.rules file was identical to that
above, showing eth1 and eth2 rather than eth0 and eth1.
Renaming the interfaces for their respective MAC addresses and
rewriting the respective ifcfg- files in
/etc/sysconfig/network-scripts fixed the problem, but I'm still at a
loss as to why it's happening.
I, therefore, still maintain that udev has lost it's mind.
Robert Donovan
--
KPLUG-List@kernel-panic.org
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
