Доводилось ли вам раскупоривать системник с Linux, который не грузится ни в какую – даже после того, как вы убедились в корректности настроек BIOS и в том, что никаких серьёзных аппаратных ошибок в машине нет?
Если да – то вам просто необходимо изучить chroot. Он станет для вас настоящей палочкой-выручалочкой.
Например, мне пару недель назад удалось таким методом восстановить устройство Nanopore GridION, после того, как мне совершенно не помог официальный метод переустановки через .iso-файл образа. Поэтому я решил задокументировать проделанные шаги.
Этот метод я нащупал только после того, как Linux более десяти лет был моей рабочей лошадкой (спасибо, Мэтт !). Поэтому у меня есть основания полагать, что этот метод очень полезен и заслуживает вашего внимания. Надеюсь, этим постом мне удастся помочь тем, кому не доставало такого рассказа.
TLDR
Вкратце, идея такова: если вы можете получить доступ к жёсткому диску неисправной машины с Linux, которая сломана или не загружается (для этого, например, используют загрузочные флешки или подключают неисправный диск в качестве внешнего к другой машине, на которой установлен Linux), то монтировать этот диск нужно особым образом. Ваша задача – перехитрить Linux в рамках текущего сеанса и заставить машину поверить, что это жёсткий диск с установленной на ней исправной операционной системой – что, конечно же, не так.
Чтобы провернуть такой фокус, нужно создать дерево файлов, в основе которого будут:
Сегмент повреждённого жёсткого диска, cмонтированный с операционной системой хоста как каталог /.
Набор специальных системных каталогов с работающей в данный момент операционной системой, которую мы будем считать временной (речь о загрузочной флешке или подставном компьютере). Это не обычные каталоги с диска, в них содержится лишь системная информация, необходимая для работы системе с Linux, действующей в настоящий момент. Среди них —
/sys,/procи некоторые другие, которые мы подробно обсудим ниже.
Вот что потребуется сделать дальше: применим команду chroot к этой новоиспечённой структуре каталогов. Таким образом, в рамках действующего у вас сейчас сеанса Linux можно будет заменить актуальную файловую систему на набор каталогов, в основном взятых со старого неисправного жёсткого диска.
Представьте себе, что подключаете неисправный автомобиль к внешнему источнику питания, так, чтобы в нём хотя бы можно было включить приборы, проверить пробег, вывести на щиток коды ошибок и просмотреть их и т.д.
В любом случае, действуя так, вы сможете выполнять различные команды, с помощью которых (если повезёт) вы сможете починить или диагностировать вашу систему. Таковы, например, команды apt upgrade, dpkg-reconfigure для работы с повреждёнными пакетами в дистрибутивах на основе Debian или какие-то другие инструменты, в зависимости от специфики вашей системы.
Ход работы
Хорошо бы настроить в одном месте весь рабочий процесс, позволяющий и обустроить собранную вами структуру каталогов, и выполнить chroot — так, чтобы при необходимости всё это можно было легко найти. В идеале даже распечатайте маленькую шпаргалку со всеми этими командами или сохраните их в текстовом файле у вас на «реанимационной флешке» или т.п.
Ниже пошагово разберём весь процесс:
Загрузим операционную систему, которую выбрали в качестве замены (для этого нам понадобится загрузочная флешка или другой компьютер, к которому мы подключили неисправный жёсткий диск как внешний).
Определим, в каком сегменте жёсткого диска с повреждённой системой содержится корневая файловая система, а в каком — каталог /boot.
Для этого я обычно пользуюсь
gparted. Этот инструмент доступен на большинстве загрузочных дисков, работающих на основе Ubuntu/Linux Mint.Также можно воспользоваться инструментами командной строки, например,
sudo fdisk -lЯ обычно стараюсь монтировать каждый из сегментов повреждённой системы в навигатор файлов (обычно они отображаются в Thunar i Linux Mint XFCE как готовые к подключению диски), чтобы не сомневаться, что я действительно выбрал нужный сегмент.
Если вам это не удастся, то придётся немного гадать, исходя из размера и типа файловой системы — чтобы узнать, доступны ли уже эти сегменты в
/etc/fstabи т.д.В этом примере будем исходить из того, что корневой каталог находится в сегменте
/dev/nvme0n1p5… и что загрузочный сегмент /boot находится в:
/dev/nvme0n1p3(Именно так всё оказалось расположено на устройстве Nanopore GridION, которое мне недавно удалось отремонтировать таким способом).
3. Где-нибудь в файловой системе работающего у вас сейчас дистрибутива создаём каталог, который примет на себя функции корневого, а в нём — каталог /boot:
sudo mkdir /rescue
sudo mkdir /rescue/boot4. Монтируем главный и загрузочный разделы повреждённой системы в эти каталоги, например:
sudo mount /dev/nvme0n1p5 /rescue
sudo mount /dev/nvme0n1p3 /rescue/boot5. Затем монтируем необходимые специальные каталоги из той системы, что работает у вас сейчас, в соответствующие нужные точки новой файловой структуры (монтирующая команда mount имеет вид mount -t <file-system-type> -o <options> <device> <mount-point>)
sudo mount -t proc proc /rescue/proc
sudo mount -t sysfs sys /rescue/sys
sudo mount -o bind /dev /rescue/dev
sudo mount -t devpts pts /rescue/dev/pts6. Теперь мы готовы выполнить chroot, то есть «изменить корневой каталог», перенеся его в эту новоиспечённую структуру каталогов:
chroot /rescue /bin/bash -i7. Вот и всё!
Теперь можно осмотреться в файловой системе и попытаться выяснить, почему повреждённое устройство не работало. Можете пользоваться любыми командами для работы с файлами, которые, на ваш взгляд, помогут починить отказавшую систему.
В моём случае со сломанным устройством GridION удалось отыскать нерабочие символьные ссылки и пусты файлы initrd.img-* в каталоге /boot. Всё выглядело так, как будто обновление ядра Linux внезапно прервалось из-за вклинившегося процесса — например, из-за обновления какого-то пакета или т.п.
В данном случае проблему удалось исправить, выполнив sudo apt update && sudo apt upgrade. Система пожаловалась на повреждённые пакеты и предложила попробовать sudo dpkg-reconfigure, после чего всё окончательно наладилось.
