fails on SailfishOS 4.0

[fuchsmich]

In journalctl I find:

systemd[1]: dev-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.device: Job dev-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.device/start failed with result 'timeout'.
systemd[1]: cryptosd-luks@crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.service: Job cryptosd-luks@crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.service/start failed with result 'dependenc
systemd[1]: Dependency failed for Open DM-Crypt LUKS on SD-card crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.
systemd[1]: Timed out waiting for device dev-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.device.
systemd[1]: dev-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.device: Job dev-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.device/start timed out.

also I found this:

# systemctl --all --full -t device |grep luks
dev-crypto_luks_cc05650d\x2d0126\x2d4bc8\x2db8e5\x2da1fe25606f6f.device                                                                               loaded active   plugged /dev/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f                                                         
dev-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.device                                                                                   loaded inactive dead    dev-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.device                                           
dev-disk-by\x2did-dm\x2dname\x2dluks\x2d3f058b38\x2d3100\x2d4fe8\x2da88e\x2dc5d9a8d3bfc7.device                                                       loaded active   plugged /dev/disk/by-id/dm-name-luks-3f058b38-3100-4fe8-a88e-c5d9a8d3bfc7                                             
dev-disk-by\x2did-dm\x2duuid\x2dCRYPT\x2dLUKS1\x2d3f058b3831004fe8a88ec5d9a8d3bfc7\x2dluks\x2d3f058b38\x2d3100\x2d4fe8\x2da88e\x2dc5d9a8d3bfc7.device loaded active   plugged /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-3f058b3831004fe8a88ec5d9a8d3bfc7-luks-3f058b38-3100-4fe8-a88e-c5d9a8d3bfc7
dev-mapper-luks\x2d3f058b38\x2d3100\x2d4fe8\x2da88e\x2dc5d9a8d3bfc7.device                                                                            loaded active   plugged /dev/mapper/luks-3f058b38-3100-4fe8-a88e-c5d9a8d3bfc7   

my conclusion is, there is sth wrong in the udev-rule creating the cryptosd-luks@.service. Maybe the char escaping in newer systemd has changed.

[Olf0]

Thank you very much @fuchsmich for your report.

While the journal entries clearly show, that the crypto-sdcard's systemd units for mounting stumble across an incorrectly unescaped (as per systemd-escape) device path (all \x2d shall be unescaped to -, not to x2d!), the second output you provided is more interesting:

# systemctl --all --full -t device |grep luks
dev-crypto_luks_cc05650d\x2d0126\x2d4bc8\x2db8e5\x2da1fe25606f6f.device   loaded active plugged   /dev/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f                                                         
dev-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.device   loaded inactive dead    dev-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.device                                           
[...]

The same device appears twice:

• Once (first entry / line) correctly escaped, active, plugged and correctly unescaped at the the end of the line: This seems to be working fine!
• Then (second entry / line) incorrectly escaped (the backslashes are missing), inactive, dead and incorrectly unescaped (i.e., not at all, due to the missing backslashes) at the the end of the line. Systemd also decided that this unescaping is not a a path conversion: The escaped "-" are not unescaped to "/" and the suffix (here: .device) is retained. This cannot work!

my conclusion is, there is sth wrong in the udev-rule creating the cryptosd-luks@.service. Maybe the char escaping in newer systemd has changed.

Well, it needed many weeks of research to discover the workaround in pull request #2 per systemd-escape in the udev-rules.
This also resulted in filing a Systemd RFE, in which the issue (neccessity for working around the inability to properly unescape in an instanciated unit file by "pre-escaping" per systemd-escape) was ultimately understood by a Systemd developer, acknowledged, filed as RFE ("request for engineering") and ... nothing.

