Ubuntu, dm-crypt и mkinitcpio

попробую предположить что в Убунте уже всё включено по умолчанию в initramfs ..

и что остаётся только подобрать [методом тыка? :) или методом тыка в гугл?] нужные cmdline..

например для шифрования попробовать что-то типа: rd.luks.uuid=blahblahblahblah

Уже пробовал ставить, надеясь на то, что оно как-нибудь само. Вкратце: загрузился в лайв, из терминала создал нужную разметку, раскрыл зашифрованный том, потом инсталлер натравил на нужные разделы (инсталлер по-идиотски себя ведёт, ему создавать разметку доверять нельзя), установил, с помощью чёрной магии настроил efistub - и fail, пароль на расшифровку не запрашивался. В параметры загрузки передавал cryptdevice и root - бестолку. По сему грешу таки на хуки...

Куда, спрашивается, добавлять хуки encrypt/plymouth-encrypt и lvm2?

В Arch добавляй.

для убунты
mkinitcpio.conf

Што?

Я понимаю, что несу ересь (не знаю, как оно там в убунте устроено всё, и манов никаких не нашёл), но не знаю, как это правильно сказать. Если запутал - то нужно, если простым языком, как-то сделать так, чтобы оно при загрузке просило пароль от зашифрованного раздела, открывало его, и нормально грузилось.

/etc/crypttab записан правильно? update-initramfs делали? cryptsetup установлен?

/etc/crypttab вообще не писал (пытался же по аналогии с арчем, где это не надо), update-initramfs, ЕМНИП, делал, cryptsetup, вроде, ставил из чрута... А может и нет... Попробую снова.

Сюда же задам ещё вопрос: можно-ли изменять размер зашифрованного раздела, учитывая, что в нём сидит LVM?

Ты либо делаешь руками всё (debootstrap), либо не лезешь в работу установщика со своей ручной разметкой (это касается как графического убунтовского, так и d-i (alternate, server). Хотя в принципе должно быть достаточно иметь установленные cryptsetup, lvm2, правильно оформленные /etc/crypttab и /etc/fstab, а также update-initramfs -u, сделанный из чрута (при этом шифрованный раздел должен быть открыт под тем же именем, которое в /etc/crypttab).

Можно, там только внимательно нужно с единицами измерения.

/etc/crypttab вообще не писал

В Ubuntu придётся написать. По нему /usr/share/initramfs-tools/hooks/cryptroot определяет, что корень зашифрован, и соответственно модифицирует initrd.img.

Сюда же задам ещё вопрос: можно-ли изменять размер зашифрованного раздела, учитывая, что в нём сидит LVM?

Сначала при помощи pvmove и pvresize разгребите место в конце раздела. Лучше с избытком. Потом отключите LVM, закройте cryptsetup, уменьшите раздел, откройте cryptsetup и LVM и увеличьте PV обратно. В заголовке LUKS размер раздела не хранится, поэтому для него специальной операции resize нет.

Можно ресайзить раздел, не закрывая cryptsetup, тогда понадобится выполнить cryptsetup resize, чтобы уточнить размер зашифрованного раздела в памяти.

Спасибо, буду снова пробовать.
Просто всё руками ставить не хочется, не устраивает лишь разметка (ну и то, что установщик лепит свой ненужный загрузчик).

Благодарю, буду знать.

debootstrap это примерно как нынешний установщик в арче, то есть довольно просто (в здешней вики есть статья). Всё равно при ручной разметке установщику почти ничего не остаётся делать.

> /etc/crypttab вообще не писал

В Ubuntu придётся написать. По нему /usr/share/initramfs-tools/hooks/cryptroot определяет, что корень зашифрован, и соответственно модифицирует initrd.img.

в каком-то смысле это напоминает современный Арчик..

только в Арчике есть два файла:

«/etc/crypttab» и «/etc/crypttab.initrd»

а в Убунте — эти два файла объединены в один файл «/etc/crypttab».. верно я понял?

Ага. В случае initramfs-tools вместо crypttab.initrd на лету собирается /conf/conf.d/cryptroot, хранящийся в initramfs.

Спасибо, уважаемые Gotf, AITap, user_id_68054! Всё поставилось.
Ещё нубовопросик - нужно было выносить /boot на нешифрованный раздел в случае UEFI, или нет? Хотел его сразу на EFI-раздел монтировать, но установщик считает себя умнее пользователя и не дал. Пришлось ещё один раздел для /boot создать. Может можно было на шифрованном корне бросить?

Совмещать /boot и ESP в принципе можно, но я бы не стал. Держать /boot на зашифрованном томе тоже можно, но только с GRUB2, и скорее всего стандартный initrd потеряется при загрузке такой конфигурации.

GRUB2, и скорее всего стандартный initrd потеряется при загрузке такой конфигурации.

там во время шифрования /boot/ — особенность в том чтобы файл grub.efi — включал бы в себя дополнительные модули для операции cryptomount .

думаю что кроме grub.efi — другие файлы груба — не меняются (не зависимо от того /boot/ — шифрованный ли или не шифрованный).

grub-install либо автоматом прочухивает как собрать grub.efi , и делает это.. либо пишет «ошибка! не буду делать это, так как <такая-то-причина>!».

зачем я это пишу?

потому что мне кажется, что от initrd это ни как не зависит :)

