Введение новых дисков в работу и LUKS

mkfs.ext4 /dev/mapper/TestStorage-test0

1. Выделить отдельный дисковый раздел под точку монтирования /boot и не шифровать его ничем.
2. Пометить, что мы используем другие дисковые разделы (их может быть один или несколько), как контейнеры для LUKS.
3. Выбрать «сконфигурировать LUKS-разделы» (никто не догадается, что это надо обязательно сделать именно на этом этапе!).
   
4. После конфигурирования появится виртуальное блочное устройство /dev/mapper/NAME, где NAME — то, как вы его назвали + учёт внутренней номенклатуры. Этот новый LUKS-раздел будет виден в списке блочных устройств на дальнейшее разбиение и/или создание файловых систем.
5. Вот только теперь можно заняться LVM: выбираем этот NAME и делаем «использовать его, как LVM-том/раздел».
   
6. Появившуюся группу логических томов (LVM) разбиваем на «логические тома» — тут всё как с дисками, выделаем пространство и назначаем имя.
7. Каждый логический том форматируем и назначаем ему точку монтирования (типа /usr, корень / и т.д.).

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

В FAQ, собственно, только вопрос затирания в общем виде и рассматривался. При установке системы лучше положиться на опции установщика с шифрованием, а варианты допиливания под свои потребности — это не вопрос для FAQ, там есть что пообсуждать или надо большую доку сочинять по всем возможным вариантам.

Кстати, перед установкой системы, винт лучше затереть рэндомом быстрыми способами из FAQ. А при инсталляции отказаться от затирания, если всё уже заранее затёрто: ведь в инсталляторе используется тормозной urandom.

Из его вопроса можно только предположить, что он хочет аккуратно затереть носитель

Имя группы томов можно узнавать динамически, сравнивая вывод vgscan до и после подключения соответствующих разделов. Будет выглядеть примерно так:

#!/bin/zsh
 
[some commands] && \
VG_before=$(vgscan |grep Found) && \
[cryptsetup opening commands] && \
VG_after=$(vgscan |grep Found) && \
VG_new=$(diff <(echo $VG_before) <(echo $VG_after) |grep Found) && \
VG_name=$(echo $VG_new |sed 's/\(^.* "\)\([^"]*\)\(" .*\)$/\2/') && \
[some commands] && \

В случае, когда внутри криптотома (к примеру, /dev/mapper/sd{b,c,d}_crypt) содержится VG с (дополнительно) шифрованными LV, иногда возникает проблема: из-за плохих контактов в USB-разъёме или из-за вашей ошибки (нечайно выдернули диск до корректного отмонтирования и отключения всего нужного) ядро решило, что диск более недоступен. Все попытки чтения диска приводят к I/O-ошибкам.

В этой ситуации выглядит логичным принудительно всё отмонтировать и отключить, выдернуть диск, если он ещё не было выдернут, а потом подсоединить заново и всё подключить. Однако, это не работает, т.к. даже после принудительного отмонтирования ФС и отключения шифрованных LV-устройств vgchange -an mygroup отказывается выполняться, а опции сделать -an для конкретной VG принудительно нет. Более того, если подключить этот же диск снова, то не удастся на нужной стадии выполнить vgchange -ay mygroup, потому что эта VG считается недоступной.

Здесь может помочь грязный хак: диск вынимаем, подключаем снова; после подключения делаем переименование: vgrename mygroup mygroup_new; теперь шифрованные LV могут быть подключены (несмотря на сыпящиеся в консоль предупреждения). Но главное тут то, что ссылки на старую VG становятся неактивными после переименования VG, т.е. VG как бы исчезает, и становится возможным сделать cryptsetup remove sd{b,c,d}_crypt для того диска, на котором находилась эта VG.

Можно делать по аналогии с предлагаемым в Tails для завершения работы системы — после отмонтирования криптотомов запускать sdmem.

P.S. Кстати, vgrename помогает и в других случаях — например, при коллизиях имён.