hi!
This sounds like an interesting approach. As I got from #465901, this
will enable dropbear per default if cryptroot is detected. While I like
the idea to be able to enable ssh support for initramfs, I object
against this default behaviour. Not everyone with cryptroot is in need
of remote access during boot process. Thus I suggest to disable the
whole feature per default, and make it configurable in any case.
ok. not my preference, but i understand the rationale.
this behaviour is implemented in the dropbear patch. i guess the
dropbear maintainer will read the related initramfs-tools and this
report, and i will submit a patch with the always-no-default if he
requests so.
Also, please resend the patch in unified format (diff -rNu).
ok.
in the initramfs scripts, the target might be unlocked (from remote) in
the background. so on non-successful cryptsetup exit, check whether the
target is unlocked, only otherwise act on it as a failure.
for this unlocking in the background (and if successful, killing the
waiting cryptsetup), the cryptcreate script is added.
to call this unlocking script from remote, dropbear has to be added to
the initramfs, so dropbear is added to the suggested list.
I have to admit that I don't get that. In your patch, a script
/sbin/cryptcreate is created, which itself uses the variables
$cryptcreate and $crypttarget. This script is made executable, but I
cannot find the place where it actually is executed. Also, how does the
script know about the variables used by it?
the idea is that when the boot process is waiting at the passphrase
prompt, it is possible to log in via ssh and manually call a script
which prompts for the passphrase, and in case the passphrase is correct
and the root-fs is unlocked, kills the process waiting at the console,
so the boot process continues.
i admit that the name 'cryptcreate' for this script is quite
unintuitive, so i changed that in the attached new, unified diff: the
script's name is now 'unlock' - i hope this is more intuitive.
the variables will be expanded when the script is written, and as
$cryptcreate is already used to store the cryptsetup call, this seemed
to me to be the most straightforward way to guarantee that the
cryptsetup call to unlock the cryptroot from the shell is identical to
the cryptsetup call at the console (and likewise the two crypttarget
tests should always test the identical target).
Chris
diff -rNu cryptsetup-1.0.6~pre1.orig/debian/control cryptsetup-1.0.6~pre1/debian/control
--- cryptsetup-1.0.6~pre1.orig/debian/control 2008-02-16 02:05:16.000000000 +0100
+++ cryptsetup-1.0.6~pre1/debian/control 2008-02-16 02:05:45.000000000 +0100
@@ -12,7 +12,7 @@
Package: cryptsetup
Architecture: any
Depends: ${shlibs:Depends}, dmsetup
-Suggests: udev, initramfs-tools (>= 0.91) | linux-initramfs-tool, dosfstools
+Suggests: udev, initramfs-tools (>= 0.91) | linux-initramfs-tool, dropbear, dosfstools
Conflicts: cryptsetup-luks (<= 1.0.1-8), hashalot (<= 0.3-1)
Replaces: cryptsetup-luks (<= 1.0.1-8)
Description: configures encrypted block devices
diff -rNu cryptsetup-1.0.6~pre1.orig/debian/initramfs/cryptroot-script cryptsetup-1.0.6~pre1/debian/initramfs/cryptroot-script
--- cryptsetup-1.0.6~pre1.orig/debian/initramfs/cryptroot-script 2008-02-16 02:05:16.000000000 +0100
+++ cryptsetup-1.0.6~pre1/debian/initramfs/cryptroot-script 2008-02-16 02:12:19.000000000 +0100
@@ -195,13 +195,26 @@
PASS="$(cat /dev/.initramfs/usplash_outfifo)"
echo -n "$PASS" | $cryptcreate > /dev/null 2>&1
else
+ cat <<EOF >/sbin/unlock
+#!/bin/sh
+
+$cryptcreate
+if [ -e "/dev/mapper/$crypttarget" ]; then
+ killall cryptsetup
+fi
+EOF
+ chmod 755 /sbin/unlock
$cryptcreate < /dev/console > /dev/console 2>&1
fi
if [ $? -ne 0 ]; then
- echo "cryptsetup: cryptsetup failed, bad password or options?"
- sleep 3
- continue
+ if [ -e "/dev/mapper/$crypttarget" ]; then
+ echo "cryptsetup: cryptsetup killed, target unlocked in the background, continuing."
+ else
+ echo "cryptsetup: cryptsetup failed, bad password or options?"
+ sleep 3
+ continue
+ fi
elif [ ! -e "$NEWROOT" ]; then
echo "cryptsetup: unknown error setting up device mapping"
return 1
