"Well, udev in this devel cycle has certainly been interesting! "
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
"Well, udev in this devel cycle has certainly been interesting! "
Hi,
I have been catching up on some of things that are floating on my TODO. Over looked this changelog entry;
Code:
Sun Jul 22 22:38:36 UTC 2012
Howdy! Lots of shiny stuff here, including the long awaited Xfce 4.10!
Thanks to Robby Workman for the initial set of build scripts, and lots
of testing (plus some very helpful notes about things such as the proper
build order). I'm calling this a beta (finally!), and it's really very
close to what we expect to release. Test away.
BTW, Mercury leaves retrograde on August 8th, position 01:26 Leo. ;-)
...
...
a/udev-182-x86_64-1.txz: Upgraded.
Well, udev in this devel cycle has certainly been interesting! A fair
number of odd bug reports have been coming in, and we hadn't really been
able to get a handle on the source of the issues. Quite some time ago
we started testing udev-182, and noticed that it caused some issues with
the persistent net and cd rules. There'd sometimes be two entries per
device, so a machine with a single Ethernet card might come up showing the
card as eth1, with two rules in 70-persistent-net.rules (eth0 and eth1).
We tested a lot of udev versions trying to determine where the problem
started, and it seemed to begin with version 176, the first one that
used libkmod rather than calling out to module-init-tools to load modules.
Asking upstream about it, they suggested that we just turn the generation
of persistent rules off. They'd already turned it off by default. "Make
'em make rules!" seemed to be the answer, and since I remember well why
the autogeneration of net and CD rules came about, I wasn't really happy
with that answer. After deploying the "safe" upgrade to 175, we got a
couple of reports of this same issue happening (though none of us could
reproduce the issue with 175). Robby ended up making some patches to
the rule writing scripts for udev-182 that were able to stop the doubling
up of rules, but the devices themselves would still be misnumbered on the
first boot without rules, and would then be correct after a reboot.
Last week I sat down determined to figure out where the race condition
was. After endless reboots with various tests, I got the idea to put my
network modules on the initrd and have it shell out so that I could take
a look at them. What I found was that the rules were generated correctly
on the initrd. Well, that was a surprise, but I must have had some kind
of hunch to even try a test like that. On another hunch, I ran
"pstree -c -p | grep udevd" on the running system. Heh. There it was.
We had been running two copies of udevd, and they were fighting it out.
At some point along the line, udevd was changed. It used to be that if
you tried to start a second copy it wouldn't start, and would exit with
status 1, and our rc.udev script relied on this behavior. Fixing the
problem was considerably easier than finding it... rworkman and I made
some changes in rc.udev to check if udevd was already running instead
of expecting it to check for itself. Another change was required to
cause it to write out rules if they didn't exist already, and then to
read them back in (otherwise optical symlinks were still missing on first
boot without rules). There's still one issue that was also present with
udev-175, which is that a hotplugged optical drive won't get symlinks
unless it has been in at boot and had rules generated for it then.
Otherwise, things are looking considerably better. Firmware is loading
correctly, rules are autogenerated properly again, and several devices
that were missing in /dev have returned.
So, there's the story. Maybe more than you really wanted to know. ;-)
Thanks to rworkman for his help on this. Please report any new problems.
And if anyone knows how to get symlinks working for a hotplugged optical
drive like they did in udev-165, a fix would be most appreciated.
I have just updated my -currrent 'ISO' and will be installing on a new Dell Laptop. Anyone notice these problems with 'udev'? I believe PV does have this problem corrected but would like to confirm from other Slackware -current users. I am wanting to do some testing with a newer Laptop. My laptop collection is getting large at this point in time. Just cannot bear to rid my babies from the collective.
Yeah, it's corrected for the most part but I've heard some hardware at random can have a hiccup or two working properly. The networking (especially the wireless which was very broken) is now working at normal levels.
I have yet to see any real broken hardware yet in my system at home, but for the most part after this last update I had no issues. Before it, and any wireless devices were next to useless due to the udev bug.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.