Ошибка «no such device: ostree» — причины и способы восстановления загрузки

Ошибка error: no such device: ostree появляется на экране GRUB при загрузке систем на базе OSTree — чаще всего это Fedora Silverblue, Kinoite, Fedora IoT или другие атомарные дистрибутивы. Сообщение означает, что загрузчик не может найти раздел или устройство, на котором размещено развёртывание OSTree, и прерывает загрузку ещё до старта ядра.

Типичный сценарий: после обновления системы, изменения разметки диска или переноса установки на другой накопитель компьютер перестаёт загружаться и показывает строку no such device с указанием пути /ostree/... или UUID раздела. Ниже разберём, почему это происходит и как безопасно восстановить загрузку, не разрушая данные развёртываний.

Что означает ошибка no such device в контексте OSTree

В атомарных дистрибутивах загрузка устроена иначе, чем в классических системах. Загрузчик GRUB (или systemd-boot на новых установках) читает конфигурацию, которая ссылается на конкретное развёртывание в каталоге /ostree/deploy, а раздел идентифицируется по UUID файловой системы. Если этот UUID перестал быть доступен — изменился, отсутствует или устройство не определилось, — GRUB сообщает no such device.

Важно понимать: сама ошибка не говорит о повреждении данных. Чаще всего содержимое развёртываний цело, а «отвалилась» только связь между загрузчиком и корневым разделом. Именно поэтому первым делом стоит диагностировать, а не переустанавливать систему.

Ключевой признак именно этой проблемы — ошибка появляется до загрузки ядра, на чёрном экране GRUB, и содержит путь или UUID, связанный с ostree. Если система падает уже после старта ядра (например, в initramfs с сообщением о невозможности смонтировать sysroot), это близкая, но другая ситуация с похожими причинами.

Типичные причины появления ошибки

Причин несколько, и от правильной идентификации зависит выбор решения. Вот наиболее распространённые сценарии:

• 🔧 Изменение UUID раздела — после переформатирования, восстановления из образа, клонирования диска или пересоздания файловой системы UUID меняется, а конфигурация GRUB ссылается на старый.
• 💽 Перенос системы на другой диск — копирование разделов без корректировки загрузчика и fstab приводит к тому, что устройство с нужным идентификатором просто отсутствует.
• 🧩 Повреждение или рассинхронизация конфигурации GRUB — например, после ручного редактирования grub.cfg или неудачного обновления загрузчика.
• 🔌 Отключённый или неопределившийся накопитель — сбойный SATA/NVMe-контакт, изменение порядка устройств в BIOS/UEFI, загрузка с внешнего носителя, который отключили.
• 📦 Проблемы с Btrfs-подтомами — если корень и /boot лежат на Btrfs, ошибка может указывать на подтом, который не был смонтирован или был удалён.

Отдельно стоит упомянуть эксперименты с ручной разметкой. OSTree-системы чувствительны к структуре каталогов /boot и /boot/loader: если при переустановке или миграции эти пути оказались на другом устройстве, загрузчик не найдёт записи развёртываний.

Быстрая диагностика: что проверить в первую очередь

Прежде чем что-либо исправлять, нужно понять, видит ли вообще загрузчик нужный раздел. Это можно сделать прямо из консоли GRUB: на экране ошибки нажмите c, чтобы попасть в командную строку загрузчика.

ls
ls (hd0,gpt2)/
search --fs-uuid ВАШ_UUID

Команда ls покажет список обнаруженных устройств и разделов. Просмотр содержимого раздела поможет определить, где лежит каталог ostree, а search — проверить, существует ли устройство с UUID, на который ссылается конфигурация. Если search ничего не находит, UUID изменился либо раздел недоступен.

Второй вариант диагностики — загрузка с Live-носителя (например, с установочного образа Fedora). Из Live-окружения посмотрите список разделов и их идентификаторы:

lsblk -f
sudo blkid

