1 |
On Mon, Dec 24, 2012 at 10:06 AM, Nuno J. Silva <nunojsilva@×××××××.pt> wrote: |
2 |
> On 2012-12-24, Dale wrote: |
3 |
> |
4 |
|
5 |
[snip] |
6 |
|
7 |
>> Well, so far I have stuck with the udev that works without a init |
8 |
>> thingy. I do have a init thingy for when the udev that requires it is |
9 |
>> marked stable. The devs are keeping the udev that requires /usr on / |
10 |
>> masked and/or keyworded until everyone is ready. That was until eudev |
11 |
>> was announced. Now they are also waiting on eudev to get stable so |
12 |
>> people can switch to it. I plan to switch too. |
13 |
>> |
14 |
>> The problem is this from my understanding. For decades, any commands or |
15 |
>> config files needed to boot Linux had to be in /bin, /sbin, /etc, and/or |
16 |
>> /lib. Those directories were what was needed to boot and anything |
17 |
>> needed to boot a system should be installed into one or more of those |
18 |
>> directories. Then someone came up with the idea of putting things into |
19 |
>> /usr instead. When they did that, it broke things. To me, this change |
20 |
>> makes as much sense as putting the mount command is /usr/bin but that is |
21 |
>> where some want Linux to go. I have read where some want to basically |
22 |
>> move about everything to /usr but not sure how much traction that is |
23 |
>> getting. |
24 |
> |
25 |
> From my understanding, the problem with udev was that the rules used to |
26 |
> process events may require stuff from /usr. Which is OK, as I think the |
27 |
> rules may even end up executing random executables. And the sole problem |
28 |
> with this is that udev will not wait, it will simply fail in a silent |
29 |
> way when applying rules that require stuff from /usr. |
30 |
> |
31 |
> Now, also, from my understanding, this was already the case for some |
32 |
> time (maybe even years?). And that's why I've asked for more details. |
33 |
> |
34 |
> So, if the udev you use is OK with no initrd, what is in the new udev |
35 |
> that actually requires the initrd? |
36 |
> |
37 |
> Meanwhile, I found https://bugs.gentoo.org/show_bug.cgi?id=446372, which |
38 |
> would explain why, all of a sudden, there is a bigger problem. |
39 |
|
40 |
You found the answer to your own question. |
41 |
|
42 |
> Now, I |
43 |
> wonder how is this solved with an initrd, by copying udevd there? If so, |
44 |
> why don't we simply install udevd under (or copy its stuff to) / instead |
45 |
> of using /usr as $PREFIX? |
46 |
|
47 |
An initr* "solves" the problem by copying all tools necessary to |
48 |
reliably mount /usr to a temporary filesystem loaded at boot (and then |
49 |
discarded). |
50 |
|
51 |
As a solution, this 'works'. Opinions differ strongly on: |
52 |
|
53 |
* The weight of the burden it places on system administrators |
54 |
* The weight of reliability and security concerns which can arise from |
55 |
** Increased maintenance complexity |
56 |
** Having separate copies of tools |
57 |
** Complications arising from maintaining multiple kernel versions on |
58 |
a system, and their corresponding supporting initr* tools. |
59 |
* The elegance of the solution |
60 |
|
61 |
> |
62 |
>> Basically, something that has worked for decades is declared to be |
63 |
>> broken all that time and if it wasn't broken, we are going to break it. |
64 |
> |
65 |
> ... yeah... the thing here is that I'm just trying to separate the |
66 |
> upstream comments on "separate /usr is broken" from the actual thing |
67 |
> that breaks the boot process. So far, even the stuff from freedesktop |
68 |
> I've read stating that "separate /usr is broken" do not seem to mention |
69 |
> that udevd is moving to /usr. |
70 |
|
71 |
Based on one or two emails on the -dev list (I'm really not sure; that |
72 |
list has been flying lately, and it's difficult for me to keep up |
73 |
right now), this may have been an individual action taken by the |
74 |
gentoo maintainer of udevd based on upstreams declaration that they |
75 |
don't give a flying frell about separate /usr contexts, and expect |
76 |
those scenarios to become more and more difficult. |
77 |
|
78 |
If that's the case, I can understand the maintainer's action; upstream |
79 |
mailing lists would let things break over time and respond to reports |
80 |
with "we don't support that configuration". The maintainer, not being |
81 |
superhuman, brought the problem to the foreground by putting udevd in |
82 |
a place such that the breakage is more up-front, concentrated and |
83 |
easier for him to mark reports as WONTFIX. |
84 |
|
85 |
The eudevd fork is intended to give people whose separate /usr |
86 |
configurations would fall under WONTFIX territory in udev a place to |
87 |
go. While there are certain to that cases where separate /usr without |
88 |
an initr* is fundamentally impossible, there's still a large number of |
89 |
cases where it ought to work, and more where its failure is the result |
90 |
of software bugs (either in code or in design). |
91 |
|
92 |
> |
93 |
>> From my understanding, if I upgrade my system to the later version of |
94 |
>> udev and bypass the init system, my system will not boot. I have not |
95 |
>> tested the theory but that is what people have been saying. Not only is |
96 |
>> my /usr separate but it is on LVM partitons too. |
97 |
> |
98 |
> Your problem would be LVM (if that's an issue at all, as I said I don't |
99 |
> know LVM), you'd not need udevd to mount /usr if it were a regular |
100 |
> partition. |
101 |
|
102 |
"you wouldn't have this problem if you did *something else*" is a |
103 |
terrible response. There are very good reasons to use LVM. There are |
104 |
good (IMO, at least) reasons to avoid using an initr* on Gentoo. |
105 |
(Those reasons are sprinkled through the thread, some spoken by me, |
106 |
some spoken by others.) |
107 |
|
108 |
You'll find most of the people in the discussion so far aren't against |
109 |
initr* in all cases. It's the increase in number of cases where it |
110 |
becomes technically required that's a problem. |
111 |
|
112 |
-- |
113 |
:wq |