Воззрения кота Manual’а на Systemback

Алексей Федорчук

manul-logo-100

Версия актуальная, сильно расширенная.

На этой странице кот Мануал излагает свои воззрения на то, как устанавливать и настраивать Systemback, изготавливать с его помощью образы кастомизированных систем, и устанавливать эти системы с собственных образов.

Вступление

Разработка и поддержка Systemback автором закончены — последняя версия его предназначена для Ubuntu 16.10 и систем на её базе. И мы с Мануалом некоторое время думали, стоит ли городить огород ради программы, брошенной разработчиком. Однако оказалось, что этот самый, крайний, Systemback прекрасно работает в тестовых сборках грядущей Ubuntu 18.04, которая будет иметь статус «долгоиграющей». Тому свидетельством — как наша прикидочная сборка Cintu 18.04, так и сборка Matuntu-B64, выполненная Татьяной Ивановой aka vita.

Более чем вероятно, что и в релизе Ubuntu 18.04 Bionic Beaver LTS, которым нам угрожают в апреле, Systemback будет отличаться столь же примерным поведением. Чем обеспечит нам возможность изготавливать при его посредстве образы Cintu ещё пять грядущих лет. А за пять лет, как говаривал Ходжа Насреддин, многое может случиться…

Так что мы с Мануалом решили обобщить всё нами написанное по заданной теме — ибо Systemback кажется нам самой подходящей (для наших целей и задач) системой ремастеринга. И, к тому же, самой простой в обращении. К тому же мы с Мануалом не теряем надежды, что кто-нибудь подхватит знамя, выпавшее из рук её разработчика, Кенде Криштиана, и продолжит его скорбный труд.

А пока мы с Мануалом хотели бы выразить свою признательность Татьяне Ивановой aka vita и всем участникам форума Matuntu: обсуждение на нём Systemback’а и позволило создать этот обобщающий материал.

Systemback: обзор

В первой, обзорной, части даются общие сведения о программе Systemback, её получении, установке, запуске и настройке.

О нём

Программа Systemback — многоцелевого назначения. Как следует из названия, теоретически она предназначается в первую очередь для резервного копирования пользовательской системы, включая все установленные приложения и индивидуальные настройки, как общесистемные, так и пользовательские. И действительно, Systemback прекрасно справляется с этой задачей, позволяя как легко и быстро сделать бэкап системы, так и восстановить её в неизменном виде в случае какого-либо сбоя или перехода на другую машину, например. Однако этим функции Systemback’а не исчерпываются, как можно видеть из скриншота главного окна программы:

Так, лёгкое нажатие на экранную кнопку Обновление системы вызывает, без дополнительных вопросов, выполнение связки команд:

$ sudo apt update && sudo apt upgrade

Есть возможность осуществить Ремонт системы, в том числе восстановить или переустановить загрузчик GRUB 2:

Имеется и функция создания снапшотов (т.н. точек восстановления): в случае сбоев системы или её повреждения с их помощью можно «откатить» её до последнего удовлетворительного состояния.

Однако всё перечисленное можно выполнить и другими средствами, подчас более удачными. Так, обновление обновление системы мы м Мануалом выполняем с помощью комплексной утилиты сопровождения системы CareSystem Core, о которой будет говориться в соответствующем месте. Для ремонтно-восстановительных и аварийно-спасательных работ у нас тоже есть привычные средства (например, GRUB Customizer — для восстановления или переустановки загрузчика), и так далее.

Ввиду всего сказанного для нас с Мануалом самыми востребованными функциями Systemback’а являются Создание системы Live и последующая Установка системы с созданного образа. Образ, кстати, создаётся в собственном формате image_name.sblive, который средствами самой программы может быть записан непосредственно на флешку и SD-карту. С одного из этих носителей и можно загрузить Live-сессию. А уже из неё запускается Systemback для установки. Впрочем, для обладателей оптических приводов (и любителей возиться с соответствующими носителями) созданный образ можно трансформировать в стандартный ISO-9660.

Именно описанию процессов создания образа и установки с него системы и будут посвящены основные разделы настоящих «Воззрений» — вопросам резервного копирования и ремонта мы с Мануалом коснёмся вскользь. Однако прежде чем как-то применять Systemback, необходимо его как-то заполучить, установить и настроить.

Получение и установка

Программа Systemback до недавнего времени разрабатывалась Кенде Криштианом (Kende Krisztián), известным в Сети как Kendek. В скобках замечу, что он — венгр, и поэтому Kende — это его фамилия, а Krisztián — имя. Собранные им пакеты можно найти в его PPA-репозитории:

