Bug#370556: initramfs-tools: does not handle cryptroot-on-lvm properly
On June 6, david@2gen.com said:
> I guess this isn't very clear, but if you have an encrypted root
> partition on top of lvm/evms/md, you have to point the root
> variable to the underlying lvm/evms/md partition (this is a
> limitation of how the current initramfs system works).
Isn't there a risk that doing this will screw up some other subsystem
that relies on root= to be set legitimately? Maybe i'm being too
conservative about changing the semantics of the root= kopt, but it
strikes me as pretty confusing. i can't think of a single kernel
parameter that more people (and probably packages) already expect to
behave a certain way than "root=whatever". Even "vga=791" and "ro"
are probably more obscure :)
> So, could you try to just change the root variable to
> root=/dev/mapper/squeak0-rt and boot? Skip the cryptopts variable
> suggested above, it should already be set to something sane via a
> config file in the initramfs.
i haven't tested it on this rig yet, but i'll give it a shot with an
untweaked initrd when i get a chance. My big worry, though, is not
how well this fares on a stripped-down machine like the one i'm
testing on, but how it interacts with a machine with a ton of
packages, any of which might want to interpret root= for some reason.
> I agree that they're not pretty. OTOH, once all bugs are ironed
> out, they shouldn't be necessary save for exceptional cases. I'll
> write more documentation when the dust settles and the scripts
> become more stable.
Agreed here. The current cryptroot initramfs scripts actually do a
good job auto-detecting what options to use by default in the new
initramfs, and they successfully relieve the end user from having to
specify anything this ugly on the command line (assuming that
/etc/crypttab is fully-specified, as we discussed in #370180).
> I think a better approach (which I've suggested before) would be to have a
> list of devices that should be present before we try to mount root. That
> list could then contain md/lvm/evms/crypto/dmraid devices as necessary, in
> the proper order.
>
> 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
>
> Then each script can inspect the list and bring up the next device in the
> order if it knows how to do so.
The more i think about it, the more i think this idea is the way to
go. In fact, we might even be able to get nfsroot handled here as
well. It also gets around some of the not-always-true assumptions of
the current prereqs() infrastructure. For example, does lvm really
always depend on md, and not the other way around? Couldn't you RAID
together a set of LVs? And what about LVM-on-RAID-on-crypto, as
opposed to crypto-on-LVM-on-RAID?
But: how much infrastructure would we need to make this work? i don't
want to see initramfs-tools become so clever that it's buggy :)
Here's a stab at a set of terms and a strategy to handle this. I've
modeled it off of the current hooks/scripts division in
initramfs-tools, which i figure it would augment (but not replace).
If anyone else has another writeup someplace, please send me a link!
i don't want to reinvent the wheel here.
---------------------------------
Certain packages are "device-enablers". device-enablers provide a
single script to initramfs-tools to run at boot time. The script
should accept an argument that is a single device. It should:
0.a) decide if the device is one that this package can enable, and
0.b) enable it if possible (cryptsetup the device, make new md
devices, bring up the network, etc)
initramfs-tools should provide the framework that runs these scripts
(according to some priority ordering between scripts?) on each
successive entry in the rootdep= list, testing after each run to see
if the device is present and readable. rootdep= should be specified
by the kernel command line (higher-priority) or by a configuration
file in the initrd (lower-priority).
device-enabler packages should also provide a hook script for
initramfs build time. The hook script should take a specific block
device as an argument, and determine:
1.a) if the given block device is a responsibility of this package, and
1.b) if so, what additional block devices it might need to recreate
this block device at boot time, and reports them back.
initramfs-tools should provide a framework at ramfs build time that
picks the current root device, passes it to these scripts, and uses
their responses to recursively build up a proper rootdeps= list
automatically (so the end user doesn't have to specify it by hand).
Any device-enabler package that claims any device in the entire chain
should have its necessary tools and scripts included in the initrd.
---------------------------------
Whew! This seems like a big spec to fill out...
Is this something that the initramfs-tools team could collaborate with
the yaird team on also? We probably don't want two competing ways to
specify this stuff. i'm embarrassed to say that i haven't looked at
yaird's equivalent functionality for bringing up the root block device
yet.
--dkg
PS is there a list somewhere of all the possible device-enabler
packages in debian? Should we be compiling one? the ones i can think
of off the top of my head are:
udev
mdadm
lvm
cryptsetup
dmsetup
ifupdown
nbd-client
nfs-common?
but i'm sure i'm missing something.
Reply to: