Восстановление Linux: Live USB, chroot и проверка файловой системы
Автор: Казачкин Даниил Михайлович · Обновлено
Восстановление начинают с сохранения данных и точного описания отказа: не запускается firmware, загрузчик, ядро или служба после монтирования корня. Эти этапы требуют разных действий. Следующий маршрут предназначен для собственной учебной VM со снимком и доступом к консоли; имена устройств нужно получить из её состояния.
Сохранить рабочий путь загрузки
После обновления ядра попробуйте предыдущую установленную версию через меню загрузчика. Если она работает, сохраните uname -r, журнал неудачной загрузки и состояние /boot. Не удаляйте рабочее ядро до проверки нового. Отсутствующий драйвер в initramfs, неверный root UUID и заполненный boot-раздел выглядят по-разному; сообщение «не найден корень» ещё не указывает, какой компонент виноват.
При emergency mode прочитайте journalctl -xb, systemctl --failed и сопоставьте /etc/fstab с lsblk -f и blkid. Ошибка UUID дополнительного диска может остановить загрузку. Для действительно необязательного тома применим nofail; добавлять его ко всем строкам вместо исправления причины нельзя. Проверка findmnt --verify --verbose помогает обнаружить проблемы конфигурации, но не заменяет реальную проверку устройства.
Live USB и правильный корень
Загрузите Live-систему в том же режиме UEFI/BIOS, который использует установленная ОС. Сначала lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINTS и findmnt: определите установленный корень, отдельный /boot и EFI System Partition. Для LUKS сначала нужен собственный ключ и штатное открытие тома, для LVM — доступ к правильной группе томов. Смена пароля пользователя не расшифровывает LUKS.
На VM после определения устройств смонтируйте установленный корень в /mnt, затем его отдельные boot-разделы по штатным путям. Далее подключите служебные деревья:
sudo mount --rbind /dev /mnt/dev
sudo mount --make-rslave /mnt/dev
sudo mount -t proc proc /mnt/proc
sudo mount --rbind /sys /mnt/sys
sudo mount --make-rslave /mnt/sys
sudo mount --rbind /run /mnt/run
sudo mount --make-rslave /mnt/run
sudo chroot /mnt /bin/bashКаталоги назначения должны существовать. --make-rslave снижает риск распространения последующего размонтирования через shared mounts. Внутри chroot проверьте /etc/os-release и содержимое /boot: вы должны увидеть установленную систему. Chroot меняет корень процесса, но использует ядро Live-среды; uname -r не выбирает автоматически ядро, для которого надо собирать initramfs. Для сетевой установки пакетов отдельно проверьте DNS, включая ссылку resolv.conf.
Исправление с проверкой
В Debian/Ubuntu dpkg --audit показывает незавершённые состояния, dpkg --configure -a завершает настройку уже распакованных пакетов. Следующий apt-get -f install может изменить набор пакетов: сначала прочитайте план и источник репозитория. Не удаляйте lock-файлы при работающем пакетном менеджере.
Для конкретного установленного ядра используйте update-initramfs -u -k ВЕРСИЯ, проверив каталог /lib/modules/ВЕРСИЯ, затем update-grub в системе с GRUB. Версию берут из установленной системы, а не из uname Live USB. update-initramfs.
Переустановка самого GRUB зависит от архитектуры и режима firmware. Для x86_64 UEFI требуется смонтированный ESP и EFI-вариант grub-install; для BIOS на GPT — соответствующий BIOS boot partition и установка в выбранный целый диск. Secure Boot может требовать штатного подписанного пакета shim. Универсальная команда с /dev/sda здесь опасна. Зафиксируйте точную команду по схеме своей VM, выполните её, обновите конфигурацию и проверьте загрузку без Live-носителя. Руководство GRUB.
Для восстановления пароля собственной Ubuntu в правильном chroot выполните passwd имя_администратора. Учтите обычную блокировку root по умолчанию: менять пароль администратора и включать вход root — разные решения. На системах с SELinux проверяют необходимость восстановления меток после изменений.
Read-only и проверка ext4
Если ядро перевело файловую систему в read-only после ошибок, сначала сохраните сообщения и оцените состояние носителя. Принудительный remount,rw может продолжить повреждение. Проверку ext4 проводят на размонтированном томе; для XFS и Btrfs используются другие средства.
Без реальных дисков можно изучить чистый файловый образ:
fs_lab=$(mktemp -d)
truncate -s 32M "$fs_lab/disk.img"
mkfs.ext4 -q -F "$fs_lab/disk.img"
e2fsck -fn "$fs_lab/disk.img"Образ не монтируется, а -n запрещает исправления. Ожидается успешная проверка нового образа. На настоящей аварии коды e2fsck различают исправление, необходимость перезагрузки и неисправленные ошибки; нулём нельзя подменять любой завершившийся запуск. Ограничения e2fsck.
Удалённый, но ещё открытый обычный файл иногда удаётся скопировать из /proc/PID/fd/FD в другое место. Сначала проверьте тип, размер и владельца дескриптора; чтение pipe или сокета не является восстановлением файла. Программа может продолжать менять данные. Не завершайте её до копирования, а после сохранения проверьте содержимое. Это временная возможность, не стратегия бэкапа.
Задание: составьте план для двух отказов — ошибочный UUID в fstab и отсутствующий драйвер в initramfs. Укажите, что сохраняете перед изменением и какое наблюдение после перезагрузки подтвердит исправление. Завершая chroot, выйдите из shell и размонтируйте только подключённые деревья в обратном порядке, убедившись, что они не заняты.
Если удалён целый каталог
Прекратите запись на затронутую файловую систему и проверьте независимый бэкап или snapshot. Не устанавливайте утилиту восстановления на тот же том: новые данные могут занять освобождённые блоки. Для дальнейшего исследования делают образ и работают с копией; успех зависит от файловой системы, перезаписи и TRIM. Восстановление одного открытого файла через /proc/PID/fd не восстанавливает автоматически имена, структуру и содержимое удалённого дерева. Если доступна резервная копия, извлеките каталог в отдельное место и проверьте его до возврата приложению. Гарантировать восстановление удалённого каталога одной командой нельзя.