[Pkg-cryptsetup-devel] checksystem and cryptdisks

[Jonas Meurer]

hello,

i've started with improving cryptdisks and implementing the documented
checksystem.

so far i've done the following changes:
- moved 'option parsing' and 'loopback device setup' code into seperate
  functions
- modified cryptdisks to use lsb_* functions for most of the output
  (unfortunately not all of it yet)
- added a general check for the source device before any action is taken
- splitted 'cryptsetup isLuks' check for LUKS devices from the general
  check for luks (via option), removed all prechecks except this one for
  luks partitions.
- modified the postcheck for LUKS to print only a warning if it failed.

implementing the rest is quite more complex than that:

- implementing a precheck for partition type swap
  all partition tools that i know (*fdisk, *parted) require the disk
  device as argument, and i simply don't know how to get the partition
  type with only the partition device as argument. it is not too hard to
  come from /dev/hda4 to /dev/hda, but what about devfs, raid devices or
  whatever.
  maybe libparted is a solution, but i don't like the idea of another
  dependency only for the sake of this check.

- implementing a precheck for all random filesystems
  as already mentioned, 'fsck -N /dev/...' could be an option, it
  supports all the filesystems for which fsck.<fs> binaries are
  installed. but on the other hand this is not really much, as a default
  debian installation has only fsck for cramfs, ext2, ext3, minix and nfs
  installed.


a last point i would like to raise is, that we should maybe split the
huge cryptdisks script into small include files with functions. first,
the script grows very fast, and new features are not unlikely. second,
we need to consider running the script twice in the boot process, once
for lvm and raid partitions, and once for for the devices provided by
lvm/evms/raid, ...

i would like to improve cryptdisks in a way that it checks for the
source device (it already does), and when the device does not exist, it
simply jumps to the next configured crypto device.

this way running it twice in the boot process would be no problem.

...
 jonas