IncusOS: что это за ОС и где она реально работает

Что такое IncusOS

IncusOS это неизменяемая операционная система на базе Debian 13. У неё одна задача: запускать Incus, менеджер системных контейнеров и виртуальных машин (VM). Запускается она далеко не везде. Ей нужны TPM 2.0, UEFI с Secure Boot и процессор Intel или AMD уровня x86-64-v3 либо ARM aarch64. Без TPM или без Secure Boot она работает только в деградированном режиме, и обойти можно лишь одно из двух. Поэтому главный вопрос про IncusOS звучит так: на каком железе она вообще заработает?

Ниже разобраны требования из официальной документации IncusOS в том виде, в каком она опубликована на 19 октября 2026 года. Это ветка main, номер релиза в адресах страниц не указан. Мы разберём деградированные режимы и то, почему «облачные» инструкции на деле описывают выделенные серверы. В конце будет ответ для владельца обычного KVM VPS.

Если Incus вам пока не знаком, начните с установки Incus и системных контейнеров на обычный VPS. Там тот же Incus, только поверх привычной Ubuntu или Debian, с SSH и пакетным менеджером.

Чем IncusOS отличается от Incus на обычном Debian

Incus можно поставить как обычный сервис почти на любой дистрибутив Linux. IncusOS устроена иначе. Это целая ОС, собранная вокруг Incus. Разработчики берут Debian 13 и ставят поверх собственные сборки Incus и ядра.

Нет оболочки. В документации прямо сказано, что у системы нет ни локального, ни удалённого shell. Нет консоли с bash и нет SSH. Есть только REST API с аутентификацией. Через этот API вы работаете с Incus и через него же управляете самой ОС. Значит, привычный приём «зайти по SSH и поправить файл в /etc» здесь не работает. Клиент подключается по сети. Например, инструкция для OpenStack требует клиентский TLS-сертификат (transport layer security, защита соединения) и открытый входящий порт 8443.

Атомарные обновления A/B. Обновление ставится целиком, по схеме A/B, а не пакет за пакетом. Если с новой версией что-то не так, документация обещает простой откат к предыдущей. Полуобновлённого состояния, когда часть системы новая, а часть старая, у такой схемы не бывает.

Шифрование диска, привязанное к TPM. Диск шифруется через LUKS (Linux Unified Key Setup) и встроенное шифрование ZFS. Ключи хранит TPM (Trusted Platform Module), аппаратный модуль для ключей и измерений загрузки. Безопасность загрузки держится на UEFI Secure Boot и измерениях TPM 2.0. Ключи диска привязаны к регистрам PCR (platform configuration register) с номерами 7, 11 и 15. Если Secure Boot выключен, к ним добавляются PCR 4 и 12. В эти регистры TPM записывает, что именно загружалось. Если цепочка загрузки изменилась, TPM не отдаёт ключ, и система просит пароль восстановления. Поэтому инструкция для OpenStack советует скачать пароль разблокировки TPM заранее. По словам той же инструкции, добавление или изменение томов, объёма памяти или числа CPU тоже срабатывает на TPM.

Если сама идея системы только для чтения вам нова, прочитайте, чем неизменяемые серверные дистрибутивы отличаются от обычных. IncusOS доводит эту идею до предела: у вас нет даже shell, чтобы что-то поменять вручную.

Минимальные требования IncusOS на 19 октября 2026 года

Список взят со страницы требований в документации IncusOS:

• Процессор Intel или AMD x86_64 с поддержкой уровня x86_64_v3, либо ARM aarch64.
• Не меньше 4 ГиБ оперативной памяти, и только для нужд самой системы.
• Не меньше 50 ГиБ на диске.
• Модуль безопасности TPM 2.0.
• UEFI с поддержкой Secure Boot.
• Хотя бы один проводной сетевой порт.

Обратите внимание на память. Эти 4 ГиБ документация отводит только системе. Контейнерам и VM нужна память сверх этого. Считайте 4 ГиБ нижней границей, а память под нагрузку добавляйте отдельно.

Проводной порт тоже важен. Ноутбук только с Wi-Fi под это требование не подходит.

Уровень x86_64_v3 в документации IncusOS записан через подчёркивание. В glibc тот же уровень называется x86-64-v3, через дефис. Это одно и то же. Процессор, который поддерживает только x86-64-v2, не подойдёт.

Требования к TPM и Secure Boot выглядят строгими, но на них держится вся модель безопасности. TPM отдаёт ключ диска только тогда, когда загрузка прошла по ожидаемой цепочке. Secure Boot следит, чтобы эта цепочка состояла из подписанных компонентов. Уберите одно из двух, и защита слабеет. Об этом следующий раздел.

Можно ли запустить IncusOS без TPM или без Secure Boot

Можно, но только в одном из двух деградированных режимов. Документация называет их вариантами для домашних лабораторий и знакомства с системой. В корпоративных установках они, как правило, не поддерживаются.

• Secure Boot выключен. Документация объясняет, зачем это нужно: на некоторых физических серверах и хостах Hyper-V прошивка UEFI не умеет записывать собственные ключи Secure Boot.
• Программный TPM (swtpm) вместо физического. Это вариант для ARM-плат вроде Raspberry Pi, у которых нет физического TPM.

Оба режима сразу включить нельзя. Документация пишет это заглавными буквами: IncusOS не может работать одновременно с выключенным Secure Boot и программным TPM. Хотя бы одна из двух опор должна быть настоящей.

Режим выбирается в seed-конфигурации установки (install seed). Для программного TPM это поле security.missing_tpm со значением true. Тогда IncusOS настроит программный TPM во время установки. Поле срабатывает, только если физический TPM не найден. Для работы без Secure Boot есть поле security.missing_secure_boot со значением true. Оно действует, только если Secure Boot выключен в BIOS.

Самое важное: отметка о деградированном режиме остаётся навсегда. Любая система IncusOS, которая хоть раз загрузилась с программным TPM, запоминает этот факт. Она сообщает его через поле system_state_is_trusted в Security API. Так же навсегда записывается загрузка с выключенным Secure Boot. Документация предупреждает, что Operations Center и другие продукты, которые работают с IncusOS через API, могут обращаться с такими системами иначе. Машина, поставленная на пробу с программным TPM, сохранит эту отметку. Для боевой установки сразу берите подходящее железо.

У каждого режима есть своя цена. Без Secure Boot загрузка предыдущей версии IncusOS всегда требует пароль восстановления шифрования. Тот же пароль может понадобиться после смены порядка загрузки, например когда в систему добавили агент BMC (baseboard management controller, контроллер удалённого управления сервером). С программным TPM IncusOS показывает заметное предупреждение на экране статуса. Если IncusOS загружается с live USB и физический TPM не найден, при первой загрузке она 30 секунд показывает предупреждение о безопасности, затем сама настраивает программный TPM и перезагружается. Такое же 30-секундное предупреждение появляется при загрузке с live USB с выключенным Secure Boot. При установке на диск без физического TPM программный TPM включают полем security.missing_tpm, описанным выше.

Почему «облачные» установки IncusOS идут на выделенные серверы

В разделе установки документации есть страницы для Hetzner и Scaleway. По названию легко решить, что речь об облачных VM. Обе инструкции описывают выделенные серверы. Причина одна: IncusOS записывает в прошивку собственные ключи Secure Boot. Для этого нужен доступ к настройкам UEFI. На арендованной машине это значит удалённую консоль KVM. Здесь KVM означает keyboard, video, mouse, то есть доступ к экрану и клавиатуре сервера, а не гипервизор.

Hetzner. Страница называется «Installing on a Hetzner dedicated server». Сначала нужно запросить у поддержки Hetzner доступ к KVM-консоли. По словам документации IncusOS, это бесплатно, а доступ даётся на срок от одного до трёх часов. Через консоль вы переводите Secure Boot в режим custom. Затем стираете KEK (key exchange key) и загружаете KEK от IncusOS. Потом стираете DB (базу разрешённых подписей) и загружаете ключи DB от IncusOS. Если сервер после этого не загружается, документация советует добавить ключи к существующим вместо замены. В конце включается TPM.

Документация советует выбирать платформу с fTPM, то есть TPM, встроенным в прошивку. Обычно это железо потребительского класса. Серверные платформы, по словам документации, скорее всего TPM не имеют. Для них понадобится образ с ослабленной защитой загрузки. Есть ещё два условия. Нужен образ в режиме USB. Нужен параметр strict_hwaddr: true, потому что Hetzner фильтрует незарегистрированные MAC-адреса.

Scaleway. Здесь речь о Dedibox, выделенном сервере, который настраивается через KVM over IP. В режиме custom Secure Boot записываются ключи IncusOS: PK (platform key), KEK и DB. В примере используется Pro-4-S с Intel Xeon E3 1245v5. Если вы попадёте в интерфейс SuperMicro, база DB там называется «Authorized Signatures». Документация отмечает, что в Dedibox обычно нет TPM. Поэтому пример ставит образ с вариантом «Degraded boot security (no TPM 2.0 module)». Иначе говоря, пример для Scaleway сам работает в деградированном режиме. В конце нужно отозвать доступ KVM и выключить режим rescue. Когда сервер больше не нужен, BIOS стоит сбросить к заводским настройкам.

OpenStack. Это исключение, и о нём стоит знать. Отдельная страница описывает установку в виртуальный инстанс OpenStack. Её проверяли на Infomaniak Public Cloud. По словам документации, шаги подходят для большинства провайдеров на OpenStack. Условие жёсткое: UEFI и TPM 2.0 нужно явно включить в настройках инстанса. Нужны образ QCOW2 в режиме USB, клиентский TLS-сертификат и входящий порт 8443. Диск нужен не меньше 50 ГиБ, как в общих требованиях. На самой странице для OpenStack написано 50 GB, но 50 ГиБ это около 53,7 ГБ, так что ориентируйтесь на большее число. Если ваш провайдер на OpenStack позволяет задать эти параметры, это реальный путь к IncusOS в виртуальной машине.

Общее различие подробно разобрано в статье о том, чем VPS отличается от выделенного сервера. Для IncusOS главная разница одна: есть ли у вас доступ к прошивке.

Запустится ли IncusOS на обычном KVM VPS

Зависит от того, что ваш провайдер отдаёт гостевой системе. Проверить нужно четыре вещи:

• Какой уровень процессора видит гость: x86-64-v3 или ниже.
• Есть ли vTPM, то есть виртуальный TPM 2.0.
• Загружается ли VM через UEFI и можно ли записать собственные ключи Secure Boot.
• Хватает ли диска: нужно не меньше 50 ГиБ.

Ответы на второй и третий вопросы ищите в документации или в панели своего провайдера. Мы не утверждаем ни про одного провайдера, что у него этого нет. Условия меняются, и проверять их нужно у источника. Если UEFI есть, а записать собственные ключи нельзя, IncusOS можно поставить с выключенным Secure Boot через security.missing_secure_boot. Тогда vTPM обязателен, а система навсегда получает отметку деградированного режима. Для стенда это допустимо, для боевой установки нет. Если VPS работает на контейнерной виртуализации, например LXC или OpenVZ, свою ОС со своим ядром туда не поставить. Как различить типы виртуализации, объясняет статья KVM, Xen и LXC на VPS: в чём разница.

Если хотя бы одно условие не выполняется, остаются два честных пути.

1. Обычный Incus на Debian или Ubuntu. Это тот же Incus с теми же контейнерами и VM, но без требований к TPM и Secure Boot. SSH и пакетный менеджер остаются на месте. Пошагово это описано в руководстве Incus и системные контейнеры на VPS.
2. IncusOS во вложенной VM, для знакомства. Это наше предложение, а не сценарий из документации. Документация описывает IncusOS как VM под Incus, но ничего не говорит о вложенной виртуализации на VPS. Для такого стенда VPS должен разрешать вложенную виртуализацию. Что для этого нужно, объясняет статья вложенная виртуализация на VPS.

Перед арендой полезно проверить и остальные условия. Об этом статья как заранее понять, запустится ли программа на VPS.

Как проверить поддержку x86-64-v3 и TPM на своей машине

Эти команды работают на любом Linux с glibc 2.33 или новее. Запустите их на домашнем сервере или внутри VPS. На VPS результат описывает процессор, который видит гостевая система. Физический процессор хоста может уметь больше.

Сначала архитектура:

uname -m

x86_64 означает Intel или AMD. aarch64 означает 64-битный ARM. Для ARM проверка уровня x86-64 не нужна.

Теперь уровень x86-64. Начиная с glibc 2.33, динамический загрузчик знает уровни x86-64-v2, x86-64-v3 и x86-64-v4. Под каждый уровень он ищет библиотеки в своём подкаталоге glibc-hwcaps. Его справка показывает, какие уровни поддерживает текущий процессор. Путь к загрузчику покажет ldd:

ldd /bin/ls
/lib64/ld-linux-x86-64.so.2 --help

