PS: с сизифными cryptsetup-1.4.2-alt2 и make-initrd-0.7.9-alt1 при ситуациях, когда в initrd уже открыли контейнер с ФС для /home, дополнительные три попытки спросить пароль и безуспешно задействовать уже занятое устройство при загрузке немного раздражают (cryptdisks.functions стоит научить проверять, не открыт ли уже контейнер).

(В ответ на комментарий №1)
> (cryptdisks.functions стоит научить проверять, не открыт ли
> уже контейнер).

Он умеет, но проверяет по отображаемому названию устройства

Подстраховать по другим именам (или realpath) в принципе возможно или нет?
Когда рассматривал всё это -- мысли были в эту сторону, но не доковырял...

Предлагаю забыть про crypttab и одать всё в руки make-initrd-luks

(В ответ на комментарий №4)
> Предлагаю забыть про crypttab и одать всё в руки make-initrd-luks

Насколько я понял, проблема в том, что если / не на luks, make-initrd-luks себя никак не проявляет и это логично..

(В ответ на комментарий №5)
> Насколько я понял, проблема в том, что если / не на luks, make-initrd-luks себя
> никак не проявляет и это логично..

Да, но если зашифрован / и /home , то make-initrd-luks проявляет свою активность на / и на /home

(В ответ на комментарий №6)
> Да, но если зашифрован / и /home , то make-initrd-luks проявляет свою
> активность на / и на /home

И оба случая должны работать..

