On June 7, [EMAIL PROTECTED] said:
> On Tue, 06 Jun 2006, David Härdeman wrote:
>
> > E.g. for root-on-lvm-on-crypto-on-lvm-on-raid-on-two-hds
> > rootdeps=/dev/hda,/dev/hdb,/dev/md0,/dev/mapper/basevg-baselv,/dev/mapper/cryptdevice,/dev/mapper/mainvg-rootlv
>
> nack, this adds extra complexity with not much gain.
> evms is pretty contained and does not need that,
> also we want to autodetect so far as as possible.
While it does add extra complexity, i don't think this is in conflict
with the goals of autodetection, given that the autodetection could
take place at initramfs-creation time (see my proposal from the
previous e-mail).
> i would not know of another usage than cryptoroot itself, which is
> still quite specialized even if easy and fun with luks.
Are you saying that all block device subsystems (with the exception of
cryptroot) are guaranteed to be set up in a pre-determined, static
ordering? Aren't many of them (dmsetup, lvm, md) essentially ways of
creating new block devices based on existing block devices? This
implies potential for a shuffled ordering to me, but i'm open to
hearing arguments against it.
If cryptroot is really the only exception (and will remain the only
exception), perhaps we could find a way that cryptroot could advise
the other subsystems what it needs, without forcing the user to
specify by hand, and have cryptroot run two scripts: once before the
chain of other subsystems, and once after the chain, to handle
whichever layer the system is configured to enable the crypted
device.
> please take care to document for the cryptoroot on lvm user what
> they need to pass as root param.
This seems like it goes against the goal of autodetecting things as
far as possible. If we can find a clean way to autodetect the
settings for crypt-on-lvm (or crypt-on-RAID, or crypt-on-evms, etc), i
think it is worth considering.
Having debian transparently support crypted root filesystems on
sophisticated block-device subsystems would be a big win.
Thanks for all your work on this!
--dkg
