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

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

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

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

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

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

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

Щоб дізнатися більше, див. rpm-ostree#415.

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

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

Стежити за усуванням цієї вади можна на сторінці rpm-ostree#233.

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

Ви можете встановити офіційні закриті драйвери NVIDIA зі сховищ RPM Fusion.

Проєкт Fedora не здійснює супроводу закритих драйверів NVIDIA, тому, можливо, вони є недоступними для версії ядра, яка є частиною Fedora Silverblue.
Проєкт Universal Blue створює образи операційної системи для Fedora Silverblue із включеними драйверами NVIDIA. Образи Universal Blue засновано на офіційних образах Fedora із додатковими змінами від авторів дистрибутива. Образи Universal Blue не мають офіційного схвалення від Проєкту Fedora. Відповідальність за користування ними покладається на вас.

  1. Спочатку, забезпечте повне оновлення вашої системи за допомогою команди sudo rpm-ostree upgrade і перезавантажте її.

  2. Then setup the RPM Fusion repositories following the documentation, including the two reboots.

  3. Нарешті, встановіть драйвери:

    # 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
# systemctl reboot
When using Secure Boot, the locally installed NVIDIA drivers have to be signed with a local key that is enrolled using mokutil. See the fedora-silverblue#499 issue for more details.

Крім того, у вас можуть виникнути такі проблеми під час встановлення: #286, #331

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

Сторонні модулі та драйвери ядра, що використовують DKMS

У поточній версії Fedora Silverblue не передбачено підтримки DKMS. Див. сторінку вади rpm-ostree#1091.

Рекомендуємо вам створити пакунки kmods для сторонніх модулів ядра і надіслати їх до сховищ RPM Fusion. Пакунки kmods згодом буде використано akmods, підтримку якого у Fedora Silverblue реалізовано.

Додавання зовнішніх сховищ пакунків

У цьому розділі описано роботу зі сторонніми джерелами програмного забезпечення, які офіційно не пов’язано із Проєктом Fedora, і які не схвалюються цим проєктом. Відповідальність за використання цих джерел покладається на вас.
Якщо ви хочете скористатися сховищами RPM Fusion, будь ласка, ознайомтеся із розділом щодо вмикання сховищ RPM Fusion.

Доступ до частини програмного забезпечення можна отримати лише зі сторонніх сховищ. Ви можете додати стороннє сховище до Fedora Silverblue вручну за допомогою файла .repo у /etc/yum.repos.d/ та ключа GPG у /etc/pki/rpm-gpg/. Нижче наведено приклад повного налаштовування сховища Taiscale:

  1. Отримання і встановлення налаштувань сховища:

    $ curl -O https://pkgs.tailscale.com/stable/fedora/tailscale.repo
[tailscale-stable]
name=Tailscale stable
baseurl=https://pkgs.tailscale.com/stable/fedora/$basearch
enabled=1
type=rpm
repo_gpgcheck=1
gpgcheck=0
gpgkey=https://pkgs.tailscale.com/stable/fedora/repo.gpg
$ sudo install -o 0 -g 0 -m644 tailscale.repo /etc/yum.repos.d/tailscale.repo

  2. Отримання і встановлення ключів GPG:

    $ curl -O https://pkgs.tailscale.com/stable/fedora/repo.gpg
$ sudo install -o 0 -g 0 -m644 repo.gpg /etc/pki/rpm-gpg/tailscale.gpg

  3. Замініть адресу gpgkey= у налаштуваннях сховища шляхом до ключів GPG:

    $ sudo $EDITOR /etc/yum.repos.d/tailscale.repo
$ cat /etc/yum.repos.d/tailscale.repo
[tailscale-stable]
name=Tailscale stable
baseurl=https://pkgs.tailscale.com/stable/fedora/$basearch
enabled=1
type=rpm
repo_gpgcheck=1
gpgcheck=0
# Update this line
gpgkey=file:///etc/pki/rpm-gpg/tailscale.gpg
#      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  4. Встановіть нові пакунки за допомогою таких команд:

    $ rpm-ostree install tailscale

Стежити за реалізацією кращої підтримки rpm-ostree можна на сторінці rpm-ostree#4014.

Проблеми із SELinux

Працюючи із Fedora 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 | sudo tee -a /etc/group
$ sudo usermod -aG libvirt $USER
Для застосування цих змін вам доведеться вийти з облікового запису і увійти до нього знову.

Стежити за усуванням цієї вади можна тут: rpm-ostree#29 і rpm-ostree#49.

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

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

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

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

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

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

Див. rpm-ostree#1380, щоб дізнатися більше.

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

Користувачі повідомляли про неможливість встановити Fedora 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, ймовірно, зробить неможливим завантаження будь-яких інших раніше встановлених операційних систем. Переконайтеся, що вами створено резервну копію будь-яких важливих даних, перш ніж користуватися цим варіантом.

Стежити за усуванням цієї вади можна тут: Bugzilla #1575957.

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

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

Див. повідомлення про ваду у системі стеження за вадами у podman: podman#3187.

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

Ніколи не запускайте restorecon у основній системі Fedora 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:fedora/39/x86_64/silverblue
$ sudo reboot

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

Подробиці можна знайти у описі цього внеску до сховища основного коду: ostree#1265.

Resetting passwords in Rescue Mode

In the case where you are unable to remember your user password or root password, you can reset the password using the following steps.

  1. While the system is booting, interrupt the boot sequence at the GRUB2 menu by using the Esc key.

  2. Select the boot entry that you wish to edit using the arrow keys.

  3. Edit the selected entry with the e key.

  4. Use the arrow keys to select the line beginning with linux, linux16, or linuxefi.

  5. Go to the end of that line and append init=/bin/bash to the end of the line.

  6. Press Ctrl-x or F10 to boot the entry.

  7. At the resulting bash prompt, run the following commands:

# mount -t selinuxfs selinuxfs /sys/fs/selinux
# /sbin/load_policy
# passwd
# sync
# /sbin/reboot -ff

If you want to change the password for a user account, replace the passwd command with passwd <username>.

After the system finishes rebooting, you should be able to login with the username and new password.

Want to help? Learn how to contribute to Fedora Docs ›