FS#48230 - [cryptsetup/linux-lts] 4.1.18 luks-root broken
Attached to Project:
Arch Linux
Opened by c (c) - Thursday, 18 February 2016, 00:44 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 24 February 2016, 17:01 GMT
Opened by c (c) - Thursday, 18 February 2016, 00:44 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 24 February 2016, 17:01 GMT
|
Details
Description:
Since today's 4.1.18 linux-lts update there's the following error at the password prompt, and I could only fix it by downgrading to 4.1.17. Tried 4.4.1 and that one works as well. |
This task depends upon
sda3 is the root dm-crypt partition supplied in the kernel cmdline.
The error:
Failed to setup dm-crypt key mapping for device /dev/sda3
linux-lts 4.1.18-1
I have an encrypted LVM. The message that appeared to me was something like:
"Failed to setup something for /dev/sda2. Make sure the Kernel has xts-plain64 support".
"""
Failed to setup dm-crypt key mapping for device /dev/sda4.
Check that kernel supports aes-xts-plain64 cipher (check syslog for more info).
"""
Reverting to 4.1.17 and rebuilding the initcpio fixes the issue.
Earlier posted kernels: 3.13.11-ckt34, 3.19.8-ckt34, 4.2.8-ckt3, 4.5-rc1
Kernels not affected by this: 3.12.54, 4.3.6, 4.4.2, 4.5-rc3
Cryptsetup already supports these changes after backporting some patches: https://gitlab.com/cryptsetup/cryptsetup/issues/284
However the kernel API need to be properly patched as well (otherwise all old cryptsetup version will not work anyway).
Can we not roll back to the previous working release? "Don't use LTS" is not a solution for everyone.
All users of the 4.1 kernel series must upgrade."
This means it fixes security related issues. All other users really want that new release.
Please help to find a quick solution what patches need to be applied to this release to make it work again.
Simply install the new cryptsetup package: https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/cryptsetup&id=ea2c8f73c45aa239ed5f356a8ecd01aeba51ef1d
All users who can't access their HDDs anymore have to fix them on their own following for example my guide: https://forum.manjaro.org/index.php?topic=31356.msg257698#msg257698
That's all well and good for those other users, *but the system cannot boot*. Worse than that, people with machines that are doing important things are left in a situation where they can't even *access their filesystem*. It's not like we're talking about new drivers for gravis gamepads. Waiting until after the system is rendered unbootable and then expecting the user to come find this bug report and patch things manually is leaving the "maintenance" part out of "maintaining a linux distribution." Maybe no one noticed it when it was released, but this bug report is *days* old now and new people are still installing that package and bricking themselves.
At the very least, slap a giant warning on it at install time.
So what is the matter here really?
It doesn't make sense to continuing distributing a *known broken* package. If we're committed to doing that for some reason, at least tell everyone it's broken when they install it so they can do something about it before rebooting.
I know that some people are angry which faced the issue. However at Manjaro we reacted within hours (stable update: Sun Feb 21 09:38:51 CET 2016; fix-release: Sun Feb 21 11:57:16 CET 2016). Also we released a guide on how to fix it, if you faced the issue before the fix came out.
However I can't speak for Archlinux. The needed fixed package is now in their testing branch. So as soon as this is on stable we are good.
So if you really want to dig deeper on when upstream knew it, you can check also this:
https://lkml.org/lkml/2015/12/29/383
https://github.com/smuellerDD/libkcapi/commit/1d6c3b1b540caea784a95b1ca6e2cf38c174f585
dd504589577d8e8e70f51f997ad487a4cb6c026f
crypto: algif_skcipher - Require setkey before accept(2)
a0fa2d037129a9849918a92d91b79ed6c7bd2818
crypto: algif_skcipher - Add nokey compatibility path
patch: http://www.spinics.net/lists/stable/msg120446.html