Bug 28255 - открытие LUKS-контейнеров с некорневыми ФС
: открытие LUKS-контейнеров с некорневыми ФС
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/cross-component)
: unstable
: all Linux
: P3 normal
Assigned To:
:
:
:
: 28268
: 27685
  Show dependency tree
 
Reported: 2012-12-21 18:02 by
Modified: 2014-01-08 15:25 (History)


Attachments
Всегда добавлять модуль luks в образ initrd (634 bytes, patch)
2012-12-27 14:26, timonbl4@altlinux.org
no flags Details | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-12-21 18:02:22
Если установить систему с /home на LUKS и обычным /, то при загрузке initrd,
собранный make-initrd-0.7.9-alt1, не будет запрашивать пароль и открывать такой
контейнер; поскольку installer >= 1.7.10-alt1 не создаёт /etc/crypttab, то
далее этим контейнером заниматься также никто не будет, а при попытке
монтирования ФС получим ошибку (UUID файловой системы в закрытом контейнере не
видел, вывод dmsetup info пуст).

Перед тем, как вешать предметные баги на make-initrd и cryptsetup, предлагаю
договориться о том, как у нас будет выполняться открытие криптоконтейнеров для
файловых систем, кроме корневой.
------- Comment #1 From 2012-12-21 18:10:22 -------
PS: с сизифными cryptsetup-1.4.2-alt2 и make-initrd-0.7.9-alt1 при ситуациях,
когда в initrd уже открыли контейнер с ФС для /home, дополнительные три попытки
спросить пароль и безуспешно задействовать уже занятое устройство при загрузке
немного раздражают (cryptdisks.functions стоит научить проверять, не открыт ли
уже контейнер).
------- Comment #2 From 2012-12-24 16:04:49 -------
(В ответ на комментарий №1)
> (cryptdisks.functions стоит научить проверять, не открыт ли
> уже контейнер).

Он умеет, но проверяет по отображаемому названию устройства
------- Comment #3 From 2012-12-24 16:11:08 -------
Подстраховать по другим именам (или realpath) в принципе возможно или нет?
Когда рассматривал всё это -- мысли были в эту сторону, но не доковырял...
------- Comment #4 From 2012-12-24 16:14:24 -------
Предлагаю забыть про crypttab и одать всё в руки make-initrd-luks
------- Comment #5 From 2012-12-24 18:08:39 -------
(В ответ на комментарий №4)
> Предлагаю забыть про crypttab и одать всё в руки make-initrd-luks

Насколько я понял, проблема в том, что если / не на luks, make-initrd-luks себя
никак не проявляет и это логично..
------- Comment #6 From 2012-12-24 18:16:58 -------
(В ответ на комментарий №5)
> Насколько я понял, проблема в том, что если / не на luks, make-initrd-luks себя
> никак не проявляет и это логично..

Да, но если зашифрован / и /home , то make-initrd-luks проявляет свою
активность на / и на /home
------- Comment #7 From 2012-12-24 18:27:55 -------
(В ответ на комментарий №6)
> Да, но если зашифрован / и /home , то make-initrd-luks проявляет свою
> активность на / и на /home

