Восстановление системы линукс роса
Обновлено: 03.07.2024
Дистрибутив Linux является динамично развивающейся средой, постоянно получающей большие пласты обновлений. Обновления призваны привнести в систему улучшения и новый функционал, однако иногда они имеют обратный эффект, ломая что-то работающее и вызывая недовольство пользователей. Кроме того, многие члены сообщества – это энтузиасты, которых постоянно тянет попробовать что-то новое.
Например, всевозможные программы из различных источников, которые не имеют прямого отношения к дистрибутиву. Рано или поздно программы могут вступить в конфликт с приложениями и политиками ОС и привести систему (по крайней мере частично) в нерабочее состояние.
Как результат, для многих пользователей актуальным вопросом является автоматический возврат поломанной системы в рабочее состояние.
Видео
Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.
Слайды
Расширенные тезисы
Инструменты уровня пакетов
Поскольку в Росе, как и в большинстве дистрибутивов Linux, установка, удаление и обновление программ сводится к манипуляции с пакетами, то и откат действий по управлению ПО логично осуществлять на уровне пакетов — то есть если с обновленным пакетом что-то не так, то надо откатиться на предыдущую версию. На практике такой подход сталкивается с двумя проблемами — во-первых, пользователь не всегда может однозначно идентифицировать пакет, который привел к сбою, а во-вторых — надо где-то взять старую версию пакета, ведь в официальных источниках (если они использовались для обновления) она уже заменена новой. Если проблемы вызваны пакетами из сторонних репозиториев, то на помощь может прийти инструмент urpm-reposync (аналог reposync из Fedora), способный привести состояние пакетной базы системы в соответствие с подключенными репозиториями — в частности, удалить пакеты, в этих репозиториях отсутствующие, а для имеющихся пакетов обновить или откатить их до официальных версий.
Urpm-reposync обладает некоторой гибкостью (в частности, позволяет не удалять «лишние» пакеты, если их зависимости по-прежнему будут присутствовать в системе после синхронизации с репозиториями), однако в целом является достаточно тяжеловесным инструментом. С его помощью можно провести синхронизацию всех пакетов, установленных в системе, но нельзя откатить конкретные обновления.
Более избирательным является urpmi.recover, работающий на уровне транзакций rpm. Этот инструмент позволяет производить откат пакетной базы по датам или транзакциям — можно откатить заданное число транзакций либо все транзакции до определенной даты.
Алгоритм работы инструмента прост — при удалении или обновлении пакетов делается резервная копия удаляемой/обновляемой версии пакета, которая и устанавливается в систему при откате. Отметим, что откатывать транзакции выборочно инструмент не позволяет, однако при сильном желании можно попробовать сделать такой откат вручную с помощью rpm — ведь старые версии пакетов доступны в кэше urpmi.recover.
Полной гарантии успешности отката urpmi.recover дать не может — ведь мэйнтейнеры далеко не всегда задумываются о том, что их пакеты могут не только обновляться, но и откатываться к предыдущим версиям.
Соответственно после отката можно ожидать «сюрпризов» в виде неожиданной отработки post-скриптов или некорректного изменения конфигурационных файлов, входящих в пакет. Тем не менее, urpmi.recover снискал популярность у тестировщиков РОСЫ, поскольку позволяет откатывать тестовые версии пакетов проще и быстрее, чем urpm-reposync.
Инструменты уровня файловой системы
Как бы ни привлекательно выглядел откат изменений на уровне пакетов, полностью гарантировать возврат системы в работоспособное состояние он не может. Во-первых, этому может воспрепятствовать специфика пакетов (например, мэйнтейнеры не проработали удаление или откат пакета до предыдущей версии), а во-вторых — ошибки в системе могли появиться и не из-за пакетов, а просто из-за некорректных действий пользователя. Традиционным способом возврата системы в рабочее состояние в таких ситуациях является использование резервных копий.
Сценарии использования систем резервного копирования подразумевают, что «плохие» ситуации в ОС происходят относительно редко, и откат ОС к предыдущему состоянию осуществляется только при выявлении подобных ситуаций. Однако в жизни бывают и другие сценарии, когда с большой вероятностью все действия пользователя в рамках текущей сессии необходимо будет откатить. Такие ситуации нередко встречаются на предприятиях, когда сотрудникам при загрузке машины предоставляется некоторая фиксированная система, которая при выключении машины или перезагрузке возвращается в исходное состояние (возможно, за исключением домашних папок сотрудников и других мест, где они могут сохранять результаты своей работы).
Нередко подобные схемы работы реализуются с помощью виртуальных машин — например, после выключения виртуальной машины можно откатывать ее к заранее сделанному снимку, а домашние директории пользователей монтировать с удаленных ресурсов. Однако Linux предоставляет средства для реализации более легковесных решений, не требующих больших накладных расходов (как в случае виртуализации) и вполне подходящих для домашнего использования.
Подобное решение — ROSA Freeze — мы реализовали в Росе. При использовании ROSA Freeze, ОС может работать в двух режимах — обычном и режиме «заморозки». При использовании последнего поверх всех системных директорий верхнего уровня (/bin, /etc, /usr и так далее; список может быть скорректирован администратором) с помощью aufs монтируются директории-«перехватчики», находящиеся в tmpfs либо на отдельном разделе жесткого диска.
Любые изменения, вносимые в «замороженные» директории, реально попадают в директории-«перехватчики», а содержимое оригинальных директорий остается неизменным. При перезагрузке машины все содержимое этих перехватчиков удаляется и системные ди- ректории возвращаются в первоначальное состояние. При этом после перезагрузки система продолжает оставаться в замороженном состоянии — выход из этого режима надо производить явно. Предусмотрена возможность переноса всех изменений из aufs, сделанных в рамках текущей сессии, в оригинальные директории. Инструмент ROSA Freeze очень молодой, однако уже готов к использованию. В настоящее время инструмент рассчитан на работу в схеме, когда все замораживаемые директории находятся на одном и том же разделе жесткого диска. В будущем мы планируем добавить поддержку заморозки директорий на разных разделах, а также реализовать в рамках ROSA Freeze механизма точек восстановления — ведь используемые подход с aufs позволяет нам автоматически получать инкрементальные различия между состояниями системы, остается только реализовать средства сохранения таких различий на диск и отката к ним.
1. Загрузиться с установочного носителя РОСА (диск, флэшка).
2. В Konsole стать главным:
3. В Konsole уточнить где установлена РОСА:
При наличии установленных, но не обнаруженных с первого раза систем,
повторить пункты 2-4 в установленной РОСА. A13:
пробовал дальше "работать" с загрузчиком Росы через Меню настроек и наконец я его заломал напрочь - не грузится ни одна моя система. Пробовал снова воспользоваться Вашим советом (см. выше), но потерпел неудачу:
Я пробовал ставить загрузчик Росы в MBR и это, видимо, его и доконало. Помог Паппи линукс и его Grub4Dos, установленный на флешку, то есть теперь системы у меня на HDD, а загрузчик на флешке. И снова вопрос: как можно теперь восстановить загрузку систем с HDD? Спасибо. А что он у вас на ntfs жалуется? вы пытаетесь поставить Гроб2 на раздел с ntfs?
Найден Windows 7 (loader) на /dev/sda1
Наш grub2 лучше все-таки ставить в MBR, а для этого надо использовать "sda", а не "sda1":
grub2-install --root-directory=/mnt/ /dev/sda
d_uragan писал(а): Наш grub2 лучше все-таки ставить в MBR, а для этого надо использовать "sda", а не "sda1":grub2-install --root-directory=/mnt/ /dev/sda Mikele1299 писал(а): Я пробовал ставить загрузчик Росы в MBR и это, видимо, его и доконало. Я пробовал ставить загрузчик Росы в MBR через Загрузку и завершение и вот после этого и случилось то, что вы видите выше. Grub4Dos, который Паппи Линукса, после первоначальной установки Винды и на её же раздел нескольких Паппи (просто как обычные папки с файлами) прекрасно ставится на раздел NTFS и я так часто делал. Но вот после попытки установить загрузчик Росы в MBR теперь и Grub4Dos не хочет ставиться на NTFS и сам загрузчик через консоль тоже ругается. Попробую поставить через консоль на раздел sda, без 1.
Вот поставил через консоль прямо на раздел sda, сейчас перезагружусь и посмотрю что будет.
Вроде-бы как загрузчик установился, но нет ни одной записи. Попробовал ставить загрузчик Росы на чистую флешку FAT32 и Ext3 - ответ один:
А Grub4Dos Паппи ставится на такие флешки без проблем и видит и Винду, и Росу, и Калькулейт. Пока загружаюсь через флешку, но все-таки хотелось бы восстановить родной загрузчик Росы. Спасибо.
Читайте также: