On 2020-07-06 02:34:56 +0200, Guilhem Moulin wrote: > On Mon, 06 Jul 2020 at 01:48:45 +0200, Vincent Lefevre wrote: > > If you let the user run a script that controls the timeout, that > > would be better. For instance, a typical setting when dropbear is > > used to unlock the disk(s) would be to set the timeout so that the > > following conditions are *both* satisfied: > > > > 1. Some lower bound has been reached (say 10 seconds). > > > > 2. The passphrase has been validated. > > > > This makes sense because in this case, it is useless to abort > > wait_for_dropbear() while the passphrase has not been validated > > yet. > > wait_for_dropbear() runs at init-bottom stage, so after dm-crypt devices > have been mapped (if cryptsetup-initramfs is installed and the crypttab > is not empty, that is). So you're essentially asking to set the timeout > to 10s.
OK, so that's even simpler. A configurable timeout would be sufficient. > > BTW, I've just noticed that the timeout introduces a second annoying > > regression: If there is a temporary issue with the DHCP server just > > after the machine has been restarted, so that the timeout is reached, > > the user will not be able to unlock the disk until he can go back in > > front of his machine! > > You mean the timeout from configure_networking() it init-premout stage? [...] Please forget that. I meant wait_for_dropbear(), but since it runs after dm-crypt devices have been mapped, there is no issue. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
