Система не загружается, падая в emergency mode, или при попытке работы выдает ошибку:

Structure needs cleaning

Это критическое повреждение метаданных файловой системы (суперблока, таблицы inode или журнала). Ядро принудительно переводит корень (/) в режим Read-Only для защиты данных.

⚠️ Ловушка восстановления «изнутри»

Попытка починить корневую ФС из-под самой этой системы ведет в тупик:

  1. mount -o remount,ro / выдает target is busy, так как фоновые процессы (Telegram, systemd, shell) держат файлы открытыми.
  2. Массовое убийство процессов (killall5, fuser) часто приводит к зависанию или перезапуску сессии.
  3. Использование umount -l / (lazy unmount) отвязывает корень, но мгновенно делает недоступными все бинарные файлы (sudo, e2fsck, mount), так как они находятся в /nix/store, который теперь отмонтирован.

💡 Вывод: Чинить корневую ФС из-под работающей на ней системы — это как менять двигатель на ходу. Единственный надежный путь — внешнее вмешательство.


🛠 Решение: Внешнее восстановление

Для безопасного ремонта диск должен быть подключен к другой системе (второй ПК или LiveUSB), где он не является корневым.

Шаг 1: Принудительная проверка и ремонт

Подключи диск к другому ПК или загрузись с Live-носителя (GParted Live, Ubuntu, Arch).

  1. Определи поврежденный раздел:

    lsblk -f
    

    Найди раздел с нужным UUID (например, /dev/sda2 или /dev/nvme0n1p2).

  2. Запусти агрессивную проверку (для ext4):

    sudo e2fsck -y -f /dev/sdXn
    
    • -y: автоматически отвечать «yes» на все исправления.
    • -f: принудительная проверка, даже если ФС помечена как «clean».
  3. Если проверка падает или не находит суперблок: Восстанови из резервной копии (стандартные резервные блоки: 32768, 98304, 163840):

    sudo e2fsck -b 32768 -y /dev/sdXn
    
  4. Для Btrfs:

    sudo btrfs check --repair /dev/sdXn
    

🔧 Шаг 2: Возврат в систему и проверка Nix Store

После успешного e2fsck физическая целостность диска восстановлена. Однако логическая структура /nix/store (особенно таблица хардлинков .links) могла быть повреждена во время сбоя.

Загрузись в свою NixOS без параметра fsck.mode=skip.

1. Проверка и восстановление хешей store

Эта команда проверит все пути в store и автоматически перекачает/пересоберет поврежденные из кэша:

sudo nix-store --verify --check-contents --repair

⚠️ Если команда выдает ошибку Bad message на файлах в /nix/store/.links/, значит, таблица хардлинков уничтожена. Перейди к шагу 2.

2. Принудительная перестройка store (если шаг 1 не помог)

Если .links повреждены, заставь Nix пересоздать их с нуля:

# Удаляем битые хардлинки (используем find, чтобы избежать "Argument list too long")
sudo find /nix/store/.links -mindepth 1 -delete

# Пересоздаем оптимизацию
sudo nix-store --optimise

3. Восстановление системных ссылок

Пересоздай /run/current-system и обнови загрузчик, используя только валидные пути:

sudo nixos-rebuild boot --repair

4. Очистка мусора

Удали старые поколения и битые ссылки, чтобы освободить место и закрепить результат:

sudo nix-collect-garbage -d

⚠️ Частые проблемы и решения

СимптомПричинаРешение
target is busy при remount,roПроцессы держат файлы в /Не борись с этим. Используй LiveUSB/другой ПК.
command not found после umount -l /Корень отмонтирован, PATH потерянЭто ожидаемо. Жестко перезагрузись (reboot -f) и чини извне.
Bad message в /nix/store/.links/Повреждена таблица хардлинков ext4Выполни find /nix/store/.links -mindepth 1 -delete + nix-store --optimise.
Система снова падает в RO при загрузкеe2fsck не был запущен с -f или повреждения критическиеПовтори Шаг 1 с флагом -b 32768 (восстановление суперблока).

Ссылки