1 |
On Thu, Sep 15, 2011 at 04:33:01PM +0200, Joost Roeleveld wrote: |
2 |
> The use for an initrd/initramfs/... will create an additional layer of |
3 |
> complexity a lot of us users are not really waiting for, especially as we are |
4 |
> not seeing any issues with our current systems. |
5 |
See below on the existing udev retry queue that is hiding many of the |
6 |
issues from you. This hidden issues are also negatively affecting boot |
7 |
times (failures and retries take time). |
8 |
|
9 |
> My idea is, to me at least, simple. |
10 |
> "udev" is split into 2 parts: |
11 |
> 1) "udevd", which creates the /dev-tree based on the events it currently gets |
12 |
> 2) "actiond" processes all the actions "udevd" puts in a seperate queue. |
13 |
This needs to be taken to the upstream udev list. |
14 |
|
15 |
The problem is that there is a bit of a catch-22 in running some udev |
16 |
rules: |
17 |
0. You're going to have to declare interdependencies between ALL udev |
18 |
rules. This is because udev rules could be usable independently, or |
19 |
they could be interrelated (first rule sets some state variable or |
20 |
file, second one consumes it). |
21 |
1. While the binary invoked by a given rule might reside entirely on a |
22 |
mounting that is already available, how do you ensure that the other |
23 |
mountpoints required by said binary are ALSO available (the bluetooth |
24 |
and ALSA rules actually need /var, what if you have a bluetooth |
25 |
keyboard? [see footnote]). |
26 |
2. If the udev rule fails because the filesystem was not yet mounted, |
27 |
how does udev know that is safe to retry? Do we have to start |
28 |
declaring every file used (opened, dlopen'd, linked against) by a |
29 |
given rule? |
30 |
|
31 |
The upstream discussions I've been party to previously (both on lists |
32 |
and in person), have been trying to avoid needing a full dependency |
33 |
system in udev, because it's a huge degree of additional complexity. |
34 |
|
35 |
> I think that if "udevd" is started at boot-time and "actiond" only after |
36 |
> "localmount" has finished, there shouldn't be the situation where a script in |
37 |
> the udev-configuration fails because of missing files. |
38 |
> Even if it does, then this can be handled in "actiond" itself and placed in a |
39 |
> retry-queue. |
40 |
udev has a retry queue already, see udev-postmount: |
41 |
=== |
42 |
# Run the events that failed at first udev trigger |
43 |
udevadm trigger --type=failed -v |
44 |
=== |
45 |
|
46 |
(upstream is actually planning to remove it, because of problems of |
47 |
rules with side-effects to being run multiple times, amongst other |
48 |
things). |
49 |
|
50 |
> With a smaller udev, the chances of it failing should also be less. (less |
51 |
> code-lines to check) and as long as the /dev-entries are created, these can be |
52 |
> used to manually mount the other partitions to get to the point where the |
53 |
> system can be fixed to get it back to a workable state. |
54 |
The problem is NOT in the udev codebase. It's in udev rules. Even at the |
55 |
rule level, it's mostly rules for packages other than udev itself. |
56 |
|
57 |
> If, in the currently planned form, udev fails, it will be necessary to use a |
58 |
> rescue-cd/usb to boot the system, try to fix it inside a chroot where it's not |
59 |
> easy to check what is actually going wrong during the boot-process as the |
60 |
> different tools can then not be run with the error-messages printed to the |
61 |
> console. |
62 |
No, you're gotten the failure case wrong. Ok, so take the minimal |
63 |
initramfs as I proposed on this list as the "working" case. Let's say |
64 |
for some reason the initramfs doesn't load at all, so you have only / |
65 |
mounted when you go into the rootfs init. |
66 |
|
67 |
If you had a setup that was complex enough to require udev to come up |
68 |
for mounting /usr, you're going to end up at a real shell on your rootfs |
69 |
by one of the following means: |
70 |
- Pressing I for interactive boot, selecting shell (if you have not |
71 |
locked it down) |
72 |
- Passing init=/bin/sh to your boot loader. |
73 |
|
74 |
The problem case that does NOT exist here is anything more complicated; |
75 |
because if you have something like root-on-LVM, or encrypted root, you |
76 |
already have an initramfs. |
77 |
|
78 |
If the initramfs itself does exist, but fails to mount anything, you |
79 |
also get a rescue shell from the initramfs. |
80 |
|
81 |
Footnotes: |
82 |
---------- |
83 |
A bluetooth keyboard as your system keyboard is a very interesting test |
84 |
case here. It's the only keyboard you can get on some tablet systems, |
85 |
because the onscreen keyboard isn't available until your graphics are |
86 |
running are running. I've had a media-centre box with a bluetooth |
87 |
keyboard in the past as well. Side-effects of having only a Bluetooth |
88 |
keyboard: |
89 |
- No ability to have ANY system input until bluetooth is online. |
90 |
- This means no ability to control GRUB, or activate interactive boot |
91 |
early on. |
92 |
|
93 |
-- |
94 |
Robin Hugh Johnson |
95 |
Gentoo Linux: Developer, Trustee & Infrastructure Lead |
96 |
E-Mail : robbat2@g.o |
97 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |