[Pkg-cryptsetup-devel] Re: RFC: Adding a lvm parameter to crypttab

[Jonas Meurer]

On 21/04/2006 David Härdeman wrote:
> In order to support both the scenario of root-on-crypto-on-lvm-on-something
> and root-on-lvm-on-crypto-on-something, I think it would be a good idea to add
> a lvm parameter to crypttab.
> 
> Some of this could be auto-probed today (especially for initramfs crypto-root)
> but doing so is both fragile (for example, there has been several reports
> already against the lvm detection I added to klibc because it turns out people
> can have both fs and lvm signatures on devices which they do not use for lvm
> any longer) and potentially dangerous.
> 
> So, I suggest a parameter of the form lvm=VG to be supported by crypttab, e.g:
> cryptroot    /dev/sda6    none    luks,lvm=rootvg
> 
> The lvm parameter would let let cryptsetup know that it should also run
> "vgchange -ay VGNAME" after the device-mapper device has been setup. And it
> would also let cryptsetup know that it should try to deactivate and remove the
> vg before it disables the mapping.

a more general solution, and one that seems better to me, is to run
cryptdisks twice in boot/halt process. once before lvm/evms/... have
been started/stopped, and once after.
at start, cryptsetup starts only the existing devices anyway, and is
quiet for nonexistant ones.
at stop, it stops only devices which are not busy anymore.

so all we would have to do, is make "cryptsetup stop" silent for busy
devices, and install additional symlinks in the /etc/rc{S,0,6} dirs.
unfortunately update-rc.d has no support for that yet, and i'm not sure
if it's allowed by policy at all.

but from a technical point of view, i see no problems with running an
initscript twice in the boot process.

what do you think?

maybe we should move that discussion to debian-devel?

> Before I wen ahead and whipped up a patch and filed a bug for this I wanted to
> see if there are any objections or comments to my proposal?

i thought the same for my solution some months ago. that's why i didn't
implement it yet.

but maybe there was simply no reason to run an initscript twice up to
now, and that's the only reason that no infrastructure
(update-rc.d/invoke-rc.d) is implemented yet. in this case maybe a patch
against sysv-rc would be the best.

...
 jonas