Yes, something must have been changed (and the systemd package was altered and updated from v225 to v238 in SFOS 4.0.1: search for ### systemd in its changelog), I just checked on my production phone (XperiaX@SFOS3.2.1) and things look "normal" there.

I will try to upgrade one of my testing devices soon after SFOS 4.0.1 has reached GA (general availability) status and take a look at it, then.

[fuchsmich]

How can I help you? Should I run any commands?

[Olf0]

Well, IMO primarily you should try to help yourself, as nobody else seem to have run into this issue yet, presumably because noone of the ~20 crypto-sdcard users has subscribed the "Early Access (EA)" channel of SFOS with their production device.
As I know and see (above), that you are quite command line savvy and likely willing to read documentation (man pages etc.) properly, I rather provide some structural guidance.

As some things seem to run O.K., I would first follow that route: It may provide a workaround to get things going again, plus some analyses may provide more insights for a proper fix, even if not primarily pursuing this.
Side note: I am typing the following commands, without having tried them. There may be typos, thinkos, incorrect option names etc.!

1. How do the "O.K." and other entries look like: ls -l /dev/crypto*
   -> Should be symbolic ("soft") links to their basic device / partition.
2. Status of units creating them and the ones mounting them:
   1. systemctl list-units -l "*crypto*"
   2. systemctl status -l "*crypto*"
3. Then look for decrypted devices: ls -l /dev/mapper/crypto*
4. Is the correct (, presumably only) one mounted? mount | fgrep crypto

[fuchsmich]

First of all, it's always a joy reading your detailed and well written posts!

Second: 4.0.1 isn't EA anymore since yesterday. ;) I switched from X to XA2, so it happend, that I flashed 4.0.1 to my phone yesterday, after the touchscreen had some problems.

Third: I wrote non-template systemd units replacing %i and %I manually. I modified the udev rule ot call this systemd unit. The mount service doesn't start automatically, but I had no time investigating that, yet. But the card mounts, when I run systemctl start mount-cryptosd-myluks.service. I'm glad I got my backups back.

# ls -l /dev/crypto*
ls: /dev/crypto*: No such file or directory

# systemctl list-units -l --all "*crypto*"
UNIT                                                                                                                                                      LOAD   ACTIVE   SUB     DESCRIPTION
dev-crypto_luks_cc05650d\x2d0126\x2d4bc8\x2db8e5\x2da1fe25606f6f.device                                                                                   loaded active   plugged /dev/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f
dev-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.device                                                                                       loaded inactive dead    dev-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.device
dev-disk-by\x2did-dm\x2dname\x2dcrypto_luks_cc05650d\x2d0126\x2d4bc8\x2db8e5\x2da1fe25606f6f.device                                                       loaded active   plugged /dev/disk/by-id/dm-name-crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f
dev-disk-by\x2did-dm\x2duuid\x2dCRYPT\x2dLUKS1\x2dcc05650d01264bc8b8e5a1fe25606f6f\x2dcrypto_luks_cc05650d\x2d0126\x2d4bc8\x2db8e5\x2da1fe25606f6f.device loaded active   plugged /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-cc05650d01264bc8b8e5a1fe25606f6f-crypto_luks_cc05650d-012
dev-disk-by\x2dlabel-jolla\x2dcrypto\x2dsd.device                                                                                                         loaded active   plugged /dev/disk/by-label/jolla-crypto-sd
dev-mapper-crypto_luks_cc05650d\x2d0126\x2d4bc8\x2db8e5\x2da1fe25606f6f.device                                                                            loaded active   plugged /dev/mapper/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f
dev-mapper-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.device                                                                                loaded inactive dead    dev-mapper-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.device
run-media-defaultuser-jolla\x2dcrypto\x2dsd.mount                                                                                                         loaded active   mounted /run/media/defaultuser/jolla-crypto-sd
cryptosd-luks@crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.service                                                                            loaded inactive dead    Open DM-Crypt LUKS on SD-card crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f
cryptosd-myluks.service                                                                                                                                   loaded active   exited  Open DM-Crypt LUKS on SD-card crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f
mount-cryptosd-luks@crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.service                                                                      loaded inactive dead    Mount LUKS encrypted SD-card (crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f) with
mount-cryptosd-myluks.service                                                                                                                             loaded active   exited  Mount LUKS encrypted SD-card (crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f) with udisks
system-cryptosd\x2dluks.slice                                                                                                                             loaded active   active  system-cryptosd\x2dluks.slice
system-mount\x2dcryptosd\x2dluks.slice 

]# systemctl status -l "*crypto*"
● mount-cryptosd-myluks.service - Mount LUKS encrypted SD-card (crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f) with udisks
   Loaded: loaded (/etc/systemd/system/mount-cryptosd-myluks.service; static; vendor preset: enabled)
   Active: active (exited) since Wed 2021-02-17 15:05:32 CET; 5h 47min ago
     Docs: https://github.com/Olf0/crypto-sdcard
  Process: 9172 ExecStart=/usr/bin/udisksctl-user mount -b /dev/mapper/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f (code=exited, status=0/SUCCESS)
  Process: 9158 ExecStartPre=/bin/sleep 1 (code=exited, status=0/SUCCESS)
 Main PID: 9172 (code=exited, status=0/SUCCESS)

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