(In reply to comment #4)
> Предлагаю забыть про crypttab и одать всё в руки make-initrd-luks
Может вылезти боком при dist-upgrade, да и разъезжаться с документацией апстрима тоже плохо.

(In reply to comment #7)
> > Да, но если зашифрован / и /home , то make-initrd-luks проявляет свою
> > активность на / и на /home
> И оба случая должны работать..
(ещё подумав) А далее у нас вылезет plymouth.

Предлагаю набросок плана действий при загрузке:
- initrd:
  + если включен plymouth, спрашиваем пароль через него и пытаемся применить
    ко всем найденным LUKS-контейнерам (сделанные инсталером должны открыться);
  + иначе спрашиваем/передаём сами (или оставляем это бинарнику cryptsetup);
- cryptsetup:
  + если включен plymouth -- идём аналогично через его спрашивалку;
  + иначе получаем realpath найденных устройств с LUKS-контейнерами и вычитаем
    из полученного списка те, для которых в `dmsetup info` есть LUKS-записи.

При этом должен закрыться и случай, когда у нас что-то из слоёв mdraid/lvm живёт на LUKS-контейнере и имеет поверх себя ещё один LUKS-контейнер.

Также повесил bug #28268 и, набравшись нахальства, приглашаю vsu@ и kas@.

Тимур, Антон, что с этой багой? Очень хотелось бы закончить интеграцией с LUKS в установщик.

Created attachment 5688 [details]
Всегда добавлять модуль luks в образ initrd

Это не патч, а хак. Такой патч я не приму. Если хотите хакать и всегда добавлять luks, то делайте:

echo "FEATURES += luks" >> /etc/initrd.mk

(В ответ на комментарий №11)
> Если хотите хакать и всегда
> добавлять luks, то делайте:
> 
> echo "FEATURES += luks" >> /etc/initrd.mk

О, спасибо

Перевешиваю на timonbl4 и переоткрываю.

(In reply to comment #11)
> echo "FEATURES += luks" >> /etc/initrd.mk
Если уж так делать, то лучше условно (но перед генерацией initrd).

Я так и не понял какую проблему вы пытаетесь решить.

Отправил в сизиф installer 1.8.12-alt1

(In reply to comment #15)
> Я так и не понял какую проблему вы пытаетесь решить.
http://www.altlinux.org/План_выпуска_бранча_p7 => "Поддержка установки на криптованные фс"

(In reply to comment #16)
> Отправил в сизиф installer 1.8.12-alt1
Переделаю в условную форму, к preinstall у нас уже есть сведения -- делали LUKS или нет.  Переоткрываю и забираю багу.

(В ответ на комментарий №17)
> (In reply to comment #15)
> > Я так и не понял какую проблему вы пытаетесь решить.
> http://www.altlinux.org/План_выпуска_бранча_p7 => "Поддержка установки на
> криптованные фс"

Что это ещё за "предвыборные обещания президента"?! Это, простите, из серии "Петька, приборы? 20!". Это не постановка задачи, а расплывчатая фраза, из которой можно вынести ещё меньше, чем из сумбурного обсуждения в нескольких багах в этой багзилле.

Из этого я понял, что 18 марта 2012 на wiki один человек что-то написал, а вы в связи с этим что-то сделали. Чудно! Видимо приёмка по этому пункту будет в том же стиле: кто-то что-то проверил и установил, что что-то сделано :)

(В ответ на комментарий №18)
> (В ответ на комментарий №17)
> > (In reply to comment #15)
> > > Я так и не понял какую проблему вы пытаетесь решить.
> > http://www.altlinux.org/План_выпуска_бранча_p7 => "Поддержка установки на
> > криптованные фс"
> 
> Что это ещё за "предвыборные обещания президента"?! Это, простите, из серии
> "Петька, приборы? 20!". Это не постановка задачи, а расплывчатая фраза, из
> которой можно вынести ещё меньше, чем из сумбурного обсуждения в нескольких
> багах в этой багзилле.
> 
> Из этого я понял, что 18 марта 2012 на wiki один человек что-то написал, а вы в
> связи с этим что-то сделали. Чудно! Видимо приёмка по этому пункту будет в том
> же стиле: кто-то что-то проверил и установил, что что-то сделано :)

Приемка за qa@. Здесь это cas@

Лёш, если ты не заметил -- то comment #0 как раз и был попыткой прояснить задачу.

Понятно, что есть что улучшать, но давай роль плешееда традиционно оставим мне. :)

(В ответ на комментарий №19)
> Приемка за qa@. Здесь это cas@

Здорово. Вот ещё один несчастный кроме исполнителя. А что он будет принимать ведь вы, Алексей, с марта прошлого года так и не смогли пояснить в wiki, что имели в виду под фразой "Поддержка установки на криптованные фс" ? Что исполнитель должен был реализовать ?

(В ответ на комментарий №20)
> Лёш, если ты не заметил -- то comment #0 как раз и был попыткой прояснить
> задачу.
 
Миш, ты прости, но это не прояснение задачи, а лирическое повествование (родился и жил он жил пока умер) какого-то процесса с интригой и болью. Это даже не описание для баги. Проблема не поставлена, ожидаемое не описано ... как воспроизвести тоже.

(В ответ на комментарий №21)
> (В ответ на комментарий №19)
> > Приемка за qa@. Здесь это cas@
> 
> Здорово. Вот ещё один несчастный кроме исполнителя. А что он будет принимать
> ведь вы, Алексей, с марта прошлого года так и не смогли пояснить в wiki, что
> имели в виду под фразой "Поддержка установки на криптованные фс" ? Что
> исполнитель должен был реализовать ?

Алексей, Вы же не спрашивали. Тот же, кто спрашивал, получил ответ. И фича эта скоро, надеюсь, пройдет qa и будет описана в документации.

(In reply to comment #21)
> Проблема не поставлена, ожидаемое не описано ... как воспроизвести тоже.
Вот и занимаюсь выяснением и фиксированием.  Мало того, в определённой мере это мне развязывает руки (см. bug #28200) -- если по ходу выяснения осмысленных use case оказывается, что что-то можно сделать иначе, чем было сделано или вроде бы как предполагалось -- можно постараться сделать по уму и не наталкиваться на устаревшее, но зато точно выписанное, формальное требование.

(In reply to comment #22)
> И фича эта скоро, надеюсь, пройдет qa и будет описана в документации.
При этом у Андрея тоже возникнет масса вопросов и предложений, поди. :)

Может быть, к 7.0.x или 8 их получится даже сделать...

Спасибо всем за конструктивную часть обсуждения и предлагаю всё-таки дать мне на праздниках время спокойно над этим подумать.  Начиная с этого самого plymouth, который тут слишком сильно влияет, и заканчивая поиском живых пользователей.

(В ответ на комментарий №22)
> Алексей, Вы же не спрашивали. Тот же, кто спрашивал, получил ответ. И фича эта
> скоро, надеюсь, пройдет qa и будет описана в документации.

Я не спрашивал, но невольно стал жертвой вашего внутреннего междусобойчика т.к. в итоге "проблема" была перевешана на мой проект без должного описания. Такой приватный выхлоп лишь тратит моё время.

Перевешиваю обратно на абстрактный компонент т.к. кулуарная проблема до меня не доведена и значит для меня её нет.

(В ответ на комментарий №24)
> (В ответ на комментарий №22)
> > Алексей, Вы же не спрашивали. Тот же, кто спрашивал, получил ответ. И фича эта
> > скоро, надеюсь, пройдет qa и будет описана в документации.
> 
> Я не спрашивал, но невольно стал жертвой вашего внутреннего междусобойчика т.к.
> в итоге "проблема" была перевешана на мой проект без должного описания. Такой
> приватный выхлоп лишь тратит моё время.
> 
> Перевешиваю обратно на абстрактный компонент т.к. кулуарная проблема до меня не
> доведена и значит для меня её нет.

Согласен, Вы абсолютно правы.

(В ответ на комментарий №19)
> Приемка за qa@. Здесь это cas@
Проверил. Не работает после установки (не монтируется, так как UUID в /etc/fstab отличен от реального).

(В ответ на комментарий №26)
> Проверил. Не работает после установки (не монтируется, так как UUID в
> /etc/fstab отличен от реального).

Нужны подробности. В установленной системе строчка "FEATURES += luks" в файле /etc/initrd.mk присутствует? make-initrd-luks установлен?

У меня с версией installer 1.8.12-alt1 работает

(В ответ на комментарий №27)
> (В ответ на комментарий №26)
> > Проверил. Не работает после установки (не монтируется, так как UUID в
> > /etc/fstab отличен от реального).
> 
> Нужны подробности. В установленной системе строчка "FEATURES += luks" в файле
> /etc/initrd.mk присутствует? 
Отсутствует.

> make-initrd-luks установлен?
0.7.9-alt1

Если добавить в initrd.mk поддержку LUKS, при загрузке в консоли начинает бесконечно запрашивать пароль. Графически ничего не показывает. Система ужасно тормозит.

(In reply to comment #28)
> > Нужны подробности. В установленной системе строчка "FEATURES += luks" в файле
> > /etc/initrd.mk присутствует? 
> Отсутствует.
А что за образ был взят для проверки?

> Если добавить в initrd.mk поддержку LUKS, при загрузке в консоли начинает
> бесконечно запрашивать пароль. Графически ничего не показывает.
Это известный, но ещё AFAIR не повешенный даже FR -- прикрутить к plymouth (причём мест сразу два -- initrd и стартап).  Отчасти обсуждали с boyarsh@.

(В ответ на комментарий №29)
> (In reply to comment #28)
> > > Нужны подробности. В установленной системе строчка "FEATURES += luks" в файле
> > > /etc/initrd.mk присутствует? 
> > Отсутствует.
> А что за образ был взят для проверки?
Вчерашняя ночная сборка.

Сегодняшняя сборка показала, что пароль на зашифрованные разделы можно ввести в консоли, если убрать параметр vga=0x314 из параметров GRUB.

> Предлагаю набросок плана действий при загрузке:
> - initrd:
>   + если включен plymouth, спрашиваем пароль через него и пытаемся применить
>     ко всем найденным LUKS-контейнерам (сделанные инсталером должны открыться);
>   + иначе спрашиваем/передаём сами (или оставляем это бинарнику cryptsetup);
Вопрос оказался неожиданно актуальным, так как:
 1) при работающем plymouth спрашивалка из cryptsetup оказывается под ним (это, конечно, добавляет безопасности :D )
 2) при vga=0xЧТО-НИБУДЬ (там, где нет kms) спрашивалка из cryptsetup нормально вообще не работает независимо от наличия plymouth (что уже через чур безопасно :DD )

Надо делать спрашивание через plymouth в initrd...

(In reply to comment #32)
> Надо делать спрашивание через plymouth в initrd...
О чём comment #8 и был.

В общем, всё равно грабли.
Казалось, бы, в первом приближении, мы решили проблему с luks на некорневых разделах, добавляя FEATURES=luks, но на самом деле мы создали себе новые проблемы.

make-initrd-luks пытается раскрыть всё, что является luks контейнерами. При том, что на дисках могут быть luks контейнеры от других систем, luks контейнеры, которые должны монтироваться при входе пользователя через pam_mount и тп.

Из этого следует, что make-initrd-luks надо модифицировать таким образом, чтоб он работал только с контейнерами, перечисленными в /etc/fstab или вообще только с корневым разделом, а остальные отдать на более позднюю стадию, обеспечив согласованность работы.

(В ответ на комментарий №34)
> Из этого следует, что make-initrd-luks надо модифицировать таким образом, чтоб
> он работал только с контейнерами, перечисленными в /etc/fstab или вообще только
> с корневым разделом, а остальные отдать на более позднюю стадию, обеспечив
> согласованность работы.

Так делать нельзя by-design. Есть идея как это исправить в принципе, но это требует сильной модификации механизма угадава.

(В ответ на комментарий №34)
> 
> make-initrd-luks пытается раскрыть всё, что является luks контейнерами. При
> том, что на дисках могут быть luks контейнеры от других систем, luks
> контейнеры, которые должны монтироваться при входе пользователя через pam_mount
> и тп.
> 
Учитывая сказанное legion@:
если раскрытие "luks контейнеров от других систем, luks
> контейнеры, которые должны монтироваться при входе пользователя через pam_mount
> и тп." не удастся, то достаточно вывести сообщение об этом, не прерывая работу.

(В ответ на комментарий №35)
> (В ответ на комментарий №34)
(В ответ на комментарий №35)

> Так делать нельзя by-design. 
Не мог бы ты пояснить (не обязательно сию минуту, разумеется), чем именно это черевато или почему нельзя сделать.

> Есть идея как это исправить в принципе, но это
> требует сильной модификации механизма угадава.
Угадава в make-initrd вообще, а не в make-initrd-luks, я правильно понимаю?

Надо что-то придумать, так как иначе поддержка luks получается.. своеобразная..

(В ответ на комментарий №37)
> > Так делать нельзя by-design. 
> Не мог бы ты пояснить (не обязательно сию минуту, разумеется), чем именно это
> черевато или почему нельзя сделать.

Когда при загрузке передаётся параметр root=UUID, то initrd не имеет никакого понятия кто будет представлять этот UUID. Он может появиться на любом уровне "матрёшки" разных систем (Например raid->lvm->luks->filesystem). У initrd в распоряжении есть лишь правила udev и предположительно все необходимые утилиты для сборки всей этой матрёшки до искомого UUID. Поэтому make-initrd пытается "развернуть" их всех если он это умеет... это относится к любым сложным системам будь то luks, lvm или raid. Initrd будет пытаться заглянуть везде. Этот подход работал лучше чем в mkinitrd, где последовательность прохакивалась и был применим к системам с "ничем лишним".

В качестве исправления у меня была идея пробовать запоминать промежуточные уникальные параметры в "матрёшке" и заглядывать лишь в те объекты, которые были на пути к UUID. Но при этом подходе появляются минусы, которые я ещё не полностью формализовал и оценил. Возможно, можно вообще подойти с другой стороны к этой проблеме, но это нужно обдумать.

Также предложенная идея потребует не только определения составных частей "матрёшки" при создании initrd, но и аккуратного сохранения последовательности и параметров иерархии. Для этого нужно переделать архитектуру угадава, сделав его более фичастым, отвечающим новым задачам (которых раньше не было). Это большая работа, которую как ты знаешь я уже веду, но прогнозов по ней у меня нет т.к. она не в приоритете у меня сейчас. Плюс тут есть над чем подумать.

> Надо что-то придумать, так как иначе поддержка luks получается.. своеобразная..

https://bugzilla.altlinux.org/show_bug.cgi?id=28255#c18 и ниже по треду.

(В ответ на комментарий №38)
>
> Также предложенная идея потребует не только определения составных частей
> "матрёшки" при создании initrd, но и аккуратного сохранения последовательности
> и параметров иерархии.
Хмм.. А ведь, вообще говоря, нам никто не обещал, что нам не передадут какой-нибудь другой UUID, который мы не знаем где брать и, соответсвенно, нам придётся искать его по всем контейнерам.. То есть в лучшем случае такое решение можно использовать для того раздела, который был корневым в момент сборки initrd, но сохранить и угадав старого образца для случая, когда нам дали другой UUID...

> Для этого нужно переделать архитектуру угадава, сделав
> его более фичастым, отвечающим новым задачам (которых раньше не было). Это
> большая работа, которую как ты знаешь я уже веду, но прогнозов по ней у меня
> нет т.к. она не в приоритете у меня сейчас. Плюс тут есть над чем подумать.
Да, спасибо за объяснение, тут действительно есть над чем задуматься..

(В ответ на комментарий №39)
> Хмм.. А ведь, вообще говоря, нам никто не обещал, что нам не передадут
> какой-нибудь другой UUID, который мы не знаем где брать и, соответсвенно, нам
> придётся искать его по всем контейнерам.. То есть в лучшем случае такое решение
> можно использовать для того раздела, который был корневым в момент сборки 
> initrd, но сохранить и угадав старого образца для случая, когда нам дали другой
> UUID...

Сейчас (в будущей версии), make-initrd запоминает UUID рута, который был на момент сборки образа и при отсутствии параметра root= при загрузке будет брать сохранённое значение.

Новый механизм можно увязать с этим же механизмом активации т.е. использовать сохранённую "матрёшку" в случае если параметр root= не указан или равен сохранённому. В этом случае задача будет ещё более интересная т.к. нужно будет не переписать действующий механизм определения, а дополнить возможностью задания вектора поиска.

(In reply to comment #34)
> Из этого следует, что make-initrd-luks надо модифицировать таким образом,
> чтоб он работал только с контейнерами, перечисленными в /etc/fstab или вообще
> только с корневым разделом, а остальные отдать на более позднюю стадию,
> обеспечив согласованность работы.
(прочитав до comment 40 включительно)

1) видимо, всё-таки не /etc/fstab, а /etc/crypttab (и вернуть тогда в /vm
   его генерацию, которая была сделана, но сейчас заремарена);
2) обязательным требованием к m-i-l является умение открыть корень,
   если он оказался в luks;
3) желательным навыком m-i-l может быть примерка заданного для корня пароля
   и к другим оставленным в итоге для попытки открытия контейнерам
   (см. тж. bug #28200 -- понимаю, что это небесспорное решение, но лучше
   пока никто не предложил);
4) luks-контейнеры для некорневых ФС могут обрабатываться уже с поднятого
   корня и при смонтированных сетевых ФС, так что облом по ним в initrd
   IMHO следует считать нефатальным и делать быстрым, если это возможно.

PS: по крайней мере для случая инсталятора видится разумным сторговать некоторое количество автоматики в пользу надёжности за счёт того, что при формировании initrd ситуация полностью открыта и может быть проанализирована без угадывания.

(В ответ на комментарий №41)
> 1) видимо, всё-таки не /etc/fstab, а /etc/crypttab (и вернуть тогда в /vm
>    его генерацию, которая была сделана, но сейчас заремарена);

Поддержка /etc/crypttab никак не поможет решить проблему. Он может пригодиться при создании образа, чтобы знать какие ещё модули ядра нужно положить и он может пригодиться при раскрытии контейнера, но не больше т.е. к проблеме ограничения куда заглядывать это не относится.

> 2) обязательным требованием к m-i-l является умение открыть корень,
>    если он оказался в luks;

Этот пункт о чём? Задача initrd заключается в умении открыть корень. Все модули позволяют распознать ту или иную схему размещения корня. Модуль make-initrd-luks уже реализует определённое количество таких схем. Модуль уже удовлетворяет этому пункту в такой постановке задачи.

> 3) желательным навыком m-i-l может быть примерка заданного для корня пароля
>    и к другим оставленным в итоге для попытки открытия контейнерам
>    (см. тж. bug #28200 -- понимаю, что это небесспорное решение, но лучше
>    пока никто не предложил);

Только после того, как кто-то предложит как _безопасно_ сохранить пароль между необходимостью очередного его использования.

> 4) luks-контейнеры для некорневых ФС могут обрабатываться уже с поднятого
>    корня и при смонтированных сетевых ФС, так что облом по ним в initrd
>    IMHO следует считать нефатальным и делать быстрым, если это возможно.

