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).
> 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). 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]). 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? 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 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 === (upstream is actually planning to remove it, because of problems of rules with side-effects to being run multiple times, amongst other things). > 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. > 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. 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. -- 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
signature.asc
Description: Digital signature