Можно видеть, что последняя поддерживаемая здесь версия предназначена для Ubuntu 16.10. После чего в апреле 2017 года Криштиан объявил о прекращении разработки Systemback’а, объяснив это тем, что у него много других дел. Что, разумеется, печально, но (пока?) не смертельно. Ибо, во-первых, до конца поддержки Ubuntu 16.04 LTS остаётся около лет, и всё это время системы на её базе можно использовать.

Во-вторых, практика показала, что репозиторий Kendek’а благополучно подключается к системам на базе Ubuntu 17.10. После чего текущая версия программы, за номером 1.8.402, предназначенная для Yakkety, устанавливается и прекрасно работает — именно с её помощью мы с Мануалом собрали оба последних релиза нашей любимой системы — cintu-1710-gw34 и cintu-1710-gw36.

В-третьих, как говорилось во Вступлении, неожиданно оказалось, что та же самая версия Systemback’а для Yakkety отлично справляется и с тестируемыми в настоящее время сборками грядущей в апреле Ubuntu 18.04 LTS. Что продлевает срок актуальности Systemback’а до весны 2023 года.

Наконец, остаётся ещё и в-четвёртых: надежда на то, что кто-нибудь либо подхватит брошенную Криштианом разработку, либо создаст клон этой программы. Как пишет автор, Systemback написан на C++ и создавался с помощью стандартного инструмента Qt Creator. Так что ничего сверхъестественного в такой надежде нет. Ведь имеем же мы пример Remastersys’а, также давно заброшенного автором, но, с одной стороны, поддерживаемого Алексеем Бухаловым aka BaaTLT, а с другой — породившего серию форков и клонов.

Однако пока мы продолжим разговор об оригинальном Systemback’е. Содержащий его репозиторий подключается стандартными командами:

$ sudo -s
# add-apt-repository ppa:nemh/systemback
# apt update

Этого достаточно для Ubuntu’идов на базе официально поддерживаемых релизов, например, 16.04 LTS. А для, скажем, систем на базе Artful’а, вроде нашей Cintu, перед обновлением кеша пакетов нужно отредактировать файл/etc/apt/sources.list.d/nemh-ubuntu-systemback-artful.list: заменить в нём значения artful на yakkety. Да и сам файл желательно (хотя и не обязательно) переименовать в nemh-ubuntu-systemback-yakkety.list. И уже только потом выполнять апдейт системы.

В любом случае сам пакет устанавливается столь же стандартно:

# apt install systemback
# exit

После чего Systemback готов к использованию.

Запуск и настройка

Запускается Systemback из главного меню текущего десктопа. Например, в среде Cinnamon он попадает в секцию Администрирование. А в Cintu мы с Мануалом вынесли пиктограммку его запуска на панель Избранное:

В любом случае, появляется главное окно программы, приведённое ранее на первом скриншоте. Кстати, после запуска Systemback блокирует доступ к файлу /var/lib/apt/lists/lock. И, следовательно, в это время невозможно манипулировать пакетами любым способом. При обращении к dpkg, apt или Synaptic такая попытка вызовет соответствующее сообщение. А вот Центр приложений не сообщит нам ничего: он будет делать вид, что устанавливает что-то — разумеется, без всякого результата.

Однако вернёмся к главному окну Systemback’а. Язык его интерфейса определяется текущей локалью. Все описания в данном мануале выполнены на примере Cintu 17.10. И поэтому в нашем случае он по умолчанию будет русским. Что, с одной стороны, хорошо. А с другой — не всегда хорошо. В частности, после создания образа Live-системы меню его загрузчика будет дано не русскими буквами, а кракозябрами. Не страшно, конечно — но не эстетично. И потому, прежде, чем что-то делать в Systemback’е, хорошо бы выполнить некоторые настройки (хотя и не обязательно). Переход к которым осуществляется нажатием кнопки с зелёным уголком «вправо»:

В этом окне первые две кнопки имеют отношение к резервному копированию, и нас сейчас не волнуют. А требуется нам в данный момент только кнопка Настройки, вызывающая следующее окно:

Во избежание упомянутых кракозябров в меню загрузчика будущей Live-системы здесь нужно отменить автоматическое определение языка, заменив его, например, «общеанглийским» — English (common):

Далее, почти во всех случаях целесообразно включить пункт Использовать сжатие XZ…. Ведь нынче машину с одноядерным процессором можно найти либо в лавке старьёвщика, либо, напротив, в бутике эстетствующего антиквара. А при процессоре с двумя и более ядрами (включая «гипертрейдинговые») алгоритм XZ даёт супротив умолчального gzip выигрыш в скорости, почти кратный числу потоков.

Наконец, если реально на выходе Live-системы требуется iso-образ, имеет резон включить его автоматическое создание. Это действительно быстрее, чем генерация его потом, из образа *.sblive. И в результате настроечное окно приобретёт такой вид:

Сделанные изменения в настройках (в частности, смена языка интерфейса) вступят в силу при следующем запуске программы. Однако перед её рестартом можно (и нужно) сделать ещё одну вещь — определить файлы и каталоги, исключаемые из будущего образа. Для чего — нажать кнопку Назад, потом — кнопку с зелёным уголком «влево», а затем выбрать кнопку Исключить, которая вызовет такое окно:

Что именно надо исключить из будущего образа — каждый сообразит в меру своей паранойи, так что мы с Мануалом распространяться на эту тему не будем. А завершим работу программы:

И запустим Systemback повторно, уже с англоязычным интерфейсом:

Который, однако, не помешает нам ни создавать образы системы, ни устанавливать систему с этих образов.

Разумеется, прежде чем устанавливать систему с образа, последний надо создать. И поэтому в следующем разделе мы поглядим, как это делается. Читатели, которые не планируют создавать собственные образы (или те, кому срочно требуется только установка), могут спокойно «перепрыгнуть» через него.

Systemback для ремастеринга

Злые люди говорят — чтобы сварить суп из курицы, надо как минимум иметь кошку. С Systemback’ом это не прокатит — для установки системы его посредством нужно обязательно иметь именно курицы установочный образ, созданный средствами Systemback’а же. Однако перед этой процедурой нужно выполнить некоторые

Подготовительные действия

Вся сила Systemback’а в… нет, не в гемоглобине. А в том, что он позволяет легко и просто изготовить образ идеальной (для себя) системы, пригодный к переносу на другие свои машины. А также — для распространения своих родных, друзей и просто коллег, вкусы которых в отношении настроек и набора софта.

Так что для начала нам потребуется установленная, настроенная и должным образом укомплектованная по части пакетов система — предположим, ею будет Cintu со средой Cinnamon и всеми необходимыми приложениями. Разумеется, в этой не обойтись и без Systemback’а — он будет присутствовать здесь по умолчанию, причём с русскоязычным интерфейсом. В случае более иного дистрибутива (но обязательно основанного на Ubuntu) Systemback должен быть установлен и настроен, как было описано в предыдущем разделе.

Однако в Cintu мы его просто запускаем, пока русскоязычный:

Язык интерфейса заменяем на английский, заодно включив XZ-сжатие и автоматическое создание ISO-образа в дополнение к образу *.sblive для записи на флешку:

Однако торопиться с перезапуском не будем. Ибо мы с Мануалом взяли за правило: перед использованием любой системы ремастеринга выполнить обновление системы и очистку её от продуктов жизнедеятельности. Первое деяние, как уже говорилось, можно выполнить и непосредственно из Systemback’а. А второе требует запуска пары команд:

$ sudo apt autoremove && sudo apt clean

Однако оба их можно свершить с помощью универсальной утилиты сопровождения системы ucaresystem-core, которой посвящена следующая интермедия.

Интермедия: утилита uCareSystem Core

Повседневные задачи по сопровождению настольной системы включают в себя проверку обновлений пакетов и, при их наличии, установку оных, а также очистку системы от отходов жизнедеятельности («осиротелых» зависимостей, конфигов удалённых пакетов, и так далее). Действия эти выполняются или вручную, командами соответствующего назначения, или наборами утилит, специфичных для отдельных дистрибутивов (такими славится Linux Mint и LMDE), или комплексными утилитами, ориентированными на семейства родственных дистрибутивов, например, Ubuntu.

К числу последних принадлежит и героиня данного очерка — uCareSystem Core. Это — запускаемый из командной строки сценарий оболочки, который обновляет локальный кэш пакетов, скачивает и устанавливает обновления, удаляет старые ядра, «заброшенные» пакеты и конфиги. И проделывает всё это автоматически, без вмешательства применителя, однако абсолютно прозрачно и понятно для него.

Узнав об утилите ucaresystem-core с подачи старого своего товарища Владимира Попова (за что, пользуясь случаем, выражаю ему свою признательность), я начал применять её в повседневной жизни. И в конце концов мы с Мануалом штатно включили её во все релизы и редакции Cintu.

В официальном репозитории Ubuntu утилиты ucaresystem-core нет, она имеет место быть в собственном PPA-репозитории. Подключается он обычным образом, и столь же обычно утилита из него устанавливается:

$ sudo -s
# add-apt-repository ppa:utappia/stable
# apt update
# apt install ucaresystem-core
# exit

После чего утилиту нужно запустить с правами администратора:

$ sudo ucaresystem-core

И затем в течении пяти секунд наблюдается следующая картина:

ucaresystem

А затем начинается работа сценария. Сначала обновляется локальный кеш пакетов, то есть, попросту говоря, выполняется команда apt update. Если в ходе этого были обнаружены обновлённые пакеты, то начинается

Чтение списков пакетов… Готово
Построение дерева зависимостей
Чтение информации о состоянии… Готово
Расчёт обновлений… Готово

После чего происходит обновление системы (то есть выполнение команды apt upgrade).

Далее система проверяется на предмет неиспользуемых пакетов, то есть «осиротелых» зависимостей. И при обнаружении таковых они удаляются — это работает команда apt autoremove.

Вслед за тем наступает время проверки системы с точки неиспользованных ядер. И если таковые обнаруживаются — удалению подлежат все, кроме активного и предпоследнего, вместе с сопутствующими компонентами (файлами initrd, System.map и так далее, а также соответствующими каталогами в /lib/modules/).

Следующий шаг — выявление и удаление конфигурационных файлов, оставшихся от удалённых пакетов. И завершается работа сценария очисткой системы от пакетов, скачанных в ходе их установки и обновления, то есть выполнение команды apt clean. Завершающееся сообщением об успехе этого предприятия:

#########################
          Done
#########################

Таким образом, утилита ucaresystem-core выполняет все нужные для поддержания целостности и чистоты системы манипуляции. И при этом не делает ничего лишнего, непонятного или, паче того, противоестественного. Что и позволяет рекомендовать её к повседневному употреблению.

Но, разумеется, применитель может использовать и любые другие средства аналогичного назначения, если они ему симпатичны и (или) привычны.

Создание образа

После обновления системы и её очистки мы в обязательном порядке перезагружаемся, дабы дабы запущенная система точно находилась в актуальном состоянии. И уже потом запускаем Systemback с серьёзными намерениями создать её образ:

Впрочем, тоже делаем это не сразу. А сначала самым внимательным образом проверяем «исключения», то есть Exclude. В отношение конфигов домашнего каталога принцип простой: исключению из образа подлежат те файлы и каталоги, которые могут содержать конфиденциальную информацию, а также те, которые генерируются автоматически при запуске конфигурируемой ими программы:

Ну что следует исключить из пользовательских данных домашнего каталога — вы знаете лучше меня. Нам с Мануалом исключать было нечего, потому как данные в своём $HOME мы не храним (пара файлов в каталоге ~/Pictuires — это нескучные обои рабочего стола):

Проверив исключения и вернувшись в главное окно программы, можно нажимать кнопку Live system create, чтобы оказаться в окне параметров будущего образа. Собственно, обязательный параметр здесь один — его имя. Например, cintu-1710-gw36-3, где cintu — собственное имя системы, 1710 — номер релиза базовой Ubuntu, gw36, означает, что эпонимическая среда Cinnamon взята из репозитория Гвендаля ле Бьена и представлена версией 3.6, ну а последняя цифра — номер конкретной сборки.

Кроме того, отметить боксик включения пользовательских файлов будет не лишним — иначе пропадут нескучные обои:

Можно, конечно, и переопределить целевой каталог, куда будут помещаться промежуточные результаты сборки образов и сами образы (по умолчанию /home). Однако мы с Мануалом очень не уверены, что это стоит делать.

Теперь можно нажимать кнопку Create new, после чего без всяких вопросов и подтверждений начнётся создание Live-системы. Которое через некоторое время завершится сообщением об успехе этого предприятия:

Время, которое займёт создание Live-системы, зависит от двух факторов — параметров сжатия и числа ядер процессора (точнее, потоков при поддержке им гипертрейдинга). Включение сжатия XZ размер образа более чем на 20%, но время его создания на однопроцессорной машине (например, в виртуалке с одним активным ядром) увеличивается в несколько раз по сравнению с умолчальной компрессией GZip. Однако на реальном «железе» в «многонитевой» конфигурации, напротив, процесс существенно ускоряется супротив последнего — почти пропорционально количеству потоков: архиватор XZ реально умеет распараллеливать задачи, и делает это очень хорошо.

В этом я убеждался неоднократно. Так, на моём десктопе с процессором i7-4790K (4 ядра, 8 потоков, тактовая частота от 4,0 до 4.4 Ггц) создание образа системы, занимающей 4,8 ГБ (той самой cintu-1710-gw36-3), продолжалось около 5 минут.

В результате в каталоге /home, кроме подкаталога Systemback (при нормальном завершении процедуры он должен быть пустым), образуется два файла, оба по 1,2 ГБ:

  • cintu-1710-gw36-3.iso — стандартный образ ISO 9660, и
  • cintu-1710-gw36-3.sblive — образ для записи на флешку или SD-карту.

Которые готовы к использованию

Запись на носитель

Что делать с первым из новообразованных файлов — понятно: это самый обычный образ ISO-9660. И его следует или «сболванить» на оптический носитель, или записать на внешний винчестер с эмуляцией OD, типа Zalman ZM-VE300. А вот второй образ нужно перенести на флешку, и сделать это можно только средствами самого Systemback’а. Да и то не сразу: если вставить флешку в USB-разъём сразу по завершении создания образов, она просто не опознается программой:

Лечится это, как оказалось, просто (спасибо Татьяне aka vita за подсказку): нужно просто нажать на кнопку с изображением зелёной «загогулины». Если этот способ покажется не надёжным — для успокоения можно, закрыв Systemback, подсоединить целевой накопитель (им может быть и SD-карта, подключаемая через кард-ридер с USB-интерфейсом), и запустить Sysytemback сызнова:

Теперь USB-накопитель не только виден в соответствующем фрейме окна программы, но кнопка Write to target оказывается активной. И нажатие на неё выводит сообщение о том, что устройство будет отформатировано (как можно будет увидеть потом — в файловой системе FAT32, и, разумеется, с потерей всего содержимого флешки, если оно имело место быть) с последующей записью образа Live-системы:

Сама по себе запись произойдёт почти мгновенно:

Однако, судя по всему, это будет лишь кеширование в оперативную память. Потому что потом начнётся процесс очистки кеша:

И вот он будет продолжаться чуть ли не дольше, чем запись ISO образа командами dd или cp. Однако и он закончится сообщением об успехе:

В чём желательно убедиться сразу, попытавшись загрузиться с новообразованного Live-носителя. Потому что тут гарантии успеха как раз нет: примерно с каждой третьей произвольной флешки у нас с Мануалом загрузиться не получалось. Почему — так и осталось покрыто мраком неизвестности.

Так что мы с котом, посоветовавшись, продолжаем обычно делать загрузочные флешки старыми добрыми способами, либо командой типа

$ sudo dd if=cintu-1710-gw36-3.iso of=/dev/sd? bs=8M

Либо ещё проще:

$ sudo cp cintu-1710-gw36-3.iso /dev/sd?

И та, и другая команда у нас всегда работала безотказно.

Systemback для установки

Образ системы, изготовленный посредством Systemback’а, будет включать последний в обязательном порядке. И устанавливать систему с него лучше его собственным инсталлятором, что, как буде сказано чуть позже, можно сделать как в Live-режиме, так и непосредственно.

Почему не Uniquity?

Теоретические, конечно, в созданный образ можно включить стандартный десктопный инсталлятор Ubuntu, именуемый Uniquity, и для установки воспользоваться им. Однако, практически нам с Мануалом это кажется не целесообразным: единственное преимущество штатного инсталлятора — возможность GPT-разметки «чистого» или «суперчистого» целевого носителя, о чём будет сказано далее. А мы с ним зареклись использовать GPT (как и UEFI), поскольку не обнаружили в нём никаких преимуществ, кроме недостатка: более сложного восстановления загрузчика при его повреждении.

Правда, скажу по секрету — GPT-разметку невозможно выполнить изнутри запущенного Systemback’а. Но никто не запрещает сделать её в Live-режиме до его запуска. Так что единственное преимущество Ubiquity над Sysytemback’ом испаряется.

А вот недостатки у самого штатного инсталлятора — есть: он требует некоторых дополнительных телодвижений. Перво-наперво — установки пакета ubiquity. А тот потянет за собой ещё несколько зависимостей, таких, как ubiquity-casper и ubiquity-frontend-gtk.

И при этом ни в коем случае не забыть про ubiquity-slideshow-[desktop-name], где desktop-name — имя одного из «законных» дистрибутивов семейства Ubuntu (ubiquity-slideshow-ubuntu, ubiquity-slideshow-ubuntu-mate и так далее). Да-да, без слайд-шоу, сопровождающего процесс инсталляции, она просто не пройдёт до конца без сообщения об ошибке, а автоматически, как зависимость, ни один из этих пакетов не установится.

Главное же — установка с помощью Systemback’а ничуть не сложнее, чем штатным инсталлятором материнского дистрибутива (по мне — так проще), почти не уступает последнему в гибкости и проходит много быстрей. Кроме того, она проходит без единого обращения к сети, и может быть выполнена в автономном режиме.

Тем не менее, если хочется иметь в своём образе инсталлятор, «похожий на настоящий» — применитель имеет такую возможность. Почему мы с Мануалом и уделили несколько строк данному вопросу.

Начало установки

Для установки Cintu нужно перво-наперво загрузиться с любого из её текущих образов, которые можно найти здесь. И в меню загрузчика выбрать любой из двух первых пунктов, причём пункт первый, Boot Live system обычно предпочтителен, особенно при установке на ноутбук с подключением по WiFi: при необходимости в Live-сессии можно настроить беспроводной доступ, параметры которого сохранятся в инсталлированной системе. Далее предполагается, что установка проводится именно в Live-режиме:

