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.
smime.p7s
Description: S/MIME cryptographic signature
