On Sun, Apr 10, 2016 at 5:37 AM, Duncan <1i5t5.dun...@cox.net> wrote: > > Tho with the initr*, I did go the dracut route myself. But I'm still not > entirely convinced that I wouldn't have been better off rolling my own, > as I'm still not entirely comfortable with the level to which I > understand, or more accurately don't understand, dracut. Tho I do > understand it well enough to have cut it down to the modules I need, > only, but I still don't understand the scripts at the level I know I > would had I created them myself... >
Well, by this logic you ought to be writing your own kernel as well. How else are you going to deal with a kernel panic? :) Dracut is pretty straightforward though and fairly well-documented. It runs through a series of stages like detecting devices, mounting filesystems, and so on. Plugins can run at any stage, and they also can add files to the initramfs at time of creation. The advantage of using something standard is that somebody else has probably already thought of all the edge cases already, and they'll fix the bugs as well. If you contribute your plugin upstream they'll take care of it for you as well. So, you can just put one line in a config file to add /usr/bin/btrfs to your initramfs and the built-in code will figure out that you'll need /usr/lib64/liblzo2.so.2 installed there as well. Of course, that is just an example as somebody else has already written the btrfs module. I was running into some kind of strange md-raid behavior ages ago and worked around it by writing a quick module: https://rich0gentoo.wordpress.com/2012/01/21/a-quick-dracut-module/ That one is a bit of a hack - I suspect there was some underlying bug in udev or something preventing the raid from being set up by the normal module. I suspect that module would no longer be needed (I've since moved on to btrfs). However, it demonstrated how dracut plugins work - you just define hooks that get run at the appropriate phase. -- Rich