После загрузки Live-сессии можно сразу запустить Systemback для немедленной установки — из панели Избранное главного меню среды Cinnamon (в Cintu, разумеется):

В более иных системах и средах Systemback запускается через одноимённый пункт главного меню. Но при любом способе запуска первым делом будет запрошен пароль для получения прав администратора — в наших сборках Cintu это будет cintu или alv, в респинах Maui Lite и Maui Heavymaui, в Nitrux’е — nitrux. Вообще здоровым решением при использовании Systemback задавать пароль Live-сессии, совпадающий с логином Live-юзера, который можно видеть на панели авторизации в явном виде:

Так или иначе, после авторизации появляется главное окно Systemback’а:

По причинам, описанным во Вступлении, интерфейс Systemback’а во всех наших (и тем более в не наших) сборках англоязычный, хотя при желании его легко переключить на русскоязычный (обратным порядком, нежели описано во Вступлении). Однако это — по желанию: и минимальных познаний в языке Вильяма нашего, Шекспира, достаточно, чтобы выбрать кнопку Install system. Установка сводится всего к трём шагам:

  1. созданию пользовательского аккаунта;
  2. настройке разделов и файловых систем;
  3. переносу файлов системы с исходного носителя на целевой.

Шаг первый: создание аккаунта

Итак, первый этап — заполнение полей аккаунта первого пользователя будущей инсталляции — он получит идентификатор (UID) 1000 и по совместительству сможет потом выполнять обязанности администратора:

К заполнению обязательны все поля, кроме пароля администратора, иначе кнопка Next (или Далее, если интерфейс таки будет русифицирован) не активизируется. Зато содержимое полей может быть достаточно вольным. Так, реальное имя пользователя при желании можно записать кириллицей, хотя логин, ясное дело, требует только чистой латиницы (точнее, символов с чистыми ASCII-кодами). Имя хоста может быть произвольным (лишь бы уникальным в данной локальной сети, если таковая имеется). А на длину пользовательского пароля, в отличие от инсталляторов многих дистрибутивов, не накладывается никаких ограничений «снизу» — он может быть хоть односимвольным, как на примере ниже.

И, что характерно, такой пароль не только «проглотится» инсталлятором, но и будет прекрасно работать в установленной системе, в том числе и при получении прав администратора командой sudo.

После разборки с полями аккаунта нажатие кнопки Next влечёт за собой переход ко второму этапу установки, в ходе которого настраиваются разделы носителей их файловые системы. Однако прежде следует сделать оговорку: все наши сборки предназначены для машин с традиционным BIOS’ом или возможностью переключения UEFI BIOS в режим Legacy. Ибо, поэкспериментировав некогда с UEFI-режимом, не обнаружив в нём никаких преимуществ перед режимом Legacy и едва не угробив содержимое флеш-памяти, мы с Мануалом «клятву страшную дали» — никогда его более не использовать. По крайней мере, до тех пор, пока для него существует альтернатива.

При разметке диска, выборе и монтировании файловых систем существует три варианта установки:

  1. на машину с носителем (или носителями), уже как-то размеченными;
  2. на «чистый» (то есть свежекупленный) носитель;
  3. на «суперчистый» носитель, не имеющий таблицы разделов.

Рассмотрение начнём, разумеется, с варианта первого.

Шаг второй, вариант первый: установка на размеченный носитель

Первый вариант — система устанавливается на машину с носителями, уже имеющими какие-то разделы, причём стиль их разметки (msdos или gpt) значения не имеет. В этом случае просто выбирается свободный раздел (или тот, что приносится в жертву новой инсталляции, или неразмеченное пространство), для которого задаётся файловая система и точка её монтирования, то есть корень файловой иерархии — /:

Выбор файловых систем определяется их набором, поддерживаемым в системе, родительской о отношению к Live-образу. В сборках Cintu 17.10 в их числе только наиболее востребованные (хотя в некоторых других наших сборках включались практически все нативные для Linux’а):

После этого следует нажать кнопку с зелёной стрелкой «взад», при наведении на которую всплывает подсказка Change partition settings. И тогда активизируется кнопка Next, позволяющая продолжить инсталляцию:

Здесь нужно помнить о нескольких важных моментах. Во-первых, раздел, выбранный под корневую файловую систему, будет отформатирован принудительно, со всеми вытекающими последствиями. К корню в качестве /home можно присобачить и какой-либо другой существующий раздел, в том числе и с данными, но тогда нужно не забыть снять «птицу» с боксика Format (для корневого раздела снять эту отметку не получится).

