[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ludovic Courtès
Subject: [bug#30604] Keyboard detection before ‘cryptsetup’ runs
Date: Sat, 24 Mar 2018 18:12:52 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)


Danny Milosavljevic <address@hidden> skribis:

> 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 :-(

Yeah, I had a nightmare where I dreamed of all the bug reports due to
devices not showing up quickly enough.  :-)

> 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.

It’s a kludge fest, which is reassuring, in a way.

> 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?

Same here!  Sounds like (b) is something we could easily try, though we
won’t know how well it works until people start running it on the bare

I can adjust the branch I have to do that and push it for people to try.

Thanks a lot of your feedback!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]