Описание проблемы
В статье «GRUB2: разговариваем с загрузчиком на языке загрузчика» мы рассмотрели ситуацию, когда операционная система на основе ядра Linux не стартует из-за того, что некорректная конфигурация загрузчика не позволяет ему найти ядро операционной системы и выполнить его загрузку. И пользуясь удобными интерактивными возможностями GRUB2, мы посмотрели, как можно восстановить систему, что называется, на месте.
Причина невозможности корректной загрузки системы вплоть до входа пользователя может быть в чем угодно, от поврежденных системных файлов до забытого пароля. Далеко не все эти проблемы можно решить на месте. В этой статье мы рассмотрим технику восстановления системы путем подключения жесткого диска с ней к другой, работоспособной системе.
Особенностью такого подхода является то, что мы находимся в контексте другой системы, — в этом есть как плюсы, так минусы. Плюсы в том, что мы вставили диск с восстанавливаемой системы в систему работоспособную, где мы обладаем привилегиями суперпользователя и, как следствие, можем выполнять любые необходимые нам действия по восстановлению, устанавливать и запускать необходимое диагностическое и «ремонтное» ПО. Минусом же является тот факт, что мы не находимся в контексте восстанавливаемой системы. То есть если мы попытаемся стандартными средствами поменять пароль пользователя, или изменить параметры автозагрузки служб, или перегенерировать конфигурацию загрузчика операционной системы, всё это будет действовать не в контексте восстанавливаемой системы, а в контексте рабочей системы.
Подготовка к переходу в контекст восстанавливаемой системы
В статье «Chroot: запуск существующего приложения в песочнице» мы рассмотрели использование команды chroot для запуска процесса в изолированной части файловой системы. Собственно, это и есть механизм получения необходимого нам контекста восстанавливаемой системы.
Итак, мы вставили диск восстанавливаемой системы в работоспособную систему, которую будем использовать как среду восстановления. Как вариант, в качестве среды восстановления можно использовать любую Live-систему, загружая ее с флешки, в этом случае диск никуда переставлять не надо.
Предполагается, что среда восстановления имеет подключение к сети и далее к интернету, то есть мы настроили в ней стек TCP/IP на сетевом интерфейсе и разрешение имен. Далее предполагаем, что среда восстановления имеет корректно настроенный конфигурационный файл библиотеки резолвера (/etc/resolv.conf), он нам понадобится потом и в контексте восстанавливаемой системы.
Для того чтобы выполняемые нами команды восстановления действовали в контексте восстанавливаемой системы, необходимо в первую очередь примонтировать корневой раздел восстанавливаемой системы, предполагаем, что это /dev/sdb1.
# mkdir /mnt/chroot
# mount /dev/sdb1 /mnt/chroot
Корень восстанавливаемой системы у нас подключен к каталогу /mnt/chroot, именно туда мы и будем переходить командой chroot. И именно там нам надо подготовить работоспособное окружение для дальнейшей работы.
Как мы договорились, у нас уже настроено сетевое взаимодействие в рамках среды восстановления. Если параметры сетевых интерфейсов перейдут с нами в chroot, то корректные настройки резолвера стоит скопировать в восстанавливаемую систему.
# cd /mnt/chroot/etc
# cp resolv.conf resolv.conf.orig
# cp -f /etc/resolv.conf ./
# cd -
Далее нам необходимо обеспечить наличие в восстанавливаемой системе каталога /dev со всеми специальными файлами устройств, соответствующих конфигурации системы, используемой для восстановления. Сделаем это через bind mount, то есть монтирование существующего каталога.
# mount --bind /dev /mnt/chroot/dev
Ряд утилит администрирования системы, например mdadm, привязывается к имени узла и вносит его в конфигурационные файлы, поэтому стоит установить на время восстановления hostname системы таким, каким он был у восстанавливаемой системы.
# hostname <origname>
Переход в контекст восстанавливаемой системы
При выполнении команды chroot удобно будет установить специфическое приглашение командного интерпретатора (переменная PS1), которое будет напоминать нам, что мы находимся в контексте восстанавливаемой системы. В качестве команды, которую мы будем выполнять средствами chroot, должен быть удобный вам для интерактивной работы командный интерпретатор.
# PS1 = “(IN-CHROOT) $PS1” chroot /mnt/chroot /bin/bash
Таким образом, мы получили сессию командного интерпретатора, запущенного в песочнице восстанавливаемой системы. Для полноценной работы по восстановлению необходимо сделать еще несколько подготовительных шагов, а именно подцепить псевдофайловые системы procfs, sysfs и devpts.
# mount -t procfs /proc
# mount -t sysfs /sys
# mount -t devpts /dev/pts
Наличие самого каталога /dev/ со специальными файлами устройств, соответствующих среде восстановления, мы обеспечили еще на подготовительном этапе.
Восстанавливаем и возвращаемся назад
Это всё, можно переходить, собственно, к действиям по восстановлению, которые, естественно, зависят от конкретной поломки или того, что вы хотите исправить.
По завершении действий по восстановлению надо выйти из chroot, корректно отмонтировав всё, что предварительно подключали, вернув собственный /etc/resolv.conf в восстанавливаемой системе:
# cp -f /etc/resolv.conf.orig /etc/resolv.conf
# umount /sys
# umount /dev/pts
# umount /proc
# exit
Всё, мы вернулись из chroot. Теперь необходимо вернуть измененный ранее hostname, отмонтировать каталог /dev восстанавливаемой системы и ее корневой каталог, удалить временную точку монтирования.
# hostname orig-name
# umount /mnt/chroot/dev
# umount /mnt/chroot
# rmdir /mnt/chroot
Если какие-нибудь из приведенных команд отмонтирования не выполняются по причине того, что оказываются открыты файлы на монтируемых ветках, можно либо завершить блокирующий процесс, определив его утилитой lsof, либо использовать опцию -l — ленивого отмонтирования команды umount.
Итак, тем самым мы рассмотрели действия, необходимые для организации восстановления системы, используя стороннюю работоспособную систему как среду восстановления.
