Bug 31832 - После обновления с 4.1.17-std-def на 4.1.18-std-def - сломалось шифрование luks
Summary: После обновления с 4.1.17-std-def на 4.1.18-std-def - сломалось шифрование luks
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: kernel-image-std-def (show other bugs)
Version: unstable
Hardware: x86_64 Linux
: P3 critical
Assignee: Vitaly Chikunov
QA Contact: qa-sisyphus
URL: https://bugzilla.kernel.org/show_bug....
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-22 08:59 MSK by Alexander
Modified: 2016-03-04 18:38 MSK (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander 2016-02-22 08:59:28 MSK
На 4.1.17 - Все ок, на 4.4.2-un-def = все ок.
Система - актуальный на вчерашний вечер сизиф.

При загрузке системы не монтируется шифрованный luks домашний каталог.
Запрашивается пароль, пароль принимается, идет попытка монтирования, которая завершается с ошибкой. В журнале нашел вот это:
Ошибка воспроизводится стабильно, при каждой перезагрузке.
На 4.1.17 и 4.4.2 стабильно все работает как полагается.

В логе обнаружил вот такое:
фев 22 08:36:42 xxx.localdomain systemd-cryptsetup[1695]: Failed to activate: Invalid argument


При попытке примонтировать шифрованную SD-карту выдается такое сооюбщение:
Error unlocking /dev/mmcblk0p1: Command-line `cryptsetup luksOpen "/dev/mmcblk0p1" "luks-a20db0a0-9a8b-436b-8ee2-dbe9c0b7d90c" ' exited with non-zero exit status 1: Failed to setup dm-crypt key mapping for device /dev/mmcblk0p1.
Check that kernel supports aes-xts-plain cipher (check syslog for more info).
.
Comment 1 Alexander 2016-02-28 05:26:00 MSK
Бага уже известная как оказалось.
https://bugzilla.kernel.org/show_bug.cgi?id=112631
Comment 2 Michael Shigorin 2016-02-28 23:49:24 MSK
Подписался; там рекомендуют обновить cryptsetup до 1.7.0, на что резонно возражают, что это слом юзерспейсного интерфейса в ядре.
Comment 3 Alexander 2016-02-29 01:54:18 MSK
(В ответ на комментарий №2)
> Подписался; там рекомендуют обновить cryptsetup до 1.7.0, на что резонно
> возражают, что это слом юзерспейсного интерфейса в ядре.

Ну у нас и так 1.7.0, что не мешает бвге быть.
Я так понял что для 1.7.0 есть этот патч:
https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/cryptsetup&id=ea2c8f73c45aa239ed5f356a8ecd01aeba51ef1d, 
а для более ранних версий он не подходит.
Comment 4 Gleb F-Malinovskiy 2016-02-29 15:07:25 MSK
Эти патчи из 1.7.1, которая уже вышла.
Можно обновить. shaba@, я займусь?
Comment 5 Alexey Shabalin 2016-02-29 15:19:46 MSK
(В ответ на комментарий №4)
> Эти патчи из 1.7.1, которая уже вышла.
> Можно обновить. shaba@, я займусь?
да, конечно.
Comment 6 Gleb F-Malinovskiy 2016-02-29 19:43:08 MSK
Проверьте пожалуйста с:

#160287 EPERM #2 [test-only] sisyphus cryptsetup.git=1.7.1-alt1
Comment 7 Alexander 2016-03-01 12:14:04 MSK
#apt-repo test 160287
....
Следующие пакеты будут ОБНОВЛЕНЫ:
  cryptsetup libcryptsetup
Следующие НОВЫЕ пакеты будут установлены:
  cryptsetup-reencrypt cryptsetup-veritysetup libcryptsetup-devel python-module-cryptsetup
2 будет обновлено, 4 новых установлено, 0 пакетов будет удалено и 7 не будет обновлено.
Необходимо получить 524kB архивов.
После распаковки потребуется дополнительно 217kB дискового пространства.
Продолжить? [Y/n] n
Прервано.

Раньше вроде не было зависимости на cryptsetup-reencrypt.. 
Что-то меня напрягло с такой новой зависимостью на reencrypt на рабочей машине эксперимент проводить...
Comment 8 Alexander 2016-03-01 19:51:05 MSK
Что-то я с тестом намудрил в прошлом случае...
После  
apt-repo add task 160287
apt-get update
apt-get dist-upgrade
ничего в зависимостях не появилось лишнего.
потому обновил cryptsetup из задания до 1.7.1
результат проверки:
На ядре 4.4.2 - работает нормально (не сломалось)
На ядре 4.1.18 - работает нормально (починилось)
Comment 9 Michael Shigorin 2016-03-04 17:35:37 MSK
Спасибо; тем не менее пока апстримная (именно ядерная) бага открыта и решение из неё (если таковое воспоследует) не добралось до kernel-image-std-def, эту багу стоит либо держать тоже открытой, либо закрыть как WONTFIX/WORKSFORME.
Comment 10 Alexander 2016-03-04 17:40:55 MSK
У этой баги есть еще следствие - до ее фиксации на уровне ядра, подверженные ей ядра не должны попадать а P7. Потому как там cryptsetup сильно древний.
Comment 11 Michael Shigorin 2016-03-04 17:47:01 MSK
Поздно, там kernel-image-un-def-4.1.18-alt0.M70P.1.
В принципе можно и на p7 перевесить...
Comment 12 Alexander 2016-03-04 18:13:15 MSK
Кстати, 3.14.63p-std-def который в P7 
http://packages.altlinux.org/en/p7/srpms/kernel-image-std-def тоже этой баге подвержен насколько я понимаю. Если только не поправили в 62 или в 63 версиях..


> Regression: yes
> Kernel versions affected: 3.10.97, 3.14.61, 3.18.27, 4.1.18,
Comment 13 Alexander 2016-03-04 18:38:39 MSK
Я бы перевесил багу на p7 - там она актуальна, а на сизифе ее уже и не воспроизвести...