Bug#754078: crypt devices not brought online (backed by iscsi)

[Michael Biebl]

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 at 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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140720/14633198/attachment-0002.sig>