First version of the patch that allows rd.luks.key to be specified almost the same way as dracut can read it.
The solution creates a temporary mount unit "mnt.mount" that the generated cryptsetup service wants. The partition where the keyfile is then mounted to /mnt and the absolute path to the keyfile is changed so it points to this temporary mount instead. I'm not sure if temporarily mounting something to /mnt in initrd is safe. If not, what would be a preffered way to do this? Also, there's a problem that I'm not sure how to solve. If the keyfile_device is somehow misspecified (for example, the uuid simply isn't valid), the boot stalls. I believe that this was one of the problems in https://bugzilla.redhat.com/show_bug.cgi?id=905683. I was thinking about using udev to verify the uuid and its device, but I'm not sure if this makes sense to do in initrd. Any pointers would be appreciated. Once the above problems are sorted out, an extension of this patch (perhaps another patch?) would be to also support the third argument that rd.luks.key can take in dracut. Jan Synacek (1): cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device src/cryptsetup/cryptsetup-generator.c | 163 +++++++++++++++++++++++++++++++--- 1 file changed, 150 insertions(+), 13 deletions(-) -- 2.1.0 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