Это и сейчас так.

> PS: по крайней мере для случая инсталятора видится разумным сторговать
> некоторое количество автоматики в пользу надёжности за счёт того, что при
> формировании initrd ситуация полностью открыта и может быть проанализирована
> без угадывания.

Мне кажется, что вам хочется mkinitrd. Там последовательность проанализирована без угадывания. Он всё ещё доступен в сизифе.

(В ответ на комментарий №42)
> (В ответ на комментарий №41)
> > 1) видимо, всё-таки не /etc/fstab, а /etc/crypttab (и вернуть тогда в /vm
> >    его генерацию, которая была сделана, но сейчас заремарена);
> 
> Поддержка /etc/crypttab никак не поможет решить проблему. Он может пригодиться
> при создании образа, чтобы знать какие ещё модули ядра нужно положить и он
> может пригодиться при раскрытии контейнера, но не больше т.е. к проблеме
> ограничения куда заглядывать это не относится.
> 
> > 2) обязательным требованием к m-i-l является умение открыть корень,
> >    если он оказался в luks;
> 
> Этот пункт о чём? Задача initrd заключается в умении открыть корень. Все модули
> позволяют распознать ту или иную схему размещения корня. Модуль
> make-initrd-luks уже реализует определённое количество таких схем. Модуль уже
> удовлетворяет этому пункту в такой постановке задачи.
> 
> > 3) желательным навыком m-i-l может быть примерка заданного для корня пароля
> >    и к другим оставленным в итоге для попытки открытия контейнерам
> >    (см. тж. bug #28200 -- понимаю, что это небесспорное решение, но лучше
> >    пока никто не предложил);
> 
> Только после того, как кто-то предложит как _безопасно_ сохранить пароль между
> необходимостью очередного его использования.
> 
> > 4) luks-контейнеры для некорневых ФС могут обрабатываться уже с поднятого
> >    корня и при смонтированных сетевых ФС, так что облом по ним в initrd
> >    IMHO следует считать нефатальным и делать быстрым, если это возможно.
> 
> Это и сейчас так.
> 
> > PS: по крайней мере для случая инсталятора видится разумным сторговать
> > некоторое количество автоматики в пользу надёжности за счёт того, что при
> > формировании initrd ситуация полностью открыта и может быть проанализирована
> > без угадывания.
> 
> Мне кажется, что вам хочется mkinitrd. Там последовательность проанализирована
> без угадывания. Он всё ещё доступен в сизифе.

Нет уж. :-)

Вообще, 2 и 4 уже выполнено, на legion@ убедительно ответил, а 3 -- пожелание. Можно двигаться дальше, положение дел обсудили.

(В ответ на комментарий №43)
> 
> Вообще, 2 и 4 уже выполнено, на legion@ убедительно ответил, а 3 -- пожелание.
> Можно двигаться дальше, положение дел обсудили.

legion@ убедительно ответил на п.1

installer-0.8.14

Реализована следующая схема: luks добавляется в initrd только в том случае, если на нём расположен /. Тогда, как и сейчас, все контейнеры раскрываются в initrd и это неизбежно, хотя, может быть, временами и неудобно.

В случае, если / расположен не на luks, в целевой системе создаётся /etc/crypttab и раскрытие контейнеров происходит уже после завершения работы initrd.

Вссем большое спасибо за обсуждение.

При попытке сгенерировать образ:

Generating module dependencies on host ...
/usr/share/make-initrd/features/luks/guess/device: line 13: guess-kbd: команда не найдена

Это новая бага на make-initrd-luks, а не переоткрытие совсем другой.
Повесите?

(В ответ на комментарий №47)
> Это новая бага на make-initrd-luks, а не переоткрытие совсем другой.
> Повесите?
Ага
#29688