On Sat, 01 Jul 2017 at 16:10:01 -0400, Antoine Beaupré wrote: > On 2017-07-01 21:10:37, Guilhem Moulin wrote: >> Does setting “IFDOWN=none” (the option was latter renamed) in >> /etc/dropbear-initramfs/config >> solves your problem? Please file a bug against dropbear-initramfs if it >> does. > > It doesn't: the script still kills my shell and dropbear unwraps > everything and kills itself as well. I then have a password prompt on > the console and no ssh access from the outside.
Hmm odd, OTHO dropbear's shutdown script is very late. From initramfs-tools(8): init-bottom are the last scripts to be executed before procfs and sysfs are moved to the real rootfs and execution is turned over to the init binary which should now be found in the mounted rootfs. udev is stopped. I'm surprised that initramfs went so far in the init process while the cryptroot script is still pending on a passphrase prompt. Could you pass ‘debug’ to the kernel command line, then sanitize and attach /run/initramfs/initramfs.debug? Probably your /etc/crypttab and /etc/fstab (at least the relevant lines) would be helpful, too. > I am *guessing* that systemd may do the right thing next: in theory, the > system *can* start without that partition (it's /srv), or at least the > real sshd and then I could login and unlock the other partition. But on > my first try, this is not what happened, at least I wasn't patient > enough to let the machine go down any longer... > > But that's my current use case: it would be a perfectly legitimate use > case to have /, /usr and /var in three different LUKS filesystems, in > which case the current configuration would just fail completely. Unlike / and /usr, /var isn't needed at initramfs stage, so the cryptsetup boot scripts won't try to unlock it early. If for some reason it needs to be mounted before systemd kicks in (for instance because its lacking a crypttab(5) feature you need, such as keyscripts), adding ‘initramfs’ to crypttab(5)'s 4th column should do the trick. >>> The normal "cryptroot-unlock" program doesn't work either for multiple >>> partitions. >> >> That's something which would be nice to have, indeed. In principle it should >> work (at least if the network interface was up) if you were to reconnect for >> each disk, but I see some benefits in using the same script for all >> passphrase >> prompts ;-) I'll need to test this, but AFAICT a while loop would be enough >> as >> dropbear's cleanup script kills the sshd and all its children (hence the >> script >> itself) at init-bottom stage. > > I tried to figure out how to do this myself, but ended up writing my own > shell script with hardcoded defaults. Same here. Then I joined the cryptsetup and dropbear maintaining team, and tried to make my solution generic enough to ship it along with the packages ;-) -- Guilhem.
signature.asc
Description: PGP signature