Hi. IIRC, I've already posted this here some time ago... A few days ago now, I've submitted #616729, suggesting Martin, that one could possible improve mdadm's initramfs-hooks to only include something in the initramfs, if really needed.
That turned out to become a more general discussion between him and myself, again about the ideas of what I've once called "advanced Startup/Shutdown with multilayered block-devices". In his last reply he suggest me, that we should move discussion back to d-d... so here I am. I've once wrote a wiki article down, where I've started to collect some ideas: http://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices Might also be worth to read the #616729, mentioned above. The basic idea is, to make startup/shutdown, with or without initramfs, powerful enough, to handle all kinds of block devices hierarchies that should be set up. Most important of course, in order to mount filesystems, and most important there, in order to mount the root-fs and to make resume devices available in order to boot. And the same for shutdown, all blockdevs should be (in their order) cleanly be stopped/removed/etc. This doesn't only safe us from data corruption (just imaging that the block level barriers in the kernel don't work as expected), but also can have security implications (e.g. dm-crypt being used for the root-fs). It's quite clear, that a real generic solution could be very complicated, it might not be possible to implement it dynamically (e.g. auto-find everything) but static rules in the (e.g.) initramfs might be required (actually most likely). It may also require an event based boot-system. Worst, it would require to get all the affected maintainers on board, which does not only mean the maintainers of block-device-tools (lvm2, dmsetup, mdadm, cryptsetup, ndb, loop-devices, multipath-tools , etc. etc.) but also the booting-guys (sysvinit, initscripts, ....) Well, I'm curious to see whether other people find it worth, to implement "all this". Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
