Bug 28255

Summary: открытие LUKS-контейнеров с некорневыми ФС
Product: Sisyphus Reporter: Michael Shigorin <mike>
Component: cross-componentAssignee: Anton V. Boyarshinov <boyarsh>
Status: CLOSED FIXED QA Contact: Dmitry V. Levin <ldv>
Severity: normal    
Priority: P3 CC: aebirukov, aen, boyarsh, cas, evg, legion
Version: unstable   
Hardware: all   
OS: Linux   
Bug Depends on: 28268    
Bug Blocks: 27685    
Attachments:
Description Flags
Всегда добавлять модуль luks в образ initrd none

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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