Debian/Ubuntu: fsck exited with status code 4 — что делать, если сервер не загружается

Сообщение fsck exited with status code 4 в Debian и Ubuntu обычно означает не мелкую ошибку загрузки, а вполне конкретную проблему: проверка файловой системы завершилась фатально, и systemd не смог безопасно продолжить запуск. На практике сервер после аварийного выключения или сбоя питания попадает в emergency mode, просит root-пароль или зависает на сообщениях о проверке дисков.

Самая частая ошибка администратора в этот момент — сразу запускать ремонт наугад. Особенно опасно делать это на неправильном устройстве, на смонтированном разделе или вообще неподходящим инструментом. Например, пытаться лечить XFS так же, как ext4. Намного безопаснее сначала понять, какой именно том упал, какая там файловая система, что сказал systemd и нет ли признаков аппаратной проблемы.

Ниже разберём пошаговый сценарий: как распознать причину, как собрать минимальную диагностику, что делать в emergency shell и initramfs, чем отличается восстановление ext4 от XFS и когда лучше переключаться с ремонта на спасение данных.

Код возврата 4 у fsck — это не «ошибки нашли и уже исправили», а фатальная ошибка проверки или неисправленные проблемы, после которых продолжать загрузку рискованно.

Что означает status code 4 у fsck

Утилита fsck и её файловосистемные бэкенды возвращают коды статуса. Во время загрузки Debian и Ubuntu systemd обычно запускает проверку для корневого раздела и других файловых систем, перечисленных в /etc/fstab. Если результат критический, система останавливает загрузку и переводит сервер в emergency mode.

Упрощённо коды можно читать так:

• 0 — ошибок нет;
• 1 — ошибки были и успешно исправлены;
• 2 — после исправления требуется перезагрузка;
• 4 — неисправленные ошибки или фатальный сбой проверки;
• 8 и выше — операционные ошибки, проблемы запуска проверки или другие серьёзные сбои.

В журнале это часто видно как сбой юнита systemd-fsck-root.service, systemd-fsck@... или сообщение вида Failed to start File System Check on /dev/....

Почему сервер попадает в emergency mode

У ошибки fsck exited with status code 4 есть несколько типовых причин, и каждая требует немного разного подхода.

Аварийное выключение

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

Проблемы с накопителем

Если в логах есть I/O error, Buffer I/O error, таймауты, reset link, ошибки NVMe или bad sector, то первопричина может быть не в самой файловой системе, а в диске, контроллере, кабеле или виртуальном блочном устройстве. В таком случае многократный запуск проверки без диагностики может сделать только хуже.

Ошибки в /etc/fstab

Бывает и более спокойный сценарий: поменялся UUID, указан неверный тип ФС, подключён несуществующий раздел или обязательная точка монтирования осталась после удаления диска. Тогда загрузка ломается не из-за потери данных, а из-за некорректной конфигурации.

Неправильный инструмент

Для ext4 нужен e2fsck или fsck.ext4, а для XFS — xfs_repair. Если перепутать инструменты, можно потерять время на ложную диагностику или вообще повредить систему ещё сильнее.

Повреждение superblock или журнала

У ext4 нередки проблемы с основным superblock. У XFS чаще страдают журнал и метаданные. Внешне это может выглядеть одинаково — сервер не загружается, но действия по восстановлению будут разными.

Если у вас проект живёт на VDS, полезно заранее иметь доступ к консоли и rescue-среде: при файловых сбоях именно они чаще всего экономят время и нервы.

С чего начать диагностику

Если система уже в emergency shell, сначала выясните три вещи: какой раздел проблемный, какой у него тип файловой системы и есть ли признаки аппаратных ошибок.

1. Посмотреть, какой юнит упал

systemctl --failed
journalctl -xb
journalctl -xb | grep -i fsck
journalctl -u systemd-fsck-root.service -b

Если проблема не в корне, а в отдельном разделе, посмотрите журнал соответствующего юнита systemd-fsck@.... По логу обычно видно, что именно проверялось и какой код вернул backend.

2. Определить устройство и тип файловой системы

lsblk -f
blkid
findmnt -no SOURCE /

Команда lsblk -f покажет устройство, UUID и тип ФС. Это особенно важно на системах с LVM, mdadm или облачными образами, где путь к корневому тому не всегда очевиден.

3. Убедиться, что раздел не смонтирован

Перед ручным ремонтом раздел нужно размонтировать. Для корня это часто означает загрузку в recovery, rescue или live-среду. Если речь о дополнительном разделе, проверьте его состояние так:

mount | grep '^/dev'
findmnt
umount /dev/sdXN

Если раздел занят, сначала выясняйте, каким процессом или сервисом. Проверка смонтированной ext4 — плохая идея.

Что делать в emergency shell и initramfs

Во многих случаях после сбоя вы оказываетесь либо в emergency mode, либо в среде initramfs. Это уже не полноценная рабочая система, поэтому набор доступных инструментов ограничен, но базовой диагностики обычно хватает.

Минимальный набор команд для старта:

blkid
lsblk -f
cat /proc/cmdline
dmesg | grep -Ei 'error|ext4|xfs|i/o|buffer|journal'

Если root-раздел на ext4 и он не смонтирован, можно переходить к ручной проверке. Но сначала убедитесь, что выбрали правильное устройство. На системах с LVM это может быть логический том вроде /dev/mapper/vg0-root, а не физический раздел.

Если вы часто работаете с разными файловыми системами, пригодится и отдельный разбор различий между ext4 и XFS на сервере: там проще понять, почему одинаковый симптом лечится разными инструментами.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Восстановление ext4: безопасная последовательность

