We have moved to a new Sailfish OS Forum. Please start new discussions there.

[regression] cryptsetup stopped working on upgrade to SFOS 2.1.4 & 2.2.0 [answered]

Tracked by Jolla

asked 2018-01-12 17:10:44 +0200

gabriel gravatar image

updated 2018-09-05 11:50:04 +0200

This post is currently set to private in the Community Beta Group. Please note that only members of the Community Beta Group can view and edit this post content…

DESCRIPTION: New version of cryptsetup isn't working, presumably you need a kernel with CONFIG_CRYPTO_USER_API_HASH and CONFIG_CRYPTO_USER_API_SKCIPHER compiled in, but I couldn't try it.


pkcon refresh
pkcon install cryptsetup
dd if=/dev/urandom of=/tmp/luksTest count=20480


losetup /dev/loop1 /tmp/luksTest
cryptsetup luksFormat /dev/loop1

(enter YES, passphrase twice)

EXPECTED RESULT: Obviusly a LUKS device :)

ACTUAL RESULT: You get a "Cannot initialize crypto backend.".

ADDITIONAL INFORMATION: This is an edge case (I use it to access an encrypted file), however, it used to work _and_ SFOS may need it for encrypted disks if they choose to use cryptsetup/LUKS.





edit retag flag offensive reopen delete

The question has been closed for the following reason "the question is answered, an answer was accepted" by gabriel
close date 2018-09-01 15:36:10.752125



A mere 1 MB (2048 * 512 Bytes) test file will not work with LUKS, as it is way too small (the LUKS header alone needs 2 MB by default).

You may try:

fallocate -v -l 64M cryptsetup-test.img
cryptsetup -v luksFormat cryptsetup-test.img
olf ( 2018-02-21 12:36:42 +0200 )edit

Thanks for the feedback and fixed. This isn't the point though, I would be happy if cryptsetup complained that the file is too small as the crypto backed would have been initialised. Can you please convert this into a comment as it doesn't work very well as an answer?

gabriel ( 2018-02-21 13:07:12 +0200 )edit

Just tested with my build of cryptsetup. This is not reproducible with my build 2.0.1) Works as expected on SFOS X https://build.merproject.org/package/show/home:nielnielsen/cryptfs

Nieldk ( 2018-02-21 17:49:29 +0200 )edit

Nieldk, this affects 2.1.4.x. It also works up to 2.1.3.x.

gabriel ( 2018-02-21 17:50:59 +0200 )edit

My device is on SFOS X Cryptsetup version (mine) is 2.0.1

Nieldk ( 2018-02-21 18:00:08 +0200 )edit

1 Answer

Sort by » oldest newest most voted

answered 2018-03-10 20:01:46 +0200

olf gravatar image

updated 2018-07-01 02:48:56 +0200

Analysis from a user's perspective:

Yes, there is something severely broken in cryptsetup-1.7.5+git1-1.2.1 from Jolla's mer-tools repository for SFOS and (at least on Jolla 1 phones).
Any Cryptsetup action (e.g. luksFormat or --type plain open) always fails, regardless of the chosen cryptography and other options, with (using -v or --debug, but the latter does not reveal more):

Cannot initialize crypto backend.
Command failed with code 22: Invalid argument

IOW, solely cryptsetup --help works with cryptsetup-1.7.5+git1-1.2.1.

Furthermore the crypto configuration of the kernel and kernel module seems to be inconsistent between device models under SailfishOS versions up to (and including) 2.2.0
On a Jolla 1, the kernel module qcrypto.ko (in /lib/modules/version/kernel/drivers/crypto/msm/) has to be explicitly loaded to enable the cryptographic chaining mode XTS, while the built-in kernel module cbc.ko for the chaining mode CBC (see cat /lib/modules/version/modules.builtin | fgrep cbc) seems to be automatically loaded on demand and the modules providing most classic cryptography algorithms are loaded by default (or something else already triggered them to be loaded on demand).
On Xperia X though, all cryptography kernel modules seem to be loaded by default (I don't have one, hence this is just a guess from information NielDK provided).

Dear sailors, please scrutinise and resolve this also, by loading the various kernel modules providing the common cryptography algorithms AES (-128 & -256), SHA-256, SHA-1, CBC(AES), XTS(AES) and ESSIV (supposedly eseqiv and / or chainiv) either on demand or by default, on all devices.


Either before or after updating to SailfishOS 2.2.0 or 2.1.4, remove Cryptsetup completely with:
pkcon remove cryptsetup-luks cryptsetup cryptsetup-libs libcryptsetup4

After updating to SFOS 2.2.0 / 2.1.4, install Cryptsetup 1.6.4 (compiled and packaged by NielDK):
curl -O https://openrepos.net/sites/default/files/packages/500/cryptsetup-1.6.4-1.armv7hl.rpm
curl -O https://openrepos.net/sites/default/files/packages/500/libcryptsetup4-1.6.4-1.armv7hl.rpm
pkcon install-local libcryptsetup4-1.6.4-1.armv7hl.rpm cryptsetup-1.6.4-1.armv7hl.rpm # Enter "y" to confirm installing

When Jolla provides a fixed Cryptsetup in their mer-tools repository (newer than cryptsetup-1.7.5+git1-1.2.1), you may install it with:
pkcon remove cryptsetup libcryptsetup4 # Remove NielDK's Cryptsetup, as the library package name does not match
pkcon install cryptsetup # Must have Jolla's mer-tools repository enabled for this with: ssu ar mer-tools

edit flag offensive delete publish link more


Upgrading SailfishOS 2.2.1 or higher without having removed NielDK's cryptsetup and libcryptsetup4 RPMs before that, results in a non-functional Cryptsetup (again), due to Jolla's cryptsetup and cryptsetup-libs RPMs being installed (working since SFOS 2.2.1) while NielDK's libcryptsetup4 RPM remains installed. The resulting "mixed" Cryptsetup installation does not work.
When trying to resolve this following above guide in this situation (i.e., under SFOS 2.1.1 and higher, in order to obtain a working installation of Jolla's Cryptsetup) a whole lot of dependent RPMs are going to be uninstalled, too.
Hence remove solely NielDK's libcryptsetup4 (with pkcon remove libcryptsetup4), if you ran into this situation (which seems to be O.K., i.e resulting in a properly working installation). Alternatively one may let pkcon uninstall all dependent RPMs along Cryptsetup (with pkcon remove cryptsetup cryptsetup-libs libcryptsetup4) and reinstall them right after that together with Jolla's Cryptsetup: This is the tedious, proper way for nitpickers (considering the possibility, that the uninstallation of the libcryptsetup4 RPM removes files, which were installed by Jolla's cryptsetup-libs RPM during the preceding SFOS upgrade), which bears its own dangers (a non-functional SailfishOS between the two steps) and thus shall be carried out booted into recovery mode (thus untested).

olf ( 2018-11-08 22:11:09 +0200 )edit

Question tools



Asked: 2018-01-12 17:10:44 +0200

Seen: 1,055 times

Last updated: Sep 05 '18