Am 20.07.2014 15:42, schrieb Peter Palfrader: > On Sun, 20 Jul 2014, Michael Biebl wrote: > >> Hi, >> >> Am 20.07.2014 11:28, schrieb Peter Palfrader: >>> On Mon, 07 Jul 2014, Peter Palfrader wrote: >>> >>>> } weasel@valiant:~$ cat /etc/crypttab >>>> } sda3_crypt UUID=81402c7d-3819-4860-b71f-ff0f808f599e none luks >>>> } sda6_crypt UUID=4385f6be-9584-4fd9-a3b8-92a2826311a5 /etc/luks/sda6.key >>>> luks >>>> } >>>> } aux1 >>>> /dev/disk/by-path/ip-172.22.118.11\:3260-iscsi-iqn.1992-04.com.emc\:storage.storcenter.sbg.palfrader.org.aux1-lun-0 >>>> /etc/luks/aux1.key luks,noearly >>>> } mailbak >>>> /dev/disk/by-path/ip-172.22.118.11\:3260-iscsi-iqn.1992-04.com.emc\:storage.storcenter.sbg.palfrader.org.mailbak-lun-0 >>>> /etc/luks/mailbak.key luks,noearly >>> >>> It seems systemd does not handle those backslashes that were previously >>> required to escape the colon correctly. >>> >>> If I remove those, systemd brings up the interfaces. It's still very >>> slow (because it tries to get them before iscsi is up). >>> >>> So, >>> - it should correctly handle backslashes, >>> - it should probably not block/timeout on bringing up "noearly" interfaces. >> >> What exactly is the effect of noearly in general and in context of iscsi >> (under sysvinit)? > > man crypttab(5) has this to say: > > | noearly > | The cryptsetup init scripts are invoked twice during the boot > | process - once before lvm, evms, raid, etc. are started and once > | again after that. Sometimes you need to start your encrypted > | disks in a special order. With this option the device is ignored > | during the first invokation of the cryptsetup init scripts. > > So, previously on my system, cryptdisk-early would run and bring up the > local cryptdevices that were backed by partitions. Then, after network > and iscsi was up, it'd run again and bring up the remaining devices. > > Currently, with systemd, it gets to where it'd like to bring up the > crypt devices. As network and open-iscsi aren't up yet, it wastes a lot > of time waiting for block devices that will never appear (at least not > without further action later in the boot process).
Hm, k. So I guess we'd need something like a cryptsetup-pre.target, where certain units can hook into (via Wants/Before), network.target being one of them. And devices flagged noearly would get a dependency on this target and be ordered after it. Lennart, do you have a different/better idea how we could handle such setups which have more complex requirements, like cryptsetup devices being backed by iscsi which in turn requires network access? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
