Усування проблем

Silverblue є радикально новим способом розгортання вашої операційної системи для робочих станцій та керування нею. Через це у вас можуть виникати проблеми зі щоденним користуванням нею. Нижче наведено список найпоширеніших проблем та способів їхнього розв’язання.

"Пропущені замінники пакунків базової системи"

Таке може трапитися, якщо нашарований пакунок має залежність від пакунка у базовій операційній системі. У проблемних випадках цей нашарований пакунок потребує новішої версії залежного пакунка, якої немає у базовій операційній системі.

У більшості випадків достатньо дочекатися новішої композиції OSTree для усування проблеми. Залежний пакунок буде оновлено у новій композиції, і нашарованим пакунком можна буде користуватися.

Втім, якщо проблема нікуди не зникне у новій композиції, ви можете спробувати вилучити усі метадані за допомогою команди rpm-ostree cleanup -m, а потім повторно спробувати виконати rpm-ostree install.

Крім того, ви можете спробувати перенести систему до будь-якого посилання updates, наприклад fedora/30/updates/x86_64, після дії cleanup.

Встановлення пакунків до /opt або /usr/local

Встановлення до /opt є типовою проблемою, коли користувачі намагаються встановити Google Chrome. Було реалізовано часткове вирішення, яке уможливлює для користувачів нашаровування Google Chrome. Втім, це не може бути рішенням для програм, які записують придатні до зміни дані до /opt.

Користування драйверами Nvidia

Користувачі вже давно прагнуть скористатися усіма можливостями графічних процесорів Nvidia у системах Silverblue. На щастя, нещодавні зміни у пакунках akmods і kmodtools, які було внесено Alex Larsson, уможливлюють звичайне встановлення драйверів Nvidia.

# rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia
# rpm-ostree kargs --append=rd.driver.blacklist=nouveau --append=modprobe.blacklist=nouveau --append=nvidia-drm.modeset=1

Докладніше про виконану Алексом роботу можна дізнатися з його блогу.

Проблеми із SELinux

Працюючи із Silverblue щоденно, користувачі можуть внести зміни до типових правил SELinux з метою обійти якісь проблеми, які пов’язано із SELinux. Зазвичай, користувачі вдаються до змін, якщо бачать у журналі якусь відмову у доступі з боку SELinux. Якщо такі зміни було внесено, а треба повернутися до типових правил SELinux, можете скористатися наведеною нижче послідовністю дій.

  1. Перевірте стан правил SELinux

    $ sudo ostree admin config-diff | grep policy
    M    selinux/targeted/active/policy.linked
    M    selinux/targeted/active/policy.kern
    M    selinux/targeted/policy/policy.31
    A    selinux/targeted/policy/policy.30

    Якщо унаслідок виконання цієї команди було виведено якісь повідомлення, ваші правила SELinux є відмінними від типових.

  2. Скопіюйте типові правила SELinux, які постачаються у композиції OSTree

    $ sudo cp -al /etc/selinux{,.bak}
    $ sudo rsync -rlv /usr/etc/selinux/ /etc/selinux/

    Після виконання цієї дії у результаті команди ostree admin config-diff | grep policy не повинно лишитися нічого, що вказує на зміну правил.

    Якщо команда повідомляє, що правила змінено, ви можете скористатися вказаним нижче підходом.

  3. Вилучіть правила SELinux; скопіюйте типові правила

    $ sudo rm -rf /etc/selinux
    $ sudo cp -aT /usr/etc/selinux /etc/selinux

    Після цього команда ostree admin config-diff | grep policy має повідомити, що ніяких змін до правил внесено не було.

Не вдається додати користувача до групи

Через спосіб, у який rpm-ostree обробляє записи «користувач + група», успішне додавання користувача до групи за допомогою usermod -a -G може стати неможливим. Аж доки rpm-ostree не буде переведено на використання systemd sysusers, користувачам доведеться заповнювати файл /etc/group на основі файла /usr/lib/group, перш ніж вони зможуть додати себе до групи. Наприклад, якщо вам потрібно додати користувача до групи libvirt:

# grep -E '^libvirt:' /usr/lib/group >> /etc/group
# usermod -aG libvirt username
Для застосування цих змін вам доведеться вийти з облікового запису і увійти до нього знову.

ostree fsck повідомляє про пошкодження файла

Може таке статися, що один або декілька файлів на диску буде пошкоджено або знищено. У такому випадку ostree fsck повідомлятиме про помилки у певних внесках. Обхідним маневром у цьому випадку є позначення усього внеску OSTree як частково отриманого і повторне отримання цього внеску.

Захист від запису /boot/efi заважає будь-якому оновленню

Ця проблема, здебільшого, виникає у користувачів, які встановлюють Silverblue на апаратне забезпечення Apple. Розділ /boot/efi на обладнанні Apple форматовано як HFS+, і він не завжди стійкий до вимикання живлення та інших типів проблем із живленням.

Оскільки до нової версії Silverblue до базової композиції включено пакунок hfsplus-tools, користувачам тепер набагато простіше усувати проблеми такого типу.

# umount /boot/efi
# fsck.hfsplus /dev/sda1
# mount -o rw /boot/efi

Див. додаткові подробиці можна дізнатися за вказаним посиланням.

