On Tue, 2013-12-31 at 11:15 -0800, Russ Allbery wrote: > For whatever it's worth, I've been using systemd on a system with LVM and > dm-crypt (with LUKS) for about a month now, in the dm-crypt -> LVM -> > filesystem mode, and haven't had any trouble. Do you use it on your root-fs? With keyscripts? > The page you linked to makes several assertions that I find curious. That > doesn't mean that they're wrong, but they seem somewhat contrary to my > experience. For example, I'm not sure where "however, for we really > should should try to avoid forcing users to use initramfs images, for > setups where they're not strictly needed" comes from; I've been using > initramfs images for every Debian system I run, and every Debian system > Stanford runs, for so long that I can't remember when we originally > changed. I don't understand why this would be something one would want to > avoid. Well so do I,.. haven't a single system which doesn't use initramfs... OTOH I'm always sceptical about "forcing" people to do so (when e.g. the kernel itself can just happily life without an initrd)... because there might be scenarios I/we can't even think of where it may make sense to run without one. After all, Debian should be the universal OS ;) > Similarly, I'm not sure why the focus on only adding necessary tools to > the initramfs image. Surely this doesn't matter much if the tools are > harmless when unneeded? Well it costs time when creating the initramfs, makes the initramfs image bigger (possibly not an advantage with embedded systems) and the useless stuff has to be decompressed every boot. Sure,... most people won't bother.. but why adding stuff that's not needed... I mean in many cases the initramfs-scripts actually run and do something, even if the respective thing (a filesystem or what ever) is not even present.... and that makes it more likely for problems to occur or performance to be wasted... as if such stuff isn't in place. Neither do we add libreoffice to initramfs ;-) Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature