Как было сказано в предыдущем очерке, установить Cintu на UEFI-машину со стандартного образа можно без особых напрягов. Однако не намного сложнее и изготовить образ этой системы с «искаропачной» поддержкой установки на UEFI. Что может стать актуальным — ведь рано или поздно машины со стандартным BIOS’ом выйдут из строя, а новые — когда-нибудь утратят способность к переключению в режим Legacy.

Предпосылки и подготовка

Вот мы с котом Мануалом и решили заранее подготовиться к этому светлому будущему. Ведь всем известно — неприятности, к которым готов, никогда не происходят. Происходят совсем другие неприятности, к которым, как всегда, оказываешься не готовым.

Для сборки UEFI-образа Cintu, как и в «стандартном» случае, необходим образ mini.iso, содержащий суперминималистическую систему Ubuntu: ядро системы, её установщик, работающий в текстовом режиме и потому называемый ныне альтернативным, и средства конфигурирования сети — всё остальное получается из официальных репозиториев. Образ этот, размером нынче более 60 МБ (в скобках прописью — мегабайт) обновляется обычно раз в неделю. Но актуальный его вариант всегда можно отыскать в официальном репозитории Ubuntu (или на любом из зеркал) здесь:

/dists/[codename]/main/installer-amd64/current/images/netboot

В частности, текущий mini.iso для будущего релиза 18.04 скачивается отсюда. И здесь уместно добавить, что аналогичный образ существует и для 32-битной архитектуры.

Стандартная установка с mini.iso неоднократно описывалась на Блогосайте. А со временем во всех деталях будет и на этом сайте. Так что здесь и сейчас мы остановимся только на тех моментах, которые раньше не были озвучены или важны в контексте сбоки Cintu именно для UEFI-машины.

Чтобы подготовить образ Cintu (в любом её варианте), необходимо для начала создать «систему-матку», из которой образ этот будет лепиться. Сделать это проще всего в виртуале — мы на сей предмет используем Virtualbox. И здесь сразу после создания виртуальной машины необходимо перво-наперво Включить EFI. Делается это через главное меню Virtualbox’а — Машина — > Настроить — > Система, вкладка Материнская плата:

Если хост-машина имеет многоядерный и (или) многопоточный процессор, то целесообразно здесь же, во вкладке Процессор, задать их число более одного. Со своим четырёхъядерным и восьмипоточным «камнем» я устанавливаю значение 4 — Virtualbox не различает физические ядра и потоки. Разумеется, в пункте Носители в качестве источника установки следует указать mini.iso прочие параметры виртуальной машины рояля не играют. Впрочем, всё это в деталях кот Мануал изложил в своих Воззрениях.

Загрузка

Теперь виртуальную машину можно загружать, в результате чего появляется меню альтернативного установщика:

Для наших целей из этого меню теоретически подходят два пункта: Command line install и Command line expert install. Ранее я всегда обращался ко второму из них. Но кот Мануал убедил меня, что результат в итоге получается идентичным, только в первом пункте он достигается гораздо быстрее. И в общем случае казалось, что это действительно так, почему мы и остановились на первом варианте. Однако в данном конкретном случае, по причинам, выявленным в ходе установки, следовало бы избрать второй вариант. Знакомство же с инсталлированной системой это мнение только подкрепило.

Так или иначе, в обоих случаях нажимать Enter сразу не следует: надо чуть подредактировать параметры загрузки, для чего мы перешли в редактор, нажав клавишу e после выбора пункта Command line install:

И здесь в строку

	linux [тра-та-та]

нужно вписать параметр pkgsel/include=network-manager. Подозреваю, что не особо важно, куда, но мы добавили его после прочих pkgsel‘ов:

Как нетрудно догадаться, этот параметр обеспечивает принудительную установку пакета network-manager и его задействование при первой загрузке — в противном случае управление сетью будет осуществляться через systemd. И это обеспечивало нам немало развлечений при настройке сети во всех сборках Cintu, основанных на systemd’изированных релизах Ubuntu. Пользуясь случаем, выражаю признательность Сергею aka SergB, комментарии которого к одному из материалов Блогосайта помогли победить эту проблему.

