Алексей Федорчук - Linux Mint и его Cinnamon. Очерки применителя

А команда

# mount | grep /home

покажет нам новые точки монтирования файловых систем:

tank/home on /home type zfs (rw,noatime,noxattr) tank/home/alv on /home/alv type zfs (rw,noatime,noxattr) tank/home/proj on /home/proj type zfs (rw,noatime,noxattr) ...

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

Здесь речь пойдёт о том, как подключить к некоей Linux-системе (конкретно, Ubuntu) пул ZFS, ранее созданный в другой системе — теоретически это могут быть Solaris, FreeBSD или более иной дистрибутив Linux, для которого предусмотрена поддержка ZFS on Linux. Но практически я опробовал только последний вариант, о чём и расскажу.

Перво-наперво нужно перезагрузиться в ту систему, в которой создавался пул (в моём случае это была openSUSE), и экспортировать его командой:

# zpool export data

где data — имя пула с точкой монтирования /home/data.

Следующий шаг — вернуться в Ubuntu и создать в ней аналогичную точку монтирования для пула ZFS — в моём случае таким образом:

$ sudo mkdir /home/data

Дать ей атрибуты принадлежности обычному пользователю:

$ sudo chown -R alv:alv /home/data

И импортировать созданный в openSUSE пул ZFS:

$ sudo zpool import -f data

Не забыв об опции -f, предписывающей принудительной выполнение импорта. Без неё ответом на эту команду будет сообщение об ошибке.

Теперь в каталоге /home/data можно видеть те же самые файловые системы ZFS, которые были созданы в родителькой для пула системе, вместе со всеми размещёнными в них данными. С которыми можно начинать работать.

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

Последний очерк посвящается апофеозу знакомства с дистрибутивом Mint и его Cinnamon — сборке индивидуализированной системы на его основе. Как сказал то ли один из премьер-министров Великобритании, то ли некий президент Франции (кому только это изречение ни приписывали?):

Тот, кто в (информационной) юности не мечтал собрать свой дистрибутив Linux'а, не имеет сердца. Тот, кто продолжает мечтать об этом в (информационной) зрелости — не имеет разума.

Однако применительно к Linux Mint вполне возможно сочетать сердечность и разумность даже в преклонные годы, ибо собрать свою индивидуализированную систему на базе этого дистрибутива и просто, и полезно.

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

В сети можно найти упоминания о нескольких инструментах для изготовления собственного дистрибутива на базе Ubuntu и её производных (а Mint, как известно, принадлежит к их числу):

• oem-config-remaster — утилита командной строки, позволяющая сделать снапшот установленной системы;

• remastersys — утилита для резервного копирования установленной системы и создания на её базе Live-носителя; именно таким образом собирается, например, дистрибутив Matuntu— отечественный вариант Ubuntu с MATE в качестве рабочей среды;

• Ubuntu Builder-- программа с графическим интерфейсом, позволяющая скомпоновать свой дистрибутив попакетно.

Однако первые две показались мне сложноватыми и избыточными для моих целей, а последняя, похоже, прекратила своё развитие — версии её для Ubuntu Trusty, на которой основываются текущие релизы Mint, в PPA-репозитории не обнаружилось.

И в итоге я остановился на программе Ubuntu Customization Kit (далее — UCK): гугление показало, что это примерно то, что мне нужно, ибо специально предназначается для коррекции состава пакетов в первую очередь.

Программа UCK в виде одноимённого пакета имеется в официальном репозитории, и потому может быть установлена любым из стандартных способов. После этого в секции Администрирование главного меню Cinnamon появляется пункт, который, как ни странно, называется Ubuntu Customization Kit, через который эту программу и можно запустить. Но прежде чем смотреть, что она после этого делает, попробуем представить, что у неё внутре.

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

• монтирование образа как loop-устройства;

• развёртывание её файловой системы — нынче все дистрибутивы используют какой-либо механизм компрессии, в частности в убунтоидах это SquashFS;

• монтирование в loop-систему как связанных (bind) таких служебных, но абсолютно необходимых каталогов материнской системы, как /dev, /sys и, на всякий случай, /proc;

• выполнение операции chroot в loop-каталог, становящийся таким образом корневым;

• выполнение в chroot-окружении необходимых действий по удалению ненужных пакетов и установке необходимых;

• выход из chroot-окружения и обратная запаковка loop-каталога;

• размонтирование loop-устройства и создание из него загрузочного iso-образа с помощью isolinux.

Интуитивно понятно, что UCK не делает ничего иного, кроме перечисленного — он просто автоматизирует описанный процесс, делая его этапы почти незаметными для применителя.

Основные исполняемые файлы пакета uck (а их 16 штук) собраны, понятное дело, в каталоге /usr/bin и имеют префикс uck-*. Все они являются самыми обычными шелл-скриптами, причём по их именам легко догадаться о назначении каждого. «Головным», то есть запускающим весь процесс скриптом является /usr/bin/uck-gui — именно он вызывается через пункт меню Администрирование -> Ubuntu Customization Kit:

А через редактор меню можно посмотреть на его свойства:

По скриншоту можно догадаться о присутствии в строке запуска опции --wait-before-exit, отвечающей за ожидание нажатия Enter перед выходом из программы после успешного завершения её работы.

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