Истории про MX, UEFI и ноутбук. Часть 4: UEFI и установка KDE-редакции MX

Содержание
  1. Немного про UEFI
  2. Подготовка источника установки: утилита MX Live USB Maker
  3. Загрузка с флешки
  4. Запуск инсталлятора
  5. Рассуждения о дисковой разметке и дисковых разделах
  6. Установка: размечаем диск

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

Немного про UEFI

Как было сказано в частях 2 и 3 нашей Истории (то есть здесь и здесь), машины с UEFI получили в наши дни повальное распространение. И всё бы было ничего, пока не стали появляться сначала ноуты, а затем и системные платы, которые невозможно переключить на режим эмуляции BIOS’а. Причём такого оборудования с каждым днём становится всё больше. И в скором времени можно ожидать, что старый добрый BIOS Legacy «вымрет весь, как лошади Пржевальского».

В отличие от явлений, описанных во второй https://www.alvstory.ru/istorii-pro-mx-uefi-i-noutbuk-chast-2-tendencii-sovremennogo-linux-a/ и третьей https://www.alvstory.ru/istorii-pro-mx-uefi-i-noutbuk-chast-3-protivostoyanie-tendenciyam/ частях нашей Истории, никакие программные ухищрения в борьбе с UEFI не помогут.

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

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

Подготовка источника установки: утилита MX Live USB Maker

Устанавливается MX на UEFI-машины точно с тех же образов, что и на машину С BIOS’ом. Поскольку в наших Историях речь идёт о дистрах со средой KDE, и дело происходило в мае 2022 года, в данном случае это был, для оправдания высокого звания дистра semi-rolling, свежий файл образа MX-21.1_May_KDE.iso, который скачивался отсюда.

Теперь этот образ следовало записать на флешку. Ранее я всегда пользовался для этой цели либо утилитой dd, либо банальной командой cp. Однако, когда во время своих «альтернативных исканий» мне потребовалась запись iso-образов на флешки почти в промышленных масштабах, я опробовал графическую утилиту USB Image Writer из штатного комплекта Linux Mint. Остался доволен результатами и потому решил сейчас повторить опыт.

В штатный комплект любого варианта MX Linux входит утилита графического режима, назначение которой очевидно из её названия — MX Live USB Maker. Она входит в состав инструментария MX и запускается из соответствующего пункта главного меню:

Скриншот pt4_01

После чего в первую очередь требует авторизации:

Скриншот pt4_02

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

Скриншот pt4_03

Тут следует воткнуть флешку, которая сразу же высветится в пустом поле целевого носителя. Если этого не произойдёт — нужно нажать кнопку Обновить список накопителей. Если флешка была воткнута до запуска программы — поле будет уже заполнено. А затем выбрать образ, подлежащий записи — и нажать кнопку Далее. После чего наблюдать (при желании) процесс создания на флешке файловых систем и развёртывание образа:

Скриншот pt4_04

Процесс этот может продолжаться 10–15 минут (в рассматриваемом случае, при объёме образа чуть меньше двух гигабайт, он занял 11 минут 14 секунд). И завершится сообщением об окончании этого безнадёжного предприятия:

Скриншот pt4_05

После чего окно программы можно закрывать, а флешку вынимать и использовать по назначению. То есть любоваться MX Linux’ом «живьём» или устанавливать его на ПМЖ.

Всё сказанное выше относится к дистрибутивам проектов MX и Antix. Первых, как мы помним, в данный момент существует три официальных и несколько респинов от Сообщества, а из Antix’а, собственно и растут ноги всех MX-утилит. В число коих входит и MX Live USB Maker.

Для дистрибутивов MX и Antix утилита эта позволяет создавать так называемые «дозаписываемые флешки», о чём недвусмысленно свидетельствует пункт секции Mode, который так и называется — Full-featured mode — writable LiveUSB. Сама по себе штука эта очень полезная, но подробнее о ней я расскажу в другом месте.

Пока замечу только, что на такую флешку можно записать файлы, созданные в «живой» сессии (например, скриншоты процесса инсталляции), в каталог /MX-Live-usb/Live-usb-storage/demo/. И потом прочитать их на любой машине из каталога /media/$HOME/MX-Live-usb/Live-usb-storage/demo/.

Это не значит, что утилита наша не позволяет записать произвольный iso-образ какого-либо другого дистрибутива. Ещё как может — только о writable’ности придётся забыть, для чего переключить умолчальный «полнофишечный» режим на режим read-only LiveUSB.

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

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

Сначала каждую флешку, на которую записывался «посторонний» (то есть не MX’ный) образ, я проверял. Безуспешно — ни одного сбоя не обнаружилось. После чего было решено, что MX’ная утилита пишет флешки хорошо, и от проверок я отказался.

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

Всё сказанное позволяет рекомендовать данную MX-утилиту для записи более-менее любых образов. При этом совсем не обязательно иметь MX Linux установленным на машине: запись прекрасно проходит и в Live-сессии. Для чего, правда, требуется не меньше двух свободных USB-разъёмов.

Загрузка с флешки

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

Скриншот pt4_06

А также тем, что никакого выбора загрузчика оно не предлагает — GRUB в режиме UEFI only безальтернативен. Так что и заморачиваться на этот счёт применителю не приходится. Ему достаточно в пункте Language — Keyboard — Timezone выбрать язык: lang=ru_RU:Русский — Russian:

Скриншот pt4_07

Раскладки клавиатуры при этом сами собой установятся как kbd=us,ru, а часовой пояс, столь же нечувствительно, определится как tz=Europe/Moscow. Часовой пояс, конечно, можно, скорректировать, но в пределах от Калининграда до Якутска, да и то с пропусками. А жителям Свердловска (ныне известного как Ёбург) придётся отыскивать свой город в Азии.

Так что обитателям городов и весей нашей некогда необъятной Родины лучше побыть москвичами до конца инсталляции, а потом выправить временную зону средствами KDE. А пока вернуться в главное меню загрузчика:

Скриншот pt4_08

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

Запуск инсталлятора

Загрузка проходит без всяких неожиданностей и завершается появлением рабочего стола KDE вместе с окном приветствия, о котором сейчас говорить не будем, как и настройках «живьём». Потому что наша цель сейчас — поскорее начать установку и поглядет, чем установка на UEFI-машину отличается от установки на машину с BIOS Legacy.

Как мы помним, запустить инсталлятор можно либо щелчком на пиктограммке рабочего стола, либо нажатием кнопки Install MX Linux на панели приветствия:

Скриншот pt4_08

Кстати говоря, на панели приветствия имеется очень ценная подсказка — логин и пароль пользователя (demo:demo) и администратора (root:root).

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

Скриншот pt4_12

Тут начинается самый охмурёж — разметка диска. И это единственное, что отличает установку MX Linux (как, впрочем, и любого другого Linux’а) на UEFI-машину, от той же процедуры, выполняемой на машине с BIOS Legacy.

Рассуждения о дисковой разметке и дисковых разделах

Здесь надо твёрдо-натвердо затвердить две вещи. Первая — что для загрузки системы в режиме UEFI only, кроме раздела под корневую файловую систему, требуется ещё и своего рода загрузочный раздельчик (так называемый ESP — EFI System Partition) с файловой системой FAT32 (обязательно!), которая будет монтироваться в каталог /boot/efi.

И вторая вещь — не забыть этот раздельчик создать в процессе установки. Или заранее, с помощью утилит типа fdisk, cfdisk или Gparted, и определить его тип как EFI System. Впрочем, как мы скоро увидим, инсталлятор MX избавит нас от лишних хлопот, позаботившись об этом. А пока продолжим общие рассуждения.

В сети часто можно встретить мнение, что режим UEFI only требует обязательно разметки в GPT-стиле. По моим наблюдениям, никакой связи между UEFI-режимом и стилем разметки нет. UEFI-машина также благополучно грузится при разметке диска в стиле msdos. Важно только, чтобы на диске имелось два раздела, оба они были бы первичными и их типы были бы: EFI System на одном и Linux filesystem на другом.

Другое дело, что GPT-разметка сама по себе надёжней, и потому на новом (или приносимом в жертву со всем содержимым) HDD или SSD лучше создавать таблицу разделов GPT — в современных версиях утилит разметки это совсем не обременительно.

О размере EFI-раздела указания также противоречивы. Обычно советуют отводить под него сотни мегабайт, и даже не первые. В дистрибутивах, инсталляторы которых предусматривают автоматическое разбиение целевого носителя, под EFI-раздел отводится 300–500 МБ. Кажется, минимальное значение, которое мне встречалось, как раз в MX, составляет 250 МБ.

В то же время, если с помощью утилиты du, например, посмотреть реально занятое на таком разделе место, обнаруживается, что оно составляет 270–300 кило-(!)байт. И даже если предположить, что применитель будет держать по несколько дистрибутивов и в каждом активно экспериментировать с разными сборками ядра (что, между нами говоря, для применителей нашего профиля не характерно), то мегабайт 10–20 должно хватить.

Должен ли EFI-раздел быть первым (скажем, /dev/sda1)? Согласно всем известным мне сетевым данным, не обязательно. Да и при автоматической разметке он оказывается первым не всегда. Тем не менее, для себя я решил создавать его в первую очередь. Не из каких-то сакральных соображений — просто так меньше шансов забыть про него вообще.

Наконец, чтобы покончить с темой разметки и разделов — несколько слов о разделе подкачки, хотя она и не имеет отношения к UEFI-режиму вообще. До сих пор я почти всегда обходился без него, и ничуть от этого не страдал. Однако сейчас обнаружил его пользу: swap-раздел размером с объём ОЗУ (лучше чуть-чуть больше) позволяет отдавать машину в объятья Морфея вместо выключения.

То есть переходить в спящий (hibernation) режим, каковым я пренебрегал ещё с тех времён, когда на Linux-машинах он или работал не так, или не работал вообще. Сейчас, похоже, связанные с ним проблемы в прошлом, и отказываться от такой фишки, особо полезной на ноутах, оснований нет.

Установка: размечаем диск

Ну, кажется, с общими рассуждениями покончено окончательно. Так что переходим к банальной рутине — то есть дисковой разметке, каковой инсталлятор MX предлагает заняться первым делом. И предлагает сделать это в одном из двух режимов: автоматическом, с использованием всего целевого носителя (и уничтожением его содержимого, буде таковое имелось), или ручном (Customize the disk layout):

Скриншот pt4_13

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

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

Скриншот pt4_14

Дальнейшие действия некоторое время происходят без нашего участия: сразу после их одобрямса начинается создание файловых систем на целевом носителе (в том числе и EFI-раздела, sda1, объёмом 256 МБ) и развёртывания на нём дистрибутива:

Скриншот pt4_15

Процесс этот доходит до 94% и притормаживается:

Скриншот pt4_16

Но, не дожидаясь «тормоза» (или сразу вслед за ним) можно задавать параметры сети (имя машины и домен)

Скриншот pt4_17

и локализации — последние, при выборе перед загрузкой «в живую» русского языка (см. скриншот 8), скорее всего, уже установлены правильно:

Скриншот pt4_18

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

Скриншот pt4_19

При указании имени пользователя (оно же логин) и его пароля нужно только не забывать несколько простых правил: они должны включать только наичистейшу латиницу (первые 127 символов кодовой страницы) и не содержать проблев. На длину и вид пароля не накладывается никаких ограничений «снизу». То есть пароль типа 123 вполне допустим, инсталлятор не будет злобно ругаться ни на его краткость, ни на «простоту».

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

Надо обратить внимание на две опции, не включённые по умолчанию. Первая из них — Автологин, то есть беспарольный вход в рабочую среду через дисплейный менеджер (в нашем случае SDDM). Включать его или нет — зависит от подверженности применителя паранойе: существует устойчивая легенда, что автоматический вход в систему вреден для её безопасности. Для всех остальных автологин добавляет немного удобства.

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

В своё время, когда я впервые писал про MX Linux, именно наследование изменений, сделанных в Live-режиме, установленной системой восхитили меня больше всего. До того времени нечто подобное я встречал только в некоторых версиях Fedora и openSUSE, однако и там, и там эти фичи пропали без следа. Вот и я за шесть лет отрыва от MX Linux’а про них забыл…

Дальше всё просто и многократно описан: установка GRUB’а, завершение установки вообще, перезагрузка. И — проверка того, что нам наразбивал на SSD автомат:

Скриншот pt4_20

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

Автор: alv

Про себя напишу потом

Истории про MX, UEFI и ноутбук. Часть 4: UEFI и установка KDE-редакции MX: 4 комментария

  1. Алексей, доброго дня!

    Установил MX 21.1 KDE гостевой системой в VMware Workstation 15 Pro,
    всё прошло в штатном режиме, но изменить разрешение с дефолтного 1024×768 на любое другое не представляется возможным, даже при установленных open-vm-tools.

    Гуглёж подсказывает, что это фича KDE, возвращающая умолчальное разрешение, в других DE такой проблемы нет, нужное на выбор разрешение устанавливается. Есть у Вас свой способ решения такой проблемы?

  2. SfilD, я, правда, пользуюсь VirtualBox’ом, но проблема там всё та же. И общего способа её решения я не знаю. Более того, думаю, что его и нет — как в орлянке.
    Одно могу сказать совершенно точно: это НЕ фича KDE — в других дистрах это может быть с любым DE.
    И не связано с самим гостевым дистром, ни с дистром хост-машины, ни с версией VB. Ни даже со схемой инициализации.
    В общем, привык, и отношусь философски 🙂

Добавить комментарий