also sprach Christoph Anton Mitterer <cales...@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@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
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
