tpsd fails to unlock or mount Persistent Storage that it just created
In wb:7e0c494d18b37f6b9a2ebc5da927f578, tpsd successfully creates a LUKS device, then attempts to unlock it, which fails with "Failed to activate device: Incorrect passphrase".
Possibly relevant:
- Creating the LUKS device is done with
cryptsetup
. I did not check but I suppose unlocking is done with udisks. - In parallel of the unlocking attempt, the system was still dealing with the side effects of
udevadm trigger
(#20020), which could potentially impact udisks.
Other reports with "incorrect passphrase":
- wb:669c52b1be55cd62945c60c18188f1bf
- wb:d5446a3f36c90afcc032d9948503f843
- wb:c2398efa2f53fe1d21c702db84d5f85a
In wb:fe3b1e32e1c1e6488ad1547fce476024, the symptom is instead Failed to unlock /dev/sdb2: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking /dev/sdb2: Failed to load device's parameters: Operation not permitted
. Here as well, the system was still dealing with the side effects of udevadm trigger
. Other bug reports with this symptom:
- wb:ada7a9534d97a043a9f4c0762efb48eb
And sometimes the error is tpsd[7058]: ERROR:device.py:591: [12087-Create] Failed to unlock /dev/sdc2: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking /dev/sdc2: Failed to load device's parameters: Invalid argument
:
- wb:a6374c70764c4a12d1ef6fb908cd76e
And I also see cases where tpsd fails to mount a filesystem that it just created, without any hint of hardware problems (e.g. I/O errors on the USB stick) in the logs:
Nov 04 13:39:24 amnesia tpsd[5998]: INFO:device.py:391: [1] Mounting filesystem
Nov 04 13:39:24 amnesia tpsd[5998]: INFO:device.py:660: [1] Executing command mount -o acl /dev/dm-0 /live/persistence/TailsData_unlocked
Nov 04 13:39:25 amnesia tca[13549]: DEBUG:stem:GETINFO status/bootstrap-phase (runtime: 0.0065)
Nov 04 13:39:25 amnesia tca[13549]: INFO:ConnectionProgress:new bootstrap_phase received: 58 going to 50.00%
Nov 04 13:39:25 amnesia kernel: JBD2: no valid journal superblock found
Nov 04 13:39:25 amnesia kernel: EXT4-fs (dm-0): error loading journal
Nov 04 13:39:25 amnesia tpsd[5998]: mount: /live/persistence/TailsData_unlocked: wrong fs type, bad option, bad superblock on /dev/mapper/TailsData_unlocked, missing codepage or helper program, or other error.
Same in:
- wb:bb248f63d8bdac7a92a4026477a52d0d
- wb:fd67d01da966101667b1ed2f029d1603
- wb:eeeadeceb15826b978db131ebb76202a
So I'm starting to wonder if something went wrong when we switched from pure udisks to cryptsetup + dmsetup + udisks + try to make them all work together.
Benefit and cost
Benefit: as of 2024 Q1, this is one of the main cause of trouble for users who try to use Persistent Storage. So the benefit of fixing this would be great.
Cost:
- Cheap first attempt: looking for potential race conditions in our code, in the hope there's a quick fix on our side
- Expensive longer-term potential solution that we could consider at some point: what would it take to go back to pure udisks?
- Any idea in between these 2 extremes?