В выводе ldd найдите строку с ld-linux-x86-64.so.2. Если путь отличается от /lib64/ld-linux-x86-64.so.2, подставьте свой во вторую команду. В конце справки загрузчик печатает раздел Subdirectories of glibc-hwcaps directories, in priority order:. Найдите в нём строку x86-64-v3. Если рядом стоит слово supported, процессор этот уровень поддерживает. Если слова supported нет, процессор, который видит система, требованию IncusOS не отвечает.

Теперь TPM. Ядро Linux показывает TPM-устройства в каталоге /sys/class/tpm/:

ls /sys/class/tpm/
cat /sys/class/tpm/tpm0/tpm_version_major

По документации ядра, файл tpm_version_major показывает основную версию спецификации TCG, которую реализует устройство. Для IncusOS там должно быть 2. Если cat не находит файл, начните с настроек UEFI на своём железе: TPM или fTPM там бывает выключен. На VPS ищите vTPM в панели провайдера.

Secure Boot и запись собственных ключей из гостевой системы так просто не проверить. Это настройка прошивки. Смотрите меню UEFI на своём железе или документацию провайдера.

Как попробовать IncusOS во вложенной VM

Документация описывает запуск IncusOS как VM под Incus. Команды ниже взяты оттуда. Нужен хост с Incus, который умеет запускать VM. Если этот хост сам является VPS, ему нужна вложенная виртуализация. Скачайте ISO-образ IncusOS по инструкции из документации. Подставьте имя своего файла вместо IncusOS.iso.

incus storage volume import default IncusOS.iso IncusOS.iso --type=iso
incus init --empty --vm IncusOS -c security.secureboot=false -c limits.cpu=1 -c limits.memory=4GiB -d root,size=50GiB
incus config device add IncusOS vtpm tpm
incus config device add IncusOS boot-media disk pool=default source=IncusOS.iso boot.priority=10
incus start IncusOS
incus console IncusOS --type=vga

Параметр security.secureboot=false нужен, чтобы установщик мог записать в прошивку VM собственные ключи. Команда incus config device add IncusOS vtpm tpm добавляет виртуальный TPM 2.0. Корневой диск на 50 ГиБ отвечает минимальному требованию. Пример выделяет VM один vCPU и 4 ГиБ памяти. Хосту нужны эти ресурсы плюс запас для него самого. Последняя команда открывает графическую консоль VM, где идёт установка.

После установки отключите установочный носитель и запустите VM снова:

incus stop IncusOS
incus config device remove IncusOS boot-media
incus start IncusOS --console=vga

Состояние можно проверить командой incus list. В строке IncusOS должен стоять статус RUNNING.

Пример из жизни: домашняя инфраструктура Солен на одном ноутбуке

Солен Рапенн (Solène Rapenne) 15 октября 2026 года описала в своём блоге на dataswamp.org домашнюю инфраструктуру на IncusOS. Это хороший пример того, как система выглядит в реальной работе.

Всё работает на одной машине. По её словам, это «обычный ноутбук» с 16 ГБ памяти, NVMe-диском и сетевой картой. Ноутбук стоит рядом с роутером провайдера. На нём около двадцати системных контейнеров Ubuntu, по одному на сервис. Ещё есть две VM для более чувствительных частей: пограничный haproxy и раннер CI. Среди сервисов есть Nextcloud, Forgejo с раннером CI, Immich, PeerTube, Vaultwarden, Kanboard, Uptime Kuma, SmokePing, стек мониторинга, CrowdSec и restic. Приложения внутри контейнеров работают как quadlet-юниты podman. Сборка заняла у неё семь месяцев свободного времени.

Резервные копии устроены в два слоя. Снимки ZFS в Incus хранятся две недели. Каждый день restic отправляет копии томов с данными в хранилище S3, с шифрованием на стороне клиента.

Солен прямо называет слабые места своей схемы:

• Одна точка отказа. Всё работает на одной машине дома. Если ноутбук сломается или пропадёт интернет, недоступным станет всё. Кластеризация в IncusOS есть, но для её задач это, по её словам, слишком.
• Бакет restic нельзя сделать неизменяемым. Restic меняет файлы при каждом запуске, и неизменяемый режим бакета его сломал бы. Она сама пишет, что злоумышленник, захвативший экземпляр restic, получит доступ к бакету и сможет удалить копии. От удаления её защищают версионирование S3 и защиты бакета.
• Короткие перерывы при пересборке. Когда она пересобирает контейнеры с caddy или haproxy, публичный трафик пропадает на минуту или две.
• Сложность. Она признаёт, что такая схема, скорее всего, сложнее, чем нужно большинству людей.

