a5s397

Thank you for your answers so far. My version of cryptsetup is 2.1.0, however I managed to mount the LUKS-drive with the newer kernels with setting another (shorter) passphrase on the older kernel, which was working with the encrypted drive. I will mark this issue as solved. Is there a bug in setting a (too) long passphrase for LUKS-encrypted drives without getting a warning? There should (in theory) not be a limit according to https://askubuntu.com/questions/487613/luks-hdd-encryption-maximum-maximum-password-length

Thanks for your answer @tparys. Maybe my first post was misunderstanding, but the problem exists for both boards (rockchip64 and sunxi), while the older version of the kernel (5.10.16-rockchip64 and 5.10.16-sunxi) works with luksOpening the LUKS-drive and newer kernels on both platforms up to 5.10.43 do not work ("No key available with this passphrase"). I will check back concerning the missing of a hash function, but I did not encounter any problems since working with the newer kernels concerning hash functions.

Unfortunately the issue also exists with 5.10.43-rockchip. Here is the diff of it: 3c3 < # Linux/arm64 5.10.16 Kernel Configuration --- > # Linux/arm64 5.10.43 Kernel Configuration 228a229 > CONFIG_KCMP=y 433a435 > CONFIG_AS_HAS_LSE_ATOMICS=y 839c841 < CONFIG_BINFMT_MISC=y --- > CONFIG_BINFMT_MISC=m 1910d1911 < # CONFIG_PCIE_BW is not set 3236a3238 > CONFIG_RTL8188EU=m 7356a7359 > CONFIG_EXTCON_USBC_VIRTUAL_PD=y 7445d7447 < # CONFIG_AD9467 is not set 7928d7929 < # CONFIG_USB_LGM_PHY is not set 8398c8399 < CONFIG_NLS_ASCII=m --- > CONFIG_NLS_ASCII=y Is there anything pointing towards an issue with mounting encrypted drives with LUKS?

Dear Armbian supporters, Using kernel 5.10.21-rockchip64 on Rock Pi 4 (and 5.10.21-sunxi on Lime2), I am not able to mount a LUKS-encrypted drive. Changing the kernel to 5.10.16-rockchip64/5.10.16-sunxi I am able to mount the LUKS-encrypted drive again. Error message when trying to mount the drive is: "No key available with this passphrase". Which change could have introduced this bug? Greetings a5s397