for remote boot/remote unlocking of a cryptoroot system there should be
initrd support at least for a ssh login. i'd suggest:
move the configure_networking (from /script/functions) call from
/script/nfs to /init, after init-premount (just before maybe_break mount):
[ -n "$IPOPTS" ] && configure_networking
(off-topic but relating, so just for completeness: installer should add
an ip=... argument corresponding to the network config to the kernel
boot parameters in menu.lst in case of a cryptoroot install)
mkinitramfs has to add the respective nic-module to the initrd modules
and add the respective entry to /conf/modules if the kernel-entry in
menu.lst has boot parameters containing an ip=... argument.
mkinitramfs schould install dropbear, either just in case of a
cryptoroot setup, or in case of an ip=... kernel boot parameter.
a statically linked minimal version of dropbear probably comes to mind
first. the existing dropbear package contains a dynamically linked
version, but installing this plus the dependencies (libc6 and zlib1g)
proved to work, with a probably acceptable increase in size of the
initrd (here: 6.1m to 9.7m).
add dropbear to the configure_networking line in /init mentioned above:
[ -n "$IPOPTS" ] && configure_networking && /usr/sbin/dropbear
mkinitramfs should add a /etc/passwd with an entry for root, create
/root/.ssh, and copy an authorized_keys file there. i don't have a
conclusion yet where this authorized_keys file should come from, but
thinking of the installer again, the installer should probably create
the keypair in case of a cryptoroot install, and just save them
somewhere in /etc, probably somewhere in /etc/initramfs-tools. the same
location is probably also a good idea to put the
dropbear_[dss|rsa]_host_key files which should be copied by mkinitramfs
to /etc/dropbear (which should be generated by the installer in case of
a cryptoroot install).
this way issuing a cryptsetup luksOpen followed by a vgchange -a y, and
then killing the console's cryptsetup via ssh works.
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org