Во-вторых, чтобы инсталлированная система унаследовала настройки, существующие в Live-режиме, нужно отметить боксик Transfer user configuration and data files.

В-третьих, если в машине имеется более одного физического носителя или более одного раздела, то желательный для установки GRUB’а следует явным образом выбрать из выпадающего списка. При наличие какой-либо ОС с настроенным загрузчиком в новой инсталляции можно отказаться от установки GRUB’а вообще, выбрав в том же списке пункт Disable:

В последнем случае нужно ещё помнить о необходимости загрузки в старую систему и выполнении в ней некоего деяния, о чем будет сказано под занавес.

Шаг второй, вариант второй: установка на «чистый» носитель

Второй из вариантов, о которых говорилось выше — установка на «чистый» диск: это случай свежекупленного HDD или SSD. Назвать его совсем чистым нельзя — он несёт на себе фабрично размеченную в стиле msdos таблицу разделов — пока пустую, так как никаких разделов на нём пока нет. И превратить dos-разметку в gpt из инсталлятора — нельзя.

Разумеется, для установки системы следует создать для неё целевой раздел — например, один на весь носитель (другие случаи будут рассмотрены позже). Нажав опять таки на кнопку с зелёной стрелкой, всплывающая подсказка над которой теперь гласит Add new partition:

Затем, как и в первом случае, для раздела задаются файловая система, точка её монтирования, указывается необходимость переноса пользовательских файлов и определяется место установки загрузчика — при одном накопителе можно положиться и на автоматику, но на всякий пожарный лучше сделать это явным выбором:

Разумеется, сделанные определения нужно опять-таки зафиксировать, нажав всё ту же кнопку с зелёной стрелкой. А дальнейшие действия — те же, что и в первом варианте.

Шаг второй, вариант третий: установка на носитель без таблицы разделов

Наконец, третий вариант — установка системы на носитель без таблицы разделов. Это, например, случай инсталляции в свежесозданную виртуальную машину. Или — на носитель, в котором MBR по каким-либо причинам был «обнулён» командой типа dd.

И вот этот случай может вызывать недоумение даже у довольно опытных применителей (например, у автора этих строк). Ибо после запуска Systemback’а, выбора установки системы и заполнения полей учётной записи вы видим перед собой диск не просто «чистый», а «суперчистый»:

На котором, казалось бы, невозможно даже создание раздела, не говоря уж о файловой системе и определения точки её монтирования. Правда, если зафиксировать курсор мыши на имени устройства, появляется ещё и активизированная кнопка с красной надписью ! Delete !, хотя уничтожать, казалось бы, и нечего:

Кнопка ! Delete !, кстати, не имеет всплывающей подсказки. Так что нужна смекалка недюжинного солдата (или — комментарий коллеги, как было в моём случае), чтобы смекнуть, что кнопка эта в данной ситуации и не должна ничего уничтожать. А, напротив, призвана создать пустую таблицу разделов — в стиле msdos, без возможности выбора GPT-разметки:

Ну а что делать с пустой таблицей разделов — мы уже знаем: на ней надо создавать раздел, и можно даже не один. Для чего под корень отводится только часть дискового пространства, а остальное отдаётся, например, под /home и SWAP:

Впрочем, повторимся мы с котом Мануалом, все действия по разметке (в том числе и создание таблицы GPT) можно выполнить в Live-режиме предварительно, до запуска Systemback’а. Для этого в абсолютно любом дистрибутиве имеются CLI-утилиты fdisk и cfdisk, а в большинстве (в том числе и в Cintu) — (почти) универсальная графическая программа для работы с разделами, GParted.

Интермедия о домашнем каталоге

Только что мы упомянули о том, что инсталлятор Systemback’а позволяет и создать раздел под будущий каталог /home, и задействовать в этом качестве раздел существующий, в том числе и с данными, причём без потери оных.

Однако возможность создать раздел под /home не значит, что это делать нужно. Более целесообразно держать свой домашний каталог /home/username на том же разделе, что и корневая файловая система, а в нём — не хранить ничего, кроме пользовательских настроек. Это, во-первых, здорово упростит создание личных резервных копий средствами Sysytemback’а.

Во-вторых, пользовательские данные есть смысл держать на обособленном разделе — у меня он монтируется в каталог /home/data, но можно выбрать и любую другую точку монтирования (например, /home/username/data).

Однако назначить для монтирования раздела-хранилища произвольную точку, вроде указанной, не получится: её можно выбирать только из выпадающего списка:

И даже если попытаться в соответствующее поле вписать руками что-нибудь типа /home/data, привычное для всех наших с Мануалом инсталляций, оно на следующем этапе будет просто проигнорировано — потому что такого каталога нет в файловой иерархии установочного образа. Так что подключением раздела с данными придётся заниматься после установки, как было некогда написано применительно к Cintu.

