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

[martin f krafft]

also sprach Christoph Anton Mitterer <calestyo at scientia.net> [2011.03.07.1410 +0100]:
> - making setups possible which do not work at all currently (e.g.
> lvm on top of cryptsetup)
> - 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.

> - "unifying" the way how the different block-device packages (nbd,
> mdadm, lvm2, cryptsetup, etc.) handle initramfs, init-scripts, etc.

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.

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.

> - allowing clean shutdown, which is currently not possible if the
> rootfs is on md/dm-crypt/etc.

Does it matter?

> 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.

> > (I never found out about this until now)
> ^^ I posted this once with some replies on d-d.

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. ;)

> > 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?

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.

-- 
 .''`.   martin f. krafft <madduck at d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 1124 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: <http://lists.alioth.debian.org/pipermail/pkg-mdadm-devel/attachments/20110307/13eb511b/attachment.pgp>