More results from my Systemd experiments
As of May 5 I sucessfully ported my "cryptall" package that unlocks all encrypted disks with one passphrase call without making a keyfile to dracut-037-1 from the Debian repos. A normal systemd/dracut boot with an encrypted root and home on an encrypted md raid normally will call the passphrase at least 4 times. I suspect a race condition between the appearance of the decrypted volumes in /dev/mapper and systemd's cryptsetup generator not finding the volume and trying again. I ran into a similar race condition in my own script when running under systemd and using the systemd password agent. This was fixed simply by slowing the script down a bit with tests to support more options. Now my code can unlock both volumes with a single passphrase call every time. Best of all, it works with or without Plymouth, and supports both LUKS and non-LUKS volumes. I will probably also drop my keyfile support and test to detect it back into this script, they are in the initramfs-tools version.
Originally Posted by Luke
Next up: I've gotten Plymouth to work in Dracut/systemd, but only in the "text" theme, and only using the Debian version hand-installed over the Ubuntu version which uses different library locations. I need to first get the Ubuntu version to work by itself, then somehow get the script themes (which include my custom one) to work. Worst case is I might have to wait for dracut to mature a bit in Debian so someone else can get systemd to run plymouth directly and with theme support. Anyway, once that happens my boot unlocker and Plymouth theme should now be drop-ins, so I have nothing to fear from Systemd.
One security perspective: If your init is systemd but you do NOT use it in the initramfs, anyone messing with your initramfs while you are out is going to have a harder time getting their code to run after the pivot-root, especially if they bring code meant for Upstart. On the other hand, I would advise making sure your network cannot be reached early in the boot process, even if your systemd install supports early network access if you use encryption. That might be why dracut uses a separate package for network filesystems/boots.
One of the complaints has been about the volume of material that often must be used on the kernel command line. For controlling a dracut systemd booter, most of this gets written as rd.(something), like using rd.auto=1 to get raid detection but rd.luks=0 to keep systemd's native cryptsetup from running in parallel with my own unlocker. I do agree that systemd devs should insure that no command line switch used in systemd ever uses the same wording as one used by the kernel, nor overlaps that used by anything else. Meanwhile kernel devs should avoid in the future using anything like rd.(anything) for kernel functions.
8PM update: Plymouth in dracut/systemd
As of 8PM May 6 I now have Plymouth working with my custom theme in dracut. Turned out I had to use the Debian version which supports Dracut and Systemd, my efforts to port it to Ubuntu's lib locations flopped for now. Only thing was-my theme's .plymouth file still referred to the old locations-and I had NOT looked in that file! Works now, though I can't get systemd itself to start it yet so scripts have to both start it, and momentarily stop it before the pivot-root or it will hang.
Originally Posted by Luke
Good enough now to be my default booter, the rest is luxuries...