В-третьих, на стадии установки в принципе можно подключить в каталог /home имеющийся раздел этого же назначения, использующийся в других системах на данной машине. Однако, как было сказано ранее, делать это надо аккуратно, не забыв снять «птицу» с чекбокса Форматировать.

В общем, наша с Мануалом настоятельная рекомендация применителям Cintu, особенно начинающим… То есть тем, кто не имеет ещё продуманной, проверенной и привычной системы хранения своих пользовательских настроек и данных. Так вот, для них она такова: ограничиться при установке одним разделом под корневую файловую систему, включающую в себя и /home/username. В обоснование чего могу привести слова брата незабвенного Голубкова:

Так лучше, Лёня!

Шаг третий

Какой бы вариант разметки мы ни выбрали, пока никаких необратимых действий с носителями, разделами и файловыми системами не произошло — в их конфигурацию можно вносить любые изменения. И даже нажатие кнопки Next ещё не повлечёт непоправимых последствий, в лишь вызовет последнее китайское предупреждение. Которому можно внять, нажав кнопку Cancel — и начать всё сначала (или просто отказаться от установки):

Однако, если нажать кнопку Start — обратной дороги уже не будет, разметка, форматирование и собственно установка системы начнутся незамедлительно:

И довольно быстро завершаться сообщением об успешном завершении установки:

По закрытии этой панели можно перезагрузиться в новую систему.

Рассмотрев (почти) все возможные варианты установки (кроме установки на softRAID, но это отдельная история), можно вспомнить о том, что следует перезагрузиться в новообразованную систему. Делать это придётся вручную, штатными средствами рабочей среды. Например, в Cintu — так:

Правда, о размонтировании установочного носителя (а для носителя оптического — и о его изъятии) система позаботится: достаточно нажать Enter. О чём будет специальное извещение.

И здесь уместно напомнить о том, что при отказе от установки GRUB’а попасть в новоисталированную систему сразу не получится. Это можно будет сделать только после загрузки в систему старую и выполнения в ней апдейта GRUB’а командой

$ sudo update-grub

Или добавления новой системы в меню загрузчика старой с помощью какого-либо графического инструмента, вроде GRUB Customizer’а или того же Systemback’а.

Итог

Подводя итог всему сказанному в этом очерке, нужно отметить: всё это на самом деле гораздо проще сделать, нежели описать. Главное — не забывать нажимать нужные кнопки в нужных местах, а также следить за отметками чекбоксов — остальное произойдёт почти само собой. И все последующие инсталляции посредством Systemback’а будут выполняться на рефлекторном уровне.

Создание снапшотов

Во вступлении упоминалось вскользь о других функциях Systemback’а. Об одной из них — создании снапшотов — есть резон поговорить чуть подробнее.

Чтобы начать создание снапшота (в терминологии Systemback’а — точки восстановления, Restore Point), достаточно нажать кнопку Создать новую во второй колонке главного окна программы — процесс начнётся незамедлительно:

А по окончании его в первой колонке появится запись о существовании точки восстановления в формате год:месяц:день,час:минута,секунда:

Снапшоты по умолчанию располагаются в каталоге /home/Systemback (если он, конечно, не переопределялся в настройках):

ls ../Systemback 
S01_2018-02-01,15.35.36/  S02_2018-01-30,09.27.19/

И представляют собой просто точные копии исходная файловой системы на указанный в имени снапшота момент времени. Разумеется, каждый снапшот занимает на диске ровно столько места, сколько и «прародительница».

По умолчанию в снапшот попадают только системные каталоги. Чтобы в него включались и пользовательские данные из каталога /home/username, нужно, нажав в главном окне программы зелёную стрелку «вправо», перейти к общим параметрам Systemback’а:

Нажать там на кнопку Include и выбрать нужные файлы и каталоги:

Снапшоты можно делать не только вручную, но и по расписанию. Оно задаётся нажатием одноимённой кнопки с том же окне параметров. Где в первую очерель включается режим планировщика (по умолчанию он выключен), после чего устанавливается нужное время ожидания следующего снапшота:

Для восстановления системы нужно отметить чекбокс необходимого снапшота, после чего активируется кнопка Восстановление системы, которую и надлежит нажать:

На что последует предложение выбрать тип восстановления (полное, только системные или только пользовательские конфиги) и опции его, относящиеся к загрузчику:

Нажатие кнопки Далее вызовет начало процесса восстановления:

А по завершении процесса — предложение рестарта:

Важно, что восстановление осуществляется на работающей системе, без всяких отмонтирований, загрузок с Live-носителя и так далее. И потому эта функция может быть удобной, не смотря на значительный расход дискового дискового пространства.

Оставьте комментарий