Hi Alan, On Monday, 12. September 2011 17:17:37 Alan Mackenzie wrote: > Hi, Michael. > > On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote: > > Hi Alan, > > > > On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote: > > > Hope nobody minds me starting a new thread with an accurate name. > > > > > > Which version of udev is it that has this nauseating feature of > > > needing > > > /usr loaded to boot? > > > > > > Somewhere in that version's source will be several (or lots of) > > > "/usr". > > > Just how difficult is it going to be to replace "/usr/bin" with > > > "/bin" > > > throughout the source? > > > > you misunderstood something. udev is able to run arbitrary scripts. Some > > of those scripts are located in /usr/* or need something there. I doubt > > you will find references to /usr in the udev-sources. > > Well, I'm a hacker. udev is free source, therefore fair game. I don't > intend to put up with this nonsense without a fight. As far as I can > make out, this is just one guy, Kay Sievers, who's on a power trip. Are > there any indications at all that he actually talked to anybody in the > wide world before making such a far reaching decision? > On my current system, udev (164-r2) works without an earlily loaded /usr. > Seemingly, later versions don't. That was why I was asking for somebody > to identify one of these later versions for me.
it works for you, because your udev-rules need nothing from /usr/* It's *not* udev requiring /usr, it's the scripts triggered by the rules. > > > udev is part of the kernel. > > > > No. udev is usperspace. > > OK, udev is in userspace, _very_ _close_ to the kernel. ;-) > > > > How come the kernel hackers aren't up in arms about this as much as > > > we are? Or are they, maybe? In which case, maybe the kernel people > > > would welcome an option to disrequire the early mounting of /usr as > > > much as we would. > > > > > > Anyhow, I'd like to take a peek at the source code which does this > > > evil > > > thing. Would somebody please tell me which version of udev is > > > involved.> > > Every udev version works this way. > > My udev (164-r2) is just fine at the moment. I'm not sure what you mean > by that statement. It works for you. Every udev-version I know of, is able to run any script you like it to. > > Fixing udev to continue working with separate /usr is far from trivial > > imo. Changing some paths is not the way to go for sure. > > Maybe, maybe not. No, I wrote "for sure", because I *know* this. > But it seems a changing of paths (/ -> /usr) is > precisely what is breaking newer udevs. No, it is *not* > It might be possible to change > them back. This could involve moving a fair amount of stuff from /usr to > /, but not half as much as moving the entire /usr partition. Again, udev can run arbitrary scripts. > > First of all, udev has to distinguish between "device not present" and > > "script error of some kind". Failing scripts have to be queued somehow > > for later execution. If a script keeps failing, it has to be removed > > from that queue, with a message to syslog or something like that. If > > udev needs a script in /usr/* to mount /usr then there's a > > chicken-egg-problem, which could be hard to solve (if possible at all > > without moving things from /usr/ to /). Note, that I am wild guessing > > here, I did not study the udev sources or any related script/rule :) > > This sounds like a separate (if related) problem. No, this *is* the problem.Canek has posted some links in the other thread, some other guy, I have forgotten who it was, posted others. If interested read them. I really don't want to offend you, but unless you understand, how things work and what the problem is, don't waste your time looking at udev's sources. Best, Michael
