Hi On Freitag, 25. Juli 2008, you wrote: > On Jul 25, Stefan Lippers-Hollmann <[EMAIL PROTECTED]> wrote: > > > > all_interfaces is broken and should not be used anyway, try raising the > > > logging level to debug with udevadm and then generate a real event: > > > > > > echo add > /sys/class/net/eth0/uevent > > > > For testing, I have removed /etc/udev/rules.d/70-persistent-net.rules, > > which was renamed properly from /etc/udev/rules.d/z25_persistent-net.rules > > by upgrading to udev 0.124-*, and rebooted it's contents were:
I'm sorry about this, but I still have serious problems to parse what kind
of information you are really looking for - given that I never really had
to debug udev itself.
> Why do you have to make my life difficult by second guessing me?
> This is not what I asked for.
<off topic explanation>
If you refer to deleting /etc/udev/rules.d/70-persistent-net.rules, again
I'm just guessing and probably not very good about it, the reason for that
simply is that I observed udev choking way too often with incomplete
*persistent-net.rules files when kernel modules are changing below udev's
radar (bcm43xx --> b43, RaLink legacy --> rt2x00,
zd1211rw (ieee80211_softmac) --> zd1211rw (mac80211)) - and, like expected,
I do experience the very same issue again, with
/etc/udev/rules.d/70-persistent-net.rules restored from a backup
(identical to the one posted in the previous mail):
$ /sbin/ifconfig -a | grep ^[a-z]
eth0 Link encap:Ethernet Hardware Adresse 00:0f:ea:e9:73:86
eth1 Link encap:Ethernet Hardware Adresse 00:0f:ea:e9:73:88
lo Link encap:Lokale Schleife
wlan0 Link encap:Ethernet Hardware Adresse 00:0e:8e:07:36:55
wlan1_rename Link encap:Ethernet Hardware Adresse 00:14:85:b2:42:ad
wmaster0 Link encap:UNSPEC Hardware Adresse
00-0E-8E-07-36-55-00-00-00-00-00-00-00-00-00-00
wmaster1 Link encap:UNSPEC Hardware Adresse
00-14-85-B2-42-AD-00-00-00-00-00-00-00-00-00-00
Therefore I wanted to avoid problems like this, where zd1211rw registers
"wlan0" and drives the renaming rules into a race which leaves wlan1_rename
(which should be wlan0, referring to the udev rule) unuseable and force
/etc/udev/rules.d/75-persistent-net-generator.rules to start from scratch
(which I consider to be pretty normal operations after changing network
devices, where these, unrelated, problems are pretty much the norm with
udev, independent of the distribution).
</off topic explantion>
But back on topic of investigating why 75-persistent-net-generator.rules
does not generate new- or append information for new interfaces to
existing, or not existing, 70-persistent-net.rules.
What exactly would you like me to test?
echo add > /sys/class/net/eth0/uevent
doesn't seem to do anything on its own and eth0 is an onboard forcedeth
driven ethernet card, where I simply don't see any chance of triggering or
catching "real [udev] events" (sorry, but I fail to parse what this is
supposed to be) udev events, I could do this with the USB wlan device
(zd1211rw) - just that /sys/class/net/wlan0/uevent only gets created after
the device has been plugged in - so are you looking for an unplug/ replug
log, using "udevadm monitor" with an existing, but incomplete (lacking
information about the new zd1211rw device)
75-persistent-net-generator.rules?
Please give me a few hints what you are looking for, both in terms of
test environment (PCI vs. USB device, 70-persistent-net.rules missing/
incomplete/ manually edited to cover all 4 devices) and the tools whose
output you're looking for ("udevadm monitor", "udevadm test <device>",
"udevadm info -a -p <sysfs path to device>", syslog, a combination thereof
or something I simply don't know about yet).
My, 100% reproducable (on 11 amd64/ i386 systems and on a freshly
(c)debootstrapped system in virtualbox-ose), observation just is, that new
interfaces aren't added to an existing 70-persistent-net.rules,
respectively that it doesn't get (re-)created from scratch, if it's
missing - while, with the same level of reproducability, udev 0.114-2
manages this just fine and ensures a stable network interface enumeration
(under "ordinary" circumstances at least). I am certainly willing to
create any test environment that would ease up this debugging, just tell me
what you expect me to do.
Regards
Stefan Lippers-Hollmann
signature.asc
Description: This is a digitally signed message part.