В качестве значений параметра pkgsel/include можно добавить и другие пакеты, нужные, но не входящие в метапакет ubuntu-minimal. Однако мы с Мануалом решили ограничиться только абсолютно необходимым NM. Потому как в одной из предыдущих попыток я дописал туда все консольные приложения, которые обычно устанавливаю между первым запуском и инсталляцией Иксов. И в результате получил кучу сообщений об ошибках, закончившихся крахом установки.

Установка

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

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

Впрочем, в установленной системе выявились и другие огрехи русификации. Например, после перезагрузки сбрасываются кириллические шрифты на 1-й виртуальной консоли (на остальных 5-ти — рестарт переживают). А изменение локали en_US.UTF-8, образовавшейся после англоязычной инсталляции, на требуемую нам ru_RU.UTF-8 командой

$ sudo dpkg-reconfigure locale

наоборот, приводит к смене русскоязычного интерфейса среды Cinnamon на английский (что, впрочем, поправимо).

Похоже, в Canonical’е доброй традицией становится — ломать русификацию системы накануне LTS-релиза. Остаётся надеяться, что, как и в прошлый раз, перед выходом Ubuntu 16.04 Xenial, ситуация, хоть и в последний момент, но будет исправлена. Кстати, тогда нам казалось, что это навсегда…

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

После этого можно видеть, что диск действительно «чист», то есть не несёт на себе никакой таблицы разделов:

Следующим шагом её предлагается создать:

Часто в сети можно прочитать, что целевой диск UEFI-машины должен быть обязательно размечен в стиле GPT. Это не более чем устойчивый предрассудок — система с поддержкой UEFI прекрасно размещается и на диске с таблицей разделов в стиле MSDOS. Каковой по умолчанию создаётся альтернативным установщиком Ubuntu. Так что отказываться от предложения никаких причин нету. С вот таким результатом:

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

Один из разделов, так называемый EFI System Partition (ESP), обязательно должен нести файловую систему vfat, имеющую точкой монтирования каталог /boot/efi, а на счёт его размера в сети можно найти противоречивые рекомендации. Впрочем, это тот редкий случай, когда при создании разделов имеет смысл положиться на автоматику — результат будет выглядеть так:

Теперь, после согласия со всеми предупреждениями, начнётся установка. В ходе её время от времени будут предлагаться варианты, в которых мы принимали все умолчания. Кроме одного — вместо русского зеркала репозиториев Ubuntu был выбран официальный сайт проекта. Ибо для предрелизной стадии (а для 18.04 она пока такая и есть) бывали случаи, когда изменения в пакетах до зеркал не доходили.

Дело завершится предложением, от которого невозможно отказаться — перезагрузить машину. Перезагрузка её в UEFI-режиме при одной системе проходит совершенно нечувствительно, и завершается выводом приглашения командной строки. Теперь предстоит работа по претворению «голой» системы CLI only в десктоп Cintu с её средой Cinnamon.

Претворение в десктоп

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

$ sudo dpkg-reconfigure console-setup

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

$ sudo apt install zsh gpm

Теперь копирование конфигов Zsh — последнее время ы делаем это командой wget с файлопомойки на собственном сайте. И смена командной оболочки:

$ chsh -s /bin/zsh

Далее — установка архинужного и архиважного пакета software-properties-common — без него сложно добавлять ppa-репозитории:

$ sudo apt install software-properties-common

Абсолютно необходимых PPA-репозиториев, без использования которых Cintu — не Cintu, всего три, остальные полезности можно добавлять по ходу дела:

$ sudo -s
# add-apt-repository ppa:gwendal-lebihan-dev/cinnamon-nightly
# add-apt-repository ppa:nemh/systemback
# add-apt-repository ppa:utappia/stable

Последний из них содержит утилиту ucaresystem-core, без которой мы с Мануалом нынче жизни не мыслим.

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

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

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

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

