Дистрибутив Mageia традиционно ценится за предсказуемость, консервативную надёжность и верность классическим традициям Unix-подобных систем. Однако при развёртывании свежего выпуска Mageia 10 на современном оборудовании (мобильные процессоры Intel Core Ultra архитектур Arrow Lake, высокоскоростные накопители NVMe, экраны высокого разрешения с расширенным динамическим диапазоном) пользователь сталкивается с целым рядом неочевидных проблем — от периодических зависаний графического стола при записи на диск до перегрева, аварийного сброса частот процессора и блокировок сетевого трафика межсетевым экраном.
В настоящей статье систематизирован практический опыт глубокой инженерной доводки дистрибутива Mageia 10 до эталонного рабочего состояния на примере компактного ультрабука HONOR MagicBook Art 14 2025 (16-ядерный процессор Intel Core Ultra 7 255H, встроенный графический ускоритель Intel Arc, сенсорный OLED-экран 3120x2080 @ 120 Гц, твердотельный накопитель NVMe 1 ТБ с шифрованием LUKS (dm-crypt) и файловой системой Btrfs, графическая среда KDE Plasma 6 под управлением Wayland).
Каждая проблема изложена по одной схеме: симптом → причина → решение с командами → проверка результата. В конце каждого подраздела курсивом приведены поисковые теги — сформулированные так, как эту проблему обычно искал бы пользователь, ещё не зная её причины. Все команды проверены на живой системе; в примерах вместо имени пользователя подставляйте своё.
1. Базовая системная инициализация
1.1. Настройка прав суперпользователя (sudo)
В Mageia после установки обычный пользователь не включён в число доверенных администраторов: sudo ему недоступен, а без него не сделать и половины шагов этого гайда. Полномочия выдаются в два приёма: включение в штатную группу wheel (стандартный путь, применяется при следующем входе в систему — в /etc/sudoers строка %wheel уже раскомментирована) и отдельный drop-in-файл в /etc/sudoers.d/, который даёт sudo немедленно, без перелогина:
su - # вход под root (пароль root, заданный при установке)
gpasswd -a <имя_пользователя> wheel # включение в группу wheel
echo '<имя_пользователя> ALL=(ALL:ALL) ALL' > /etc/sudoers.d/<имя_пользователя>
chmod 0440 /etc/sudoers.d/<имя_пользователя>
visudo -cf /etc/sudoers.d/<имя_пользователя> # обязательная проверка синтаксиса
exit
Важное правило: любой файл в каталоге /etc/sudoers.d/ обязан валидироваться утилитой visudo -cf — вывод должен быть <файл>: parsed OK. Один файл с синтаксической ошибкой ломает sudo во всей системе целиком (парсер останавливается на первой ошибке и перестаёт принимать всё, включая корректные файлы). Поэтому правило такое: создали файл — тут же проверили.
🔎 Теги для поиска: mageia нет sudo, как включить sudo mageia, пользователь не администратор mageia, sudoers wheel, не работает sudo после установки
1.2. Сетевое имя компьютера (hostname)
После назначения имени машины через hostnamectl необходимо синхронизировать его с файлом статического разрешения имён /etc/hosts: без записи в строке 127.0.0.1 система не может отрезолвить собственное имя, и приложения при старте испытывают характерные технологические задержки (таймауты на каждом первом обращении к «себе»):
sudo hostnamectl set-hostname magicbook
# дописать имя в /etc/hosts к локальной петле 127.0.0.1:
sudo sed -i 's/^\(127\.0\.0\.1.*\)/\1 magicbook/' /etc/hosts
Мелочь, о которой легко забыть: уже открытый терминал продолжит показывать старое имя в приглашении — bash кэширует \h на момент запуска. Откройте новый терминал или выполните exec bash.
🔎 Теги для поиска: сменить имя компьютера mageia, hostname mageia, изменить имя хоста, приложения долго запускаются mageia, как назвать компьютер linux
1.3. Шрифты высокой чёткости
Метрически-совместимые свободные замены (Liberation, Carlito, Caladea) в Mageia 10 уже установлены — они решают проблему «поехавшей вёрстки» документов, но выглядят иначе, чем оригиналы. Готового пакета с настоящими шрифтами Microsoft в репозиториях нет (лицензия EULA не позволяет их распространять — как и в большинстве дистрибутивов). Официальный путь — самораспаковывающиеся пакеты corefonts (исходно от Microsoft, раздаются SourceForge):
sudo dnf install -y cabextract
cd /tmp && for f in andale32 arial32 arialb32 comic32 courie32 georgi32 impact32 times32 trebuc32 verdan32 webdin32; do
curl -fsSL -o "$f.exe" "https://downloads.sourceforge.net/corefonts/$f.exe"
done
sudo mkdir -p /usr/share/fonts/msttcore
for f in *.exe; do cabextract -L -q -d /tmp/ttf "$f"; done
sudo cp /tmp/ttf/*.ttf /usr/share/fonts/msttcore/ && sudo fc-cache -f
fc-match Arial # проверка: должно вывести Arial.ttf
Это покрывает Arial, Times New Roman, Courier New, Verdana, Georgia, Trebuchet, Comic Sans, Impact, Andale и Webdings. Свободного эквивалента Tahoma и Segoe UI не существует — их можно взять только из установленной копии Windows, скопировав в пользовательский каталог ~/.local/share/fonts/ с последующей пересборкой кэша fc-cache -f. После установки шрифтов перезапустите браузеры — они держат шрифтовые подстановки в памяти.
🔎 Теги для поиска: шрифты windows в linux, arial times new roman mageia, кривые шрифты на сайтах mageia, установить ms шрифты linux, msttcorefonts, шрифты в браузере выглядят иначе
2. Дисковая подсистема: ликвидация зависаний интерфейса и тонкая настройка Btrfs
2.1. Зависания графического окружения из-за планировщика BFQ на накопителях NVMe
Симптом: при интенсивной фоновой записи на диск (работа систем контроля версий, распаковка архивов, сброс кэша операционной системы, синхронизация облака) графический стол подвисает на 5–10 секунд — при этом курсор мыши продолжает плавно двигаться, создавая классическую иллюзию «зависшего рабочего стола при живой мыши». Проблема проявлялась только в Mageia 10 и отсутствовала в Debian и Manjaro на том же железе.
Причина — комбинация трёх факторов, все — специфика Mageia и этого контроллера:
- Главная: планировщик BFQ на NVMe. В ядре Mageia (
kernel-desktop) включён параметр сборки CONFIG_IOSCHED_DEFAULT_BFQ=y: Mageia назначает планировщик BFQ всем блочным устройствам без исключения, в отличие от других дистрибутивов, где быстрые NVMe работают на none (сквозные аппаратные параллельные очереди). BFQ сворачивает аппаратные очереди NVMe в одну логическую и для «справедливого» распределения полосы выдерживает технологические микропаузы slice_idle = 8ms. На скоростных накопителях при любой интенсивной записи контроллер захлёбывается в этой искусственной очереди, и процессы GUI (kwin_wayland, plasmashell, браузеры), пытаясь синхронно прочитать кэш или сделать мелкую запись, встают в непрерываемое ожидание ввода-вывода (состояние ядра D-wait). Курсор при этом движется: аппаратный указатель отрисовывается DRM-слоем ядра без дискового ввода-вывода.
- Усилитель: глубокое энергосбережение APST контроллера NVMe. Засыпание контроллера в глубокие фазы APST (Autonomous Power State Transition) и выход из них на ряде контроллеров (в частности, YMTC PC411) сопровождаются аппаратными задержками в десятки миллисекунд, которые на фоне BFQ складываются в заметные «подёргивания».
- Усилитель: дефолтный сброс «грязных» страниц. При 32 ГиБ ОЗУ порог по умолчанию (20 % памяти) позволяет накопить свыше 6 ГиБ несинхронизированных данных, которые файловая система Btrfs затем сбрасывает залпом каждые 30 секунд — прямо в узкое горлышко BFQ.
Решение — три шага:
- Правило udev
/etc/udev/rules.d/60-ioschedulers.rules, назначающее планировщик по типу накопителя: NVMe — none (аппаратные очереди), SATA/USB SSD — mq-deadline, магнитные HDD — bfq (там BFQ как раз уместен — он сглаживает позиционирование головок):
# Перевод накопителей NVMe на режим аппаратных параллельных очередей (none)
ACTION=="add|change", KERNEL=="nvme[0-9]*n[0-9]*", ENV{DEVTYPE}=="disk", ATTR{queue/scheduler}="none"
# Перевод твердотельных накопителей SATA и USB на mq-deadline
ACTION=="add|change", KERNEL=="sd[a-z]*", ENV{DEVTYPE}=="disk", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
# Назначение планировщика BFQ исключительно для магнитных жестких дисков (HDD)
ACTION=="add|change", KERNEL=="sd[a-z]*", ENV{DEVTYPE}=="disk", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"
Применить без перезагрузки и проверить:
sudo udevadm control --reload && sudo udevadm trigger --subsystem-match=block
cat /sys/block/nvme0n1/queue/scheduler # в квадратных скобках должно быть [none]
- Отключить задержку перед переходами энергосбережения APST контроллера NVMe — параметром ядра в
GRUB_CMDLINE_LINUX файла /etc/default/grub:
nvme_core.default_ps_max_latency_us=0
Применить на лету (до перезагрузки) и обновить конфигурацию загрузчика:
echo 0 | sudo tee /sys/module/nvme_core/parameters/default_ps_max_latency_us
sudo update-grub2
- Задать контролируемые пороги сброса буферов записи в файле
/etc/sysctl.d/99-dirty-writeback.conf:
# начало плавного фонового сброса при накоплении 512 МиБ
vm.dirty_background_bytes = 536870912
# принудительная блокирующая синхронизация при накоплении 2 ГиБ
vm.dirty_bytes = 2147483648
⚠️ Значения проверены опытным путём: занижать их не стоит. Пробный вариант 128 МБ / 512 МБ дал результат хуже дефолта — слишком частые мелкие сбросы помножаются на задержки LUKS+Btrfs. 512 МБ / 2 ГиБ — подтверждённый оптимум для системы с 32 ГиБ ОЗУ на Btrfs-корне.
Результат тестов: сброс и синхронизация 2 ГиБ случайных данных на шифрованный Btrfs-корень ускорились с 5–10 секунд блокирующего фриза до 0,13 секунды (sync), без малейших задержек интерфейса; синхронизация даже десятков гигабайт данных выполняется бесшовно.
🔎 Теги для поиска: зависает рабочий стол mageia, курсор двигается всё остальное висит, mageia подвисает при копировании файлов, фризы при записи на диск, nvme планировщик bfq, подвисает kde при работе с диском, mageia тормозит debian нет
2.2. Файл подкачки на Btrfs и гибернация при шифровании LUKS
На файловой системе Btrfs файл подкачки обязан иметь атрибут отсутствия копирования-при-записи (NoCoW) — CoW-файл ядро откажется активировать как своп (swapon: Invalid argument). Штатная утилита btrfs mkswapfile сама выставляет NoCoW и создаёт своп-сигнатуру, поэтому ручные трюки с chattr +C и dd не нужны:
# размер: минимум = объём ОЗУ (иначе гибернация невозможна), с запасом — 2× ОЗУ
MEM_KB=$(awk '/^MemTotal:/{print $2}' /proc/meminfo)
SIZE=$(( MEM_KB * 1024 * 2 )) # 2× RAM в байтах
sudo btrfs filesystem mkswapfile --size "$SIZE" /swapfile # сам делает NoCoW + mkswap
sudo swapon /swapfile
echo '/swapfile none swap defaults 0 0' | sudo tee -a /etc/fstab
Сразу полезно ограничить склонность к свопированию — при 32 ГиБ ОЗУ своп нужен только под реальным давлением памяти:
echo 'vm.swappiness=1' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl -w vm.swappiness=1
⚠️ Свопинг — это вес склонности, а не жёсткий триггер «свопить при заполнении X %». Полезный побочный бонус: файл подкачки лежит на LUKS-контейнере, поэтому содержимое свопа на диске зашифровано. Если своп «залип» (система висит при свободной RAM после пиковой нагрузки): sudo swapoff -a && sudo swapon -a (нужно достаточно свободной памяти).
Настройка гибернации (спящего режима с сохранением на диск) сквозь контейнер LUKS:
- Определение физического смещения первого блока файла подкачки — только штатной командой btrfs (
filefrag на Btrfs даёт неверное значение, использовать его нельзя):
sudo btrfs inspect-internal map-swapfile -r /swapfile # выведет число, напр. 14798603
- Определение идентификатора корневой файловой системы:
- Параметры в
/etc/default/grub в строку GRUB_CMDLINE_LINUX: при загрузке LUKS-контейнер уже расшифрован средствами initramfs, поэтому в resume достаточно указать UUID самой файловой системы корня:
GRUB_CMDLINE_LINUX="... resume=UUID=<UUID-корня> resume_offset=<число>"
- Пересборка начального образа и меню загрузчика:
sudo update-grub2
sudo dracut -f
⚠️ Mageia собирает классический (не systemd) initramfs по пути /boot/initrd-<версия-ядра>.img. Поэтому dracut -f печатает безобидные строки вида dracut[E]: Module 'systemd*' can't be installed — игнорировать их: нужные модули (crypt/luks, btrfs, resume) всё равно оказываются в образе. Проверить можно так: lsinitrd /boot/initrd-$(uname -r).img | grep -c crypt.
После перезагрузки проверить восстановление: systemctl hibernate. Если /sys/kernel/security/lockdown отсутствует, Secure Boot/lockdown гибернацию не блокируют.
🔎 Теги для поиска: swap файл btrfs, не создаётся swap btrfs, гибернация mageia, не работает гибернация linux, resume_offset, своп на btrfs luks, swapon invalid argument, спящий режим ноутбук linux
2.3. Автоматическая оптимизация твердотельного накопителя (fstrim.timer)
В Mageia 10 системный таймер еженедельной фоновой очистки блоков SSD (fstrim.timer) отключен по умолчанию, и корневая файловая система также монтируется без параметра discard=async (проверка: findmnt -o OPTIONS /). В долгую это означает деградацию скоростей накопителя — контроллер не знает, какие блоки свободны, и вынужден стирать их на ходу при каждой записи. Включение таймера:
sudo systemctl enable --now fstrim.timer
Таймер раз в неделю в фоне отправляет команду TRIM на все подключённые файловые системы, поддерживающие очистку.
Важное замечание для разделов LUKS: диспетчер dm-crypt по умолчанию блокирует прохождение TRIM сквозь криптоконтейнер (в целях безопасности — чтобы не раскрывать карту заполнения блоков). Чтобы команды очистки доходили до физического контроллера, в /etc/crypttab для соответствующего тома нужно указать флаг discard (например: crypt_root UUID=... none discard), после чего пересобрать initramfs (sudo dracut -f). Это компромисс: карта заполнения раздела становится видимой, что для домашнего ноутбука обычно не считается риском, а скорость и ресурс накопителя сохраняются.
🔎 Теги для поиска: ssd тормозит со временем, trim mageia, включить fstrim, ssd медленный linux, trim через luks, discard crypttab, ssd скорость падает
2.4. Ошибка загрузчика GRUB sparse file not allowed на Btrfs
Симптом: при каждом старте компьютера загрузчик печатает ошибку: error: ../../grub-core/commands/loadenv.c:216: sparse file not allowed. Она постоянная, но безвредная — загрузка продолжается.
Причина — грабли Btrfs. GRUB при старте читает свой файл переменных /boot/grub2/grubenv (команда load_env, размер 1024 байта), а Btrfs упаковывает столь мелкие файлы inline — прямо внутрь дерева метаданных (проверка: filefrag -v показывает флаг inline). Честные «разрежённые» файлы и inline-файлы GRUB не различает, поэтому принимает inline-файл за разрежённый и завершает чтение с ошибкой. Причём Mageia вставляет load_env в grub.cfg безусловно, поэтому одного отключения «запоминания последнего пункта меню» мало — файл нужно ещё пересоздать как обычный extent.
Решение — два шага:
# 1) отключить запоминание последнего пункта (чтобы grubenv больше не перезаписывался).
# Бонус: GRUB_DEFAULT=0 — всегда грузится первый пункт меню.
sudo sed -i 's/^GRUB_DEFAULT=.*/GRUB_DEFAULT=0/' /etc/default/grub
sudo sed -i 's/^GRUB_SAVEDEFAULT=.*/GRUB_SAVEDEFAULT=false/' /etc/default/grub
# 2) пересоздать grubenv как NoCoW-файл (реальный extent, а не inline):
sudo chattr +C /boot/grub2 # новые файлы в каталоге наследуют NoCoW
sudo rm -f /boot/grub2/grubenv
sudo grub2-editenv /boot/grub2/grubenv create
sudo chmod 644 /boot/grub2/grubenv
sudo update-grub2
# проверка — флага inline быть НЕ должно (пустой вывод = ок):
sudo filefrag -v /boot/grub2/grubenv | grep -i inline
Железобетонный запасной вариант: если ошибка осталась — просто sudo rm /boot/grub2/grubenv. Тогда GRUB пропустит load_env (проверка [ -f grubenv ] даст ложь), и ошибки не будет; с GRUB_SAVEDEFAULT=false файл заново не создастся. Проверять результат — по факту следующей загрузки: строки об ошибке быть не должно.
Попутно — быстрая загрузка. Если других ОС на диске нет, меню GRUB можно почти не показывать: в /etc/default/grub задать GRUB_TIMEOUT=1 (меню мелькнёт одну секунду — успеете нажать стрелку при необходимости) или GRUB_TIMEOUT=0 (меню скрыто, вызвать можно, держа при загрузке Esc или Shift). Меню можно сделать на весь нативный экран: GRUB_GFXMODE=3120x2080,auto (подставьте родное разрешение своей панели) — дефолтные 1024x768 заставляют GRUB обрезать фоновую картинку до 4:3.
🔎 Теги для поиска: grub sparse file not allowed, ошибка grub при загрузке mageia, grub ошибка btrfs, loadenv ошибка, убрать меню grub, ускорить загрузку mageia