И оба случая должны работать..
------- Comment #8 From 2012-12-24 19:48:27 -------
(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@.
------- Comment #9 From 2012-12-27 13:01:18 -------
Тимур, Антон, что с этой багой? Очень хотелось бы закончить интеграцией с LUKS
в установщик.
------- Comment #10 From 2012-12-27 14:26:44 -------
Created an attachment (id=5688) [details]
Всегда добавлять модуль luks в образ initrd
------- Comment #11 From 2012-12-27 14:42:29 -------
Это не патч, а хак. Такой патч я не приму. Если хотите хакать и всегда
добавлять luks, то делайте:

echo "FEATURES += luks" >> /etc/initrd.mk
------- Comment #12 From 2012-12-27 15:01:59 -------
(В ответ на комментарий №11)
> Если хотите хакать и всегда
> добавлять luks, то делайте:
> 
> echo "FEATURES += luks" >> /etc/initrd.mk

О, спасибо
------- Comment #13 From 2012-12-27 15:08:01 -------
Перевешиваю на timonbl4 и переоткрываю.
------- Comment #14 From 2012-12-27 15:13:47 -------
(In reply to comment #11)
> echo "FEATURES += luks" >> /etc/initrd.mk
Если уж так делать, то лучше условно (но перед генерацией initrd).
------- Comment #15 From 2012-12-27 15:18:31 -------
Я так и не понял какую проблему вы пытаетесь решить.
------- Comment #16 From 2012-12-27 15:34:36 -------
Отправил в сизиф installer 1.8.12-alt1
------- Comment #17 From 2012-12-27 15:46:36 -------
(In reply to comment #15)
> Я так и не понял какую проблему вы пытаетесь решить.
http://www.altlinux.org/План_выпуска_бранча_p7 => "Поддержка установки на
криптованные фс"

(In reply to comment #16)
> Отправил в сизиф installer 1.8.12-alt1
Переделаю в условную форму, к preinstall у нас уже есть сведения -- делали LUKS
или нет.  Переоткрываю и забираю багу.
------- Comment #18 From 2012-12-27 16:08:05 -------
(В ответ на комментарий №17)
> (In reply to comment #15)
> > Я так и не понял какую проблему вы пытаетесь решить.
> http://www.altlinux.org/План_выпуска_бранча_p7 => "Поддержка установки на
> криптованные фс"

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

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

Приемка за qa@. Здесь это cas@
------- Comment #20 From 2012-12-27 16:29:49 -------
Лёш, если ты не заметил -- то comment #0 как раз и был попыткой прояснить
задачу.

Понятно, что есть что улучшать, но давай роль плешееда традиционно оставим мне.
:)
------- Comment #21 From 2012-12-27 16:40:59 -------
(В ответ на комментарий №19)
> Приемка за qa@. Здесь это cas@

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

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

Миш, ты прости, но это не прояснение задачи, а лирическое повествование
(родился и жил он жил пока умер) какого-то процесса с интригой и болью. Это
даже не описание для баги. Проблема не поставлена, ожидаемое не описано ... как
воспроизвести тоже.
------- Comment #22 From 2012-12-27 16:44:13 -------
(В ответ на комментарий №21)
> (В ответ на комментарий №19)
> > Приемка за qa@. Здесь это cas@
> 
> Здорово. Вот ещё один несчастный кроме исполнителя. А что он будет принимать
> ведь вы, Алексей, с марта прошлого года так и не смогли пояснить в wiki, что
> имели в виду под фразой "Поддержка установки на криптованные фс" ? Что
> исполнитель должен был реализовать ?

Алексей, Вы же не спрашивали. Тот же, кто спрашивал, получил ответ. И фича эта
скоро, надеюсь, пройдет qa и будет описана в документации.
------- Comment #23 From 2012-12-27 16:49:44 -------
(In reply to comment #21)
> Проблема не поставлена, ожидаемое не описано ... как воспроизвести тоже.
Вот и занимаюсь выяснением и фиксированием.  Мало того, в определённой мере это
мне развязывает руки (см. bug #28200) -- если по ходу выяснения осмысленных use
case оказывается, что что-то можно сделать иначе, чем было сделано или вроде бы
как предполагалось -- можно постараться сделать по уму и не наталкиваться на
устаревшее, но зато точно выписанное, формальное требование.

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

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

Спасибо всем за конструктивную часть обсуждения и предлагаю всё-таки дать мне
на праздниках время спокойно над этим подумать.  Начиная с этого самого
plymouth, который тут слишком сильно влияет, и заканчивая поиском живых
пользователей.
------- Comment #24 From 2012-12-27 17:00:32 -------
(В ответ на комментарий №22)
> Алексей, Вы же не спрашивали. Тот же, кто спрашивал, получил ответ. И фича эта
> скоро, надеюсь, пройдет qa и будет описана в документации.

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

Перевешиваю обратно на абстрактный компонент т.к. кулуарная проблема до меня не
доведена и значит для меня её нет.
------- Comment #25 From 2012-12-27 17:02:08 -------
(В ответ на комментарий №24)
> (В ответ на комментарий №22)
> > Алексей, Вы же не спрашивали. Тот же, кто спрашивал, получил ответ. И фича эта
> > скоро, надеюсь, пройдет qa и будет описана в документации.
> 
> Я не спрашивал, но невольно стал жертвой вашего внутреннего междусобойчика т.к.
> в итоге "проблема" была перевешана на мой проект без должного описания. Такой
> приватный выхлоп лишь тратит моё время.
> 
> Перевешиваю обратно на абстрактный компонент т.к. кулуарная проблема до меня не
> доведена и значит для меня её нет.

Согласен, Вы абсолютно правы.
------- Comment #26 From 2012-12-27 17:34:44 -------
(В ответ на комментарий №19)
> Приемка за qa@. Здесь это cas@
Проверил. Не работает после установки (не монтируется, так как UUID в
/etc/fstab отличен от реального).
------- Comment #27 From 2012-12-27 18:10:39 -------
(В ответ на комментарий №26)
> Проверил. Не работает после установки (не монтируется, так как UUID в
> /etc/fstab отличен от реального).

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

У меня с версией installer 1.8.12-alt1 работает
------- Comment #28 From 2012-12-27 18:34:03 -------
(В ответ на комментарий №27)
> (В ответ на комментарий №26)
> > Проверил. Не работает после установки (не монтируется, так как UUID в
> > /etc/fstab отличен от реального).
> 
> Нужны подробности. В установленной системе строчка "FEATURES += luks" в файле
> /etc/initrd.mk присутствует? 
Отсутствует.

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

Если добавить в initrd.mk поддержку LUKS, при загрузке в консоли начинает
бесконечно запрашивать пароль. Графически ничего не показывает. Система ужасно
тормозит.
------- Comment #29 From 2012-12-27 18:48:32 -------
(In reply to comment #28)
> > Нужны подробности. В установленной системе строчка "FEATURES += luks" в файле
> > /etc/initrd.mk присутствует? 
> Отсутствует.
А что за образ был взят для проверки?

> Если добавить в initrd.mk поддержку LUKS, при загрузке в консоли начинает
> бесконечно запрашивать пароль. Графически ничего не показывает.
Это известный, но ещё AFAIR не повешенный даже FR -- прикрутить к plymouth
(причём мест сразу два -- initrd и стартап).  Отчасти обсуждали с boyarsh@.
------- Comment #30 From 2012-12-28 13:04:59 -------
(В ответ на комментарий №29)
> (In reply to comment #28)
> > > Нужны подробности. В установленной системе строчка "FEATURES += luks" в файле
> > > /etc/initrd.mk присутствует? 
> > Отсутствует.
> А что за образ был взят для проверки?
Вчерашняя ночная сборка.
------- Comment #31 From 2012-12-28 16:01:32 -------
Сегодняшняя сборка показала, что пароль на зашифрованные разделы можно ввести в
консоли, если убрать параметр vga=0x314 из параметров GRUB.
------- Comment #32 From 2012-12-28 16:03:35 -------
> Предлагаю набросок плана действий при загрузке:
> - initrd:
>   + если включен plymouth, спрашиваем пароль через него и пытаемся применить
>     ко всем найденным LUKS-контейнерам (сделанные инсталером должны открыться);
>   + иначе спрашиваем/передаём сами (или оставляем это бинарнику cryptsetup);
Вопрос оказался неожиданно актуальным, так как:
 1) при работающем plymouth спрашивалка из cryptsetup оказывается под ним (это,
конечно, добавляет безопасности :D )
 2) при vga=0xЧТО-НИБУДЬ (там, где нет kms) спрашивалка из cryptsetup нормально
вообще не работает независимо от наличия plymouth (что уже через чур безопасно
:DD )

Надо делать спрашивание через plymouth в initrd...
------- Comment #33 From 2012-12-28 17:52:18 -------
(In reply to comment #32)
> Надо делать спрашивание через plymouth в initrd...
О чём comment #8 и был.
------- Comment #34 From 2013-01-23 13:32:28 -------
В общем, всё равно грабли.
Казалось, бы, в первом приближении, мы решили проблему с luks на некорневых
разделах, добавляя FEATURES=luks, но на самом деле мы создали себе новые
проблемы.

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

Из этого следует, что make-initrd-luks надо модифицировать таким образом, чтоб
он работал только с контейнерами, перечисленными в /etc/fstab или вообще только
с корневым разделом, а остальные отдать на более позднюю стадию, обеспечив
согласованность работы.
------- Comment #35 From 2013-01-23 13:39:37 -------
(В ответ на комментарий №34)
> Из этого следует, что make-initrd-luks надо модифицировать таким образом, чтоб
> он работал только с контейнерами, перечисленными в /etc/fstab или вообще только
> с корневым разделом, а остальные отдать на более позднюю стадию, обеспечив
> согласованность работы.

Так делать нельзя by-design. Есть идея как это исправить в принципе, но это
требует сильной модификации механизма угадава.
------- Comment #36 From 2013-01-23 13:46:45 -------
(В ответ на комментарий №34)
> 
> make-initrd-luks пытается раскрыть всё, что является luks контейнерами. При
> том, что на дисках могут быть luks контейнеры от других систем, luks
> контейнеры, которые должны монтироваться при входе пользователя через pam_mount
> и тп.
> 
Учитывая сказанное legion@:
если раскрытие "luks контейнеров от других систем, luks
> контейнеры, которые должны монтироваться при входе пользователя через pam_mount
> и тп." не удастся, то достаточно вывести сообщение об этом, не прерывая работу.
------- Comment #37 From 2013-01-23 13:53:41 -------
(В ответ на комментарий №35)
> (В ответ на комментарий №34)
(В ответ на комментарий №35)

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

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

Надо что-то придумать, так как иначе поддержка luks получается.. своеобразная..
------- Comment #38 From 2013-01-23 14:32:06 -------
(В ответ на комментарий №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 и ниже по треду.
------- Comment #39 From 2013-01-23 14:47:56 -------
(В ответ на комментарий №38)
>
> Также предложенная идея потребует не только определения составных частей
> "матрёшки" при создании initrd, но и аккуратного сохранения последовательности
> и параметров иерархии.
Хмм.. А ведь, вообще говоря, нам никто не обещал, что нам не передадут
какой-нибудь другой UUID, который мы не знаем где брать и, соответсвенно, нам
придётся искать его по всем контейнерам.. То есть в лучшем случае такое решение
можно использовать для того раздела, который был корневым в момент сборки
initrd, но сохранить и угадав старого образца для случая, когда нам дали другой
UUID...

> Для этого нужно переделать архитектуру угадава, сделав
> его более фичастым, отвечающим новым задачам (которых раньше не было). Это
> большая работа, которую как ты знаешь я уже веду, но прогнозов по ней у меня
> нет т.к. она не в приоритете у меня сейчас. Плюс тут есть над чем подумать.
Да, спасибо за объяснение, тут действительно есть над чем задуматься..
------- Comment #40 From 2013-01-23 15:15:44 -------
(В ответ на комментарий №39)
> Хмм.. А ведь, вообще говоря, нам никто не обещал, что нам не передадут
> какой-нибудь другой UUID, который мы не знаем где брать и, соответсвенно, нам
> придётся искать его по всем контейнерам.. То есть в лучшем случае такое решение
> можно использовать для того раздела, который был корневым в момент сборки 
> initrd, но сохранить и угадав старого образца для случая, когда нам дали другой
> UUID...

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

Новый механизм можно увязать с этим же механизмом активации т.е. использовать
сохранённую "матрёшку" в случае если параметр root= не указан или равен
сохранённому. В этом случае задача будет ещё более интересная т.к. нужно будет
не переписать действующий механизм определения, а дополнить возможностью
задания вектора поиска.
------- Comment #41 From 2013-01-23 16:13:18 -------
(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 ситуация полностью открыта и может быть проанализирована
без угадывания.
------- Comment #42 From 2013-01-23 16:42:17 -------
(В ответ на комментарий №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. Там последовательность проанализирована
без угадывания. Он всё ещё доступен в сизифе.
------- Comment #43 From 2013-01-23 17:43:54 -------
(В ответ на комментарий №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 -- пожелание.
Можно двигаться дальше, положение дел обсудили.
------- Comment #44 From 2013-01-23 17:45:16 -------
(В ответ на комментарий №43)
> 
> Вообще, 2 и 4 уже выполнено, на legion@ убедительно ответил, а 3 -- пожелание.
> Можно двигаться дальше, положение дел обсудили.

legion@ убедительно ответил на п.1
------- Comment #45 From 2013-01-24 08:54:58 -------
installer-0.8.14

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

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

Вссем большое спасибо за обсуждение.
------- Comment #46 From 2014-01-06 20:25:38 -------
При попытке сгенерировать образ:

Generating module dependencies on host ...
/usr/share/make-initrd/features/luks/guess/device: line 13: guess-kbd: команда
не найдена
------- Comment #47 From 2014-01-07 15:05:27 -------
Это новая бага на make-initrd-luks, а не переоткрытие совсем другой.
Повесите?
------- Comment #48 From 2014-01-08 15:25:41 -------
(В ответ на комментарий №47)
> Это новая бага на make-initrd-luks, а не переоткрытие совсем другой.
> Повесите?
Ага
#29688