On Mon, 14.02.11 08:45, Andrey Borzenkov (arvidj...@gmail.com) wrote: > > Hmm, they way I read > > http://git.fedorahosted.org/git/?p=initscripts.git;a=blob;f=rc.d/init.d/functions;h=1256d10e452816a4a60dbfddfd31cb8b292886c8;hb=HEAD > > we actually activate all crypto devices, there is no matching up against > > fstab? > > > > You are right, I was fooled by other code in rc.sysinit before > actually checking. Still it means some room for improvements, doe not > it? :)
Well, but major changes in behaviour might not be advisable. > > >> So after switching to systemd user is suddenly presented with password > >> requests which (s)he never expected before. Nor are those password > >> requests necessary, as these encrypted containers may be opened only > >> on demand, not even every time system is booted. And in case of shared > >> system user may not even know passwords for all units. > > > > I am not sure how else this should be working. The thing is that before > > you decrypt it you cannot know what file system a device contains. It is > > hence impossible to figure out which crypto disk you need to decrypt and > > which one you don't. Or to be more explicit: if you have a line with > > LABEL=foo in fstab, how are you supposed to find the fs with this label > > in its superblock without actually having decrypted it? As long as you > > see only encrypted devices there is no way to figure out their UUID or > > LABELs. > > > > The only reason to use LABEL or UUID is because you do not know how > your device will be named next time you boot. With device mapper > devices naming is completely predictable. Arguably there is absolutely > no reason to use LABEL with crypto devices; using > /dev/mapper/container is pretty much enough. Well, I think it's a good thing to mount by uuid, even if things happen to reside on dm. I think it is a good idea to not bind our higher levels of the stack unnecessarily to layers much lower. > >> So removing default WantedBy=cryptsetup.target results in expected > >> (well, compatible) behaviour - cryptsetup unit is implicitly pulled in > >> by mountpoint (I have not tried swap but I assume it is the same) if > >> this mount point is auto-mounted on startup. > > > > No, this doesn't work, see above. > > it depends, see above :) > > So may be systemd could offer boot trime optimization thus encouraging > distributions to change from LABEL/UUID on encrypted devices (assuming > anyone is using it that is) to using device names? Hmm, I am not necessarily convinced this is even a good idea. Dunno. > Does something like this make sense: > > - if crypto device name is present in /etc/fstab, do not add > dependency on crypto.taget, rather rely on target being auto-pulled by > corresponding mount unit? Hmm, not convinced. A mount point might not be the only reason why a device is needed? And fstab is not the only place for mounts to be configured? Dunno. I think the right answer to this problem is "noauto", since things become deterministic by that. Otherwise things might become fragile since depending on the configuration of one "consumer" of a device (i.e. the mount) the system behaviour for *all* "consumers" would change. Also, this would be quite a deperature from the current behaviour. > This also adds additional advantage by allowing to display file system > name in password prompt. Currently prompt is mostly useless - I have > on my test VM dozen of hard disks all with identical ID_MODEL - so I > have no way to know which one is prompted for. Yupp, this is a valid point. We probably should change our cryptsetup implementation to use the eventual mount point name if there is one and only fall back to ID_MODEL if we cannot figure it out. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
