Your message dated Tue, 22 Aug 2023 17:26:05 +0200
with message-id <008d38ba-196b-4010-940a-bc78cbf79...@debian.org>
and subject line Re: Bug#754078: crypt devices not brought online (backed by 
iscsi)
has caused the Debian Bug report #754078,
regarding crypt devices not brought online (backed by iscsi)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
754078: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754078
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: systemd
Version: 204-14
Severity: normal

Hi,

as discussed on IRC, systemd fails to bring up my iscsi-backed crypt
devices.  Before systemd-sysv hit testing and was installed, they
worked.

Also, it seems to spend an awful lot of time bringing them online
(significantly longer than a minute or so).

I booted with systemd.log_level=debug, and put the contents of
/var/log/debug.log up at
https://www.palfrader.org/volatile/2014-07-07-8CnmVmaPpZA/var-log-debug

} 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

sda* are online, aux1 and mailback are not.  Their backing devices exist:
] lrwxrwxrwx 1 root root 9 Jul  7 13:11 
/dev/disk/by-path/ip-172.22.118.11:3260-iscsi-iqn.1992-04.com.emc:storage.storcenter.sbg.palfrader.org.aux1-lun-0
 -> ../../sdi
] lrwxrwxrwx 1 root root 9 Jul  7 13:11 
/dev/disk/by-path/ip-172.22.118.11:3260-iscsi-iqn.1992-04.com.emc:storage.storcenter.sbg.palfrader.org.mailbak-lun-0
 -> ../../sdh

fstab does not reference aux1 and mailbak - they get included using autofs.

Cheers,
weasel

--- End Message ---
--- Begin Message --- On Thu, 14 Aug 2014 20:03:12 +0200 Lennart Poettering <lenn...@poettering.net> wrote:
On Sun, 20.07.14 15:58, Michael Biebl (bi...@debian.org) wrote:

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

Not following here. In contrast to classic sysv the jobs actually stay
queued until the devices show up. If you have iscsi devices that shall
be mounted during boot, then you really need to make sure that iscsi can
work in early boot. Then, if iscsi needs the network, then your network
system needs to be able to run in early-boot too.

I have the suspcicion this works on Fedora already.

But generally, the old Debian scheme of running cryptsetup twice doesn't
really apply to systemd, since we never scan for devices, we just
subscribe to them.

Anyway, still not grokking the actual problem here I must say...


Let's close this issue at this point. I don't think it's helpful to keep this issue open while a lot has changed since 2014.

If there is still something missing, please file a new bug report.

Regards,
Michael

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


--- End Message ---

Reply via email to