Re: [gentoo-dev] udev and /usr

[Robin H. Johnson]

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     : robbat2@g.o
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85