On Sat, 12.02.11 09:11, Andrey Borzenkov ([email protected]) wrote: > Currently all encrypted disks found in crtypttab are activated (by > adding WantedBy cryptsetup.target) unless cryptsetup contains noauto. > > Unfortunately noauto is not even documented in cryptsetup man page and > is unlikely to be present on any system. The standard behaviour, found > at least in RH-like init scripts is to activate those encypted > containers that are needed for file systems mounted on boot > (respectively, for those that are swap).
The "noauto" option originates from Debian. It appeared quite useful to me which is why I added it to the generic systemd implementation of the crypto stuff. 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? > 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. > 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. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
