LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   "Well, udev in this devel cycle has certainly been interesting! " (http://www.linuxquestions.org/questions/slackware-14/well-udev-in-this-devel-cycle-has-certainly-been-interesting-4175420333/)

onebuck 08-04-2012 09:29 AM

"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. :)

ReaperX7 08-05-2012 06:49 AM

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.

hitest 08-05-2012 10:03 AM

My -current box is working just fine. I just finished updating it this morning after getting back from holidays. :)


All times are GMT -5. The time now is 02:45 PM.