● system-mount\x2dcryptosd\x2dluks.slice
   Loaded: loaded
   Active: active since Wed 2021-02-17 15:02:04 CET; 5h 51min ago
   Memory: 0B
   CGroup: /system.slice/system-mount\x2dcryptosd\x2dluks.slice

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

● cryptosd-myluks.service - Open DM-Crypt LUKS on SD-card crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f
   Loaded: loaded (/etc/systemd/system/cryptosd-myluks.service; static; vendor preset: enabled)
   Active: active (exited) since Wed 2021-02-17 15:02:04 CET; 5h 51min ago
     Docs: https://github.com/Olf0/crypto-sdcard
  Process: 2953 ExecStart=/usr/sbin/cryptsetup --allow-discards -d /etc/crypto-sdcard/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f.key luksOpen /dev/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f (code=exited, status
 Main PID: 2953 (code=exited, status=0/SUCCESS)

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

● run-media-defaultuser-jolla\x2dcrypto\x2dsd.mount - /run/media/defaultuser/jolla-crypto-sd
   Loaded: loaded (/proc/self/mountinfo)
   Active: active (mounted) since Wed 2021-02-17 15:05:32 CET; 5h 47min ago
    Where: /run/media/defaultuser/jolla-crypto-sd
     What: /dev/mapper/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

● system-cryptosd\x2dluks.slice
   Loaded: loaded
   Active: active since Wed 2021-02-17 15:02:04 CET; 5h 51min ago
   Memory: 0B
   CGroup: /system.slice/system-cryptosd\x2dluks.slice

# ls -l /dev/mapper/crypto*
brw-rw----    1 root     disk      252,   2 Feb 17 15:02 /dev/mapper/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f

# mount |fgrep crypto
/dev/mapper/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f on /run/media/defaultuser/jolla-crypto-sd type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2)

...but I'm afraid my system is a mess now, as I left crypto-sdcard installed and modified the files like mentioned above. When I find some more time, I can run the commands with a fresh install of crypto-sdcard.

[Olf0]

I'm glad I got my backups back.

Good!
This is why I was aiming at a workaround, first.
So since yesterday, this may also happen to a broader group of people and more likely on production devices. Now everyone affected can access their data manually, until a proper adaption to SFOS 4.0.1 is deployed.

Thank you for the command line outputs. They are helpful, even though a bit hard to interpret, because the effects of the units you manually fixed and the original ones failing are displayed.

I perceived the first ls-output as surprising: Yes, one might assume, that none of the rules in /etc/udev/rules.d/96-cryptosd.rules are run, because even the symlink in line 2 is not created. But wouldn't the effect be the same, if /usr/bin/systemd-escape fails somehow?

Output 2 displays the "usual" mix of correctly and incorrectly escaped paths, either (see suffix) to a .device or in the instance name of an instanciated .service unit. You see that both original service units (the unlocking and the mounting one) carry the same, faulty instance name, likely a result of the incorrectly escaped .device path. Again, this looks as if something in 96-cryptosd.rules became severely broken.
It would be easier to interpret, if only one set of service units is running while generating this output, either your patched ones or the original ones. You can easily disable a unit completely by appending a "~" to its file name, so it ends in ".service~".

Outputs 3, 4 and 5 show, that you have everything up and running, although by your patched units, plus by manually starting them.

[erikderzweite]

I would be the second one to run into that issue :)
I cannot start the systemd scripts though:
systemctl start mount-cryptosd-luks@nemo A dependency job for mount-cryptosd-luks@nemo.service failed. See 'journalctl -xe' for details.
need to luksOpen manually to access the data. Sailfish's GUI always asks for password even if no keys with password are set up.

[Olf0]

I would be the second one to run into that issue :)

I am just upgrading my new testing device (an XA2+) to SFOS 4.0.1, because my old one dies (and became useless, anyway: it is a Jolla 1). It does not have an encrypted SD-card in it, yet (but I have some SD-cards around), so I may start my own efforts to analyse this issue this weekend.

[...] Sailfish's GUI always asks for password even if no keys with password are set up.

