On Monday, August 15, 2016 08:41:31 AM Rich Freeman wrote: > On Mon, Aug 15, 2016 at 5:06 AM, J. Roeleveld <jo...@antarean.org> wrote: > > On Monday, August 15, 2016 04:32:29 AM Rich Freeman wrote: > >> It is also somewhat dependent on a correct fstab. Don't take that for > >> granted: the kernel doesn't look at fstab at all when mounting root, > >> and neither do most of the other tools, so if your root partition > >> isn't correctly defined in fstab you might never know it and dracut > >> will get confused. If nothing else once it does have it correctly > >> mounted it will read fstab and then mess it up when it re-mounts root > >> per "your" instructions. > > > > I understand what you're saying. Except in my case, that wasn't the cause. > > Oh, I agree. I just said that in lieu of replying to every single > other email in this thread. :) > > >> If you just need to tweak dracut behavior you may be better off with a > >> dracut module. They're just shell scripts and pretty simple to write. > >> That lets you tweak something at some point during boot without having > >> to build the entire thing yourself. > > > > This actually had (or has, not bothered to check current status) a > > distinct > > lack of usable documentation. Looking for clear howto's on creating my own > > (embedded into the kernel) initramfs was a lot quicker. > > Yeah, I found this frustrating as well. > > This may or may not be helpful: > https://rich0gentoo.wordpress.com/2012/01/21/a-quick-dracut-module/
It shows where to find it and add custom steps. For my scenario, I'd need to first find where the code is that currently handles it. Disable that and insert my own in its place. The majority works, except for it asking for my passphrase multiple times, which, in Dracut, might actually be handled by "cryptsetup" itself. In which case I'm stuck. In my script it's handled via: ---- # Obtain key through loop device /sbin/losetup /dev/loop0 /key.iso || rescue_shell /sbin/cryptsetup -T 5 luksOpen /dev/loop0 key || rescue_shell # Unlock the root partition /sbin/cryptsetup --key-file /dev/mapper/key luksOpen --allow-discards /dev/sda2 sda2 || rescue_shell /sbin/cryptsetup --key-file /dev/mapper/key luksOpen --allow-discards /dev/sdb2 sdb2 || rescue_shell # Clean up the loop device /sbin/cryptsetup luksClose key /sbin/losetup -d /dev/loop0 ---- > In general the benefits of using dracut are the benefits of using > anything that somebody else maintains. You could replace openrc with > a single shell script as well, or a fair bit of systemd. That doesn't > mean that this is really the optimal approach. If I'd need the level of complexity Dracut allows, I'd look into it. But all I need to do is maintain a few small and simple files and the kernel-build handles all the heavy lifting. > >> And since it uses udev it is fairly robust against things like adding > >> a drive and now the kernel re-letters everything. > > > > If I were using normal partitioning, I wouldn't need an initramfs. > > An initramfs is beneficial even if you don't "need" one. To start > with it allows you to build a more modular kernel, which is especially > beneficial if you aren't customizing your kernel for every host. It > also tends to be more robust when something goes wrong. You end up > having a rescue shell even if root doesn't mount, more robust fsck/etc > during early boot, and it is going to be a lot smarter when you > add/remove a drive (since root can be identified by UUID or label). > > Dracut is becoming common enough that I think it is worth learning... For binary distributions, I tend to stick with the supplied kernel and initramfs. Those are usually for running software from big vendors like Oracle or IBM. For the rest, it's quicker to make the few changes needed to the init-script. I don't have a large serverfarm requiring that level of standardisation. -- Joost
