1 |
On Fri, Sep 16, 2011 at 10:36:27AM +0200, Joost Roeleveld wrote: |
2 |
> > > Either udev does this already and the execution sequence is always the |
3 |
> > > same. In which case my suggestion above would follow the same sequence |
4 |
> > > as the queue would be on a First-in First-out basis. |
5 |
> > > Or, if udev doesn't do this yet, udev will end up having the same |
6 |
> > > problem. |
7 |
> > It doesn't do it presently. The worst case I've seen is having an early |
8 |
> > rule that succeeds, but gives different results w/ /var mounted vs. not |
9 |
> > mounted. This rule didn't actual fail, so it does not get retried... |
10 |
> And here is my main concern with this. The udev team don't list all the |
11 |
> possible filesystems where things can go wrong. They only mention /usr. |
12 |
We know that there are rules that invoke various parts of /usr, and |
13 |
rules that have state storage in various parts of /var. I agree that a |
14 |
lot more granularity would be useful, to help those that might have |
15 |
multiple mountpoints within each of /usr and /var (eg, I have |
16 |
/usr/lib64/debug in a seperate LV). |
17 |
|
18 |
> > > This is why I would suggest the "actiond" process to be started after |
19 |
> > > localmount. |
20 |
> > That's too late. What about all the udev rules required to get the |
21 |
> > device nodes for localmount to succeed? |
22 |
> Shouldn't these already exist for currently working setups? |
23 |
Specifically, I meant, how do you know which rules to run immediately |
24 |
before localmount, and which to postpone via actiond? |
25 |
|
26 |
> > > > The upstream discussions I've been party to previously (both on |
27 |
> > > > lists |
28 |
> > > > and in person), have been trying to avoid needing a full dependency |
29 |
> > > > system in udev, because it's a huge degree of additional complexity. |
30 |
> > > I don't see why it would not be possible to pause actioning of these |
31 |
> > > scripts till the boot-process says all required mounts are available. |
32 |
> > |
33 |
> > You still have to declare which scripts need to be paused, and/or which |
34 |
> > rules inside the scripts need to be paused. Even worse are cases where |
35 |
> > mounting some of localmount entries requires those scripts to have |
36 |
> > completed. |
37 |
> In other words, a dependency on the rules would be needed? |
38 |
Yes, as I noted in my initial response to you, there's going to be |
39 |
interdependencies between udev rules and other parts of the system. |
40 |
(The other reason I think systemd and udev might merge at some point, or |
41 |
at least have good IPC between them, because there is a potential for |
42 |
speed gains there). |
43 |
|
44 |
> > udev runs that rule as soon as the hardware turns up, which is often |
45 |
> > before localmount. |
46 |
> I have doubts about having all these things handled by udev. As you said, |
47 |
> there is an init-script that handles this. Is the ultimate goal to get rid of |
48 |
> init-scripts and have everything done automagically? |
49 |
The rule is really useful & important if you plug in a USB or Firewire |
50 |
sound card at some point after boot. If you already had it configured a |
51 |
previous time, that rule will restore your volume settings :-). |
52 |
|
53 |
The other parts of that init script are valuable still, but the volume |
54 |
restore is just a crutch for failing to load the volume when the device |
55 |
was first detected. If you have a soundcard that makes a pop when your |
56 |
system boots, that's a bug caused by this. |
57 |
|
58 |
> > Just because there are no visible errors, doesn't mean that they don't |
59 |
> > exist. This move to encourage initramfs is to ensure that there isn't |
60 |
> > any major breakage incidents soon. What if udev upstream suddenely |
61 |
> > starts hard requiring /usr to mounted, and not doing retries at all. |
62 |
> > How many systems are going to break, and users going to complain about |
63 |
> > needing to use livecds to recover? |
64 |
> A lot. And those will be very vocal. |
65 |
> I have a few goals with this thread and one of them is to try to figure out |
66 |
> how best to avoid users to get affected by this. |
67 |
For now, users having an initramfs ahead of time is the best option to |
68 |
avoid future breakages. |
69 |
|
70 |
> > DEVTMPFS creates the first batch, and udev creates the rest. |
71 |
> > |
72 |
> > The deciding case then becomes: |
73 |
> > - Is the device for your /usr entry in fstab created by udev or |
74 |
> > something else? |
75 |
> > |
76 |
> > MD: done by devtmpfs |
77 |
> > LVM: done by udev+lvm |
78 |
> > by-uuid/by-label: done by udev |
79 |
> > |
80 |
> > by-uuid and by-label present a lot of annoyance to the minimal |
81 |
> > initramfs. We have to ensure that we explicitly support them, which has |
82 |
> > increased the complexity of the initramfs. |
83 |
> My /usr is on LVM. That requires udev. |
84 |
> |
85 |
> My understanding is: |
86 |
> - udev needs /usr to be mounted to work |
87 |
Correct. |
88 |
|
89 |
> - udev is needed to sort out LVM to get access to /usr |
90 |
Incorrect. But perhaps not for the reason that you think. |
91 |
|
92 |
Using genkernel's initramfs here as an example, this is the sequence of |
93 |
LVM commands that run: |
94 |
vgscan |
95 |
vgchange -ay --sysinit |
96 |
|
97 |
That --sysinit part is important, as it tells LVM to avoid locking (and |
98 |
some interaction with udev), and then LVM has fallback code to create |
99 |
the symlinks and other device nodes in /dev. What udev CAN do is create |
100 |
all of the by-label/by-uuid bits above. The fallback code in LVM is very |
101 |
complex, just for the case of handling udev not being there yet. |
102 |
|
103 |
> And why can't this be implemented in localmount? |
104 |
/etc/init.d/lvm does it on your system. |
105 |
|
106 |
-- |
107 |
Robin Hugh Johnson |
108 |
Gentoo Linux: Developer, Trustee & Infrastructure Lead |
109 |
E-Mail : robbat2@g.o |
110 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |