Поставив в Главе 4 точку в создании Малой Редакции системы Cintu, приступаем к увековечиванию её в виде образа посредством утилиты Systemback. Она во всех подробностях описана котом Мануалом. Поэтому ниже будет говориться только о том, что имеет отношение к созданию образа Cintu и записи его на установочный носитель.

Установка

Развитие Systemback’а прекратилось в 2016 году, и последняя его версия, доступная в PPA-репозитории, предназначена для Ubuntu Yakkety и её производных. Однако это не мешает программе успешно функционировать и в системах на базе 18.04 LTS, а несоответствие версий, вызывающее сообщение об ошибке при апдейте локального кеша, легко преодолевается.

Для начала подключаем репозиторий:

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

В apt версии от 1.6, используемой в Cintu, обновление локального кеша происходит автоматически при добавлении каждого PPA. Что в данном случае оказывается некоторым минусом, ибо гранаты пакеты systemback‘а у нас оказывается не той системы версии, и добавления репозитория не происходит.

Поэтому, во-первых, переименовывается соответствующий list-файл:

# /etc/apt/sources.list.d
# mv nemh-ubuntu-systemback-bionic.list nemh-ubuntu-systemback-yakkety.list

Во-вторых, редактируется его содержимое, например, так:

# xed nemh-ubuntu-systemback-yakkety.list

И в нём оба значения bionic заменяем на yakkety, в результате чего он приобретает следующий вид:

deb http://ppa.launchpad.net/nemh/systemback/ubuntu yakkety main
# deb-src http://ppa.launchpad.net/nemh/systemback/ubuntu yakkety main

В-третьих, тут уж от обновления локального кеша руками не отвертеться:

# apt update

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

# apt install systemback
# exit

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

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

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

Внимание: после запуска Systemback блокирует доступ к файлу /var/lib/apt/lists/lock. И, следовательно, во время его работы невозможно манипулировать пакетами любым способом.

После запуска для начала запрашивается пароль:

А после его ввода появляется главное окно программы:

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

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

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

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

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

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

В ней из левой части в правую нужно перенести те dot-файлы и dot-каталоги, которые не должны попасть в итоговый образ. То есть, с одной стороны, те, что могут содержать личную информацию (например,, Mozilla, .zhistory). А с другой — те, которые, возникнув самопроизвольно, не изменялись применителем. На скриншоте выше представлен пример.

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

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

И можно приступать к созданию образа. Но сначала —

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

Для начала нам потребуется установленная, настроенная и должным образом укомплектованная по части пакетов система — та самая, создание которой было завершено в Главе 4. Разумеется, в этой системе не обойтись и без Systemback’а — он должен быть установлен и настроен, как было описано в предыдущем разделе.

Далее, мы с Мануалом взяли за правило: перед использованием Systemback’в выполнить обновление системы и очистку её от продуктов жизнедеятельности. Что можно свершить с помощью универсальной утилиты сопровождения системы ucaresystem-core, которая подробно описана котом Мануалом.

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

$ sudo ucaresystem-core

Что можно сделать также через главное меню Cinnamon — из секции Прочие или из Избранного:

И после ввода пароля

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

А затем начинается работа сценария:

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

Завершается работа сценария сообщением об успехе этого предприятия:

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

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

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

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

Для чего нажимаем кнопку Live system create, чтобы оказаться в окне параметров будущего образа. Собственно, обязательный параметр здесь один — его имя. Например, cintu-18.04.1_1-se, где cintu — собственное имя системы, 18.04.1 — номер релиза базовой Ubuntu, se — Small Edition (то есть Малая редакция). Ну а последняя цифра — номер конкретной сборки. И, кроме того, не лишним будет отметить боксик включения пользовательских файлов:

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

Теперь можно нажимать кнопку Create new, после чего без всяких вопросов и подтверждений начнётся создание Live-системы, происходящее в три четыре стадии. Перовая — создание файловой системы будущего образа (Squashfs):

Вторая стадия, самая длинная — компрессия по алгоритму XZ:

Третья стадия — создание из компрессированной Squashfs образа cintu-18.04.1_1-se.sblive, который может быть записан на флешку или SD-карту (как — будет сказано в следующем разделе):

Четвёртая стадия — превращение его в образ стандарта ISO-9660, предназначенный для записи на оптический носитель:

Через некоторое время завершится сообщением об успехе всего предприятия:

На «двухпроцессорной» виртуальной машине (хост — с четырёхъядерным восьмипоточным процессором i7-4790K/4.00 ГГц) система, занимающая 4,5 ГБ, превращается в iso’шник за 11–12 минут. Зависимость от числа ядер и потоков процессора — почти линейная: при выполнении той же процедуры на хост-машине я едва успевал перекурить. Разумеется, такие результаты достигаются только при включении XZ-сжатия. При сжатии по умолчальному алгоритму GZ всё происходит медленно и печально, вне зависимости от числе процессоров.

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

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

Которые готовы к помещению на установочный носитель — оптический или твердотельный.

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

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

А вот второй образ нужно перенести на флешку, и сделать это можно только средствами самого Systemback’а. Да и то не сразу: если вставить флешку в USB-разъём сразу по завершении создания образов, она просто не опознается программой:

Для исправления этого нужно нажать на кнопку с изображением зелёной «загогулины». И тогда USB-накопитель будет виден в соответствующем фрейме окна программы, а кнопка Write to target активизируется:

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

Сама по себе запись произойдёт: казалось бы, почти мгновенно. Однако это будет лишь кеширование в оперативную память. А потому что потом начнётся процесс очистки кеша (то есть реальная запись) — и вот он будет продолжаться чуть ли не дольше, чем запись ISO-образа командой dd даже при размере блока по умолчанию (512 байт).

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

$ sudo cp cintu-18.04.1_1-se.iso /dev/sd?

И способ этот всегда работал безотказно. Но это будет потом — сначала iso-образ подвергается ьесчеловечному тестированию

Тестирование образа

Тестирование образа предваряется его выраскивание из виртуальной машмины на хост. Мы это делаем посредством Яндекс.Диска через WebDAV — как было описано в Главе 4. В данных условиях это оказалосб быстрее и проще, чем настраивать сетевое loopback-соединение хоста и гостя или устанавливать «гостевые дополнения» для прямого обмена между ними.

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

Вторая стадия — тестирование в условиях, приближенных к боевым. Под это дело на нашем резервном HDD отведён последний возможный раздел на 30 ГБ. А образ помещается на Zalman ZM-VE300 (описанный здесь), с которого и происходит загрузка. И, после просмотра в Live-режиме, система устанавливается на указанный раздел HDD.

Всё опять прохожит прекрасно — до перезагрузки из Live-режима в установленную систему: опять приходится выключать машину ввиду ошибки размонтирования «оптического привода». А в остальном, прекрасная маркиза…

Наконец, третья стадия — реальные полевые испытания. Поскольку эмулятор оптического привода, типа упомянутого ранее Zalman’а — девайс у применителей не частый, образ переносится на твердотельный носитель (в нашем случае — на SD-карту) командой

$ sudo cp cintu-18.04.1_1-se.iso /dev/sd?

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

Предварительное заключение

На этом Часть I Книги о Cintu заканчивается. Предварительным её итогом будет образ системы Cintu 18.04.1 Small Edition и описание процесса его создания.

В Части II мы рассмотрим вопросы установки системы, её донастройки и применения.