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. > > 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. > 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. But it seems a changing of paths (/ -> /usr) is precisely what is breaking newer udevs. 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. > 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. > > Thanks. > Best, > Michael -- Alan Mackenzie (Nuremberg, Germany).
