cryptdisks: altering order of mounting at boot

[Paul <debian-user@lookmumnohands.net>]

Hi all,

I need to mount a small encrypted volume so that I can access a
cryptographic keyfile that unlocks another disk that contains my
/home.

I don't want to end up with a fragile system (especially one that
breaks during an upgrade), so I am asking for your suggestions.


Here is the description of the system:

  1. Debian sid.  Regular use of 'aptitude safe-upgrade', hence the
     requirement to avoid "fragile" solutions.

  2. A solid state disk (SSD) with a hard disk password.  (I
     understand this encrypts the contents... but I don't exactly
     trust it!)

  2a. SSD holds the operating system, but not /home, /var or /tmp.
      See below.

  2b. SSD has a small LUKS encrypted partition containing a
      cryptographic keyfile that can be used to unlock other
      partitions.  A passphrase is used to unlock this partition.

  3. A hard disk (HDD).  This contains LUKS encrypted partitions for
     /home, /var and /tmp.  Although these can be unlocked by
     passphrase, it gets tiresome to enter multiple times, so there is
     a keyfile (see above) that can automate the process.


This is the boot order I want:

  * read passphrase for the small encrypted partition on the SSD (with
    the keyfile)

  * mount that partition as /autounlock

  * now use /autounlock/keyfile to unlock partitions on the HDD and
    mount in their respective places (/home, /var, etc)


Currently, as the system boots it asks for the passphrase, but it can
not unlock the other partitions automatically because
/autounlock/keyfile doesn't exist yet.  (It hasn't been mounted yet.)


I can tell the system to ignore these other partitions (/home, etc) at
boot ('noauto' option in /etc/crypttab), and then later mount them
manually with 'cryptdisks_start', but this can means:

  a) I miss out on the fsck during boot of these partitions

  b) I am unsure of the best place to script the cryptdisks_start
     commands early enough in the boot process (since these partitions
     contain important parts of the filesystem).


So - does anyone have any bright ideas?

--
Paul.