На этой странице кот Мануал излагает свои воззрения на инструменты ремастеринга вообще и на 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 кажется нам самой подходящей (для наших целей и задач) системой ремастеринга. И самой простой в обращении. К тому же мы с Мануалом не теряем надежды, что кто-нибудь подхватит знамя, выпавшее из рук её разработчика, Кенде Кристиана, и продолжит его скорбный труд.

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

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

Обзор систем ремастеринга

Создавать на базе Ubuntu собственные ремиксы, респины и тому подобные пересборки, в том числе и узкоспециальные, очень просто — и это известно всем. По крайней мере, всем заинтересованным. Они-то знают, что для этого есть минимум три метода:

1. «потрошение» одного из официальных образов дистрибутива с целью его индивидуализации,
2. установка одного из них с последующей коррекцией набора пакетов в обе стороны, и
3. установка базовой системы с mini.iso и последующее наращивание её Иксами, любимым десктопом или оконным менеджером, а также необходимыми приложениями.

Для «потрошения» образов в официальном репозитории Ubuntu имеется (полу-)штатный инструмент — Ubuntu Customization Kit (UCK), о котором в своё время немало говорилось в книге про Linux Mint и его Cinnamon. Он очень просто в использовании, и применение его целесообразно, когда стоит задача кое-что добавить или кое-что убавить в исходном образе, не меняя в целом его концепции (в том числе и «титульного» рабочего окружения). Результатом «потрошения» будет пересозданный iso-образ, пригодный как для запуска в Live-режиме, так и для установки с него системы. Впрочем, последнее время применение UCK к дериватам Ubuntu вызывало у нас с Мануалом проблемы, и поэтому речи о нём (пока?) не будет.

«Корректирующий» метод также в большинстве случаев подходит при изменении комплектации пакетами в рамках заданного десктопа. Хотя в принципе никто не запрещает и заменить рабочее окружение исходного дистрибутива на более иное, не имеющее аналогов среди официальных дериватов Ubuntu. Хотя для этой цели имеет смысл рассмотреть и «метод наращивания». Впрочем, мы с Мануалом опробовали оба метода при сборке системы Cintu с практически идентичным результатом.

Однако радости от такой системы будет мало, если её не удастся легко тиражировать по крайней мере в узких кругах родных и близких. А для этого нужен ещё и инструментарий ремастеринга — то есть создания образов на основе самосборной системы. И такого инструментария существует немало, хотя и не в официальных репозиториях.

Первым в этом ряду следует отметить Remastersys, давно заброшенная автором, но до сих пор поддерживаемая «на плаву» усилиями Алексея Бухалова aka BaaTLT, в том числе и для актуальных версий Ubuntu, включая будущий релиз 18.04 (см. обсуждение на форуме Matuntu). От него (или неё?) происходят (в произвольном порядке):

• Pinguy Builder, который также то ли дышит на ладан, то ли даже это перестал делать;
• Wasta Remastersys, развиваемый в рамках проекта Wasta-Linux — одного из многочисленных внебрачных отпрысков Ubuntu, впрочем, достаточно своеобразного;
• bodhibuilder, который является составной частью дистрибутива Bodhi, также незаконного потомка Ubuntu, но с десктопом Enligthtenmet (вернее, ныне с его клоном Moksha).

Кроме того, имеется несколько систем ремастеринга, изначально ориентированных на Debian. Среди них — инструментарий Refracta и набор утилит из дистрибутива MX Linux. И ту, и другую «ремастерию» можно, затратив некоторые усилия, прикрутить к членам семейства Ubuntu, где и использовать их вполне успешно.

Однако для нас с Мануалом важнейшей из систем ремастеринга оказался 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

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

А затем начинается работа сценария. Сначала обновляется локальный кеш пакетов, то есть, попросту говоря, выполняется команда 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 Heavy — maui. Вообще здоровым решением при использовании 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, привычное для всех наших с Мануалом инсталляций, оно на следующем этапе будет просто проигнорировано — потому что такого каталога нет в файловой иерархии установочного образа. Так что подключением раздела с данными придётся заниматься после установки, о чём будет рассказано в соответствующем «Воззрении».

В-третьих, на стадии установки в принципе можно подключить в каталог /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-носителя и так далее. И потому эта функция может быть удобной, не смотря на значительный расход дискового дискового пространства.

Remastersys и его производные

Программы ремастеринга, о которых далее пойдёт речь, имеют три общие особенности. Во-первых, в отличие от Systemback’а, ни та, ни другая не имеют своего инсталлятора: для установки созданных ими образов используется стандартный Ubiquity из прародительской Ubuntu. Причём, согласно изысканиям Алексея Бухалова, обязательным условием успешной установки является наличие одного из пакетов, поддерживающих слайд-шоу в ходе развёртывания системы.

Во-вторых, и пользователь Live-сессии, и пользователь, чей аккаунт создаётся при установке, наследуют свои настройки не от пользователя «системы-матки», а из dot-файлов каталога /etc/skel. И наполнением его следует озаботиться перед созданием образа.

Наконец, в-третьих, по крайней мере две из фигурирующих далее программ (Remastersys и wasta-remastersys) могут запускаться в режиме командной строки (впрочем, вторая из них — только в нём, ибо GUI’ёвой оболочки не имеет).

Remastersys

Главной альтернативой Systemback’у выступает программа Remastersys, которая нынче развивается Алексеем Бухаловым aka BaaTLT и существует в сборка для Ubuntu и её клонов вплоть до релиза 17.10 и будущего релиза 18.04.

О программе Remastersys я много говорить не буду — Алексеем подготовлена исчерпывающая по ней документация (см. также здесь). Так что просто вкратце опишу свои впечатления.

Remastersys состоит из двух пакетов — remastersys_3.1.1-3_all.deb, отвечающего за функционал, и remastersys-gtk_3.1.1-3_all.deb, обеспечивающего графический интерфейс. Установка обоих посредством утилиты Qapt (именно в такой последовательности) прошла без всяких приключений.

Как уже говорилось, Remastersys можно использовать в командном режиме. Однако я на нём останавливаться не буду — его команды и опции совпадает с таковым wasta-remastersys, о которой речь пойдёт в следующем разделе. Но Remastersys имеет и графический интерфейс, который выглядит таким образом:

А нажав кнопку О программе, можно ознакомиться с авторским коллективом её создателей:

Описывать возможности программы и порядок действий при её использовании не буду. Скажу только, что процесс создания образа, запуска с него live-сессии, а в ней — инсталлятора, прошли без всяких проблем. Однако в ходе развёртывания системы у меня появилось сообщение о крахе установочной программы.

В причины сего прискорбного события вдаваться не буду — в обсуждении на форуме Matuntu BaaTLT высказал по этому поводу несколько резонных соображений, к которым я и отсылаю заинтересованных лиц. Там же можно найти многочисленные примеры удачного применения Remastersys’а. Так что свою неудачу с этой программой списываю на личную невезуху.

Wasta-remastersys

Программа wasta-remastersys развивается в рамках проекта Wasta-Linux — одного из многочисленных внебрачных отпрысков Ubuntu, впрочем, достаточно своеобразного.

Пакет wasta-remastersys мал и просто, ибо не имеет GUI’ёвой оболочки. В сущности он сводится к двум командам (обе требуют привилегий администратора):

• wasta-remastersys-skelcopy — как явствет из её имени, она копирует dot-файлы из домашнего каталога текущего пользователя «системы-матки» в каталог /etc/skel;
• собственно wasta-remastersys, результат выполнения которой зависит от опций.

Среди опций команды — тройка основных backup|clean|dist, очевидного назначения, и пара дополнительных cdfs|iso: первая ограничивает деятельность программы созданием файловой системы образа, вторая — образ создаёт (с нуля или из уже развёрнутой файловой системы). Я не мудрстуя лукаво, запустил эту команду в такой форме:

$ sudo wasta-remastersys dist image_name.iso

И про прошествии потребного количества времени получил два файла — iso-образа и md5-суммы его.

С образа я немедленно запустил вновь созданную в Virtualbox’е виртуальную машину. В live-режиме всё работало прекрасно. Не было по началу и проблем с инсталляцией. До тех пор, пока не началось собственно перенос системы на целевой носитель. Ибо процесс этот продолжался недолго, и завершился сообщением о крахе программы инсталляции. Причём в log-файле, с содержимым которого предлагалось ознакомиться, внятной информации о причинах краха я не увидел.

Pinguy Builder

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

Однако уроки истории учат нас, что большинство программ ремастеринга имеют особенность со временем прекращать своё развитие. И в новых релизах своих родных дистрибутивов (в данном случае речь идёт только о системе Ubuntu) начинают работать криво, а то и не работают вовсе. И потому всегда надо иметь «запасной аэродром» на такой случай.

Поэтому, встретив в одном из комментариев Dena упоминание о дистрибутиве Pinguy OS, основанном на Ubuntu и имеющем собственную систему создания дистрибутивных образов, я решил с ней ознакомиться. Система эта носит имя Pinguy Builder и представляет собой развитие программы Remastersys (и, кажется, даже продолжает нумерацию её версий).

Правда, оказалось, что дистрибутив Pinguy OS, судя по последнему сообщению на официальном сайте (от 19 мая 2016 года), похоже, прекращает своё развитие. Однако, как часто бывает в мире Open Source, дело его не пропало, по крайней мере, частично. Потому что интересующая меня часть проекта, то есть сам Pinguybuilder, обнаружилась в одном из PPA-репозиториев во вполне свежем виде: бинарный пакет для Xenial’а имеет версию 4.3 от 30 августа сего года.

Так что для начала я озаботился подключением указанного репозитория самым что ни на есть стандартным образом:

$ sudo add-apt-repository ppa:inameiname/stable
$ sudo apt update

После чего нужный пакет легко может быть найден

$ apt search pinguybuilder                                                                                    [~]
Сортировка… Готово
Полнотекстовый поиск… Готово
pinguybuilder/xenial,xenial,now 4.3-8-1ppa1~inameiname1 all
  This script creates a livecd of the installed system and works with *buntu systems.

И установлен со всеми своими зависимостями (весьма, надо сказать, многочисленными, ибо включают они инсталлятор Ubuntu — Ubiquity, и всё, что к нему относится):

$ sudo apt install pinguybuilder

После этого программа под именем Pinguy Builder появится в секции Администрирование главного меню Cinnamon — разумеется, всё описываемое происходило в Cintu. Но и во всех прочих Ubuntu’идах порядок действий будет тем же самым.

Программа Pinguy Builder настолько похожа на Remastersys, что для работы с ней можно смело пользоваться прекрасным описанием последней, сделанным BaaTLT’ом. Так что дальше я остановлюсь только на незначительных отличиях Pinguy Builder от Remastersys.

Сразу после запуска окно Pinguy Builder’а выглядит таким образом:

Значения первого (Backup) и последнего (Clear) пунктов «верхней» части меню вкладки Actions очевидны — полное копирование системы вместе а с данными и очистка кеша программы от «отходов жизнедеятельности» (то есть файлов предыдущего сеанса). В первом случае следует помнить, что в создаваемом образе будут сохранены файлы из каталога $HOME. И если объём очень велик — легко превысить ограничение на размер файловой системы SquashFS (если не изменяет память, 4,2 ГБ). Ну и, разумеется, в Backup попадут только те пользовательские данные, которые лежат на одном разделе с корнем файловой иерархии. Впрочем, разговор на эту тему будет отдельный (своевременно или несколько позже).

А по поводу очистки нужно помнить, что при этом удаляется всё содержимое каталога /home/PinguyBuilder, в том числе и iso-образ, созданный в предыдущую сессию FB, со всеми его чексуммами. Так что если они представляют собой не очень преходящую ценность, то их лучше заблаговременно скопировать куда-нибудь в другое место.

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

Обращаю внимание, во-первых, на то, что здесь можно переопределить рабочий каталог программы (в нём будут и «отходы жизнедеятельности», и её результаты, в виде образа и чексумм *.md5 и *.sha256). А во-вторых, на то, что опция, ответственная за XZ-компрессию, -comp xz, включена по умолчанию. Если это почему-либо не устраивает — опцию эту нужно просто убрать. В каких случаях убрать, а в каких оставить — говорилось ранее на примере Systemback.

По умолчанию включён также вывод на рабочем столе Live-сессии пиктограммки запуска установочной программы — в отличие от Sysytemback’а, эту роль здесь играет обычный Ubiquity, инсталлятор всех официальных представителей семейства Ubuntu.

Расправившись с Setting‘ами, можно и вернуться на вкладку Actions, и обратиться к «нижней» части её меню. Начну снизу вверх. Поскольку никаких таких особых тем Plumouth’а у меня нет, самый нижний пункт я проигнорировал. В пункте же предпоследнем выбирается каталог, который станет «домашним» в Live-сессии созданного образа:

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

Два остальных пункта же позволяют выбрать фоновую картинку для обоих загрузчиков Isolinux (для старта Live-сессии) и GRUB’а — для системы, установленной на диск. Так что необходимости ручной работы в этом направлении, описанной Алексеем для Remastersys’а, в Pinguy Builder не возникает.

Вот теперь можно заняться тремя «средними» пунктами из «верхней» части вкладки Actions. Начну со среднего — Distcdfs. Он не создаёт готового iso-образа, дело ограничивается сборкой файлового древа, которое может быть преобразовано в образ. А перед тем в древо это можно вмешаться руками — чего-то изменить, прибавить, а возможно, и убавить. Из этого дерева посредством пункта Distiso собирается «живо-установочный» образ (или пересобирается существующий). Ну а через пункт Dist выполняются обе эти операции в один присест.

При создании образа посредством любого из этих трёх пунктов пользовательские настройки в Live-образ сами собой не наследуются от исходной системы, а переносятся из dot-файлов каталога /etc/skel. Куда и следует заблаговременно поместить все необходимые конфиги (обязательно забыв чего-нибудь важное, как было в моём случае). А если ещё и умолчальный login shell в системе более иной, нежели Bash, то нужно внести изменения в файл /etc/adduser.conf. Например, в Cintu, где в качестве регистрационной оболочки по умолчанию используется Zsh, они сводятся к замене строки

DSHELL=/bin/bash

на

DSHELL=/bin/zsh

После создания образа и переноса на какой-либо носитель систему можно запустить в Live-режиме, полюбовавшись предварительно на картинку загрузчика:

А затем, убедившись в её работоспособности, запустить установочную программу. Для чего можно воспользоваться пиктограммкой на рабочем столе или пунктом меню Установить Release из секции Администрирование. Как уже было сказано, установка осуществляется Ubuntu’евым инсталлятором Ubiquity и проходит точно так же, как в любом дистрибутиве этого семейства. Правда, при этом никакого слайд-шоу не показывается — ни один пакет из этого набора я не устанавливал. И, как оказалось, необходимости в нём (у меня) не возникло.

В общем, как показали первые опыты, использовать Pinguy Builder для сборки Cintu вполне можно. Нужно ли — пока не решил. Как и то, лучше ли он, чем крепдешен Systemback, или хуже. Постараюсь ответить на него после некоторых дополнительных экспериментов.

Bodhubuilder

После неудачи с wasta-remastersys из всех программ ремастеринга неопробованной в у меня оставался только Bodhubuilder, который поначалу просто не хотел в нём устанавливаться.

Однако затем Татьяна Иванова ala Vita надоумила меня воспользоваться для установки этого пакета утилитой Gdebi. Оставалось только проверить обретённый пакет bodhubuilder. Так что я запустил эту программу через «Доску приложений» (дело происходило в дистрибутиве Neon с KDE) и, после ввода пароля для получения прав администратора, прочитал такое предупреждение:

Хотя выполнять его, насколько я понял не обязательно. А можно сразу перейти к главному окну программы:

Здесь резонно было сразу ознакомиться с умолчальными настройками Bodhubuilder’а (во вкладке Settings) и, при необходимости, кое-что поправить. Поскольку моей первоочередной задачей было просто проверить работоспособность программы и, главное, инсталлятора, запущенного с созданного ею образа, я ограничился добавлением русской локали:

Далее я вернулся к вкладке Actions и, понту ради, добавил собственную заставку для загрузчика Live-сессии. А затем нажал кнопку Dist, предназначение которой — создание образа. И затем, естественно, согласился с предложением запустить процесс:

Судя по скорости его выполнения, в Bodhubuilder’е по умолчанию также задействуется zx-сжатие. Так что ждать результата, в виде файлов bodhibuilder.iso, bodhibuilder.iso.md5 и bodhibuilder.iso.sha256 в каталоге /home/bodhibuilder/bodhibuilder, долго ждать мне не пришлось. После чего я немедленно запустил «свежую» виртуальную машину и полюбовался на заставку загрузчика:

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

Кстати, пиктограммы для запуска инсталлятора я на рабочем столе не обнаружил (хотя соответствующая опция в настройках Bodhubuilder’а отмечена по умолчанию). Так что программу установки я запустил, просто набрав в терминале команду ubiquity. Вслед за чем, выполнив все подготовительные действия, и, ни на что особо не надеясь, отправился курить. Успев, правда, разглядеть, что никакого слайд-шоу в ходе установки не демонстрируется.

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

Системы ремастеринга для клонов Debian’а

Все фигурировавшие ранее системы ремастеринга ориентированы на использование в Ubuntu и его клонах. Вероятно, их можно прикрутить и к чистым дистрибутивам Debian based. Мы с Мануалом это делать не пробовали. Во-первых, из-за различия в устройстве Live-образов это задача… не то что очень сложная, но и не совсем тривиальная. А во-вторых, в чистых deb-клонах имеются и своим системы ремастеринга.

Нам с Мануалом таких известно две — набор утилит Refracta и набор инструментов из дистрибутива MX Linux. И вот их тоже можно прикручивать в Ubuntu’идам, причём для Refracta мы это проделывали, и не без успеха. Но сначала посмотрим, как эта система ведёт себя в родной среде, на примере LMDE 2 Betsy.

Refractasnapshot: образ с нескучными обоями

Установка любой минимальной системы и последующая трансформация её в полноценный, хотя и без всяких излишеств, десктоп вызывает желание увековечить результаты своих трудов в виде iso-образа, способного как загрузить систему в live-режиме, так и установить её на любой компьютер. Далее процесс этот будет описан для кастомизированной системы LMDE 2 Betsy и инструментария Refracta

Проще всего сделать это путём создания снапшота установленной и настроенной системы. Для чего можно использовать либо комплекс утилит CLI с полукилометровым набором опций, либо специализированный фронт-энд к ним, работающий или в графическом, или в текстовом режиме. Таких фронт-эндов для дистрибутивов семейства Mint обнаружилось три: remastersys, makulu-constructor и сладкая парочка от проекта Refracta — refractasnapshot для изготовления образа LiveCD и refractainstaller, обеспечивающая установку с него системы на целевой носитель.

По некоторым причинам, о которых расскажу в другом месте, я остановился на последнем варианте. Который требовал, разумеется, установки соответствующих пакетов, которые можно скачать с Sourceforge.net в виде стабильных или тестовых версий. Первые, доступные также с Ibiblio.org, датируются августом 2013 года, поэтому я обратился ко вторым.

Программы Refracta каждого назначения представлены парами пакетов, содержащими утилиты командной строки (refractasnapshot-base и refractainstaller-base) и графические «морды» для них (refractasnapshot-gui и refractainstaller-gui). По причинам, о которых я скажу позже, для нормальной работы достаточно первой пары, однако я, ещё не зная этого, на всякий случай скачал и установил обе. А установить их проще всего с помощью утилиты Gdebi в графическом режиме.

После установки gui-версий соответствующие пункты появляются в главном меню Cinnamon. Однако запускаться оттуда не желают — refractainstaller-gui потому, что устанавливает систему с LiveCD, изготовленного с помощью refractasnapshot-gui, а последняя — потому, что не запрашивает необходимых ей прав суперпользователя: это надо сделать явным образом или в строке минитерминала через gksu, или просто через sudo из терминала обычного.

После запуска refractasnapshot-gui сначала предлагается отредактировать её конфиги, следуя указаниям из документации, но более полагаясь на комментарии в них самих. Я своё вмешательство в них свёл к минимуму (переопределению базового имени образа) — и в результате из системы, образованной шаг за шагом, получился Live-образ размером 900 МБ без копеек, с которого система загрузилась и работала.

Разумеется, в состав этого образа вошёл и refractainstaller-gui, с которого, теоретически говоря, Live-систему можно установить на винчестер. Однако практически это получается не всегда. Например, если в процессе установки задать отельный раздел для каталога /home, то происходит обрыв процесса с не очень внятным сообщением об ошибке, предгагающим читать log-файл. Основное же содержание последнего — пересказ man-страницы команды mount. Впрочем, и отсюда можно извлечь кое-какую информацию, о чём будет сказано далее.

Однако я предположил, что может быть что-то не так с образом — и решил опробовать текстовый инструментарий и для его изготовления, и для установки. Ожидая, что, как часто бывает, он окажется более функциональным, более гибким или более информативным по части вывода. Ожидания мои оправдались частично — но он однозначно оказался более простым в употреблении, а главное — надёжным. Почему и беру на себя смелость рекомендовать к употребелнию именно CLI-версии программ от Refracta.

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

$ sudo refractasnapshot

И получаю предложение наложить патч на «изготовитель» initrd:

It looks like you need to patch /usr/share/initramfs-tools/init
If you want to continue without patching, you must 
set patch_init_nosystemd to no in the config file.
If you don't patch init, your iso will probably not boot.
Run patch? (y/n)

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

Видно из снапшота, конфиг refractasnapshot.conf следовало бы, при необходимости отредактировать предварительно — но я это уже проделал при попытке использования gui-версий. Поэтому мне оставалось только задать имя моего «дистрибутива»:

Процесс создания образа начался незамедлительно, и завершился сообщением о его успехе:

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

Refractainstaller: установка с нескучного образа

Как было сказано в предыдущем очерке, попытка установить систему с собственного образа с помощью графического фронт-энда оказалась у меня неудачной. И потому я прибег в текстовой утилите refractainstaller, загрузившись с только что изготовленного образа. Загрузочное меню выглядело так:

Согласившись с вариантом по умолчанию (благо по прошествии некоторого времени он грузится автоматически), я авторизовался в системе:

И оказался в среде Cinnamon, настроенной в соответствии со своими предпочтениями:

Где вызвал терминал и в его командной строке ввёл:

$ sudo refractainstaller

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

Инструментом для чего, соблюдения единства стиля для, логично было выбрать cfdisk. Разметка проводится обычным образом — сначала создание таблицы разделов:

Затем раздела или разделов для системы — я сделал их два, под корень и под /home:

