На 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). .
Бага уже известная как оказалось. https://bugzilla.kernel.org/show_bug.cgi?id=112631
Подписался; там рекомендуют обновить cryptsetup до 1.7.0, на что резонно возражают, что это слом юзерспейсного интерфейса в ядре.
(В ответ на комментарий №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, а для более ранних версий он не подходит.
Эти патчи из 1.7.1, которая уже вышла. Можно обновить. shaba@, я займусь?
(В ответ на комментарий №4) > Эти патчи из 1.7.1, которая уже вышла. > Можно обновить. shaba@, я займусь? да, конечно.
Проверьте пожалуйста с: #160287 EPERM #2 [test-only] sisyphus cryptsetup.git=1.7.1-alt1
#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 на рабочей машине эксперимент проводить...
Что-то я с тестом намудрил в прошлом случае... После apt-repo add task 160287 apt-get update apt-get dist-upgrade ничего в зависимостях не появилось лишнего. потому обновил cryptsetup из задания до 1.7.1 результат проверки: На ядре 4.4.2 - работает нормально (не сломалось) На ядре 4.1.18 - работает нормально (починилось)
Спасибо; тем не менее пока апстримная (именно ядерная) бага открыта и решение из неё (если таковое воспоследует) не добралось до kernel-image-std-def, эту багу стоит либо держать тоже открытой, либо закрыть как WONTFIX/WORKSFORME.
У этой баги есть еще следствие - до ее фиксации на уровне ядра, подверженные ей ядра не должны попадать а P7. Потому как там cryptsetup сильно древний.
Поздно, там kernel-image-un-def-4.1.18-alt0.M70P.1. В принципе можно и на p7 перевесить...
Кстати, 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,
Я бы перевесил багу на p7 - там она актуальна, а на сизифе ее уже и не воспроизвести...
Репорт про регрессию между 4.1.17 и 4.1.18; flavour std-def удалён. Если воспроизводится на текущем kernel-image-6.x — просьба завести новый репорт.