Не вдається встановити Silverblue у системи з EFI

Користувачі повідомляли про неможливість встановити Silverblue на засновані на EFI, де раніше було встановлено іншу операційну систему. Повідомлення про помилку, яке часто спостерігали, виглядало так:

ostree ['admin', '--sysroot=/mnt/sysimage', 'deploy', '--os=fedora-workstation', 'fedora-workstation:fedora/28/x86_64/workstation'] exited with code -6`

Існує декілька можливих вирішень:

  • Під час процедури встановлення вибрати «Нетиповий поділ на розділи» і створити додатковий розділ EFI. Призначте для новоствореного розділу EFI точку монтування /boot/efi. Після цього ви зможете завантажувати ваші попередні операційні системи паралельно до Fedora Silverblue. Якщо цей варіант не спрацює, виконайте наведений нижче крок.

  • Переформатуйте розділ EFI у основній системі під час процедури встановлення. Зробити це можна вибором варіанта «Нетиповий поділ на розділи» із наступним позначенням пункту «Переформатувати» при створенні розділу /boot/efi.

Вибір варіанта із переформатуванням /boot/efi, ймовірно, зробить неможливим завантаження будь-яких інших раніше встановлених операційних систем. Переконайтеся, що вами створено резервну копію будь-яких важливих даних, перш ніж користуватися цим варіантом.

toolbox: failed to list images with com.redhat.component=fedora-toolbox

З версії podman 1.4.0 потреби у цьому обхідному маневрі немає. Переконайтеся, що встановлено актуальну версію podman, віддавши команду rpm-ostree upgrade, перш ніж намагатися скористатися цим обхідним маневром.

Якщо віддати команду toolbox list, системи, у яких встановлено podman версій, новіших за 1.2.0, призведе до такого повідомлення про помилку:

`toolbox: failed to list images with com.redhat.component=fedora-toolbox`
Наведений нижче варіант дій може бути корисним для інших помилок toolbox, які спричинено використанням версій podman, новіших за 1.2.0. Див. сховища Toolbox на Github

Обійти цю проблему можна заміною пакунків podman, які є новішими за версію 1.2.0, за допомогою такої команди:

$ rpm-ostree override --remove=podman-manpages replace https://kojipkgs.fedoraproject.org//packages/podman/1.2.0/2.git3bd528e.fc30/x86_64/podman-1.2.0-2.git3bd528e.fc30.x86_64.rpm

Перезавантажте систему для застосування змін.

Просто для довідки, замінити пакунок на якусь іншу версію можна за допомогою таких кроків:

  1. Отримайте podman-1.2.0-2.git3bd528e.fc30.x86_64.rpm з Koji

  2. Вилучіть podman-manpages за допомогою такої команди: rpm-ostree override remove podman-manpages

  3. Замінити поточну встановлену версію пакунка podman (на пакунок, який ви отримали на першому кроці) можна за допомогою такої команди: rpm-ostree override replace podman-1.2.0-2.git3bd528e.fc30.x86_64.rpm

Після цього систему можна перезавантажити, щоб зміни набули чинності.

Щоб повернути усе до типового стану, віддайте таку команду:

$ rpm-ostree override reset podman; rpm-ostree override reset podman-manpages

Не вдається увійти до toolbox через помилки із правами доступу

У певних версіях podman спроба увійти до toolbox призводить до повідомлення про помилку. Виправити помилку можна скиданням прав доступу до накладених контейнерів за допомогою наведеної нижче команди.

$ sudo chown -R $USER ~/.local/share/containers/storage/overlay-containers

Ця команда призведе до скидання прав доступу до ваших контейнерів і уможливлення входу до них.

Віддайте команду restorecon

Ніколи не запускайте restorecon у основній системі Silverblue. Подробиці наведено у цьому звіті щодо вади: https://bugzilla.redhat.com/show_bug.cgi?id=1259018

Втім, якщо ви вже віддали цю команду, систему ще можна відновити.

  1. Завантажте систему з enforcing=0 у командному рядку ядра

  2. Створіть новий «виправний» внесок локально

  3. Розгорніть новий «виправлений» внесок

  4. Віддайте команду restorecon

  5. Перезавантажте систему

  6. Виконайте очищення системи

    $ rpm-ostree status -b | grep BaseCommit
                    BaseCommit: 696991d589980aeaef5eda352dd7ad3d33c444c789c209f793a84bc6e7269aee
    $ sudo ostree checkout -H 696991d589980aeaef5eda352dd7ad3d33c444c789c209f793a84bc6e7269aee /ostree/repo/tmp/selinux-fix
    $ sudo ostree fsck --delete
    $ sudo ostree commit --consume --link-checkout-speedup --orphan --selinux-policy=/ /ostree/repo/tmp/selinux-fix
    $ sudo restorecon -Rv /var
    $ sudo restorecon -Rv /etc
    $ sudo ostree admin deploy fedora-atomic:fedora/30/x86_64/silverblue
    $ sudo reboot

Проблема такого способу відновлення полягає ту тому, що усі ваші нашаровані пакунки буде вилучено — вам доведеться знову нашарувати їх після відновлення.

Подробиці можна знайти у описі цього внеску до сховища основного коду: https://github.com/ostreedev/ostree/issues/1265#issuecomment-484557615