Bug#616729: mdadm includes stuff in initrd even if this is not needed

[Christoph Anton Mitterer]

Well I guess this ticket is not the right place for philosophical
discussions on which setup may be required by people.


On Mon, 2011-03-07 at 21:37 +0100, martin f krafft wrote:
> > - solving other problems on the way,... e.g. lvm2 cannot boot as
> > it's initramfs-scripts are broken (although the maintainer ignores
> > this)
> These work fine for me btw.
Taking my lvm->dm-crypt->filesystem example...
The root-kernel-parameter is correctly set to the device holding the
root-fs (which is e.g. something like /dev/mapper/encrypted-root).
The lvm initramfs-scripts however misuse this parameter as the one
holding LVs which should be activated.
And as these scripts simply exit if the device name doesn't match IIRC
two patterns.


> Other than aesthetics, is there a real benefit in this? All these
> block devices are different in subtle ways, so I wonder if they can
> even be unified.
Surely not completely... but e.g. they could use the same program to
build up a the hierarchy of blockdevices (below e.g. root-fs) and use
that to find out whether they are needed or not and...

> Also, once unified, you'd need a dependency mechanism. And now
> imagine a situation where you have MD→LVM→LV+dmcrypt→LVM — you'd
> need the LVM setup to run twice with different logic.
... at which stages they're needed with which config.

Nevertheles,.. I've never claimed that's easy... but in the end it would
be worth it, IMO.
Currently only the schema, physical->mdadm->lvm->crypt->fs (IIRC) is
supported,... and I've often seen requests by people, wanting to
implement much more complex schemas, even involving NBD or so ;)


> > - allowing clean shutdown, which is currently not possible if the
> > rootfs is on md/dm-crypt/etc.
> Does it matter?
Well I'm not sure whether you follow all that filesystem and
block-layers barriers...
I doubt that really in every situation data consistency is fully
guaranteed, if all those devices are simply force-closed by the kernel.


> > Also allowing things like securely shutting the system down (which
> > is currently not possible with dm-crypt.
> I am somewhat hesitant to accept this as a real threat.
Well one can always argue, that there are much weaker parts in the
chain,... but actually there are several papers (even youtube videos)
out there, which show how easy this is.
Just ask Milan Broz (dm-crypt/cryptsetup upstream) he can probably tell
you nice stories on that =)


> I do not read all of d-d anymore, and you probably did not include
> 'mdadm' or my name in the mail, so I did not see it. ;)
Sorry ;)

I mean the general problem here are, that we'd need for this
(http://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices) to become true fetch really all the affected maintainers...
And probably chance many parts of initramfs-tools and the boot-process
(well at least the shutdown process, as we'd probably need something
like an un-initramfs).


> > > It's just very brittle and thus dangerous. Adding a few kilobytes to
> > > the initramfs is a lesser concern, isn't it?
> > Well of course,... nevertheless, keeping it small should be a long term goal =)
> Really? Given how storage space and memory grow much faster than
> initramfs files?
Well for desktops this is probably no problem,... but what about embedded devices?
Ok you might argue that they typically don't use mdadm,.. but other
blocklayers (cryptsetup) are often common with them.
Admittedly, the goal of keeping it small is rather out of perfectionism
and cosmetic reasons ;)


> We should probably move this discussion to d-d. Feel free to forward
> my mail there. I do not have a reference to your thread at hand,
> else I would.
Done with:
http://lists.debian.org/debian-devel/2011/03/msg00374.html


Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5677 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-mdadm-devel/attachments/20110307/a9dd0b72/attachment.bin>