В Thu, 23 Apr 2015 00:48:38 +0200 Lennart Poettering <lenn...@poettering.net> пишет:
> On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote: > > Sorry for the late review. > > What's the precise background of this? Can you elaborate? Is there > some feature request for this? > There are multiple bug reports that switching to dracut with integrated systemd breaks ability to auto-setup encrypted devices using keyfile on external USB stick. > What does this actually do? Is the specified key file read from the > specified device? It reads keyfile from filesystem on device identifed by keyfile_device. > The order of keyfile:device sounds weird, no? > Shouldn't it be the other way round? > keyfile is mandatory, keyfile_device is optional and can be omitted. I believe dracut looked at all existing devices then. This order makes it easier to omit optional parameter(s). In any case it became dracut API which is too late to change. > Is this specific to Dracut so far? Is this widely used, and something > that we really want. > I can say about dracut only but yes, it is used and it is serious regression when it is used comparing with pre-systemd version. > > 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. > > Well, I'd place this in /run somewhere. Maybe > /run/systemd/cryptsetup/mount or so... > > > 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? > > What does temporarily mean? When is this unmounted? > To fetch keyfile dracut needs to mount USB stick. This mount is not normally needed after cryptomount setup is completed. > > 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. > > Things like this are necessarily racy: at boot time devices are not > probed yet, and just start to appear. That means if you enumerate them > it is highly likely your block device has not shown up yet, but will > so shortly. Hence you need to wait for them. But that means you cannot > really distuingish the case "not shown up yet, but will" from "will > never show up"... > > > 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. > > Which is? > LUKS device to which key applies. Can be wildcarded. > Lennart > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel