Package: udev
Version: 164-3
I (like some other people) am having a hell of a time trying to get
a Squeeze upgrade working. I've been trying to read up on and figuring out
during the last 4 hours why 70-persistent-net.rules does
a) not get processed any more (since Squeeze upgrade - obviously was
working properly previously given its effects)
b) not get created any more on boot, if removed, no matter whichever
things are being attempted
Result was loss of routing for the main router
due to mismatching interface names in /etc/network/interfaces...
Since udev, due to being a central part of the system,
has a rather abnormally large list of dependency requirements
which may easily cause problems, IMHO the udevd start script itself should best
invoke a checking helper function/script to verify that all/most
currently required (as listed by doc...README.gz) CONFIG_* options
are available (and ideally there would also be a note requesting
the two configuration lists/checks in script/README to be kept in sync).
While the current init script version does check for some prominent
environment setup items, at least on my system given my custom-built
kernels I violated README.gz items CONFIG_SYSFS_DEPRECATED (ouch),
CONFIG_TMPFS_POSIX_ACL and CONFIG_BLK_DEV_BSG.
Despite all this, 3 udevd processes got _successfully_ launched,
and even low-level analysis steps don't show many bumps
other than a potentially(!) relevant ECONNREFUSED on strace udevd
(and udev.conf log level debug doesn't seem to do much either).
I tried to have persistent-net rule created manually via
for NIC in /sys/class/net/eth0; do INTERFACE=${NIC##*/}; echo $INTERFACE;
udevadm trigger --action=add $NIC; done
(supplying both trigger and test arguments)
Also, trying to log env and a start message in /lib/udev/write_net_rules was
unsuccessful, too, more or less proving that that script never got started
at all.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572951
sounded somewhat relevant, however that bug was closed quite early
unfortunately.
https://bugzilla.redhat.com/show_bug.cgi?id=557771 might be related,
too.
All in all there's too much silent failure occurring, there should be
additional and more verbose checks against an incomplete/wrong setup,
ideally both in init script and udevadm invocation processing.
Especially since IMHO there's quite a lot of (read: too much?)
compatibility pressure between kernel and udev configuration/versioning.
I'll now revert to installing a standard Debian kernel with currently
fashionable settings ;)
(and make oldconfig:ing further custom kernels based on a _current_ .config);
this should hopefully correct these problems.
Thanks,
Andreas Mohr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