# nano 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 xorg

Затем делается такой финт ушами:

# apt install tint2

Фигурирующий здесь пакет — простая панель запуска задач (taskbar), нужная только для обеспечения fallback-режима, собственное средство для этого в Cinnamon отсутствует. Так что без tint2 было бы установлено одно из альтернативных предложений — mate-panel (по умолчанию) или gnome-panel. И любое из них потянуло бы массу зависимостей из соответствующих сред, более ни для чего в Cintu не нужных.

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

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

# apt install cinnamon

А в придачу — самый подходящий для неё дисплейный менеджер:

# apt install mdm

Всё, можно перезагружать машину, дабы после авторизации в графическом режиме почувствовать вкус «корицы».

Образ и его применение

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

Первая задача была решена шутя благодаря следованию «Воззрениям кота Мануала на Systemback» — благо они содержали специальный раздел. А благодаря включению виртуальной «четырёхпроцессорности» и использованию XZ-сжатия образа (которое хорошо распараллеливается) заняло это буквально считанные минуты.

Не сложнее было и с установкой системы в виртуальной машине. Процесс этот опять же подробно описан в Воззрениях. Так что самое главное было — не забыть про включение EFI в Virtualbox’е до установки, и про создание ESP в её процессе — но это было описано в предыдущем очерке. Правда, он был не таким быстрым, как хотелось бы: виртуальные машины моего «хостового» десктопа располагаются на старом и медленном винчестере. Тем не менее, после установки не обнаружилось никаких проблем, в том числе и с сетью: Network Manager заработал «искаропки».

Наступил момент третьего свершения — проверки установки образа и работы системы на реальном «железе». Что, как известно всем заинтересованным лицам, отличается от установки и работы в виртуалке так же, как бег по пересечённой местности — от бега по асфальту в мешках.

В принципе в моей ныне единственной машине на единственном сохранившемся в ней SSD имелся последний свободный раздел, специально предназначенный для таких целей. Вот только машина эта — ни разу не UEFI, работала в режиме Legacy и несла на себе, в том числе, и мою рабочую систему (в которой сейчас сочиняются эти строки). Что попутно поставило ещё одну интересную задачу: а можно ли с образа, представляющего собой, в сущности, снапшот UEFI-системы, установить (тем же «снапшотным» методом) систему «BIOS’ную»? И если можно, то насколько сложно? Ведь обратная задача, как говорилось в прошлом очерке, была решена, и достаточно просто: потребовалось лишь загрузиться в Live-режиме и ввести несколько команд.

Однако прямая задача не решилась просто. Потому что он не потребовала решения от слова вообще: UEFI-система установилась на машину с «BIOS’ом» так, как будто для неё и была сделана. Представ пред нами вот в таком виде:

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

Вердикт

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

И потому мы с котом Мануалом посоветовались и решили: впредь готовить только UEFI-образы, которые будут основой разных редакций Cintu. Правда, результаты нашего творчества в открытый доступ решили пока не выкладывать. Во-первых, наш образ не лишён некоторых шероховатостей, связанных с тестовым характером и базиса (то есть ubuntu-minimal), и «настройки» (среды Cinnamon). И можно надеяться, что они сгладятся в ближайшее время.

Во-вторых, копание в установленной системе выявило некоторые её недочёты, связанные с методом установки. В частности, при инсталляции в экспертном режиме запрашивается, какой из вариантов ядра устанавливать (их довольно много), тогда как в «стандартном» режиме без всяких яких устанавливается signed-версия, что мы с Мануалом полагаем позорным и преступным.

В-третьих, наша сборка образа — это даже не mini-редакция, а некая супер-мини, к практическому применению не пригодная. А заниматься её доукомплектацией на данном этапе мы полагаем нецелесообразным. И потому в деле подготовки «общедоступных» сборок решили подождать хотя бы 2-й беты, а то и релиза. К коему, кстати, можно ожидать и обновления среды Cinnamon до очередной версии (3.8), как всегда бывало ранее.