Эта задача является частным случаем использования задачи поиска установленной системы во время загрузки спасасательной системы. Ряд вопросов связанных с этим указан на странице Каким должен быть установщик системы, а также в обсуждении [Comm] Rescue в М2.4 и Ц3.0. Текущий алгоритм восстановления представлен на ряде ресурсов ( школьный линукс, центр свободного ПО в образовании, рассылка сообщества) и выглядит так:
Если вкратце это может прозвучать и так:
Такой подход волей не волей интересно увидеть, работающим в более адаптированном для пользователя виде. Основной компромисс, который решается выбором автоматического или полуавтоматического решения связан с выбором между возможностью быстро решить проблему и не получить «зависающей» консоли восстановления, в случае проблем на повреждённых файловых системах, которые эта консоль может попытаться подключить автоматически. Если Мастер 2.4 имел неосторожность восстановления с уклоном в пользу автоматического подключения, то, начиная с Компакта 3.0, этот режим сделан ручным. В Десктоп 4.0 сделана попытка полуавтоматического восстановления – для подключения дерева файловых систем, установленных на восстанавливаемом компьютере, имеется команда mount-system. Эта комада представляет собой скрипт проводящий поиск всех разделов с помощью средств evms и монтирующий деревья всех файловых систем по наличию файла fstab в найденном разделе. Деревья систем монтируются в каталоги /mnt/system1, /mnt/system2 и т.д.
Новый вариант (упомянут последний раз в рассылке Junior), который планируется ввести в следующем релизе школьного линукса, предполагает возможность сокращения рассмотренного алгоритма до вида:
В ТЗ на установщик ALT Linux уже прописан дополнительный метод загрузки восстановления консоли – «восстановление загрузчика системы (restore loader) – для восстановления загрузчика, запорченного другой системой». Кроме того новое решение уже решает большую часть проблем. Тем не менее вопрос о способе поиска и подключения разделов остаётся открытым. Рядовому пользователю, практически не реально в случае возникновения проблемы, самостоятельно найти нужную информацию по сети, хотя бы потому, что для этого нужно загрузить систему, а кроме того знать, что искать. В этом плане можно выделить следующие этапы решения проблемы:
В плане решения конкретных задач существует несколько уcтоявшихся проблем, автоматизация решения которых может оптимизирована:
Многие специфичнвые проблемы вызванные крахом файловой системы на отдельном или коневом разделах трудно поддаются автоматическому восстановлению, поскольку обычно связаны с необходимостью предварительного восстановления данных на повреждённых носителях.
Рассматривая решение первых двух проблем можно говорить о полностью автоматическом восстановлении только в случае «стандартно установленных систем». Выбор неверного раздела может повлечь за собой ещё больший ряд проблем. В связи с этим вариант ручного подхода к их решению оправдан. Тем не менее возможность упрощения работы по восстановлению можно найти, если свести список решаемых проблем к выбору из ряда вариантов. Для этого можно добавить:
Предполагается, что такой вариант может стать достаточным компромиссом между пользовательским удобством и безопасной загрузкой в минимальном режиме. Поскольку текущий полуавтоматический подход имеет ряд критичных моментов связанных с автоматическим сбором информации о системе после загрузки. Этот механизм стоит добавить в виде опционального варианта действия после загрузки, с возможностью выбора действия по перенесению его результата на внешний носитель. Это целесообразно поскольку этот механизм тоже может приводить к сбоям во время загрузки, что уже имело место быть на личном примере, во время проверки большого ntfs-раздела жёстком диске, подключенного через USB-rack.
Хочется отметить, что всё вышеописанное рассматривалось в основном для восстановления загрузчика lilo, который по умолчанию устанавливается в ALT Linux.