31832 2016-02-22 08:59:28 +0300 После обновления с 4.1.17-std-def на 4.1.18-std-def - сломалось шифрование luks 2016-03-04 18:38:39 +0300 1 1 4 Development Sisyphus kernel-image-std-def unstable x86_64 Linux NEW https://bugzilla.kernel.org/show_bug.cgi?id=112631 P3 critical --- 1 alxste vt evg kernelbot placeholder shaba vt qa-sisyphus oldest_to_newest 155202 0 alxste 2016-02-22 08:59:28 +0300 На 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). . 155451 1 alxste 2016-02-28 05:26:00 +0300 Бага уже известная как оказалось. https://bugzilla.kernel.org/show_bug.cgi?id=112631 155454 2 mike 2016-02-28 23:49:24 +0300 Подписался; там рекомендуют обновить cryptsetup до 1.7.0, на что резонно возражают, что это слом юзерспейсного интерфейса в ядре. 155455 3 alxste 2016-02-29 01:54:18 +0300 (В ответ на комментарий №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, а для более ранних версий он не подходит. 155461 4 glebfm 2016-02-29 15:07:25 +0300 Эти патчи из 1.7.1, которая уже вышла. Можно обновить. shaba@, я займусь? 155462 5 shaba 2016-02-29 15:19:46 +0300 (В ответ на комментарий №4) > Эти патчи из 1.7.1, которая уже вышла. > Можно обновить. shaba@, я займусь? да, конечно. 155463 6 glebfm 2016-02-29 19:43:08 +0300 Проверьте пожалуйста с: #160287 EPERM #2 [test-only] sisyphus cryptsetup.git=1.7.1-alt1 155467 7 alxste 2016-03-01 12:14:04 +0300 #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 на рабочей машине эксперимент проводить... 155478 8 alxste 2016-03-01 19:51:05 +0300 Что-то я с тестом намудрил в прошлом случае... После apt-repo add task 160287 apt-get update apt-get dist-upgrade ничего в зависимостях не появилось лишнего. потому обновил cryptsetup из задания до 1.7.1 результат проверки: На ядре 4.4.2 - работает нормально (не сломалось) На ядре 4.1.18 - работает нормально (починилось) 155523 9 mike 2016-03-04 17:35:37 +0300 Спасибо; тем не менее пока апстримная (именно ядерная) бага открыта и решение из неё (если таковое воспоследует) не добралось до kernel-image-std-def, эту багу стоит либо держать тоже открытой, либо закрыть как WONTFIX/WORKSFORME. 155525 10 alxste 2016-03-04 17:40:55 +0300 У этой баги есть еще следствие - до ее фиксации на уровне ядра, подверженные ей ядра не должны попадать а P7. Потому как там cryptsetup сильно древний. 155527 11 mike 2016-03-04 17:47:01 +0300 Поздно, там kernel-image-un-def-4.1.18-alt0.M70P.1. В принципе можно и на p7 перевесить... 155528 12 alxste 2016-03-04 18:13:15 +0300 Кстати, 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, 155530 13 alxste 2016-03-04 18:38:39 +0300 Я бы перевесил багу на p7 - там она актуальна, а на сизифе ее уже и не воспроизвести...