Re: [gentoo-user] udev + /usr

[Michael Schreckenbauer <grimlog@gmx.de>]

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