There are no "keys with password": You just input entropy, which is hashed then. The hash is then used as a "key value", which must match one saved in a "key slot" to unlock the real cryptographic key.
Technically it does not matter, from where this entropy is coming (e.g., file or terminal), but the source still makes a difference in how the input data is parsed: For LUKS (see special notes about that and option --key-file ff.: without this option reading stops at a newline) and subtly different for "plain" mode.
I once considered to alter the reading of a "key-file" to make it fully compatible to manually inputting it (at the SFOS GUI or in a terminal with cryptsetup or udisksctl unlock at the command line), but dropped the idea, because it would lower the entropy used (relevant to counteract brute force attacks), as it stops reading at the first newline character. Furthermore, it would break all extant "key-files", which contain newline characters, as they result in a different hash after such a change. As I advise to generate "key-files" with random content (by reading from /dev/[u]random), extant ones likely do contain newline characters.

So if your "key-file" does not contain newline characters and also only characters which can be entered per keyboard, you can just as well input its content at the SFOS GUI to unlock your encrypted partition.

[Olf0]

Easier workaround to manually access the LUKS encrypted partitions (used with crypto-sdcard) at the GUI.
You may use this (works since SailfishOS 3.0.0), until a proper adaption for SFOS 4.0.1 is designed, implemented, tested and deployed.

devel-su
# Input NUMERIC "key" interactively, concluding by hitting the "Return (CR)" key (which emits a newline character):
cryptsetup LuksAddKey --key-file /etc/crypto-sdcard/crypto_luks_$(blkid -c /dev/null -s UUID -o value /dev/<device-name>).key /dev/<device-name>
# Mind to substitute <device-name> twice, e.g. with mmcblk1p2 

Side note: For details, see LUKS key management.
Then you should be able to unlock & mount (in one go) the encrypted partition at the SFOS GUI by using the freshly set numeric "key".

Can someone please check, that this works fine?

[Olf0]

Looking for possibly relevant changes between Systemd 225 and 238, I found introduced in v236, "If a udev device has a SYSTEMD_WANTS= ...", and (more unlikely to cause this issue) in v233, "When units are about to be started ...". At least something worth investigating.

Edit:
Much more interesting are these entries from the udev changelog: In udev 138, "fix NAME= and OPTION+="string_escape=..." logic" and in udev 131, "fix handling of string_escape option", but both are historic (about a decade old; as udev follows the Systemd version numbers since its integration, SFOS always had way newer versions).
But these changelog entries led me to searching the web, finding e.g, "Why does udev ...?"@stackexchange, which is much more recent and also points to OPTIONS+="string_escape=none".

[fuchsmich]

I reinstalled crypto-sdcard now.

udevadm test $(udevadm info --query=path --name=/dev/mmcblk1p1) 2>&1 |grep crypto
Reading rules file: /etc/udev/rules.d/96-cryptosd.rules
PROGRAM '/usr/bin/systemd-escape crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f' /etc/udev/rules.d/96-cryptosd.rules:2
starting '/usr/bin/systemd-escape crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f'
'/usr/bin/systemd-escape crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f'(out) 'crypto_luks_cc05650d\x2d0126\x2d4bc8\x2db8e5\x2da1fe25606f6f'
Process '/usr/bin/systemd-escape crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f' succeeded.
MODE 0660 /etc/udev/rules.d/96-cryptosd.rules:2
LINK 'crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f' /etc/udev/rules.d/96-cryptosd.rules:2
found 'b179:65' claiming '/run/udev/links/\x2fcrypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f'
creating link '/dev/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f' to '/dev/mmcblk1p1'
preserve already existing symlink '/dev/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f' to 'mmcblk1p1'
DEVLINKS=/dev/disk/by-id/mmc-SC64G_0x51babdea-part1 /dev/disk/by-uuid/cc05650d-0126-4bc8-b8e5-a1fe25606f6f /dev/block/mmcblk1p1 /dev/disk/by-path/platform-c084000.sdhci-part1 /dev/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f
ID_FS_TYPE=crypto_LUKS
ID_FS_USAGE=crypto
SYSTEMD_WANTS=cryptosd-luks@crypto_luks_cc05650d\x2d0126\x2d4bc8\x2db8e5\x2da1fe25606f6f.service

Full output: https://gist.github.com/fuchsmich/9aa70436de48a7bb811b13009cdb5b4c

[fuchsmich]

