On Fri, Sep 16, 2011 at 10:36:27AM +0200, Joost Roeleveld wrote: > > > Either udev does this already and the execution sequence is always the > > > same. In which case my suggestion above would follow the same sequence > > > as the queue would be on a First-in First-out basis. > > > Or, if udev doesn't do this yet, udev will end up having the same > > > problem. > > It doesn't do it presently. The worst case I've seen is having an early > > rule that succeeds, but gives different results w/ /var mounted vs. not > > mounted. This rule didn't actual fail, so it does not get retried... > And here is my main concern with this. The udev team don't list all the > possible filesystems where things can go wrong. They only mention /usr. We know that there are rules that invoke various parts of /usr, and rules that have state storage in various parts of /var. I agree that a lot more granularity would be useful, to help those that might have multiple mountpoints within each of /usr and /var (eg, I have /usr/lib64/debug in a seperate LV).
> > > This is why I would suggest the "actiond" process to be started after > > > localmount. > > That's too late. What about all the udev rules required to get the > > device nodes for localmount to succeed? > Shouldn't these already exist for currently working setups? Specifically, I meant, how do you know which rules to run immediately before localmount, and which to postpone via actiond? > > > > The upstream discussions I've been party to previously (both on > > > > lists > > > > and in person), have been trying to avoid needing a full dependency > > > > system in udev, because it's a huge degree of additional complexity. > > > I don't see why it would not be possible to pause actioning of these > > > scripts till the boot-process says all required mounts are available. > > > > You still have to declare which scripts need to be paused, and/or which > > rules inside the scripts need to be paused. Even worse are cases where > > mounting some of localmount entries requires those scripts to have > > completed. > In other words, a dependency on the rules would be needed? Yes, as I noted in my initial response to you, there's going to be interdependencies between udev rules and other parts of the system. (The other reason I think systemd and udev might merge at some point, or at least have good IPC between them, because there is a potential for speed gains there). > > udev runs that rule as soon as the hardware turns up, which is often > > before localmount. > I have doubts about having all these things handled by udev. As you said, > there is an init-script that handles this. Is the ultimate goal to get rid of > init-scripts and have everything done automagically? The rule is really useful & important if you plug in a USB or Firewire sound card at some point after boot. If you already had it configured a previous time, that rule will restore your volume settings :-). The other parts of that init script are valuable still, but the volume restore is just a crutch for failing to load the volume when the device was first detected. If you have a soundcard that makes a pop when your system boots, that's a bug caused by this. > > Just because there are no visible errors, doesn't mean that they don't > > exist. This move to encourage initramfs is to ensure that there isn't > > any major breakage incidents soon. What if udev upstream suddenely > > starts hard requiring /usr to mounted, and not doing retries at all. > > How many systems are going to break, and users going to complain about > > needing to use livecds to recover? > A lot. And those will be very vocal. > I have a few goals with this thread and one of them is to try to figure out > how best to avoid users to get affected by this. For now, users having an initramfs ahead of time is the best option to avoid future breakages. > > DEVTMPFS creates the first batch, and udev creates the rest. > > > > The deciding case then becomes: > > - Is the device for your /usr entry in fstab created by udev or > > something else? > > > > MD: done by devtmpfs > > LVM: done by udev+lvm > > by-uuid/by-label: done by udev > > > > by-uuid and by-label present a lot of annoyance to the minimal > > initramfs. We have to ensure that we explicitly support them, which has > > increased the complexity of the initramfs. > My /usr is on LVM. That requires udev. > > My understanding is: > - udev needs /usr to be mounted to work Correct. > - udev is needed to sort out LVM to get access to /usr Incorrect. But perhaps not for the reason that you think. Using genkernel's initramfs here as an example, this is the sequence of LVM commands that run: vgscan vgchange -ay --sysinit That --sysinit part is important, as it tells LVM to avoid locking (and some interaction with udev), and then LVM has fallback code to create the symlinks and other device nodes in /dev. What udev CAN do is create all of the by-label/by-uuid bits above. The fallback code in LVM is very complex, just for the case of handling udev not being there yet. > And why can't this be implemented in localmount? /etc/init.d/lvm does it on your system. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
