1 |
Hi Alan, |
2 |
|
3 |
On Monday, 12. September 2011 17:17:37 Alan Mackenzie wrote: |
4 |
> Hi, Michael. |
5 |
> |
6 |
> On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote: |
7 |
> > Hi Alan, |
8 |
> > |
9 |
> > On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote: |
10 |
> > > Hope nobody minds me starting a new thread with an accurate name. |
11 |
> > > |
12 |
> > > Which version of udev is it that has this nauseating feature of |
13 |
> > > needing |
14 |
> > > /usr loaded to boot? |
15 |
> > > |
16 |
> > > Somewhere in that version's source will be several (or lots of) |
17 |
> > > "/usr". |
18 |
> > > Just how difficult is it going to be to replace "/usr/bin" with |
19 |
> > > "/bin" |
20 |
> > > throughout the source? |
21 |
> > |
22 |
> > you misunderstood something. udev is able to run arbitrary scripts. Some |
23 |
> > of those scripts are located in /usr/* or need something there. I doubt |
24 |
> > you will find references to /usr in the udev-sources. |
25 |
> |
26 |
> Well, I'm a hacker. udev is free source, therefore fair game. I don't |
27 |
> intend to put up with this nonsense without a fight. As far as I can |
28 |
> make out, this is just one guy, Kay Sievers, who's on a power trip. Are |
29 |
> there any indications at all that he actually talked to anybody in the |
30 |
> wide world before making such a far reaching decision? |
31 |
> On my current system, udev (164-r2) works without an earlily loaded /usr. |
32 |
> Seemingly, later versions don't. That was why I was asking for somebody |
33 |
> to identify one of these later versions for me. |
34 |
|
35 |
it works for you, because your udev-rules need nothing from /usr/* |
36 |
It's *not* udev requiring /usr, it's the scripts triggered by the rules. |
37 |
|
38 |
> > > udev is part of the kernel. |
39 |
> > |
40 |
> > No. udev is usperspace. |
41 |
> |
42 |
> OK, udev is in userspace, _very_ _close_ to the kernel. ;-) |
43 |
> |
44 |
> > > How come the kernel hackers aren't up in arms about this as much as |
45 |
> > > we are? Or are they, maybe? In which case, maybe the kernel people |
46 |
> > > would welcome an option to disrequire the early mounting of /usr as |
47 |
> > > much as we would. |
48 |
> > > |
49 |
> > > Anyhow, I'd like to take a peek at the source code which does this |
50 |
> > > evil |
51 |
> > > thing. Would somebody please tell me which version of udev is |
52 |
> > > involved.> |
53 |
> > Every udev version works this way. |
54 |
> |
55 |
> My udev (164-r2) is just fine at the moment. I'm not sure what you mean |
56 |
> by that statement. |
57 |
|
58 |
It works for you. |
59 |
Every udev-version I know of, is able to run any script you like it to. |
60 |
|
61 |
> > Fixing udev to continue working with separate /usr is far from trivial |
62 |
> > imo. Changing some paths is not the way to go for sure. |
63 |
> |
64 |
> Maybe, maybe not. |
65 |
|
66 |
No, I wrote "for sure", because I *know* this. |
67 |
|
68 |
> But it seems a changing of paths (/ -> /usr) is |
69 |
> precisely what is breaking newer udevs. |
70 |
|
71 |
No, it is *not* |
72 |
|
73 |
> It might be possible to change |
74 |
> them back. This could involve moving a fair amount of stuff from /usr to |
75 |
> /, but not half as much as moving the entire /usr partition. |
76 |
|
77 |
Again, udev can run arbitrary scripts. |
78 |
|
79 |
> > First of all, udev has to distinguish between "device not present" and |
80 |
> > "script error of some kind". Failing scripts have to be queued somehow |
81 |
> > for later execution. If a script keeps failing, it has to be removed |
82 |
> > from that queue, with a message to syslog or something like that. If |
83 |
> > udev needs a script in /usr/* to mount /usr then there's a |
84 |
> > chicken-egg-problem, which could be hard to solve (if possible at all |
85 |
> > without moving things from /usr/ to /). Note, that I am wild guessing |
86 |
> > here, I did not study the udev sources or any related script/rule :) |
87 |
> |
88 |
> This sounds like a separate (if related) problem. |
89 |
|
90 |
No, this *is* the problem.Canek has posted some links in the other thread, |
91 |
some other guy, I have forgotten who it was, posted others. If interested read |
92 |
them. I really don't want to offend you, but unless you understand, how things |
93 |
work and what the problem is, don't waste your time looking at udev's sources. |
94 |
|
95 |
Best, |
96 |
Michael |