Andrei Borzenkov <arvidj...@gmail.com> writes: > В Fri, 20 Feb 2015 10:56:41 +0100 > Jan Synacek <jsyna...@redhat.com> пишет: > >> First version of the patch that allows rd.luks.key to be specified almost >> the same way as dracut can >> read it. >> > > This sounds like working around dracut bug. Dracut already has code to > deal with it, it updates /etc/crypttab and reload systemd to run > generators but it completely ignores keyfile parameter in non-systemd > branch. > > The code in dracut for systemd-enabled case does > > echo "$luks $dev - timeout=0,$allowdiscards" >> /etc/crypttab > systemctl daemon-reload > systemctl start cryptsetup.target > > which means it won't even use keyfile anyway. > > Why do not you simply mount device here? Dracut already has code to > temporary mount keyfile device in non-systemd-enabled case, you can > simply reuse it.
I've done some digging around and... I don't get it. It makes sense to put the functionality to dracut, so why is this implemented *differently* in both dracut and systemd? Why is there code to make this systemd-independent task in a systemd-enabled and non-systemd-enabled case? It's quite confusing. >> 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? >> > > Dracut creates unique name for it already. Ok, I found the code. Thanks for the pointers! >> 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(-) >> > -- Jan Synacek Software Engineer, Red Hat
signature.asc
Description: PGP signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
