On Thursday, September 15, 2011 07:41:57 PM Robin H. Johnson wrote: > On Thu, Sep 15, 2011 at 04:33:01PM +0200, Joost Roeleveld wrote: > > The use for an initrd/initramfs/... will create an additional layer of > > complexity a lot of us users are not really waiting for, especially as > > we are not seeing any issues with our current systems. > > See below on the existing udev retry queue that is hiding many of the > issues from you. This hidden issues are also negatively affecting boot > times (failures and retries take time).
I don't actually mind too much about the boot time. If there are retries like this, I would expect this to be visible in the system logs. > > My idea is, to me at least, simple. > > "udev" is split into 2 parts: > > 1) "udevd", which creates the /dev-tree based on the events it currently > > gets 2) "actiond" processes all the actions "udevd" puts in a seperate > > queue. > This needs to be taken to the upstream udev list. > > The problem is that there is a bit of a catch-22 in running some udev > rules: > 0. You're going to have to declare interdependencies between ALL udev > rules. This is because udev rules could be usable independently, or > they could be interrelated (first rule sets some state variable or > file, second one consumes it). 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. > 1. While the binary invoked by a given rule might reside entirely on a > mounting that is already available, how do you ensure that the other > mountpoints required by said binary are ALSO available (the bluetooth > and ALSA rules actually need /var, what if you have a bluetooth > keyboard? [see footnote]). This is why I would suggest the "actiond" process to be started after localmount. > 2. If the udev rule fails because the filesystem was not yet mounted, > how does udev know that is safe to retry? Do we have to start > declaring every file used (opened, dlopen'd, linked against) by a > given rule? See my reply to "1". > 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. I see this as a "solution" for the situation where someone decides to use less-common hardware and force this solution onto everyone else. If I would want to put my /usr filesystem on a bluetooth harddrive (for instance my mobile phone), then I would not expect to have this work without a lot of extra effort. > > I think that if "udevd" is started at boot-time and "actiond" only after > > "localmount" has finished, there shouldn't be the situation where a > > script in the udev-configuration fails because of missing files. > > Even if it does, then this can be handled in "actiond" itself and placed > > in a retry-queue. > > udev has a retry queue already, see udev-postmount: > === > # Run the events that failed at first udev trigger > udevadm trigger --type=failed -v > === This is a retry-queue. That's a good start already, but why not redo this queue and put ALL the scripts into that queue untill after localmount? > (upstream is actually planning to remove it, because of problems of > rules with side-effects to being run multiple times, amongst other > things). If this mechanism would be used to have all external scripts run after localmount for the first time, these side-effects shouldn't happen. > > With a smaller udev, the chances of it failing should also be less. > > (less > > code-lines to check) and as long as the /dev-entries are created, these > > can be used to manually mount the other partitions to get to the point > > where the system can be fixed to get it back to a workable state. > > The problem is NOT in the udev codebase. It's in udev rules. Even at the > rule level, it's mostly rules for packages other than udev itself. Yes, but as I already stated, the problem-rules do not exist on all systems. My systems for instance don't have any pointing to anything other then /etc/... These scripts also don't call anything that isn't mounted at the time. That system has been running without incident for several years. Why do I suddenly have to make that system more complex? > > If, in the currently planned form, udev fails, it will be necessary to > > use a rescue-cd/usb to boot the system, try to fix it inside a chroot > > where it's not easy to check what is actually going wrong during the > > boot-process as the different tools can then not be run with the > > error-messages printed to the console. > > No, you're gotten the failure case wrong. Ok, so take the minimal > initramfs as I proposed on this list as the "working" case. Let's say > for some reason the initramfs doesn't load at all, so you have only / > mounted when you go into the rootfs init. > > If you had a setup that was complex enough to require udev to come up > for mounting /usr, you're going to end up at a real shell on your rootfs > by one of the following means: > - Pressing I for interactive boot, selecting shell (if you have not > locked it down) > - Passing init=/bin/sh to your boot loader. > > The problem case that does NOT exist here is anything more complicated; > because if you have something like root-on-LVM, or encrypted root, you > already have an initramfs. > > If the initramfs itself does exist, but fails to mount anything, you > also get a rescue shell from the initramfs. >From my understanding, udev is needed to create the /dev-entries to be able to mount /usr. If the changes proposed are actually done (moving everything out of / and into /usr) then udev won't be available to create the /dev-entries. A pre-populated set would work for most, but /dev/mapper used to require an initramfs as this device would have different numbers upon boot. If this is still the case, how would I be able to get LVM and MDADM to run to get to my partitions? > Footnotes: > ---------- > A bluetooth keyboard as your system keyboard is a very interesting test > case here. It's the only keyboard you can get on some tablet systems, > because the onscreen keyboard isn't available until your graphics are > running are running. I've had a media-centre box with a bluetooth > keyboard in the past as well. Side-effects of having only a Bluetooth > keyboard: > - No ability to have ANY system input until bluetooth is online. > - This means no ability to control GRUB, or activate interactive boot > early on. In this case, you'd need to put full bluetooth support into the initramfs. On all the "normal" computers I see for sale online all have USB-keyboards. And that is, still, the vast majority of systems currently in use and available. I'm sorry, but I see bluetooth-keyboards still as a minority. If someone wants/has to use this, then an initramfs will be necessary. Same as if someone wants to have his filesystem on a strange new harddrive (like my bluetooth enabled mobile phone storage). The vast majority doesn't use those. -- Joost
