Re: [MEETINGS] Cancel or reschedule meeting?
I'm not able to attend the meeting this weekend, so following Davide's
example, I'll also post a status report for integration of crypto and
the version of partman-crypto which is in unstable/testing is ancient and
lacks the proper dependencies. A new version (5) has been in the
ftp-master NEW queue for a bit more than a week. New uploads of
partman-crypto are on hold until it has been processed. This is currently
the biggest blocker for working (dm-crypt) crypto support in partman.
o partman-crypto device-mapper support
the device-mapper support of partman-crypto is now at the point where it
is possible to do a root-on-crypto and root-on-lvm-on-crypto installation
(version 5 or later). dm-crypt support is mostly feature-complete.
I created a partman-auto-crypto package in my personal dir
(d-i/people/alphix-guest). The basic functionality seems to work - it
creates a /boot partition, a swap partition and one large encrypted
partition which in turn holds a LVM PV which is used for the rest of the
partitions (root and possibly /home depending on the recipe).
The benefit of using LVM on crypto is that a single password needs
to be input during boot to access all partitions (instead of one
password per partition).
Looking at the TODO list, partman-auto-crypto needs better integration
with partman-auto-lvm and partman-crypto. Most importantly, shared parts
need to be split out into shared scripts rather than duplicated, this will
also remove confusing and/or irrelevant prompts that are currently
I'll work on this some more in a few days, I believe I will be able to get
it to the stage where it could be moved to trunk during next week. It
relies on the newer partman-crypto though but it will have to go through
the NEW queue as well so partman-crypto should already be in unstable
once that's done.
Apart from the duplicated code, the major blocker right now is that
partman-auto-lvm creates the swap partition outside of the lvm which
partman-crypto refuses to allow (as keys and sensitive data could be
writted to en unencrypted swap partition which would defeat the purpose
of the encryption).
I'll initiate a discussion on debian-devel, debian-kernel and with
yaird/initramfs-tools maintainers next week to see if it would be possible
to change partman-auto-lvm to create the swap partition as a LVM LV.
An alternative solution would of course be to create specific recipies for
partman-auto-crypto, but I'd like to avoid it if possible since they would
be copies of partman-auto-lvm with the exception of the swap partition.
cryptsetup-udeb 2:1.0.3-2 which contains important fixes for LVM/crypto
combinations has migrated to testing. Some more fixes are probably
necessary for root-on-crypto-on-lvm (as opposed to root-on-lvm-on-crypto
which works), they should be present in the next version of
the recent upload (version 38) should fix the bugs introduced by the
rewrite and integration of the lvmcfg functionality which broke
partman-auto-lvm and introduced some formatting bugs.
Together with the new lvm2-udeb (2.02.06-2), this should restore both
partman-lvm and partman-auto-lvm to working order.
still needs to be written for partman-crypto, partman-auto-crypto and
cryptsetup initramfs hooks. It's possible that it also needs to be
updated to account for the changes to partman-auto-lvm and partman-lvm.
o device locking
as discussed on debian-boot a week ago or so, I've committed a patch
which adds the ability to "lock" partitions or devices (that are in use
for some other system, e.g. as a lvm PV or an encrypted device). The
functionality is there and integrated with partman-lvm and partman-crypto
but there might be other packages which might benefit from it (e.g.