В статье пошагово разберём установку Gentoo в инфраструктуре одного из наверное самых доступных и известных зарубежных хостеров с KVM виртуализацией - Hetzner.  Статья написана с целью описать установку Gentoo с: шифрованным корневым разделом (LUKS) без размещения ключа для расшифровки на виртуальной машине. разблокировка шифрованного раздела только при подключении по SSH до загрузки ОС - как наиболее простой и безопасный способ передачи ключа. Создание виртуальной машины. Разметка диска. Создание LUKS для корневого раздела ( rootfs ) . Получение Gentoo stage3. Установка Gentoo. Настройка и сборка ядра и initramfs. Настройка grub2 Для примера будем использовать ВМ на тарифе CPX11 со следующими параметрами - 2 vCPU (AMD EPYC 2nd Gen), 2GB RAM, 40GB NVMe SSD.Под спойлером будет несколько скриншотов пошагового создания ВМ, перевода в её в RESCUE режим (режим при котором система будет загружена по PXE). Для нашей установки не имеет значения какой шаблон использовать. После создания ВМ, нужно будет отправить её в RESCUE режим используя панель управления виртальной машиной. Отправляем ВМ в RESCUE режим. Hetzner использует Debian для RESCUE. ВМ будет перезагружена в RESCUE по PXE. Дожидаемся завершения развертывания ВМ (примерно минуту). Для ВМ будет выделен внешний IP, по нему подключаемся по SSH.После авторизации нам демонстрируют информацию о нашей виртуальной машине: Из выводимой информации видим - сеть используется Virtio. Нам эта информация понадобится далее при настройке параметров ядра. Получаем список подключенных дисков их разделов: Удаляем разметку диска: Создаём необходимую разметку диска: Проверям что получилось: Подключаем модуль ядра для работы с LUKS: Создаем файловую систему для раздела /boot .В этом разделе будут расположены grub2, ядро и initramfs.В качестве файловой системы - используем ext2, активно писать в этот раздел не планируем, поэтому нет необходимости в журналировании: Создаём секретный ключ, желательно НЕ на виртуальной машине которую разворачиваем. Не забывам сохранить у себя в надёжном месте. Утилита сryptsetup c опцией benchmark помогает определить наиболее производительный алгоритм шифрования: По результатам бенчмарка AES заметно опережает остальных. Мы будем использовать aes-xts с размером ключа 512 бит. При создании потребуется ввести подтверждение заглавными буквами - YES, только затем уже ввести ключ/пароль для раздела. Создание LUKS раздела с AES-XTS шифрованием: Открываем LUKS том для установки системы (Gentoo): Дополняем LUKS том необходимыми опциями для работы с SSD: Добавляем в LUKS раздел allow-discard, чтобы функция TRIM передавалась по направлению Filesystem -> LUKS -> Disk(sda) Размечаем файловую систему (xfs):Параметр bigtime - необходим для  корректной работы XFS, если планируется её использование после 2038 ( проблема 2038 года ). По умолчанию этот флаг не используется при создании файловой системы и вследствии этого команда mkfs.xfs создаёт файловую систему с поддержкой timestamps лишь до января 2038г, о чём вы можете получать сообщение в логах при монтировании файловой системы с XFS. Указываем метки (LABEL) для файловых систем.Это нам понадобится для удобства работы с fstab. указание метки для раздела /boot с ext2  : указание метки для корневого раздела / с xfs.  если для ext2 можно указать LABEL без размонтирования раздела, то для xfs так не получится, поэтому лучше указать метку сразу: Проверяем получившуюся разметку диска с разделами: Создаём необходимые директории и монтирируем разделы: Stage3 можно загрузить со страницы загрузки Gentoo. Раздел "Details (contents, hashes, and signatures)" внизу страницы  и ссылка "Stage 3" приведёт нас к странице загрузки автобилдов Gentoo. Оставляю это здесь, потому что это неочевидное место для такой нужно ссылки: Для нашей статьи воспользуемся зеркалом Яндекса (https://mirror.yandex.ru), т.к. для скачивания рекомендуется использовать зеркала, чтобы снизить сетевую нагрузку на инфраструктуру проекта Gentoo. Нам понадобится следующее: путь в директорию с необходимым для примера stage3https://mirror.yandex.ru/gentoo-distfiles/releases/amd64/autobuilds/current-stage3-amd64-openrc/ stage3 архивhttps://mirror.yandex.ru/gentoo-distfiles/releases/amd64/autobuilds/current-stage3-amd64-openrc/stage3-amd64-openrc-20211018T200943Z.tar.xz файл со списком файлов в архиве stage3https://mirror.yandex.ru/gentoo-distfiles/releases/amd64/autobuilds/current-stage3-amd64-openrc/stage3-amd64-openrc-20211018T200943Z.tar.xz.CONTENTS.gz файл с контрольными суммы stage3 в различных алгоритмах.https://mirror.yandex.ru/gentoo-distfiles/releases/amd64/autobuilds/current-stage3-amd64-openrc/stage3-amd64-openrc-20211018T200943Z.tar.xz.DIGESTS так же как и .DIGESTS файл, содержит контрольные суммы stage3 в различных алгоритмах, но в отличие от DIGESTS - здесь контрольные суммы подписанны gpg ключом проекта Gentoo.https://mirror.yandex.ru/gentoo-distfiles/releases/amd64/autobuilds/current-stage3-amd64-openrc/stage3-amd64-openrc-20211018T200943Z.tar.xz.DIGESTS.asc Воспользуемся BASH переменными для удобства и сделаем небольшой скрипт для скачивания stage3 и проверки его подписей: После получения stage3 архива и перед его использованием - необходимо проверить скачанный архив и его подписи. Рекомендовал бы воспользоваться уже имеющимся скриптом расположенным в проекте Gentoo, но здесь некоторые неудобства вызваны тем, что в RESCUE образе от Hetzner основанном на Debian поставляется mawk вместо gawk. Опции в gawk и mawk отличаются, поэтому проверку будем проводить в chroot окружении.При желании, можете модифицировать скрипт под опции в скрипте для под mawk и выполнять проверку в Debian. Я это опущу и как описано выше - проверку выполню в  chroot окружении Gentoo. Распаковываем архив: Копируем ssh ключ:Копируем публичный SSH ключ для доступа уже в создаваемую систему после перезагрузки. Публичную часть ключа мы указывали в панели управления Hetzner перед загрузкой виртуальной машины в RESCUE. И пока мы в RESCUE - он раположен по стандартному пути /root/.ssh/authorized_keys Создаем resolv.conf или можно скопировать из RESCUE системы: Завершаем подготовку chroot окружения: Переключаемся в chroot (Gentoo): Далее следуют операции в chroot окружении Gentoo. Т.е. команды будут выполняться в Gentoo, а не Debian, с которого была загружена ВМ в RESCUE. Проверяем stage3 архив: Проверка прошла успешно. Синхронизируем дерево portage: Выбираем профиль portage: Для получения списка доступных профилей выполните: В статье используем профиль - default/linux/amd64/17.1 (stable), под номером 1.  Указываем часовой пояс: Добавим немного удобства при сборке в emerge: MAKEOPTS: -jN - опция для GCC. Указывает во сколько потоков будет проходить компиляция. Руководством рекомендуется использовать на единицу больше от количества доступных ядер/потоков процессора. EMERGE_DEFAULT_OPTS: --jobs - указывает сколько ставить одновременно пакетов. --load-average - указывает нагрузку на процессор при превышении которой запуск на установку следующих билдов будет приостановлен. Т.е. при указанных настройках у вас может быть запущено на сборку 9 копий gcc для различных компонентов пакетов. После завершения сборки одного из пакетов если нагрузка на процессор также не превышает указанного числа, будет запущена установка следующего пакета с возможной параллельной компиляцией тремя копиями gcc. FEATURES:Переменная FEATURES содержит список опций portage. Опции влияют на поведение Portage. Является инкрементной переменной, добавление значений в которую не будет переопределять значения из профиля Gentoo. candy - включает идикатор прогресса при подсчёте зависимостей emerge для сборки пакета. compress-build-logs - включает сжатие для логов при сборке пакета. Пока поддерживается только gzip сжатие. parallel-fetch - скачивание необходимых для копиляции компнентов в фоновом режиме. parallel-install - отключает блокировку при установке пакетов, позволяет запускать одновременно несколько сборок, не дожидаясь завершения запущенной сборки. Настраиваем локализацию: Указываем необходимые опции для сборки dropbear, grub2: Собираем необходимые пакеты: Настраиваем сеть: О маршрутизации в Hetzner Cloud. Для создаваемых ВМ необходимо указывать  172.31.1.1 в качестве маршрута по умолчанию. Модифицируем файл /etc/fstab под наши нужды.Т.к. ранее мы указывали LABEL для файловых систем, пришло время их использовать: Устанавливаем загрузчик GRUB2 на диск /dev/sda: Закомментируем имеющуюся строку GRUB_CMDLINE_LINUX в /etc/default/grub: Указываем для GRUB_CMDLINE_LINUX необходимые параметры в /etc/default/grub:Мы не указали параметр gk.net.iface, т.к. у нас всего один интерфейс - eth0. Для именования сетевых интерфейсов в виде eth0, мы передаём net.ifnames=0 в параметрах при загрузке ядра. Устанавливаем символьную ссылку /usr/src/linux на текущую версию ядра: Используем параметр menuconfig для make при настройки ядра: Для включения/отключения опции ядра необходимо установить выделение на выбираемом пункте/модуле и используя клавишу <ПРОБЕЛ> обозначить выбор, при этом выделение в нижнем меню необходимо установить на  Сохранить - для сохранения изменений нужно установить выделение на кнопке  в нижнем меню, подтвердить выбор кнопкой Enter на клавиатуре и ещё раз подтвердить название файла сохранения (.config). Выход - для выхода достаточно установить выделение на кнопке  в нижнем меню и подтвердить выбор. Включаем модуль virtio в ядре: Включаем dm-crypt: Включаем поддержку файловых систем ext2 и XFS: Включаем поддержку крипто-алгоритмов в ядре:Cовременные процессоры уже имеют поддержку AES-NI инструкций. Вот список процессоров с поддержкой AES-NI инструкций. AES-NI инструкции предназначены для ускорения работы приложений использующих шифрование по алгоритму AES.При включении пунктов, необходимо исходить из того - какие алгоритмы были заданы при создании LUKS раздела командой cryptsetup. Включаем подписи модулей ядра: Пункт "Require modules to be validly signed" можно будет включить после успешной загрузки системы, пересобрав ядро. Также этот пункт можно включить через параметры ядра при загрузке. В статье мы это опустим, т.к. подпись, проверка и загрузка подписанных модулей значительно увеличит статью. Но тема отлично описана в документации. Сборка ядра, модулей и initramfs:В genkernel мы используем опции для генерации initramfs c запуском SSH на порту 22022, для этого нам понадобился dropbear. во время загрузки (grub2) воспользуемся другими ключами для SSH сервера, отличных от тех что мы используем в ОС ( /etc/ssh_host_{ALG}_key ). будут сгенерированы отдельные SSH ключи.  публичную часть ключа используем для исключения MITM. Добавив публичную часть ключа у себя на рабочей машине в ~/.ssh/known_hosts. положим в initramfs публичную часть нашего SSH ключа для авторизации. Получаем публичную часть ключа сгенерированного для initramfs. Нужна будет вторая строка с ключом. Вносим полученный ключ к себе на рабочую машину с которой подключаемся к ВМ в ~/.ssh/known_hosts в формате (необходимо заменить REMOTE_HOST_IP адресом вашего сервера, оставив квадратные скобки): Задаём пароль для root-a: Необходимо сохранить пароль в надёжном месте: Выходим из chroot окружения и перезагружаем ВМ: Подключение по SSH для разблокировки LUKS: Виртуальная машина отправлена в reboot и будет доступна по порту 22022 для SSH подключения. Открываем LUKS раздел: Продолжаем загрузку Gentoo: Далее можно подключаться по SSH к системе с Gentoo на 22 порту. Возможно статья сэкономит времени новичкам и не только, также поможет тем кто знакомится с Linux или Gentoo, начинает создавать виртуалки(контейнеры) на чужом железе(в облаке).  *nix System Administrator