Gregory's Server
Про полнодисковое шифрование #FDE средствами #Luks
На ровном месте проявилась проблема, что идентификаторы разделов (partitions) теряются в определённых обстоятельствах. Потому система не может загрузиться, из-за чего в опции
Т.е. идентификатор раздела зафрованного #LUKS затирается в каких-то обстоятельствах и отдельных случаях, тем самым является совершенно ненадёжным способом указания на раздел диска.
Например, это затирание было замечено после того как выполнялось выставление флагов allow-discards, no_read_workqueue и no_write_workqueue через:
Соответственно, для `systemd-boot` загрузчика в файле /boot/loader/etries/your-system-100.500.conf приходится указывать нечто сродни:
Где:
Тоже самое касается и /etc/cryptsetup.initramfs, если таковой используется.
Почему #systemd-boot?
Использование #GRUB весьма неразумно при полнодисковом шифровании, так же использовать GRUB затруднительно, когда при старте надо открывать несколько шифрованных разделов.
Например, один из разделов на диске может быть swap, в который сохраняется система при hibernate. Да swap может быть и файлом на основном разделе, но далеко не всех такое устраивает и не все файловые системы это поддерживают.
#lang_ru #linux
На ровном месте проявилась проблема, что идентификаторы разделов (partitions) теряются в определённых обстоятельствах. Потому система не может загрузиться, из-за чего в опции
rd.luks.data приходится использовать /dev/disk/by-id/... вместо UUID'а раздела на диске.
Т.е. идентификатор раздела зафрованного #LUKS затирается в каких-то обстоятельствах и отдельных случаях, тем самым является совершенно ненадёжным способом указания на раздел диска.
Например, это затирание было замечено после того как выполнялось выставление флагов allow-discards, no_read_workqueue и no_write_workqueue через:
cryptsetup open --type luks2 --persistent --allow-discards --perf-no_read_workqueue --perf-no_write_workqueue ...
Соответственно, для `systemd-boot` загрузчика в файле /boot/loader/etries/your-system-100.500.conf приходится указывать нечто сродни:
options rd.luks.data=7f2df3a2-3c68-492e-bbd6-1ccf956379c0=/dev/disk/by-id/nvme-VENDOR_MODEL_SERIAL_ID_-partN
options rd.luks.name=7f2df3a2-3c68-492e-bbd6-1ccf956379c0=crypto_dev_name
... или ...
options rd.luks.data=2b507209-fcf1-4aae-a55a-1ba4e908cc8b=/dev/disk/by-id/ata-VENDOR_MODEL_SERIAL_ID_-partNГде:
- partN — это part1 или part2... part3.
- Используемые UUID'ы это те что из заголовка Luks, видимые через cryptsetup luksDump и отсутствующие в выдаче: lsblk -f
- Идентификаторы разделов конкретного диска ...-VENDOR_MODEL_SERIAL_ID_-partN можно наблюдать через: ls /dev/disk/by-id/
Тоже самое касается и /etc/cryptsetup.initramfs, если таковой используется.
Почему #systemd-boot?
Использование #GRUB весьма неразумно при полнодисковом шифровании, так же использовать GRUB затруднительно, когда при старте надо открывать несколько шифрованных разделов.
Например, один из разделов на диске может быть swap, в который сохраняется система при hibernate. Да swap может быть и файлом на основном разделе, но далеко не всех такое устраивает и не все файловые системы это поддерживают.
#lang_ru #linux