cryptsetup fails after linux-imx6-cubox-dt 3.14.14 upgrade

[pg99]

After upgrading from linux-imx6-cubox-dt 3.10.30-30 to 3.14.14-[1,2,4] cryptsetup stopped working on my cubox i4-pro. When I try to unlock the drive (with 'cryptsetup luksOpen /dev/sdb1 crypt-sdb1), I simply get the same response as if I typed the password incorrectly: "No key available with this passphrase.". The disk does work on other (non-arm) linux computers (kernel 3.16 arch/gentoo) .It also works again if I downgrade the cubox to the 3.10 kernel. There are no errors that I could find yet.
Does anybody have clue where I should start searching? And is this the correct place in the forum to pose this question? I could also post a bug report, but I thought I should ask here first.

[WarheadsSE]

This is approximately the right place to ask. Posting an Issue at github for something like this (not a packaging issue) is not right.

[pepedog]

My gut tells me something is not builtin, made as a module
Maybe you could investigate here https://raw.githubusercontent.com/archl ... -dt/config
You find it and I'll happily change, I have other request, solid run simply wanted their default CONFIG followed but already found holes

[nwestfal]

Perhaps related to this issue?

[Geoff]

I concur that LUKS doesn't work with 3.14.14. I notice that the cryptodev module is not loaded unless I explicitly modprobe it, and that LUKS doesn't work either way. I have openssl-cryptodev installed also, and it works until I modprobe cryptodev, which then causes ssh and https authentication to fail but allows established ssh connections to continue working. I wonder whether cryptodev and AF_ALG (alternative crypto-hardware interfaces) are interfering with each other, and which of these is being used by LUKS, OpenVPN, OpenSSL, etc. OpenSSL is supposed to be configurable to use either one. My guess is that the kernel is configured just fine and that AF_ALG might be working, but there's something wrong with the cryptodev module.

[pepedog]

The 3.10.30 kernel was using the same cryptodev commit as the later 3.14.14 versions

[Geoff]

$this->bbcode_second_pass_quote('pepedog', 'T')he 3.10.30 kernel was using the same cryptodev commit as the later 3.14.14 versions

[pg99]

Thanks for all the replies and suggestions.
In my case (cubox kernel) I think all the relevant kernel modules are built-in. If I do lsmod I get none of the mentioned modules:

## 3.10 kernel ##
Module Size Used by
hid_logitech_dj 9600 0
mxc_v4l2_capture 22458 0
ipu_bg_overlay_sdc 4224 1 mxc_v4l2_capture
brcmfmac 156287 0
snd_usb_audio 93217 1
ipu_still 1663 1 mxc_v4l2_capture
snd_usbmidi_lib 15992 1 snd_usb_audio
ipu_prp_enc 4895 1 mxc_v4l2_capture
snd_hwdep 4769 1 snd_usb_audio
brcmutil 3955 1 brcmfmac
snd_rawmidi 15210 1 snd_usbmidi_lib
ipu_csi_enc 3091 1 mxc_v4l2_capture
ipu_fg_overlay_sdc 5085 1 mxc_v4l2_capture

## 3.14 kernel ##
Module Size Used by
brcmfmac 184865 0
joydev 17772 0
brcmutil 15863 1 brcmfmac
cfg80211 219114 1 brcmfmac
rfkill 24250 1 cfg80211
snd_usb_audio 126324 0
snd_usbmidi_lib 25372 1 snd_usb_audio
snd_rawmidi 27377 1 snd_usbmidi_lib
ir_lirc_codec 13150 0
ir_mce_kbd_decoder 13047 0
lirc_dev 20316 1 ir_lirc_codec
ir_sanyo_decoder 12721 0
ir_sony_decoder 12718 0
ir_jvc_decoder 12715 0
ir_rc6_decoder 12715 0
ir_rc5_decoder 12715 0
ir_nec_decoder 12715 0
gpio_ir_recv 13139 0

I will compare the /proc/config.gz files of both kernels and see if there is an imporant difference. What puzzles me most is that I simply get the 'No key available with this passphrase' notification. I would expect a 'kernel functionality missing' error or something similar. It is as if the all the relevant modules are available, but simply calculating wrong cryptography results....

[pepedog]

Please test when 3.14.14-5 is available
https://github.com/archlinuxarm/PKGBUILDs/commit/1f11af80ebc574e6742792040a8661ef417aa9ac

[Geoff]

$this->bbcode_second_pass_quote('pepedog', 'P')lease test when 3.14.14-5 is available