От предложения просмотреть результат я, в соответствие с умолчанием, отказался:

Далее нужно было ввести явным образом имя устройства для установки загрузчика:

Пропустив нажатием клавиши Enter определение раздела под /boot (ибо его у меня не было), я столь же явным образом задал имя устройства под корень, файловую систему для него и отказался от шифрования:

После чего повторил все те же шаги для раздела под будущий /home, отказавшись заодно, опять же в соответствие с умолчанием, от использования UUID для идентификации файловых систем в /etc/fstab:

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

Каковая в обязательно порядке включала в себя создание swap-файла (по умолчанию 256 МБ) и завершалась предложением отказаться от автоматического входа в систему:

После чего прошли подготовительные действия и приглашение к продолжению банкета:

В ходе которого был установлен GRUB и дана возможность поменять имя пользователя и его пароль:

Следующий шаг — очень важен, ибо это определение способа получения прав администратора. Здесь я, естественно, остановился на варианте, традиционном для Mint и Ubuntu, то есть с отключением доступа к root-аккаунту (вариант c:

После этого вдруг выяснилось, что система установлена. А чтобы в этом убедиться, следовало идти на рестарт, в ходе которого сначала было продемонстровано меню GRUB’а:

Затем последовало приглашение к авторизации через MDM:

И вот тут случился облом: по вводе логина и пароля дисплейный менеджер упорно не грузил ни малейшей Cinnamon, а упорно возвращал меня в свою панель авторизации. Хотя никаких проблем ни с ним самим, ни с параметрами аккаунта не предвиделось.

Ладно, переключаюсь в текстовую консоль и ищу причину. Она лежала на поверхности: раздел под /home оказался несмонтированным и, соответственно, не было доступа к домашнему каталогу пользователя.

Тут до меня дошёл и смысл сообщений в log-файле при инсталляции в графическом режиме — то же самое явление имело место быть и там, только refractainstaller-gui при этом вырубался, а refractainstaller в меру своих возможностей доводил дело до конца. И первопричина, видимо, в ошибке программы — на то она и тестовая версия. Поскольку это — обычный шелл-скрипт, поправить её, видимо, большого труда не составит.

Ну а пока — пока я просто поправил /etc/fstab, перемонтировал файловые системы и благополучно загрузился в среду Cinnamon, которая и предстала передом мной в задуманном виде:

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

Cintu 17.10 и Refracta

Все сборки Cintu на базе Ubuntu 16.04 посредством Systemback проходили у нас с мануалом (почти всегда) безболезненно. Но при попытках собрать её на 16.10 начались сбои, которые усугубились при базировании на 17.04. Тем более что, как уже говорилось, автор Systemback’а свою разработку забросил, а желающих продолжать её (пока?) не нашлось.

До некоторого времени нас с Мануалом это не особо волновало — собирать Cintu на чём-то, отличном от 16.04 LTS мы всерьёз не планировали до окончания срока поддержки последнего. Однако по некоторым причинам у нас с ним появилась кровная заинтересованность в сборке нашей любимицы на базе вскоре грядущего релиза 17.10 Artful, ожидать в котором работоспособности Systemback’а было бы опрометчиво. Хотя, как ни странно, наши опасения на этот счёт оказались напрасными — однако они послужили поводом для прикручивания Refracta к нашей Cintu.

Потому как для начала мы вспомнили о другом инструментарии ремастеринга — Refracta, который некогда успешно использовали для сборок на базе LMDE Betsy. Правда, этот инструментарий изначально разрабатывался для чистого Debian’а, а нынче вообще ориентирован на Devuan. И потому следовало ожидать некоторых трудностей с прикручиванием его к базовой Ubuntu. Однако пример серии дистрибутивов ExTiX вселял надежду, что трудности эти преодолимы.

И, как показала практика, преодолимы они легко. Во-первых, требуется скачать с SourceForge последние версии четырёх пакетов: refractainstaller-base, refractainstaller-gui, refractasnapshot-base и refractasnapshot-gui. И попытаться установить их «в лоб» — посредством dpkg, Gdebi или Qapt.

Что вызовет сообщение о непреодолимом нарушении зависимостей от пакетов live-config и live-config-systemd, отсутствующих в репозиториях Ubuntu. Каковое нарушение на самом деле преодолевается с лёгкостью — пакеты эти берутся из репозитория последней стабильной версии Debian’а (например, отсюда и отсюда, соответственно). А в некоторых версиях Ubuntu дело обстоит ещё проще — эти пакеты имеются в репозитории proposed.

Все прочие зависимости, достаточно многочисленные, удовлетворяются уже из официального репозитория Ubuntu. Причём Qapt и (по идее) Gdebi сделают это автоматически. Ну а dpkg потребует предварительного запуска команды

$ sudo apt install [длинный_список_пакетов]

Испытав чувство глубокого удовлетворения зависимостями, остаётся только запустить из меню среды Cinnamon Администрирование программу создания образов — Refracta Snapshot. Однако это будет следующим номером в программе нашего сборочного цирка.

Post Scriptum. Все описанные выше действия были проделаны в Cintu на базе Artful’а. Однако есть большое подозрение, что они пройдут и во всех системах, основанных на последних релизах Ubutnu и с любыми десктопами или оконными менеджерами. Если кто сподобится проделать соответствующие опыты — мы с Мануалом будем весьма признательны за информацию о их результатах.

Cintu 17.10 и Refracta Snapshot: создание образа

Для изготовления образов в системе Refracta предназначены две утилиты — текстовая refractasnapshot и графическая refractasnapshot-gui. Функционально они абсолютно одинаковы, и потому использование той или иной — по вкусу и (или) по ситуации. Например, текстовая утилита незаменима при создании образов базовой системы, без какого либо десктопа или оконного менеджера. Однако в данный исторический момент такая задача не стоит, и потому ниже речь пойдёт об утилите графической.

Замечание: прежде чем приступать к созданию образа, мы с Мануалом взяли за правило обновить систему и очисть её от продуктов жизнедеятельности:

$ sudo ucaresystem-core

И на всякий случай перезагрузить машину. Чего и всем желаем.

Как было сказано ранее, графический «снапшоттер» запускается из пункта Администрирование главного меню Cinnamon, и для начала запрашивает пароль для доступа к правам администратора. После чего возникает окно с предложением либо продолжить процедуру (Next), либо сначала заняться настройками (Setup):

Разумеется, при первом запуске «снапшоттера» начать надо со второго варианта. Который сводится к редактированию двух файлов — /etc/refractasnapshotter.conf и так называемого «файла исключений»:

Что предваряется проверкой свободного дискового пространства — здесь надо просто нажать OK:

Редактирование производится в умолчальном текстовом редакторе графического режима (в Cintu это будет Geany). У нас с Мануалом для файла /etc/refractasnapshotter.conf оно свелось к заданию шаблона имени будущих образов (значения строк stamp и snapshot-basename) и определению максимальной степени xz-сжатия (по умолчанию xz-сжатие вообще отключено):

Файл исключений по умолчанию — /usr/lib/refractasnapshot/snapshot_exclude.lisr. В нём перечисляются каталоги и файлы, которые не должны включаться в будущие образы. Секции, относящиеся к корневой файловой системе, мы не трогали вообще. Ну а что исключать из каталога /home — каждый должен решать сам. Очевидно, что здесь в перую очередь надо изымать всякие кэши и прочие dot-каталоги, содержимое которых не должно тиражироваться:

Смысл прочих опций обоих файлов можно уточнить в официальной документации проекта Refracta, имеющейся и в русском переводе.

После окончания редактирования и сохранения его результатов окно редактора автоматически закроется и поступит предложение приступить собственно к созданию образа — здесь достаточно нажать Enter:

Перед этим, однако, можно изменить имя дистрибутива с умолчального Ubuntu на какое угодно. В нашем случае логично назвать его Cintu, это имя попадёт потом в меню загрузчика:

Вот теперь процесс пойдёт:

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

И завершится сообщением о счастливом финише:

По нажатии клавиши OK можно полюбоваться плодами своих трудов — они будут в каталоге /home/snapshot в виде файла образа *.iso и файла контрольной суммы к нему — *.sha256. Ну а дальше остаётся «сболванить» полученный образ или «отфлешить» его, а затем загрузить целевую машину с полученного носителя и приступить к установке. Но об этом — в продолжении программы нашего цирка.

Cintu 17.10 и Refracta Installer: установка системы

Некогда пан Вотруба объяснял пану Гималайскому в «Кабачке 13 стульев» принципиальную порочность предложенного тем метода борьбы с курением: «После того, как человек выпил и закусил, ему обязательно захочется что..? — Закурить».

Аналогично и с самосборными системами. После того как человек таковую собрал и сделал её снапшот, ему обязательно захочется его куда-нибудь да установить. А как это сделать — и будет показано в данном очерке на примере предварительной сборки Cintu 17.10 с прикрученной системой Refracta.

Система Refracta имеет собственны инсталлятор, который так и называется — Refracta Installer. И, подобно «снапшоттеру», имеет две ипостаси — консольную, refractainstaller, и графическую, refractainstaller-gui. О первой опять же уже говорилось применительно к LMDE 2 Betsy. А вот поговорить о второй — самое время.

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

Как всегда, пунктом по умолчанию отмечен первый. Однако попытка загрузиться с него дала у меня в виртуалке только рябой экран, на котором не было видно ничего. Правда, на реальном железе всё было реально нормально — но мы-то для начала планировали установку в виртуалке. Почему и перешли к пункту Cintu (nomodest), с которого система загрузилась нормально. Правда, с разрешением 1024×768 — и не более:

Но и это не могло помешать нам с Мануалом выпить установить систему, запустив Refracta Installer через главное меню Cinnamon:

Установка начинается с предложения выбрать режим получения прав администратора — через su (то есть с актвизацией аккаунта root) или через sudo (без таковой):

Поскольку это вам не лезгинка Debian, а твист Ubuntu, первое — не наш метод, останавливаемся на втором варианте.

Далее предлагается выбрать метод инсталляции — простой или экспертный:

Поскольку в виртуалке простора эксперту мало, выбираем первый. После чего поступает предложение заняться разметкой диска. Если на нём уже заготовлен раздел — этот шаг можно было бы пропустить. Но диск новообразованной виртуалки девственно чист — так что выбираем GParted:

Процедура разметки диска описывалась бессчётно, так что говорить о ней не буду. Скажу только, что мы с Мануалом ограничились одним разделом с файловой системой ext4:

На который нам и будет предложено установить систему, спорить с чем было бы опрометчиво:

Далее, как обычно, выводится Summary со всякими предупреждениями и сообщениями:

Впрочем, пока не окончательными. Ибо предстоит ещё выбрать часовой пояс (сначала — Europe, а затем, в моём случае, Moscow)

При желании — выбрать дополнительные локали (мы от этого отказались):

А из имеющихся в наличии — определить умолчальную:

Каковой, разумеется, оказалась русская юникодовская для России:

И вот теперь — предупреждение уже последнее и окончательное:

После чего процесс пошёл:

И завершился предложением задать имена хоста и пользователя, отказываться от чего — не резон:

Разумеется, в соответствующих полях следует вписать свои значения.

Вслед за чем наступает время паролей. Для пароля root’а достаточно согласиться с текущим его значением (то есть отсутствием такового). Ну а для юзера с только что заданным именем пароль ввести необходимо:

Далее последует сообщение об успешном окончании установки:

И тогда остаётся только нажать OK, перезагрузить систему (даже носитель извлекать не обязательно) и в меню загрузчика выбрать пункт Boot hard disk:

Затем — авторизоваться через SLiM:

И полюбоваться на рабочий стол установленной системы:

Ну а что делать для избавления от лицезрения SLiM’а и ввода в нём логина с паролем — также будет рассказано в своё время.

MX Linux: виртуальная кастомизация

Дистрибутив MX Linux имеет средства для очень простого создания кастомизированных сборок на базе себя самого, и увековечивания своих трудов в виде образа — «живого» и установочного. Правда, оказалось, что с прямым созданием образа из Live-сессии всё обстоит не так гладко, как казалось — установка системы после кастомизации таки потребовалась. Но вот её саму целесообразно проводить в Live-сессии, запущенной в виртуальной машине, хост-системой для которой выступала моя самосборная Cintu.

Кастомизация в моём понимании в значительной степени сводится к удалению ненужных пакетов и доустановке пакетов нужных. И то, и другое требует привилегий администратора, которые в MX можно получить обоими традиционными способами — командой su с вводом пароля root’а и командой sudo, задав пароль обычного пользователя. Так что для начала неплохо выяснить хотя бы один из них, а ещё лучше оба.

Благо, делается это просто: после загрузки системы с Live-носителя пред глазами изумлённого применителя предстаёт панель приветствия, в нижней левой части которой можно видеть надпись Информация о входе:

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

На всякий случай поясню словами: пользователя Live-сессии зовут demo, и пароль у него — demo. А имя администратора — root, и пароль у него, как это ни странно, тоже root.

Обретя это тайное знание, можно приступать собственно к кастомизации. Каковая в любом случае должна начинаться командами

# apt update
# apt upgrade

Примечание: здесь и далее # символизирует, что команды эти даются с правами администратора. А уж каким способом они получены — разовым ли sudo, через sudo -s (предпочитаемый мной способ) или через su — остаётся на усмотрение применителя. Команды, для выполнения которых достаточно прав обычного пользователя, в дальнейшем будут символизироваться милым сердцу россиянина знаком — $.

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

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

• всего содержимого секции меню Графика, кроме простого вьювера изображений (в MX эту роль исполняет Mirage);
• в секции Интернет я оставил только FireFox и Transmission;
• в секции Мультимедиа расправы избежали Asunder (вдруг пригодится) и регуляторы громкости;
• из секции Офис были изъяты LibreOffice Draw и LibreOffice Impress.

Секции Инструменты и Настройки я трогать не стал, потому как ещё не до конца разобрался с их содержимым. А выполнил команду избавления от «осиротелых» зависимостей:

# apt autoremove

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

Как ни странное, но в MX не сработал привычный мне способ очистки от локалей:

# locale-gen --purge [что надо оставить]

Она вызывала регенерацию всех локалей. И даже безобидная, казалось бы, команда

# locale-gen --help

вызывала тот же процесс. Поэтому пришлось «в лоб» редактировать файл /etc/locale.gen (предварительно сохранив копию под именем /etc/locale.orig), приведя его вот к такому виду:

en_US.UTF-8 UTF-8
ru_RU.UTF-8 UTF-8

Вслед за этим была выполнена команда

# locale-gen

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

$ locale -a
C
C.UTF-8
en_US.utf8
POSIX
ru_RU.utf8

После разбрасывания лишних камней наступило время собирать камни необходимые. То есть — устанавливать пакеты, из которых для меня важнейшей является кино командная оболочка Zsh. Она была мной установлена:

# apt intall zsh

И назначена любимой женой оболочкой входа:

# chsh -s /bin/zsh demo

А мои конфиги, .zshrc и .zshenv для неё — скопированы в каталог /home/demo. Разумеется, с хост-машины: при установке MX «гостевые дополнения» не просто подключаются автоматически, но и образовывается разделяемый каталог, в моём случае — такой:

Правда, его требуется смонтировать в гостевую Live-систему руками — командой вроде

# mount -t vboxfs mx-custom /media/demo/sf_mx-linux

После этого все необходимые конфиги копируются в эту папку из хост-машины, а затем в гостевой Live-среде разносятся куда надо, в частности, конфиги Zsh — в каталог /home/demo. Однако этого недостаточно: чтобы они унаследовались пользователем, чей аккаунт в дальнейшем будет создан при инсталляции, их же следует поместить и в каталог /etc/skel.

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

# apt install fonts-cantarell gpm mpv

Теперь можно выполнить все потребные настройки пользовательской среды Xfce. И, пожалуй, что и нужно: они будут унаследованы в пользовательском аккаунте и запланированного «живого» образа, и установленной системы.

Наконец, последний штрих: вынести на рабочий стол пиктограмму запуска инсталлятора MX Linux — утилиты minstall. Делается это очевидным способом, из контекстного меню рабочего стола. Единственно, что тут надо помнить — что команда запуска инсталлятора должна иметь такой вид: gksu /usr/sbin/minstall. Что можно видеть на приводимом скриншоте:

После этого я приступил к созданию образа непосредственно из Live-сессии, но потерпел в этом деле фетяску. То есть образ-то благополучно создался, однако система с него грузиться отказалась с таким сообщением:

Причина этого более-менее понятна и, скорее всего, проблема эта решаема. Правда, я ещё не придумал, как. А если честно, то даже и не думал, потому как занялся установкой кастомизированной системы в виртуальной машине, каковая прошла без проблем. Дав в итоге полную копию той системы, которая получилась в Live-сессии после всех описанных выше действий. Из этой-то установленной системы я и сваял в итоге работоспособный «живой», он же установочный образ. О чём будет рассказано в следующем очерке.

MX Linux: ISO’изация системы

Как было сказано впредыдущем очерке, после виртуальной кастомизации системы и безуспешной попытки претворить её в ISO-Образ прямо из Live-сессии мне ничего не осталось, кроме как установить её и повторить процедуру уже «с винта». Где, повторяю, образовалась точная копия системы, кастомизированной в Live-сессии. Оставалось только загрузиться в неё (дело по прежнему происходит в виртуальной машине) и из приветственного окна запустить MX-инструментарий:

Общая панель управления дистрибутив-специфичными инструментами выглядит так:

И выбор нужного инструмента тут очевиден — отмеченный на скришоте пункт запустит утилиту mx-snapshot. Что, разумеется, можно сделать и любым другим способом — через меню, набрав в его строке поиска это самое слово (или даже русское — снимок системы), из командной строки терминала или минитерминала. В любом случае результатом будет (после авторизации root’ом и некоторого времени, затрачиваемого на подсчёт занимаемого системой места) появление такого окна:

Отступление: обращаю внимание, что кастомизированная система у меня заняла 3,3 ГБ, тогда как умолчальная инсталляция MX Linux развернулась бы чуть менее чем на 3,5 ГБ. То есть, при нынешних объёмах любых носителей, вся моя кастомизация дала грошовую экономию. Однако смысл её был в ином: избавиться от раздражающих меня «лишних» компонентов, которые по жизни иногда действительно оказываются лишними (как можно было видеть на примере с локалями).

В начальном окне «снапшоттера» следует обратить внимание на то, чтобы свободное место в каталоге /home было существенно больше, чем объём «снапируемой» системы: хотя размер итогового файла ISO-образа при заданных условиях составит около 1ГБ, места под временные файлы потребуется много. И если свободного места — менее чем вдвое против занимаемой системы — надо изменить каталог для размещения снапшота.

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

При желании можно отредактировать (в текстовом редакторе Leafpad) конфиг mx-snapshot‘а:

И список каталогов, подлежащих исключению из итогового образа:

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

После чего мог бы в течении некоторого времени наблюдать за ходом создания образа:

В моей виртуальной машине, настроенной как однопроцессорная, процедура заняла весьма длительное время (точно не засечённое, правда — но больше 20 минут). При работе в реале, как будет сказано позднее, оно оказалось много меньшим.

Так или иначе, но создание снапшота рано или поздно закончится. В моём случае — с таким результатом: в каталоге /home/snapshot образовался файл snapshot-20160218_1728.iso размером 1,0 ГБ (или 1 023 410 176 байт) и парный к нему файл с контрольной суммой snapshot-20160218_1728.iso.md5. Как нетрудно догадаться, цифирь в имени означает год, месяц, число создания снапшота плюс время начала процесса.

Оставалось проверить полученный образ на вшивость. Для чего он сначала был загружен в новую виртуальную машину (созданную тем же образом, и с теми же параметрами, что родительская система). Загрузка прошла без всяких яких, система оказалась идентичной исходной, за исключением того, что данные аккаунтов пользователя и администратора, как и было обещано, вернулись в первозданное состояние, как на образе, скачанном с сайта проекта. То есть — demo и demo, и root и root, соответственно.

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

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

Как известно, на виртуалку надейся, а в реале не плошай. И потому полученный образ был сначала скопирован на внешний диск с эмуляцией OD (поминаемый раньше Zalman ZM-VE300), а затем — на USB-флешку с помощью команды

# dd if=path2/snapshot...iso of=/dev/sd?

Никаких проблем ни с записью, ни с загрузкой, ни с инсталляцией (на реальный экспериментальный винчестер) не обнаружилось ни в одном случае. Обрадованный этим, я отправился делать снапшот своей рабочей инсталляции MX Linux в режиме бэкапа — для тренировки и просто на всякий пожарный случай. О чём — в следующем очерке.

MX Linux: backup’истый снапшот

Завершив минимизацию исходной системы MX Linu и запечатлев результаты в виде iso-образа, я решил опробовать mx-snapshot и для резервного копирования своей системы в индивидуализированном виде — со всеми необходимыми мне приложениями и настройками. Сама по себе процедура проходит практически так же — утилиту можно вызвать, например, через MX Инструменты в пункте Избранное главного меню:

После этого можно изменить каталог для размещения снапшота и убедиться, что места в целевом разделе достаточно для записи итогового iso’а и всего промежуточного хозяйства:

Далее следует отметить пункт Сохранение учётных записей — это автоматически включит в итоговый образ все подкаталоги ~/:

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

И после согласия с ним можно наблюдать за её ходом, обращая внимание на то, что эта задача действительно хорошо распараллеливается:

Либо идти курить, чтобы по возвращении увидеть сообщение об успешном завершении операции:

А закрыв его, можно ознакомиться со всеми деталями произошедших событий:

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

В последнем мне вскоре представился случай убедиться. Занимаясь кириллизацией системы в консольном режиме (кстати сказать, безуспешно), я обнаружил, что в MX Lunux, в отличие от родительской Jessie, используется sysvinit в режиме эмуляции systemd посредством пакета systemd-shim, аналогично LMDE2 Betsy. Каковой я попробовал заменить на чистый systemd, не смотря на всю свою «любовь» к этому произведению. И в результате, из-за собственной неаккуратности, благополучно развалил половину системы.

Разумеется, ситуация была поправима — но долго и нудно. И я решил опробовать в деле сохранённый не очень давно снапшот. Процедура восстановления прошла точно таким же образом, как и первичная инсталляция — с той только разницей, что в итоге я получил точную копию системы на момент её сохранения, со всеми установленными приложениями и настройками. Благодаря чему я окончательно проникся величием MX Linux.

В заключение замечу, что, хотя мы с Мануалом прикручивать MX-инструментарий к Ubuntu’идам не пробовали, но такой опыт имеется у viktor_ja — и опыт положительный (см. обсуждение на форуме Matuntu).