1 |
On Thursday, September 15, 2011 07:41:57 PM Robin H. Johnson wrote: |
2 |
> On Thu, Sep 15, 2011 at 04:33:01PM +0200, Joost Roeleveld wrote: |
3 |
> > The use for an initrd/initramfs/... will create an additional layer of |
4 |
> > complexity a lot of us users are not really waiting for, especially as |
5 |
> > we are not seeing any issues with our current systems. |
6 |
> |
7 |
> See below on the existing udev retry queue that is hiding many of the |
8 |
> issues from you. This hidden issues are also negatively affecting boot |
9 |
> times (failures and retries take time). |
10 |
|
11 |
I don't actually mind too much about the boot time. If there are retries like |
12 |
this, I would expect this to be visible in the system logs. |
13 |
|
14 |
> > My idea is, to me at least, simple. |
15 |
> > "udev" is split into 2 parts: |
16 |
> > 1) "udevd", which creates the /dev-tree based on the events it currently |
17 |
> > gets 2) "actiond" processes all the actions "udevd" puts in a seperate |
18 |
> > queue. |
19 |
> This needs to be taken to the upstream udev list. |
20 |
> |
21 |
> The problem is that there is a bit of a catch-22 in running some udev |
22 |
> rules: |
23 |
> 0. You're going to have to declare interdependencies between ALL udev |
24 |
> rules. This is because udev rules could be usable independently, or |
25 |
> they could be interrelated (first rule sets some state variable or |
26 |
> file, second one consumes it). |
27 |
|
28 |
Either udev does this already and the execution sequence is always the same. |
29 |
In which case my suggestion above would follow the same sequence as the queue |
30 |
would be on a First-in First-out basis. |
31 |
Or, if udev doesn't do this yet, udev will end up having the same problem. |
32 |
|
33 |
> 1. While the binary invoked by a given rule might reside entirely on a |
34 |
> mounting that is already available, how do you ensure that the other |
35 |
> mountpoints required by said binary are ALSO available (the bluetooth |
36 |
> and ALSA rules actually need /var, what if you have a bluetooth |
37 |
> keyboard? [see footnote]). |
38 |
|
39 |
This is why I would suggest the "actiond" process to be started after |
40 |
localmount. |
41 |
|
42 |
> 2. If the udev rule fails because the filesystem was not yet mounted, |
43 |
> how does udev know that is safe to retry? Do we have to start |
44 |
> declaring every file used (opened, dlopen'd, linked against) by a |
45 |
> given rule? |
46 |
|
47 |
See my reply to "1". |
48 |
|
49 |
> The upstream discussions I've been party to previously (both on lists |
50 |
> and in person), have been trying to avoid needing a full dependency |
51 |
> system in udev, because it's a huge degree of additional complexity. |
52 |
|
53 |
I don't see why it would not be possible to pause actioning of these scripts |
54 |
till the boot-process says all required mounts are available. |
55 |
|
56 |
I see this as a "solution" for the situation where someone decides to use |
57 |
less-common hardware and force this solution onto everyone else. |
58 |
|
59 |
If I would want to put my /usr filesystem on a bluetooth harddrive (for |
60 |
instance my mobile phone), then I would not expect to have this work without a |
61 |
lot of extra effort. |
62 |
|
63 |
> > I think that if "udevd" is started at boot-time and "actiond" only after |
64 |
> > "localmount" has finished, there shouldn't be the situation where a |
65 |
> > script in the udev-configuration fails because of missing files. |
66 |
> > Even if it does, then this can be handled in "actiond" itself and placed |
67 |
> > in a retry-queue. |
68 |
> |
69 |
> udev has a retry queue already, see udev-postmount: |
70 |
> === |
71 |
> # Run the events that failed at first udev trigger |
72 |
> udevadm trigger --type=failed -v |
73 |
> === |
74 |
|
75 |
This is a retry-queue. That's a good start already, but why not redo this |
76 |
queue and put ALL the scripts into that queue untill after localmount? |
77 |
|
78 |
> (upstream is actually planning to remove it, because of problems of |
79 |
> rules with side-effects to being run multiple times, amongst other |
80 |
> things). |
81 |
|
82 |
If this mechanism would be used to have all external scripts run after |
83 |
localmount for the first time, these side-effects shouldn't happen. |
84 |
|
85 |
> > With a smaller udev, the chances of it failing should also be less. |
86 |
> > (less |
87 |
> > code-lines to check) and as long as the /dev-entries are created, these |
88 |
> > can be used to manually mount the other partitions to get to the point |
89 |
> > where the system can be fixed to get it back to a workable state. |
90 |
> |
91 |
> The problem is NOT in the udev codebase. It's in udev rules. Even at the |
92 |
> rule level, it's mostly rules for packages other than udev itself. |
93 |
|
94 |
Yes, but as I already stated, the problem-rules do not exist on all systems. |
95 |
My systems for instance don't have any pointing to anything other then |
96 |
/etc/... |
97 |
These scripts also don't call anything that isn't mounted at the time. |
98 |
|
99 |
That system has been running without incident for several years. Why do I |
100 |
suddenly have to make that system more complex? |
101 |
|
102 |
> > If, in the currently planned form, udev fails, it will be necessary to |
103 |
> > use a rescue-cd/usb to boot the system, try to fix it inside a chroot |
104 |
> > where it's not easy to check what is actually going wrong during the |
105 |
> > boot-process as the different tools can then not be run with the |
106 |
> > error-messages printed to the console. |
107 |
> |
108 |
> No, you're gotten the failure case wrong. Ok, so take the minimal |
109 |
> initramfs as I proposed on this list as the "working" case. Let's say |
110 |
> for some reason the initramfs doesn't load at all, so you have only / |
111 |
> mounted when you go into the rootfs init. |
112 |
> |
113 |
> If you had a setup that was complex enough to require udev to come up |
114 |
> for mounting /usr, you're going to end up at a real shell on your rootfs |
115 |
> by one of the following means: |
116 |
> - Pressing I for interactive boot, selecting shell (if you have not |
117 |
> locked it down) |
118 |
> - Passing init=/bin/sh to your boot loader. |
119 |
> |
120 |
> The problem case that does NOT exist here is anything more complicated; |
121 |
> because if you have something like root-on-LVM, or encrypted root, you |
122 |
> already have an initramfs. |
123 |
> |
124 |
> If the initramfs itself does exist, but fails to mount anything, you |
125 |
> also get a rescue shell from the initramfs. |
126 |
|
127 |
From my understanding, udev is needed to create the /dev-entries to be able to |
128 |
mount /usr. |
129 |
If the changes proposed are actually done (moving everything out of / and into |
130 |
/usr) then udev won't be available to create the /dev-entries. |
131 |
A pre-populated set would work for most, but /dev/mapper used to require an |
132 |
initramfs as this device would have different numbers upon boot. |
133 |
If this is still the case, how would I be able to get LVM and MDADM to run to |
134 |
get to my partitions? |
135 |
|
136 |
> Footnotes: |
137 |
> ---------- |
138 |
> A bluetooth keyboard as your system keyboard is a very interesting test |
139 |
> case here. It's the only keyboard you can get on some tablet systems, |
140 |
> because the onscreen keyboard isn't available until your graphics are |
141 |
> running are running. I've had a media-centre box with a bluetooth |
142 |
> keyboard in the past as well. Side-effects of having only a Bluetooth |
143 |
> keyboard: |
144 |
> - No ability to have ANY system input until bluetooth is online. |
145 |
> - This means no ability to control GRUB, or activate interactive boot |
146 |
> early on. |
147 |
|
148 |
In this case, you'd need to put full bluetooth support into the initramfs. On |
149 |
all the "normal" computers I see for sale online all have USB-keyboards. |
150 |
And that is, still, the vast majority of systems currently in use and |
151 |
available. |
152 |
|
153 |
I'm sorry, but I see bluetooth-keyboards still as a minority. If someone |
154 |
wants/has to use this, then an initramfs will be necessary. Same as if someone |
155 |
wants to have his filesystem on a strange new harddrive (like my bluetooth |
156 |
enabled mobile phone storage). |
157 |
|
158 |
The vast majority doesn't use those. |
159 |
|
160 |
-- |
161 |
Joost |