Сравните вывод с тем, что записано в конфигурации загрузчика на нужном разделе (обычно /boot/loader/entries/*.conf для systemd-boot или /boot/grub2/grub.cfg для GRUB). Расхождение UUID — прямое подтверждение причины.

Восстановление загрузки через chroot с Live-носителя

Наиболее надёжный способ — смонтировать систему из Live-окружения и перегенерировать конфигурацию загрузчика. Общий порядок выглядит так (точные пути зависят от вашей разметки):

sudo mount /dev/ВАШ_КОРЕНЬ /mnt
sudo mount /dev/ВАШ_РАЗДЕЛ_BOOT /mnt/boot
sudo mount /dev/ВАШ_EFI /mnt/boot/efi   # для UEFI-систем
for d in /dev /proc /sys /run; do sudo mount --bind $d /mnt$d; done
sudo chroot /mnt

Внутри chroot для систем с GRUB обычно выполняют переустановку загрузчика и генерацию конфигурации. На OSTree-системах конфигурация формируется на основе записей развёртываний, поэтому важно, чтобы /boot был смонтирован корректно и содержал актуальные файлы развёртываний. Точные команды зависят от версии дистрибутива и типа загрузчика — сверьтесь с официальной документацией вашего дистрибутива (Fedora Silverblue и Kinoite имеют разделы по восстановлению загрузки в документации проекта).

⚠️ Внимание: команды grub2-install и grub2-mkconfig различаются между BIOS- и UEFI-установками, а на атомарных дистрибутивах прямое редактирование grub.cfg может быть перезаписано при следующем обновлении. Не копируйте команды из инструкций для классической Fedora Workstation без проверки — там загрузка устроена иначе.

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

Проверка файловой системы и состояния развёртываний

Если раздел определяется, но загрузка всё равно обрывается, проверьте файловую систему. Для ext4 используется fsck.ext4, для Btrfs — btrfs check в режиме только чтения (запускать проверку нужно на размонтированном разделе из Live-окружения):

sudo fsck.ext4 -f /dev/ВАШ_РАЗДЕЛ
sudo btrfs check --readonly /dev/ВАШ_РАЗДЕЛ

Далее имеет смысл проверить состояние самих развёртываний OSTree. В chroot-окружении команда ostree admin status покажет список развёртываний и какое из них отмечено как загружаемое по умолчанию. Если текущее развёртывание повреждено, но предыдущее цело, можно выполнить откат: в меню GRUB при загрузке выберите предыдущую запись — атомарная модель как раз рассчитана на такой сценарий.

Если меню GRUB вообще недоступно, попробуйте при старте удерживать клавишу вызова меню загрузчика (на многих системах это Esc или Shift — зависит от конфигурации). Появление списка развёртываний уже означает, что загрузчик рабочий, и проблема локализована в конкретной записи.

Почему откат на предыдущее развёртывание безопасен

OSTree хранит каждое развёртывание как неизменяемое дерево файлов в /ostree/deploy. Обновление не перезаписывает старую систему, а создаёт новую. Поэтому выбор предыдущей записи в меню загрузки возвращает систему ровно в то состояние, в котором она была до обновления. Ограничение: пользовательские данные в /var и /home общие для всех развёртываний, поэтому изменения в них откатом не затрагиваются.

Сравнение сценариев и подходящих решений

Соберём типичные ситуации и соответствующие им действия в одну таблицу — это поможет быстро сориентироваться:

Ситуация	Вероятная причина	Решение
Ошибка после обновления	Повреждённое новое развёртывание	Загрузить предыдущее развёртывание из меню GRUB
Ошибка после клонирования диска	Сменился UUID раздела	Перегенерировать конфигурацию загрузчика из chroot
Диск не виден в консоли GRUB	Аппаратная проблема, настройки BIOS/UEFI	Проверить подключение накопителя и режим контроллера
Раздел читается, но записей нет	Повреждены файлы в /boot/loader	Восстановить записи загрузчика по документации дистрибутива
Ошибка после падения в initramfs	Не монтируется sysroot	Проверить файловую систему и параметры root= в записи

⚠️ Внимание: не используйте btrfs check --repair как первый шаг — этот режим потенциально деструктивен и рекомендуется разработчиками Btrfs только как крайняя мера. Сначала сделайте копию важных данных и попробуйте менее инвазивные варианты.

Профилактика: как снизить риск повторения ошибки

Большинство случаев no such device: ostree связано с действиями вокруг системы, а не с самой системой. Несколько практических мер заметно снижают вероятность проблемы:

• 💾 Перед клонированием или переносом диска зафиксируйте текущие UUID (blkid) и план восстановления загрузчика.
• 🔄 Не выключайте питание во время rpm-ostree upgrade — прерванное развёртывание обычно не ломает старое, но усложняет диагностику.
• 🗂️ Не редактируйте вручную grub.cfg на атомарных системах — конфигурация управляется автоматически и правки будут перезаписаны.
• 🧪 Держите под рукой Live-USB с совместимой версией дистрибутива — это главный инструмент восстановления.

Полезно также периодически проверять, что в системе присутствует как минимум два рабочих развёртывания: rpm-ostree status покажет их список. Наличие запасной записи — ваша страховка при повреждении текущего развёртывания.

Часто задаваемые вопросы

Можно ли исправить ошибку без Live-USB?

Иногда да. Если меню GRUB доступно, попробуйте загрузить предыдущее развёртывание — оно использует те же разделы, и если причина в повреждённой записи нового развёртывания, система стартует. Если же ошибка возникает на уровне поиска устройства (UUID не найден), без внешнего носителя обойтись сложно: потребуется перегенерация конфигурации загрузчика.

Опасна ли эта ошибка для данных пользователя?

Сама по себе — нет. Ошибка возникает до монтирования корня, и данные в /var и /home остаются нетронутыми. Риск появляется только при некорректных попытках починки: форматировании разделов, деструктивных режимах проверки файловых систем, перезаписи загрузчика не туда.

Почему ошибка появилась после переноса системы на SSD?

При клонировании или пересоздании разделов их UUID обычно меняются, а конфигурация загрузчика и fstab продолжают ссылаться на старые идентификаторы. Решение — смонтировать систему из Live-окружения, актуализировать ссылки на UUID и перегенерировать конфигурацию загрузчика.

Чем эта ошибка отличается от «grub rescue»?

Режим grub rescue> означает, что GRUB не смог найти даже собственные модули и конфигурацию — это более глубокая проблема, обычно связанная с повреждением раздела /boot. Ошибка no such device: ostree возникает на более позднем этапе: загрузчик работает, но не находит конкретное устройство из записи развёртывания.

Поможет ли переустановка системы?

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