Для ext4 основной инструмент — e2fsck. Обёртка fsck тоже подойдёт, но в аварийной ситуации лучше явно указывать backend, чтобы не было путаницы.

Базовая проверка

e2fsck -f /dev/sdXN

Ключ -f принудительно запускает полную проверку, даже если раздел считается чистым. Если нужен полностью неинтерактивный режим, иногда используют -y, но на боевой системе это стоит делать только когда вы точно понимаете последствия.

После первого прохода есть смысл запустить проверку ещё раз. Нормальный результат — завершение без новых исправлений.

Если повреждён основной superblock

Признаки обычно такие: bad magic number in super-block, невозможность прочитать superblock, отказ обычного e2fsck продолжить работу.

Сначала посмотрите резервные superblock:

mke2fs -n /dev/sdXN

Эта команда не форматирует раздел, а только показывает возможные расположения резервных superblock. Затем можно попробовать восстановление с одним из них:

e2fsck -b 32768 /dev/sdXN

Номер superblock нужно брать из вывода своей команды, а не копировать из примера. После успешного восстановления снова прогоните обычный e2fsck -f.

Когда ремонт ext4 уже опасен

Если проверка сыплет новыми ошибками чтения, диск периодически пропадает из системы, а dmesg заполнен I/O-проблемами, лучше сначала думать о копии данных. На виртуальной машине это повод проверить состояние виртуального диска и недавние инциденты инфраструктуры. На физическом сервере — сразу смотреть SMART и логи контроллера.

Что делать с XFS

С XFS логика совсем другая. Обычный fsck не делает для неё привычный ремонт, поэтому переносить ext4-привычки на XFS нельзя.

Сначала диагностика без изменений

xfs_repair -n /dev/sdXN

Ключ -n запускает анализ без записи. Это хороший первый шаг: он помогает понять, действительно ли повреждены метаданные XFS, или проблема глубже и связана уже с устройством хранения.

Потом ремонт

xfs_repair /dev/sdXN

Если повреждён журнал и обычный ремонт не может продолжить работу, иногда используют:

xfs_repair -L /dev/sdXN

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

Как понять, что проблема глубже, чем fsck

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

Проверьте журнал ядра на такие признаки:

• повторяющиеся I/O error;
• Buffer I/O error;
• EXT4-fs error или сообщения о повреждении metadata у XFS;
• ошибки чтения GPT или partition table;
• таймауты NVMe, reset, abort command.

Полезные команды:

dmesg -T | grep -Ei 'error|i/o|ext4|xfs|nvme|buffer|blk|abort|reset'
journalctl -k -b
smartctl -a /dev/sdX

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

Частый источник проблемы — /etc/fstab

После ремонта файловой системы сервер иногда всё равно не загружается. Кажется, что проблема осталась в fsck, но на деле уже ломается монтирование.

Проверьте:

• актуальны ли UUID в /etc/fstab;
• верно ли указан тип ФС;
• не осталась ли обязательная точка монтирования для отсутствующего устройства;
• нет ли ошибок в поле pass, которое влияет на порядок проверки.

blkid
cat /etc/fstab
mount -a

Команда mount -a помогает быстро проверить синтаксис и доступность устройств без полной перезагрузки. Для root обычно используют pass 1, для остальных Linux-разделов — 2. Для XFS и специальных ФС поведение зависит от сценария.

Пошаговый runbook: как вернуть сервер в строй

Если нужен короткий алгоритм без лишней теории, используйте такой порядок.

1. Откройте консоль recovery, emergency shell или initramfs.
2. Найдите проблемный раздел через journalctl -xb, systemctl --failed и lsblk -f.
3. Определите тип файловой системы: ext4, XFS, LVM-том и так далее.
4. Проверьте dmesg и журнал ядра на I/O-ошибки.
5. Убедитесь, что раздел не смонтирован.
6. Для ext4 запустите e2fsck -f, при необходимости используйте резервный superblock.
7. Для XFS сначала выполните xfs_repair -n, затем xfs_repair.
8. Проверьте /etc/fstab, UUID и типы файловых систем.
9. Перезагрузитесь и снова просмотрите journalctl -b.
10. После восстановления обязательно оцените состояние диска и актуальность бэкапов.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Как снизить риск повторения

Ошибка fsck exited with status code 4 часто выглядит как разовый инцидент, но нередко возвращается, если не устранить корень проблемы.

• проверьте логи за предыдущие загрузки на аппаратные ошибки;
• убедитесь, что файловая система не переполнена;
• проверьте корректность /etc/fstab и порядка монтирования;
• держите актуальные бэкапы и регулярно проверяйте восстановление;
• для виртуальных машин контролируйте корректное выключение и состояние диска.

Если проект размещён на виртуальном хостинге или VDS, полезно заранее держать под рукой rescue-процедуру: доступ к консоли, карту разделов, список UUID и понятный порядок восстановления.

Когда лучше остановиться и спасать данные

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

В таком случае лучше действовать так:

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

Это особенно важно для баз данных, почтовых хранилищ, CI-нод и файловых серверов. Сам факт успешного завершения fsck ещё не гарантирует логическую целостность прикладных данных.

Итог

Если Debian или Ubuntu показывает fsck exited with status code 4, воспринимайте это как сигнал к аккуратной диагностике, а не к немедленному ремонту вслепую. Сначала нужно понять, какой том сломался, что говорит журнал, какой там тип файловой системы и нет ли аппаратных симптомов.

Рабочая стратегия почти всегда одна: определить проблемное устройство, посмотреть journalctl, не ремонтировать смонтированный раздел и использовать правильный инструмент. Для ext4 это e2fsck, для XFS — xfs_repair. Если же видны признаки деградации диска, приоритетом становятся бэкап и сохранность данных, а не быстрая загрузка любой ценой.