---
tags: [linux, freebsd, tooling]
verified: 2026-09-02
---

# Восстановление незагружающейся системы

## Как пользоваться этой заметкой

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

Три правила, которые экономят больше времени, чем любая команда ниже.

Сначала прочитать сообщение целиком. «Не грузится» — это не диагноз; на экране почти всегда есть имя устройства, точки монтирования или юнита, и оно указывает на причину точнее любых догадок.

Ничего не форматировать и не «чинить» до того, как понятен этап. Большая часть безвозвратных потерь при восстановлении наносится самим восстанавливающим — `mkfs` не на том разделе, `xfs_repair -L` на живом журнале, переустановка загрузчика на не тот диск.

Начинать с наименее разрушительного средства. Порядок такой: изменить параметры ядра на одну загрузку → загрузиться в аварийный режим → chroot с live-носителя → чинить файловую систему.

Механика загрузчика и снепшотов подробно разобрана в [обновлении и управлении загрузкой](./linux-boot-management.md); здесь — только то, что делают, когда система уже не грузится.

## Шаг первый: на каком этапе встали

| Что на экране | Этап | Куда дальше |
|---|---|---|
| Логотип прошивки, потом ничего; «No bootable device» | Firmware не нашёл загрузчик | [Загрузчик и EFI](#загрузчик-grub-и-запись-efi) |
| Меню GRUB не появилось, чёрный экран с курсором | Загрузчик повреждён | [Загрузчик и EFI](#загрузчик-grub-и-запись-efi) |
| `grub rescue>` или `grub>` | Загрузчик жив, не находит конфиг или ядро | [Загрузчик и EFI](#загрузчик-grub-и-запись-efi) |
| «Kernel panic — not syncing: VFS: Unable to mount root fs» | Ядро загрузилось, корень не смонтирован | [Корень не монтируется](#корень-не-монтируется) |
| Приглашение `(initramfs)` или `dracut:/#` | initramfs жив, дальше не идёт | [Корень не монтируется](#корень-не-монтируется) |
| «Failed to start …», система висит или уходит в emergency | init работает, падает юнит или монтирование | [Система стартует, но не доходит до логина](#система-стартует-но-не-доходит-до-логина) |
| Приглашение входа есть, войти не удаётся | Загрузка прошла | [Забыт пароль root](#забыт-пароль-root) |
| `mountroot>` (FreeBSD) | Ядро не нашло корень | [FreeBSD](#freebsd) |

Если ничего не видно вовсе, потому что машина удалённая, — это тот случай, ради которого хостеры дают VNC-консоль или IPMI. Без доступа к консоли восстановление сводится к переустановке, поэтому проверить, что такой доступ есть и вы знаете, как его открыть, стоит заранее, а не сейчас.

## Linux

### Правка параметров ядра на одну загрузку

Базовый приём, с которого начинается почти всё остальное. В меню GRUB — `e` на нужной записи, курсор в конец строки `linux …`, дописать нужное, `Ctrl+X` для запуска. Изменения не сохраняются: следующая загрузка снова обычная.

| Параметр | Что делает |
|---|---|
| `rescue` (или `1`, `s`, `single`) | однопользовательский режим: корень смонтирован, сеть и большинство сервисов не запущены |
| `emergency` | минимум: оболочка на консоли, больше ничего не стартует и не монтируется; корень остаётся в том режиме, в каком его оставили ядро и initramfs |
| `systemd.unit=multi-user.target` | загрузка без графики, когда виноват дисплей-менеджер |
| `init=/bin/bash` | вместо init запускается оболочка; ни один сервис не стартует |
| `rd.break` | остановиться в initramfs, до передачи управления системе |
| `systemd.debug_shell` | оболочка на tty9 параллельно обычной загрузке |
| `nomodeset` | без загрузки драйвера видеокарты — против чёрного экрана на графике |

Разница между `rescue` и `emergency` практична: первый монтирует файловые системы из `fstab`, второй — нет. Если проблема как раз в `fstab`, нужен `emergency`.

`init=/bin/bash` — самый радикальный вариант: не запускается вообще ничего, включая systemd. Корень при этом смонтирован только для чтения, и перед правкой его нужно перемонтировать:

```bash
mount -o remount,rw /
# ...правки...
mount -o remount,ro /
exec /sbin/init          # либо reboot -f
```

Обычным `reboot` из такого окружения выходить нельзя — некому его обработать; отсюда `reboot -f` или `exec /sbin/init`.

### Корень не монтируется

Симптом — паника ядра с `Unable to mount root fs` или приглашение `(initramfs)`. Ядро загрузилось, initramfs работает, а корневая файловая система не найдена или не читается.

В аварийной оболочке initramfs доступен минимальный набор утилит — обычно busybox. Первым делом выяснить, видит ли ядро диски вообще:

```bash
cat /proc/partitions
blkid                       # какие UUID видны на самом деле
```

Дальше три типичные причины.

**UUID в параметрах ядра не совпадает с реальным.** Случается после клонирования диска, пересоздания файловой системы или замены накопителя. Сверить `root=UUID=…` из `/proc/cmdline` с выводом `blkid`. Лечение — загрузиться с правильным UUID (правкой строки в GRUB), затем поправить `/etc/fstab` и пересобрать конфигурацию загрузчика.

**Нет драйвера контроллера или файловой системы в initramfs.** Типично после смены железа, миграции виртуалки на другой гипервизор или неудачной пересборки. Проверяется просмотром содержимого образа:

```bash
lsinitrd /boot/initramfs-$(uname -r).img | grep -i virtio
```

Лечение — пересобрать initramfs из chroot (см. ниже): `dracut --force --regenerate-all` либо `update-initramfs -u -k all`.

**Файловая система повреждена.** Переходить к [проверке файловой системы](#повреждённая-файловая-система).

Смонтировать корень вручную и посмотреть, что там, можно прямо из initramfs:

```bash
mkdir /mnt/root && mount /dev/sda2 /mnt/root && ls /mnt/root
```

### Система стартует, но не доходит до логина

Init работает, значит корень смонтирован и большая часть системы жива. Виноват конкретный юнит или строка `fstab`.

```bash
systemctl --failed                       # что упало
journalctl -b -p err                     # ошибки текущей загрузки
journalctl -b -1 -p err                  # ошибки предыдущей, если сейчас загрузились
systemd-analyze blame                    # что заняло время, если загрузка зависла надолго
```

Самая частая причина зависания без сообщений — несуществующее устройство в `fstab`: systemd честно ждёт его появления полторы минуты на каждую запись, а потом уходит в emergency. Лечение и профилактика — в разделе про [испорченный fstab](#испорчен-fstab).

### chroot с live-носителя

Когда починить изнутри не получается, система собирается из live-образа. Порядок монтирования важен: без псевдофайловых систем внутри chroot не будут работать ни `grub-install`, ни пересборка initramfs.

```bash
mount /dev/sda2 /mnt                     # корень
mount /dev/sda1 /mnt/boot                # отдельный /boot, если есть
mount /dev/sda1 /mnt/boot/efi            # ESP на UEFI-машине

for d in dev proc sys run; do mount --rbind /$d /mnt/$d; done
chroot /mnt /bin/bash
```

`--rbind`, а не `--bind`: внутри `/dev` и `/sys` смонтированы вложенные файловые системы (`devpts`, `efivarfs`), и без рекурсии они не попадут внутрь. Отсутствие `efivarfs` — самая частая причина, по которой `efibootmgr` в chroot отвечает «EFI variables are not supported on this system».

В Arch и производных всё это делает `arch-chroot /mnt` одной командой, включая копирование `resolv.conf` для работающего DNS.

Если корень на LVM или зашифрован, до монтирования нужно его активировать:

```bash
cryptsetup open /dev/sda2 root           # LUKS
vgchange -ay                             # LVM
```

Выход — `exit`, затем `umount -R /mnt`. Рекурсивный размонтаж обязателен, иначе часть файловых систем останется занятой и изменения могут не попасть на диск.

### Загрузчик: GRUB и запись EFI

Внутри chroot. На BIOS-машине загрузчик ставится в MBR диска, на UEFI — в раздел ESP:

```bash
# BIOS
grub-install /dev/sda

# UEFI
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
```

Аргумент `grub-install` на BIOS — диск целиком (`/dev/sda`), а не раздел. Указание раздела — классическая ошибка, ведущая к неработающей загрузке.

Пересборка конфигурации:

```bash
grub-mkconfig -o /boot/grub/grub.cfg     # Arch
grub2-mkconfig -o /boot/grub2/grub.cfg   # Fedora, RHEL, openSUSE
update-grub                              # Debian, Ubuntu (обёртка над тем же)
```

В Fedora, RHEL и openSUSE утилиты GRUB носят префикс `grub2-` (`grub2-install`, `grub2-mkconfig`), а конфигурация лежит в `/boot/grub2/grub.cfg`; в chroot об этом легко забыть и пересобрать не тот файл.

Отдельный класс проблем — потерянная запись в NVRAM прошивки. Файлы загрузчика на месте, но firmware о них не знает: обновление прошивки, сброс настроек, замена материнской платы, иногда обновление у хостера.

```bash
efibootmgr -v                            # что прошивка знает сейчас
efibootmgr -c -d /dev/sda -p 1 -L "GRUB" -l '\EFI\GRUB\grubx64.efi'
efibootmgr -o 0003,0001                  # порядок загрузки
```

Запасной путь на случай, когда NVRAM не сохраняет записи (встречается на дешёвых материнских платах и у части хостеров): положить загрузчик по «дефолтному» пути, который прошивка ищет без всяких записей — `/EFI/BOOT/BOOTX64.EFI` на ESP.

### Откат снепшота

Если перед обновлением был снепшот, это самый быстрый и наименее травматичный путь. Инструменты и их настройка разобраны в [обновлении и управлении загрузкой](./linux-boot-management.md); здесь — суть операции.

Btrfs: подтом с рабочей системой заменяется на снепшот. Из live-образа монтируется корень тома целиком (`subvolid=5`), рабочий подтом отодвигается, снепшот встаёт на его место:

```bash
mount -o subvolid=5 /dev/sda2 /mnt
mv /mnt/@ /mnt/@broken
btrfs subvolume snapshot /mnt/@snapshots/42/snapshot /mnt/@
```

Если стоит `grub-btrfs`, всё это делается проще: снепшоты видны прямо в меню GRUB, и можно сначала загрузиться в снепшот и убедиться, что он рабочий.

LVM: снепшот сливается обратно в исходный том, операция выполняется при следующей загрузке, поэтому нужен перезапуск:

```bash
lvconvert --merge /dev/vg0/root-snap
reboot
```

Важное свойство, о котором забывают: слияние уничтожает снепшот. Второй попытки отката не будет.

### Повреждённая файловая система

Общее правило: проверять только размонтированную файловую систему. Проверка смонтированной ничего не чинит и может испортить.

**ext4.** `fsck` в интерактивном режиме, `-y` — соглашаться со всем (осмысленно, когда вопросов сотни):

```bash
fsck -f /dev/sda2
```

Если повреждён сам суперблок, `fsck` не сможет начать. У ext4 есть резервные копии суперблока; их расположение зависит от размера блока и параметров, а узнать его можно, не трогая диск, — `mke2fs` в режиме предпросмотра:

```bash
mke2fs -n /dev/sda2                      # -n НИЧЕГО не пишет, только печатает раскладку
e2fsck -b 32768 /dev/sda2                # использовать резервный суперблок
```

Флаг `-n` здесь критичен: без него та же команда создаст новую файловую систему поверх старой.

**XFS.** `fsck` для XFS ничего не делает — по замыслу; используется `xfs_repair`. Ключевая тонкость касается журнала. Если в журнале остались незаписанные изменения, `xfs_repair` откажется работать и сообщит, что файловую систему нужно смонтировать, чтобы журнал проигрался, затем размонтировать и повторить попытку. Это и есть правильная последовательность:

```bash
mount /dev/sda2 /mnt && umount /mnt      # проиграть журнал
xfs_repair /dev/sda2
```

Флаг `-L` обнуляет журнал и позволяет починку без проигрывания. Он выбрасывает всё, что в журнале было, то есть теряет данные, и применяется только когда смонтировать не удаётся никак. Совет «просто добавьте `-L`», который часто встречается на форумах, стоит воспринимать как предложение потерять последние изменения.

**Btrfs.** `btrfs check --repair` в документации помечен как опасный и не является первым средством. Прежде него: `btrfs scrub` для проверки контрольных сумм и `mount -o ro,rescue=all` — режим для монтирования повреждённого тома в режиме чтения, чтобы вытащить данные. Правильный порядок для Btrfs почти всегда — сначала спасти данные, потом чинить.

## FreeBSD

### Однопользовательский режим

Пункт 2 в загрузочном меню либо `boot -s` в приглашении загрузчика. Корень монтируется только для чтения; для правок:

```sh
mount -u -o rw /
mount -a -t ufs
zfs mount -a
```

Первая команда перемонтирует корень в режиме записи, две следующие подключают остальное. Без них правки в `/etc` не сохранятся.

### Приглашение загрузчика

`Esc` в меню даёт приглашение `OK`, где можно вмешаться в загрузку до старта ядра:

```sh
unload
boot /boot/kernel.old/kernel             # загрузить прежнее ядро
set kern.geom.label.disk_ident.enable=0  # изменить tunable на одну загрузку
lsdev                                     # какие устройства видит загрузчик
```

Загрузка прежнего ядра — штатный способ пережить неудачную сборку или обновление: `installkernel` сохраняет предыдущее в `/boot/kernel.old`.

Отдельный случай — модуль, который ломает загрузку. Отключается в том же приглашении: `set module_blacklist=имя` перед `boot`.

### Откат boot environment

Самый сильный аргумент FreeBSD с ZFS в этом сценарии. Boot environment — отдельный загрузочный датасет; откат означает загрузиться в предыдущий, а не чинить текущий.

Прямо из загрузочного меню доступен пункт выбора boot environment — то есть откат возможен вообще без работающей системы. Если система запускается хотя бы в однопользовательском режиме:

```sh
bectl list
bectl activate -t before-upgrade         # -t: только на следующую загрузку
reboot
```

Флаг `-t` делает выбор одноразовым: если и в этом BE что-то не так, следующая загрузка вернётся к прежнему по умолчанию. Механика BE подробнее — в [ZFS](./freebsd-zfs.md) и [обновлении системы](./freebsd-updating.md).

### Импорт пула с live-образа

Когда не грузится ничего, загружаемся с установочного образа и выбираем Live CD. Пул от незагружающейся системы импортируется в отдельный каталог:

```sh
zpool import                             # какие пулы видны
zpool import -f -R /mnt zroot            # -R: смонтировать под /mnt, не трогая /
zfs mount zroot/ROOT/default
```

`-R` здесь обязателен: без него пул попытается смонтироваться в свои штатные точки и займёт корень live-системы. `-f` нужен, потому что пул числится импортированным на другой системе — той, которая не загружается.

Откат к снепшоту, если система сломалась после обновления:

```sh
zfs rollback -r zroot/ROOT/default@before-upgrade
```

`-r` уничтожает более поздние снепшоты — как и слияние LVM, операция без второй попытки.

## Частые случаи

### Забыт пароль root

Linux, через параметры ядра:

```bash
# в строке linux: init=/bin/bash
mount -o remount,rw /
passwd root
touch /.autorelabel                      # если включён SELinux
exec /sbin/init
```

Строка с `.autorelabel` не косметическая: без неё система с SELinux после смены пароля может не загрузиться, потому что у нового `/etc/shadow` окажется неверный контекст.

FreeBSD — однопользовательский режим:

```sh
mount -u -o rw /
passwd root
```

Отсюда следует то, что часто формулируют как принцип, но редко принимают всерьёз: физический доступ к консоли равносилен root. Если это неприемлемо — нужны пароль на GRUB (`grub-mkpasswd-pbkdf2` и `superusers` в конфигурации) и шифрование диска; без второго первое обходится загрузкой с флешки.

### Испорчен fstab

Симптом — система уходит в emergency или висит по полторы минуты на запись. Загрузиться нужно в `emergency` (именно он, а не `rescue`: `rescue` попытается смонтировать всё из `fstab`), затем:

```bash
mount -o remount,rw /
vi /etc/fstab
systemctl daemon-reload
```

Профилактика стоит одного слова в опциях монтирования. `nofail` означает «не считать ошибкой, если устройства нет», а `x-systemd.device-timeout=` сокращает ожидание:

```conf
UUID=...  /mnt/data  ext4  defaults,nofail,x-systemd.device-timeout=10s  0 2
```

Для всего, что не является корнем — внешних дисков, сетевых шар, дополнительных томов — это правильное умолчание. Отсутствующая флешка не должна мешать серверу загружаться.

### Переполнен /boot

Отдельный раздел `/boot` на несколько сотен мегабайт заполняется старыми ядрами, после чего обновление падает на середине, а иногда система остаётся без рабочего initramfs.

```bash
uname -r                                 # текущее ядро — его не трогать
dpkg -l 'linux-image-*' | grep ^ii       # Debian/Ubuntu
apt purge linux-image-5.15.0-56-generic
dnf remove --oldinstallonly              # Fedora/RHEL
pacman -Qe | grep linux                  # Arch
```

Чистить нужно пакетным менеджером, а не `rm` в `/boot`: удалённые вручную файлы оставят пакет в системе, и следующая пересборка initramfs снова попытается их создать.

Профилактика — ограничить число хранимых ядер: `installonly_limit` в `dnf.conf`, `unattended-upgrade` с автоочисткой либо соответствующий хук в Arch.

### Недоступен ключ LUKS

Симптом: запрос пароля не появляется вовсе, либо система сообщает, что не может открыть устройство.

Если ключевой файл лежал в initramfs, а initramfs пересобран без него, — открывать придётся паролем, а `crypttab` и образ пересобрать. Проверить, какие ключевые слоты вообще заняты:

```bash
cryptsetup luksDump /dev/sda2
```

Если пароль забыт, а слоты пусты — данные потеряны, и это не преодолевается. Единственный работающий ответ на этот случай даётся заранее: заголовок LUKS сохраняется отдельно, до аварии.

```bash
cryptsetup luksHeaderBackup /dev/sda2 --header-backup-file luks-header.img
```

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

## Профилактика

Всё, что реально сокращает время простоя, делается заранее.

**Live-носитель и доступ к консоли.** Флешка с образом системы — для физической машины; проверенный доступ к VNC или IPMI — для удалённой. «Проверенный» означает, что вы им хоть раз пользовались: узнавать, что консоль хостера требует Java-апплета или отдельного пароля, лучше не в момент аварии.

**Снепшот или boot environment перед каждым обновлением.** На FreeBSD с ZFS `freebsd-update` делает это сам; на Linux с Btrfs или LVM — либо snapper, либо привычка. Откат из снепшота занимает минуты против часов на восстановление.

**Ограничение числа ядер и `nofail` в `fstab`.** Две настройки, закрывающие два самых частых случая из предыдущего раздела.

**Резервная копия заголовка LUKS и пароля от репозитория бэкапов.** Оба — вне восстанавливаемой машины.

**Проверенные бэкапы.** Восстановление незагружающейся системы имеет смысл, пока оно дешевле развёртывания заново из бэкапа. Если бэкап есть и проверен, у всей этой заметки появляется граница: в какой-то момент правильный ответ — не чинить, а развернуть. Как убедиться, что бэкап рабочий, — в [резервном копировании](./backup-strategy.md).

**Записывать, что сделали.** При восстановлении делается десяток шагов, и через полгода при повторе не вспомнится ни один. Заметка на пять строк после успешного восстановления окупается.

## Источники

- [kernel-command-line(7)](https://www.freedesktop.org/software/systemd/man/kernel-command-line.html) — `systemd.unit=`, `rescue`, `emergency`, `systemd.debug_shell`
- [dracut.cmdline(7)](https://github.com/dracut-ng/dracut-ng/blob/main/man/dracut.cmdline.7.adoc) — `rd.break` и его точки останова, `rd.shell`, `rd.debug`
- [e2fsck(8)](https://man7.org/linux/man-pages/man8/e2fsck.8.html) — `-b` и поиск резервных суперблоков через `mke2fs -n`
- [xfs_repair(8)](https://man7.org/linux/man-pages/man8/xfs_repair.8.html) — требование проиграть журнал монтированием и цена флага `-L`
- [efibootmgr](https://github.com/rhboot/efibootmgr) — управление записями в NVRAM
- [bectl(8)](https://man.freebsd.org/cgi/man.cgi?bectl8) — `activate -t` и одноразовый выбор boot environment
- [zpool-import(8)](https://openzfs.github.io/openzfs-docs/man/master/8/zpool-import.8.html) — `-f` и `-R` при импорте чужого пула
- [FreeBSD Handbook: The Boot Process](https://docs.freebsd.org/en/books/handbook/boot/) — приглашение загрузчика и однопользовательский режим

---

## Связанные заметки

- [Linux — обновление и управление загрузкой](./linux-boot-management.md) — как устроены GRUB, initramfs и снепшот-откаты, когда система ещё грузится
- [Linux — файловые системы: ext4, XFS, Btrfs, LVM](./linux-filesystems.md) — устройство файловых систем, которые здесь чинят, и границы применимости их инструментов
- [FreeBSD — обновление системы](./freebsd-updating.md) — boot environments как штатная страховка обновления
- [FreeBSD — ZFS](./freebsd-zfs.md) — снепшоты, `rollback` и импорт пула с чужой системы
- [Резервное копирование: стратегия и проверка восстановления](./backup-strategy.md) — граница, за которой чинить дороже, чем развернуть заново
- [Debian: модель релизов и управление пакетами](./debian-releases-and-packages.md) — переполненный `/boot` как следствие политики хранения ядер и порядок перехода между релизами
- [KDF для паролей: почему медленно и с памятью](./crypto-password-kdf.md) — что лежит в слоте LUKS2 и почему параметры вывода ключа можно сменить, не трогая данные