Вывод из её примера простой. IncusOS может держать целую домашнюю инфраструктуру на одном ноутбуке. Доступность и резервные копии при этом остаются вашей задачей, как и на любом другом хосте.

Кому подходит IncusOS, а кому лучше остаться на Proxmox или обычном Incus

IncusOS подходит, если у вас есть что-то из этого списка:

• Домашний сервер или мини-ПК с TPM 2.0, UEFI и проводной сетью, которым вы управляете целиком.
• Выделенный сервер с доступом к KVM-консоли, где можно записать собственные ключи Secure Boot.
• Небольшой кластер под Operations Center.
• Стенд для знакомства во вложенной VM, без боевой нагрузки.

Operations Center описан в документации на сайте FuturFusion. Это центральная панель для всей установки Incus. Серверы с IncusOS регистрируются в нём. Он отслеживает и раскатывает обновления, создаёт новые кластеры Incus и ведёт учёт ресурсов по всем кластерам. У него есть REST API, CLI и веб-интерфейс. Кластер можно собрать и без него. Документация IncusOS описывает это так: дополнительные серверы ставятся из образа, в котором настройки Incus по умолчанию выключены, и затем присоединяются к первому.

На Proxmox лучше остаться, если вам нужен shell на хосте. Это же касается случая, когда в железе нет TPM, а деградированные режимы вас не устраивают. Ещё одна причина: команда уже хорошо знает Proxmox. Сравнение своего железа с арендой разобрано в статье Proxmox на своём железе или VPS.

Обычный Incus разумнее на арендованном VPS без доступа к прошивке. Он даёт те же контейнеры и VM. Требования IncusOS к vTPM и ключам Secure Boot на таком VPS заранее проверить получается не всегда.

Короткое правило: сначала проверьте процессор, TPM, Secure Boot и доступ к прошивке. Ставьте IncusOS, когда все ответы вас устроили.

FAQ

Есть ли в IncusOS SSH или командная строка?

Нет. Документация прямо пишет, что у IncusOS нет ни локального, ни удалённого shell. Управление идёт только через REST API с аутентификацией: через него вы работаете с Incus и настраиваете саму ОС. Клиент подключается по сети с TLS-сертификатом. Если вам нужен SSH на хосте, ставьте обычный Incus на Debian или Ubuntu.

Можно ли установить IncusOS без TPM 2.0?

Да, в деградированном режиме с программным TPM (swtpm). Для этого в seed-конфигурации установки задают security.missing_tpm: true. Поле срабатывает, только если физического TPM нет. Secure Boot при этом должен работать, потому что программный TPM вместе с выключенным Secure Boot документация запрещает. Система навсегда запоминает загрузку с программным TPM и сообщает её через поле system_state_is_trusted в Security API.

Запустится ли IncusOS на моём VPS?

Это зависит от провайдера. Для полного режима безопасности нужны процессор уровня x86-64-v3 (если это x86_64) или aarch64, vTPM 2.0, загрузка через UEFI с возможностью записать собственные ключи Secure Boot и не меньше 50 ГиБ диска. Если записать ключи нельзя, Secure Boot можно выключить через security.missing_secure_boot, но тогда нужен vTPM, а система получит постоянную отметку деградированного режима. Уровень процессора и TPM можно проверить изнутри VPS: через справку загрузчика glibc и файл /sys/class/tpm/tpm0/tpm_version_major. Про vTPM и ключи Secure Boot смотрите документацию провайдера. Если условия не выполняются, ставьте обычный Incus или пробуйте IncusOS во вложенной VM.

Почему инструкции IncusOS для Hetzner и Scaleway требуют выделенный сервер?

IncusOS записывает в прошивку UEFI собственные ключи Secure Boot. Для этого нужен доступ к настройкам прошивки через KVM-консоль, поэтому обе инструкции описывают выделенные серверы. Для Hetzner доступ к KVM запрашивают через поддержку. Пример для Scaleway Dedibox работает в режиме без TPM, потому что в Dedibox его обычно нет. Для виртуальных машин в документации есть отдельная инструкция для OpenStack, где UEFI и TPM 2.0 включают явно.