#  ls -l /dev/crypto*
lrwxrwxrwx    1 root     root             9 Feb 20 12:53 /dev/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f -> mmcblk1p1

# systemctl list-units -l --all "*crypto*"
UNIT                                                                           LOAD   ACTIVE   SUB     DESCRIPTION                                                 
dev-crypto_luks_cc05650d\x2d0126\x2d4bc8\x2db8e5\x2da1fe25606f6f.device        loaded active   plugged /dev/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f       
dev-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.device            loaded inactive dead    dev-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f
cryptosd-luks@crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.service loaded inactive dead    Open DM-Crypt LUKS on SD-card crypto_luks_cc05650dx2d0126x2d
system-cryptosd\x2dluks.slice                                                  loaded active   active  system-cryptosd\x2dluks.slice                               

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

4 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.

# ls -l /dev/mapper/crypto*
ls: /dev/mapper/crypto*: No such file or directory

# mount |fgrep crypto

# systemctl status -l "*crypto*"
● system-cryptosd\x2dluks.slice
   Loaded: loaded
   Active: active since Sat 2021-02-20 12:40:32 CET; 21min ago
   Memory: 0B
   CGroup: /system.slice/system-cryptosd\x2dluks.slice

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

[Olf0]

udevadm test $(udevadm info --query=path --name=/dev/mmcblk1p1) 2>&1
Full output: https://gist.github.com/fuchsmich/9aa70436de48a7bb811b13009cdb5b4c

Thank you, this is interesting: All looks perfectly fine on udev level WRT /dev/mmcblk1p1!
Side note: I never saw found 'b179:65' claiming '/run/udev/links/\x2fcrypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f (note the added "\x2f"), but likely never looked at this output before.

And there is nothing to observe with udevadm test $(udevadm info --query=path --name=/dev/mapper/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f) 2>&1, because /dev/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f is not successfully unlocked, anymore.

# systemctl list-units -l --all "*crypto*"
UNIT                                                                           LOAD   ACTIVE   SUB     DESCRIPTION                                                 
dev-crypto_luks_cc05650d\x2d0126\x2d4bc8\x2db8e5\x2da1fe25606f6f.device        loaded active   plugged /dev/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f       
dev-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.device            loaded inactive dead    dev-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f
cryptosd-luks@crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.service loaded inactive dead    Open DM-Crypt LUKS on SD-card crypto_luks_cc05650dx2d0126x2d
...

• Where is cryptosd-luks@dev-crypto_luks_cc05650d\x2d0126\x2d4bc8\x2db8e5\x2da1fe25606f6f.service, which successfully created the first entry: dev-crypto_luks_cc05650d\x2d0126\x2d4bc8\x2db8e5\x2da1fe25606f6f.device?
  -> Likely a statement in some line in udev rule 96-... did, but not a service unit.
• What creates the broken cryptosd-luks@crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.service (fourth line), which created the broken dev-crypto_luks_cc05650dx2d0126x2d4bc8x2db8e5x2da1fe25606f6f.device (third line)?
  -> Also likely a statement in some line in udev rule 96-...!

Still puzzled, but I think we're slowly encircling the core of this issue.

[Olf0]

Oh, from your third posting, in its second command line output:

systemctl status -l "*crypto*"
...
● run-media-defaultuser-jolla\x2dcrypto\x2dsd.mount - /run/media/defaultuser/jolla-crypto-sd
  Loaded: loaded (/proc/self/mountinfo)
  Active: active (mounted) since Wed 2021-02-17 15:05:32 CET; 5h 47min ago
  Where: /run/media/defaultuser/jolla-crypto-sd
  What: /dev/mapper/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f
...

Is that still there? That seems to have successfully mounted the unlocked partition (/dev/mapper/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f, but what unlocked it?) at /run/media/defaultuser/jolla-crypto-sd.
It is a mount unit. You did not create one, correct?
Side note: Jolla stated long ago, that they consider making crypto-sdcard's functionality (automatic mounting) available in SailfishOS. Maybe their first steps in this direction interfere with crypto-sdcard.

Edit: Apparently not, see last listing in your latest post, above.

[fuchsmich]

Is that still there? That seems to have successfully mounted the unlocked partition (/dev/mapper/crypto_luks_cc05650d-0126-4bc8-b8e5-a1fe25606f6f, but what unlocked it?)

AFAIR, back then I unlocked the sd manually before I ran the commands in my third post.