ReadySet: что ломалось

Разбор двух проблем мастера первой настройки: мастер возвращался при каждом входе, а выбранные в нём приложения не ставились. Как работает мастер для пользователя, написано на странице ReadySet.

Мастер возвращался при каждом входе#

Симптом. После каждого входа мастер просил создать пользователя. Пользователей в системе было несколько.

Как ReadySet выбирает режим. Режим зависит от того, состоит ли процесс в группе ready-set (проверка getgroups): в группе значит режим initial-setup (создание пользователя), иначе existing-user (настройка существующего). Группы ready-set и gnome-initial-setup служебные: у них права polkit без пароля, они принадлежат временному пользователю мастера. Менеджер входа добавляет _greeter в ready-set.

Причина. Всех обычных пользователей (UID от 1000) добавляли в группу gnome-initial-setup, потому что шаги мастера ещё не поддерживали режим existing-user. В этом режиме ReadySet показывает только шаги, которые реализуют ReadySet.ExistingUser, и финализатор existing-user не вызывает apply(): он только записывает выполненные шаги в GSettings org.altlinux.ReadySet. Группа выдавала всем права initial-setup и ломала режим мастера.

Исправление.

• Все шаги реализуют ExistingUser и применяют настройки в BasePage.try_continue (continue_from, затем apply.begin). Шаги AMD, голосового ввода и источников приложений применяются один раз за запуск.
• Шаг «Добро пожаловать» ставит метку readyset-first-run-done при нажатии «Далее».
• В образе скрипт ensure-groups.sh снимает пользователей с групп ready-set и gnome-initial-setup, а группы _greeter задаёт grpconf.d/atomic-niri-plafon.yml (группы оборудования для обычных пользователей уже в базе APM).
• Тесты: tests/unit/test_readyset_groups.py, проверка первой загрузки в контейнере, tests/test_existing_user.py в плагинах, tests/test_first_run.vala.

Группы настраиваются конфигом /usr/share/apm/grpconf.d/*.yml и командой apm s i sync-groups (при загрузке её выполняет sync-users.service).

Выбранные в мастере приложения не ставились#

Симптом (issue #30). В мастере выбрали приложения, а после установки не поставилось ни одно из выбранных. Базовый набор поставился.

Причина. Remote flathub был только в системной области (его добавляет flatpak-setup на шаге «Источники»). А выбранные приложения каталог ставит через Booster в пользовательскую область: flatpak --user install flathub <id>. Без пользовательского remote команда отвечает: «Для 'flathub' не найдено удалённых ссылок». Базовый набор ставит системный flatpak-setup, поэтому он и проходил. На машине автора пользовательский remote был создан вручную, поэтому не воспроизводилось.

Первое исправление оказалось недостаточным. Добавили flatpak --user remote-add. На актуальной сборке ALT (gnupg2 2.5.20, libostree 2026.4, flatpak 1.18.4) эта команда падала у любого пользователя: «GPG: fchown: Операция не позволена». Под strace проходила, то есть дело в гонке или окружении, причину в gnupg не искали.

Рабочий путь (проверен реальной установкой на чистой виртуальной машине):

1. flatpak --user remote-add --if-not-exists --no-gpg-verify flathub <адрес системного remote>;
2. скопировать /var/lib/flatpak/repo/flathub.trustedkeys.gpg в <пользователь>/repo/;
3. flatpak --user remote-modify с включением проверки подписи.

Зеркало берётся из системного remote. Исправление в Booster (FlatpakService.ensure_user_flathub) и в readyset_apply_flatpaks.py. Побочная находка: в тестовом файле run_all() стоял посреди файла, и часть тестов в CI не выполнялась. Теперь он в конце.

Установка из Live ISO на машине с малым объёмом памяти#

Симптом. При установке из live-образа на компьютере с 8 ГБ ОЗУ установка падала: «no space left on device». С 16 ГБ проходила.

Причина. В live-сессии верхний слой оверлея это tmpfs, его размер равен половине ОЗУ. Служба flatpak-setup скачивала в него 3,4 ГБ Flatpak-приложений, и для слоя образа в /var/tmp не оставалось места.

Исправление. В рецепте live-сессии (10-live-session.yml) маскируются flatpak-setup и lactd. Проверка на виртуальной машине с 8 ГБ: Flatpak в live занимает 20 КБ, занято 1,2 ГБ ОЗУ, установка проходит.

Метод проверки без GPU. Графическое приложение в QEMU без ускорения запускается через cage с рендерером pixman (systemd-run с PAMName=login), снимки экрана берутся через screendump монитора QEMU, клики через input-send-event.

См. также: находки по образу, установка.