28255 2012-12-21 18:02:22 +0400 открытие LUKS-контейнеров с некорневыми ФС 2014-01-08 15:25:41 +0400 1 1 4 Development Sisyphus cross-component unstable all Linux CLOSED FIXED P3 normal --- 28268 27685 1 mike boyarsh aebirukov aen boyarsh cas evg legion ldv oldest_to_newest 136247 0 mike 2012-12-21 18:02:22 +0400 Если установить систему с /home на LUKS и обычным /, то при загрузке initrd, собранный make-initrd-0.7.9-alt1, не будет запрашивать пароль и открывать такой контейнер; поскольку installer >= 1.7.10-alt1 не создаёт /etc/crypttab, то далее этим контейнером заниматься также никто не будет, а при попытке монтирования ФС получим ошибку (UUID файловой системы в закрытом контейнере не видел, вывод dmsetup info пуст). Перед тем, как вешать предметные баги на make-initrd и cryptsetup, предлагаю договориться о том, как у нас будет выполняться открытие криптоконтейнеров для файловых систем, кроме корневой. 136248 1 mike 2012-12-21 18:10:22 +0400 PS: с сизифными cryptsetup-1.4.2-alt2 и make-initrd-0.7.9-alt1 при ситуациях, когда в initrd уже открыли контейнер с ФС для /home, дополнительные три попытки спросить пароль и безуспешно задействовать уже занятое устройство при загрузке немного раздражают (cryptdisks.functions стоит научить проверять, не открыт ли уже контейнер). 136342 2 timonbl4 2012-12-24 16:04:49 +0400 (В ответ на комментарий №1) > (cryptdisks.functions стоит научить проверять, не открыт ли > уже контейнер). Он умеет, но проверяет по отображаемому названию устройства 136343 3 mike 2012-12-24 16:11:08 +0400 Подстраховать по другим именам (или realpath) в принципе возможно или нет? Когда рассматривал всё это -- мысли были в эту сторону, но не доковырял... 136344 4 timonbl4 2012-12-24 16:14:24 +0400 Предлагаю забыть про crypttab и одать всё в руки make-initrd-luks 136346 5 boyarsh 2012-12-24 18:08:39 +0400 (В ответ на комментарий №4) > Предлагаю забыть про crypttab и одать всё в руки make-initrd-luks Насколько я понял, проблема в том, что если / не на luks, make-initrd-luks себя никак не проявляет и это логично.. 136347 6 timonbl4 2012-12-24 18:16:58 +0400 (В ответ на комментарий №5) > Насколько я понял, проблема в том, что если / не на luks, make-initrd-luks себя > никак не проявляет и это логично.. Да, но если зашифрован / и /home , то make-initrd-luks проявляет свою активность на / и на /home 136348 7 boyarsh 2012-12-24 18:27:55 +0400 (В ответ на комментарий №6) > Да, но если зашифрован / и /home , то make-initrd-luks проявляет свою > активность на / и на /home И оба случая должны работать.. 136352 8 mike 2012-12-24 19:48:27 +0400 (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@. 136432 9 aen 2012-12-27 13:01:18 +0400 Тимур, Антон, что с этой багой? Очень хотелось бы закончить интеграцией с LUKS в установщик. 136435 10 5688 timonbl4 2012-12-27 14:26:44 +0400 Created attachment 5688 Всегда добавлять модуль luks в образ initrd 136436 11 legion 2012-12-27 14:42:29 +0400 Это не патч, а хак. Такой патч я не приму. Если хотите хакать и всегда добавлять luks, то делайте: echo "FEATURES += luks" >> /etc/initrd.mk 136437 12 timonbl4 2012-12-27 15:01:59 +0400 (В ответ на комментарий №11) > Если хотите хакать и всегда > добавлять luks, то делайте: > > echo "FEATURES += luks" >> /etc/initrd.mk О, спасибо 136438 13 aen 2012-12-27 15:08:01 +0400 Перевешиваю на timonbl4 и переоткрываю. 136439 14 mike 2012-12-27 15:13:47 +0400 (In reply to comment #11) > echo "FEATURES += luks" >> /etc/initrd.mk Если уж так делать, то лучше условно (но перед генерацией initrd). 136440 15 legion 2012-12-27 15:18:31 +0400 Я так и не понял какую проблему вы пытаетесь решить. 136441 16 timonbl4 2012-12-27 15:34:36 +0400 Отправил в сизиф installer 1.8.12-alt1 136443 17 mike 2012-12-27 15:46:36 +0400 (In reply to comment #15) > Я так и не понял какую проблему вы пытаетесь решить. http://www.altlinux.org/План_выпуска_бранча_p7 => "Поддержка установки на криптованные фс" (In reply to comment #16) > Отправил в сизиф installer 1.8.12-alt1 Переделаю в условную форму, к preinstall у нас уже есть сведения -- делали LUKS или нет. Переоткрываю и забираю багу. 136444 18 legion 2012-12-27 16:08:05 +0400 (В ответ на комментарий №17) > (In reply to comment #15) > > Я так и не понял какую проблему вы пытаетесь решить. > http://www.altlinux.org/План_выпуска_бранча_p7 => "Поддержка установки на > криптованные фс" Что это ещё за "предвыборные обещания президента"?! Это, простите, из серии "Петька, приборы? 20!". Это не постановка задачи, а расплывчатая фраза, из которой можно вынести ещё меньше, чем из сумбурного обсуждения в нескольких багах в этой багзилле. Из этого я понял, что 18 марта 2012 на wiki один человек что-то написал, а вы в связи с этим что-то сделали. Чудно! Видимо приёмка по этому пункту будет в том же стиле: кто-то что-то проверил и установил, что что-то сделано :) 136445 19 aen 2012-12-27 16:24:17 +0400 (В ответ на комментарий №18) > (В ответ на комментарий №17) > > (In reply to comment #15) > > > Я так и не понял какую проблему вы пытаетесь решить. > > http://www.altlinux.org/План_выпуска_бранча_p7 => "Поддержка установки на > > криптованные фс" > > Что это ещё за "предвыборные обещания президента"?! Это, простите, из серии > "Петька, приборы? 20!". Это не постановка задачи, а расплывчатая фраза, из > которой можно вынести ещё меньше, чем из сумбурного обсуждения в нескольких > багах в этой багзилле. > > Из этого я понял, что 18 марта 2012 на wiki один человек что-то написал, а вы в > связи с этим что-то сделали. Чудно! Видимо приёмка по этому пункту будет в том > же стиле: кто-то что-то проверил и установил, что что-то сделано :) Приемка за qa@. Здесь это cas@ 136446 20 mike 2012-12-27 16:29:49 +0400 Лёш, если ты не заметил -- то comment #0 как раз и был попыткой прояснить задачу. Понятно, что есть что улучшать, но давай роль плешееда традиционно оставим мне. :) 136449 21 legion 2012-12-27 16:40:59 +0400 (В ответ на комментарий №19) > Приемка за qa@. Здесь это cas@ Здорово. Вот ещё один несчастный кроме исполнителя. А что он будет принимать ведь вы, Алексей, с марта прошлого года так и не смогли пояснить в wiki, что имели в виду под фразой "Поддержка установки на криптованные фс" ? Что исполнитель должен был реализовать ? (В ответ на комментарий №20) > Лёш, если ты не заметил -- то comment #0 как раз и был попыткой прояснить > задачу. Миш, ты прости, но это не прояснение задачи, а лирическое повествование (родился и жил он жил пока умер) какого-то процесса с интригой и болью. Это даже не описание для баги. Проблема не поставлена, ожидаемое не описано ... как воспроизвести тоже. 136451 22 aen 2012-12-27 16:44:13 +0400 (В ответ на комментарий №21) > (В ответ на комментарий №19) > > Приемка за qa@. Здесь это cas@ > > Здорово. Вот ещё один несчастный кроме исполнителя. А что он будет принимать > ведь вы, Алексей, с марта прошлого года так и не смогли пояснить в wiki, что > имели в виду под фразой "Поддержка установки на криптованные фс" ? Что > исполнитель должен был реализовать ? Алексей, Вы же не спрашивали. Тот же, кто спрашивал, получил ответ. И фича эта скоро, надеюсь, пройдет qa и будет описана в документации. 136453 23 mike 2012-12-27 16:49:44 +0400 (In reply to comment #21) > Проблема не поставлена, ожидаемое не описано ... как воспроизвести тоже. Вот и занимаюсь выяснением и фиксированием. Мало того, в определённой мере это мне развязывает руки (см. bug #28200) -- если по ходу выяснения осмысленных use case оказывается, что что-то можно сделать иначе, чем было сделано или вроде бы как предполагалось -- можно постараться сделать по уму и не наталкиваться на устаревшее, но зато точно выписанное, формальное требование. (In reply to comment #22) > И фича эта скоро, надеюсь, пройдет qa и будет описана в документации. При этом у Андрея тоже возникнет масса вопросов и предложений, поди. :) Может быть, к 7.0.x или 8 их получится даже сделать... Спасибо всем за конструктивную часть обсуждения и предлагаю всё-таки дать мне на праздниках время спокойно над этим подумать. Начиная с этого самого plymouth, который тут слишком сильно влияет, и заканчивая поиском живых пользователей. 136454 24 legion 2012-12-27 17:00:32 +0400 (В ответ на комментарий №22) > Алексей, Вы же не спрашивали. Тот же, кто спрашивал, получил ответ. И фича эта > скоро, надеюсь, пройдет qa и будет описана в документации. Я не спрашивал, но невольно стал жертвой вашего внутреннего междусобойчика т.к. в итоге "проблема" была перевешана на мой проект без должного описания. Такой приватный выхлоп лишь тратит моё время. Перевешиваю обратно на абстрактный компонент т.к. кулуарная проблема до меня не доведена и значит для меня её нет. 136455 25 aen 2012-12-27 17:02:08 +0400 (В ответ на комментарий №24) > (В ответ на комментарий №22) > > Алексей, Вы же не спрашивали. Тот же, кто спрашивал, получил ответ. И фича эта > > скоро, надеюсь, пройдет qa и будет описана в документации. > > Я не спрашивал, но невольно стал жертвой вашего внутреннего междусобойчика т.к. > в итоге "проблема" была перевешана на мой проект без должного описания. Такой > приватный выхлоп лишь тратит моё время. > > Перевешиваю обратно на абстрактный компонент т.к. кулуарная проблема до меня не > доведена и значит для меня её нет. Согласен, Вы абсолютно правы. 136466 26 cas 2012-12-27 17:34:44 +0400 (В ответ на комментарий №19) > Приемка за qa@. Здесь это cas@ Проверил. Не работает после установки (не монтируется, так как UUID в /etc/fstab отличен от реального). 136470 27 timonbl4 2012-12-27 18:10:39 +0400 (В ответ на комментарий №26) > Проверил. Не работает после установки (не монтируется, так как UUID в > /etc/fstab отличен от реального). Нужны подробности. В установленной системе строчка "FEATURES += luks" в файле /etc/initrd.mk присутствует? make-initrd-luks установлен? У меня с версией installer 1.8.12-alt1 работает 136471 28 cas 2012-12-27 18:34:03 +0400 (В ответ на комментарий №27) > (В ответ на комментарий №26) > > Проверил. Не работает после установки (не монтируется, так как UUID в > > /etc/fstab отличен от реального). > > Нужны подробности. В установленной системе строчка "FEATURES += luks" в файле > /etc/initrd.mk присутствует? Отсутствует. > make-initrd-luks установлен? 0.7.9-alt1 Если добавить в initrd.mk поддержку LUKS, при загрузке в консоли начинает бесконечно запрашивать пароль. Графически ничего не показывает. Система ужасно тормозит. 136473 29 mike 2012-12-27 18:48:32 +0400 (In reply to comment #28) > > Нужны подробности. В установленной системе строчка "FEATURES += luks" в файле > > /etc/initrd.mk присутствует? > Отсутствует. А что за образ был взят для проверки? > Если добавить в initrd.mk поддержку LUKS, при загрузке в консоли начинает > бесконечно запрашивать пароль. Графически ничего не показывает. Это известный, но ещё AFAIR не повешенный даже FR -- прикрутить к plymouth (причём мест сразу два -- initrd и стартап). Отчасти обсуждали с boyarsh@. 136495 30 cas 2012-12-28 13:04:59 +0400 (В ответ на комментарий №29) > (In reply to comment #28) > > > Нужны подробности. В установленной системе строчка "FEATURES += luks" в файле > > > /etc/initrd.mk присутствует? > > Отсутствует. > А что за образ был взят для проверки? Вчерашняя ночная сборка. 136501 31 cas 2012-12-28 16:01:32 +0400 Сегодняшняя сборка показала, что пароль на зашифрованные разделы можно ввести в консоли, если убрать параметр vga=0x314 из параметров GRUB. 136502 32 boyarsh 2012-12-28 16:03:35 +0400 > Предлагаю набросок плана действий при загрузке: > - initrd: > + если включен plymouth, спрашиваем пароль через него и пытаемся применить > ко всем найденным LUKS-контейнерам (сделанные инсталером должны открыться); > + иначе спрашиваем/передаём сами (или оставляем это бинарнику cryptsetup); Вопрос оказался неожиданно актуальным, так как: 1) при работающем plymouth спрашивалка из cryptsetup оказывается под ним (это, конечно, добавляет безопасности :D ) 2) при vga=0xЧТО-НИБУДЬ (там, где нет kms) спрашивалка из cryptsetup нормально вообще не работает независимо от наличия plymouth (что уже через чур безопасно :DD ) Надо делать спрашивание через plymouth в initrd... 136503 33 mike 2012-12-28 17:52:18 +0400 (In reply to comment #32) > Надо делать спрашивание через plymouth в initrd... О чём comment #8 и был. 137157 34 boyarsh 2013-01-23 13:32:28 +0400 В общем, всё равно грабли. Казалось, бы, в первом приближении, мы решили проблему с luks на некорневых разделах, добавляя FEATURES=luks, но на самом деле мы создали себе новые проблемы. make-initrd-luks пытается раскрыть всё, что является luks контейнерами. При том, что на дисках могут быть luks контейнеры от других систем, luks контейнеры, которые должны монтироваться при входе пользователя через pam_mount и тп. Из этого следует, что make-initrd-luks надо модифицировать таким образом, чтоб он работал только с контейнерами, перечисленными в /etc/fstab или вообще только с корневым разделом, а остальные отдать на более позднюю стадию, обеспечив согласованность работы. 137158 35 legion 2013-01-23 13:39:37 +0400 (В ответ на комментарий №34) > Из этого следует, что make-initrd-luks надо модифицировать таким образом, чтоб > он работал только с контейнерами, перечисленными в /etc/fstab или вообще только > с корневым разделом, а остальные отдать на более позднюю стадию, обеспечив > согласованность работы. Так делать нельзя by-design. Есть идея как это исправить в принципе, но это требует сильной модификации механизма угадава. 137160 36 aen 2013-01-23 13:46:45 +0400 (В ответ на комментарий №34) > > make-initrd-luks пытается раскрыть всё, что является luks контейнерами. При > том, что на дисках могут быть luks контейнеры от других систем, luks > контейнеры, которые должны монтироваться при входе пользователя через pam_mount > и тп. > Учитывая сказанное legion@: если раскрытие "luks контейнеров от других систем, luks > контейнеры, которые должны монтироваться при входе пользователя через pam_mount > и тп." не удастся, то достаточно вывести сообщение об этом, не прерывая работу. 137161 37 boyarsh 2013-01-23 13:53:41 +0400 (В ответ на комментарий №35) > (В ответ на комментарий №34) (В ответ на комментарий №35) > Так делать нельзя by-design. Не мог бы ты пояснить (не обязательно сию минуту, разумеется), чем именно это черевато или почему нельзя сделать. > Есть идея как это исправить в принципе, но это > требует сильной модификации механизма угадава. Угадава в make-initrd вообще, а не в make-initrd-luks, я правильно понимаю? Надо что-то придумать, так как иначе поддержка luks получается.. своеобразная.. 137162 38 legion 2013-01-23 14:32:06 +0400 (В ответ на комментарий №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 и ниже по треду. 137165 39 boyarsh 2013-01-23 14:47:56 +0400 (В ответ на комментарий №38) > > Также предложенная идея потребует не только определения составных частей > "матрёшки" при создании initrd, но и аккуратного сохранения последовательности > и параметров иерархии. Хмм.. А ведь, вообще говоря, нам никто не обещал, что нам не передадут какой-нибудь другой UUID, который мы не знаем где брать и, соответсвенно, нам придётся искать его по всем контейнерам.. То есть в лучшем случае такое решение можно использовать для того раздела, который был корневым в момент сборки initrd, но сохранить и угадав старого образца для случая, когда нам дали другой UUID... > Для этого нужно переделать архитектуру угадава, сделав > его более фичастым, отвечающим новым задачам (которых раньше не было). Это > большая работа, которую как ты знаешь я уже веду, но прогнозов по ней у меня > нет т.к. она не в приоритете у меня сейчас. Плюс тут есть над чем подумать. Да, спасибо за объяснение, тут действительно есть над чем задуматься.. 137169 40 legion 2013-01-23 15:15:44 +0400 (В ответ на комментарий №39) > Хмм.. А ведь, вообще говоря, нам никто не обещал, что нам не передадут > какой-нибудь другой UUID, который мы не знаем где брать и, соответсвенно, нам > придётся искать его по всем контейнерам.. То есть в лучшем случае такое решение > можно использовать для того раздела, который был корневым в момент сборки > initrd, но сохранить и угадав старого образца для случая, когда нам дали другой > UUID... Сейчас (в будущей версии), make-initrd запоминает UUID рута, который был на момент сборки образа и при отсутствии параметра root= при загрузке будет брать сохранённое значение. Новый механизм можно увязать с этим же механизмом активации т.е. использовать сохранённую "матрёшку" в случае если параметр root= не указан или равен сохранённому. В этом случае задача будет ещё более интересная т.к. нужно будет не переписать действующий механизм определения, а дополнить возможностью задания вектора поиска. 137171 41 mike 2013-01-23 16:13:18 +0400 (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 ситуация полностью открыта и может быть проанализирована без угадывания. 137173 42 legion 2013-01-23 16:42:17 +0400 (В ответ на комментарий №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. Там последовательность проанализирована без угадывания. Он всё ещё доступен в сизифе. 137176 43 aen 2013-01-23 17:43:54 +0400 (В ответ на комментарий №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 -- пожелание. Можно двигаться дальше, положение дел обсудили. 137177 44 aen 2013-01-23 17:45:16 +0400 (В ответ на комментарий №43) > > Вообще, 2 и 4 уже выполнено, на legion@ убедительно ответил, а 3 -- пожелание. > Можно двигаться дальше, положение дел обсудили. legion@ убедительно ответил на п.1 137241 45 boyarsh 2013-01-24 08:54:58 +0400 installer-0.8.14 Реализована следующая схема: luks добавляется в initrd только в том случае, если на нём расположен /. Тогда, как и сейчас, все контейнеры раскрываются в initrd и это неизбежно, хотя, может быть, временами и неудобно. В случае, если / расположен не на luks, в целевой системе создаётся /etc/crypttab и раскрытие контейнеров происходит уже после завершения работы initrd. Вссем большое спасибо за обсуждение. 144475 46 aebirukov 2014-01-06 20:25:38 +0400 При попытке сгенерировать образ: Generating module dependencies on host ... /usr/share/make-initrd/features/luks/guess/device: line 13: guess-kbd: команда не найдена 144483 47 mike 2014-01-07 15:05:27 +0400 Это новая бага на make-initrd-luks, а не переоткрытие совсем другой. Повесите? 144490 48 aebirukov 2014-01-08 15:25:41 +0400 (В ответ на комментарий №47) > Это новая бага на make-initrd-luks, а не переоткрытие совсем другой. > Повесите? Ага #29688 5688 2012-12-27 14:26:44 +0400 2012-12-27 14:26:44 +0400 Всегда добавлять модуль luks в образ initrd make-initrd-luks.patch text/plain 634 timonbl4 Y29tbWl0IDJiZTZhOTdiNzRjZGQ2ZTQ5M2JhZmYwZGU4ZTJmZjQ0ZTRjZDIwODMKQXV0aG9yOiBU aW11ciBBaXRvdiA8dGltb25ibDRAYWx0bGludXgub3JnPgpEYXRlOiAgIFRodSBEZWMgMjcgMTQ6 MTk6MTkgMjAxMiArMDQwMAoKICAgIExVS1M6IGFsd2F5cyBhZGQgdGhpcyBtb2R1bGUKCmRpZmYg LS1naXQgYS9mZWF0dXJlcy9sdWtzL2d1ZXNzL2RldmljZSBiL2ZlYXR1cmVzL2x1a3MvZ3Vlc3Mv ZGV2aWNlCmluZGV4IDgyNDE5ZWYuLmFjMDU0OWMgMTAwNzU1Ci0tLSBhL2ZlYXR1cmVzL2x1a3Mv Z3Vlc3MvZGV2aWNlCisrKyBiL2ZlYXR1cmVzL2x1a3MvZ3Vlc3MvZGV2aWNlCkBAIC0yLDEzICsy LDYgQEAKIAogLiBndWVzcy1mdW5jdGlvbnMKIAotWyAtZCAiJFNZU0ZTX1BBVEgkMSIvZG0gXSB8 fAotCWV4aXQgMAotCi11dWlkPSIkKGNhdCAiJFNZU0ZTX1BBVEgkMSIvZG0vdXVpZCkiCi0KLWlm IFsgLXogIiR7dXVpZCMjQ1JZUFQtKn0iIF07IHRoZW4KLQlndWVzc19mZWF0dXJlIGx1a3MKLQkj IFdlIG5lZWQga2V5Ym9hcmQgdG8gZW50ZXIgcGFzc3dvcmQKLQlndWVzcy1rYmQKLWZpCitndWVz c19mZWF0dXJlIGx1a3MKKyMgV2UgbmVlZCBrZXlib2FyZCB0byBlbnRlciBwYXNzd29yZAorZ3Vl c3Mta2JkCg==