[bug#30604] Keyboard detection before ‘cryptsetup’ runs

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 3144 bytes --]

Hi Ludo,

I thought about it for a bit...

On Sun, 18 Mar 2018 16:03:06 +0100
ludo@gnu.org (Ludovic Courtès) wrote:

> One way to do that would be to have a separate thread that calls
> ‘load-needed-linux-modules’ as appropriate.  Ideally it would use
> inotify on /sys like udev does, but a poor programmer’s version could
> simply call ‘load-needed-linux-modules’ every half a second or so.
> 
> Alternately, before passing control to user code (pre-mount actions,
> etc.), we could do a “settle” kind of thing: call
> ‘load-linux-modules-from-directory’ every 0.5 seconds until its result
> is the same as before.  There’s still a risk of missing devices, and
> those devices will never show up later because nobody’s monitoring /sys.
> But then again, “udevadm settle” must have the same problem: it can’t
> really know whether things have settled, I guess.

Yes, but udevd continues running and monitoring /sys anyway - so I guess
they don't really care (if I wrote it, I'd start up the monitoring first
and then traverse /sys for modalias - and make sure the modprobe is
idempotent).

I have to say what we have to do is much more complicated than I thought
it would be - and I kinda regret starting this patchset.  I didn't
want to make it less likely for people to boot than before :-(

I suggest we find out how the other distributions do it - if they do it.

A small bit of research shows that:

- Busybox uses a loop with timeout to try to mount over and over again,
depending on bus type [2].
- Alpine coldplugs twice [1].
- Fatdog has a "waitdev" boot parameter that specifies how long it sleeps
until it tries to mount the root.
- Redhat mkinitrd has an mkinitrd option like "--with=scsi_wait_scan" which
they use after they saw a modalias starting with "scsi:" - or add the
kernel option "scsi_mod.scan=sync" to the command line [3] (but they say that
this is unreliable now and one is supposed to use udev inside the initrd).
Not sure what they do for USB.

The Linux kernel itself has a "rootdelay" parameter which
was specifically introduced because of USB devices that took 15 s (!)
to show up.

All in all, we have alternative ways to continue:

(a) Drop this patchset/feature entirely because it's too unreliable.
(b) Monitor /sys using inotify in an extra thread/process.
(c) Include udev into the initrd and have it do its thing.
(d) Monitor the netlink socket in our own thread and play udev ourselves.
(e) Find out how to, for each bus type, detect when enumeration is finished.
Find out which buses are there.  Wait for them to finish enumerating.
(f) Always modprobe usb-hid first, no matter what.  I think this would
become a whack-a-mole thing fast.

I'd prefer either (a) or (b) for reliability and simplicity.  WDYT?

(inotify is Linux-only, but so is /sys/devices :P)

[1] https://git.alpinelinux.org/cgit/abuild/tree/initramfs-init?id=9154b0d9b7251cca900f9e834ac9af9ae2ae61d9 (scan_drivers)
[2] http://lists.busybox.net/pipermail/busybox/2015-March/082688.html
[3] https://bugzilla.redhat.com/show_bug.cgi?id=466607

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]