а вот если версия grub чуть более старая чем последняя — то проблемы думаю быть должны.. :)

/boot на LUKS работает (в случае GRUB2), но до инсталляторов это ещё не дошло. Целиком в EFI-разделе загрузчик вместе с ядром и initramfs тоже можно расположить, но тогда нужно либо напомнить загрузчику, что он ставится в /boot/efi, а это отдельный раздел, либо монтировать EFI-раздел как /boot, чего какие-то скрипты могут не учесть (насколько я понимаю, EFI-раздел сейчас принято монтировать в /boot/efi).

кстати, офтоп, но всё-равно напишу..

мне кажется что единственная причина шифровать /boot/ — это наличие алиби в стиле "этот компьютер не работает, и пароль от него я не помню вообще".

то есть — можно сделать grub-install , и затем не обновлять загрузчик (в течении многих месяцев).

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

не сможет следователь увидить: ни дату обновления файлов «vmlinuz-linux, intel-ucode.img, initramfs-linux.img, ...», ни поглядеть на версию ядра, ни засунуть свой нос в initramfs и его сокровенныие конфиги :-)

потому что мне кажется, что от initrd это ни как не зависит :)

Мой initrd считал иначе.

но ведь если initrd уже в оперативной памяти (во время загрузки) — значит grub своё дело сделал успешно.

то есть когда grub отработал успешно и *смог* засунуть в оперативную память образ-ядра и initrd — то какая теперь разница initrd каким образом его засовывали в оперативную память? :-)

а если через kexec-tools (и затем systemd kexec) это засунуть вообще в память? не будет же и в этом случае оно тоже сопративляться?

Чтобы добиться неотличимости от забитого случайными данными диска, всё равно придётся как-то избавиться от исполняемого незашифрованного кода загрузчика (например, носить его на карте microSD вместе с LUKS detached headers, а карту при задержании раскусить).

Кстати, то, что у LUKS есть заголовок, меня недавно спасло, когда я по дурости затёр MBR.

то какая теперь разница initrd каким образом его засовывали в оперативную память?

Это ему без разницы, но корень он найти не смог. Я разбираться не стал, поскольку сама ситуация, когда GRUB занимался расшифровкой корня возникла как бы случайно и мне на самом деле это не было нужно.

Спасибо, понятно - лучше не буду рисковать без нужных навыков

Чтобы добиться неотличимости от забитого случайными данными диска, всё равно придётся как-то избавиться от исполняемого незашифрованного кода загрузчика (например, носить его на карте microSD вместе с LUKS detached headers, а карту при задержании раскусить).

это ты конечно прав.

но я склонен полагать — что LUKS-заголовки это не страшно :) . [в случае если кроме luks-заголовков — больше ни чего не доступно]

чем прятать luks-заголовки — проще словестно сказать: "ну luks. да. зашифровал. давно (год назад) . пароль не помню, компом не пользуюсь, ни чего уже не работает.. вчера пробовал включить — не включилось"

кто же докажет что на самом деле компом пользуюсь — в случае если нет доступа даже до /boot/ :-)