Solução de problemas
Fedora Silverblue is a new way of deploying and managing your desktop operating system, so you may occasionally run into problems while going through your day to day. Below are some of the more common problems reported and any workarounds for those problems.
"Forbidden base package replacements"
Isso pode acontecer quando um pacote que está sendo colocado em camadas depende de um pacote que está no sistema operacional base. No caso problemático, o pacote em camadas requer uma versão mais recente do pacote dependente que não está disponível no sistema operacional base.
Na maioria dos casos, esperar por uma composição de OSTree mais recente resolverá esse problema. O pacote dependente será atualizado na composição e o pacote que será colocado em camadas será bem-sucedido.
No entanto, se você continuar a encontrar esse problema com uma composição mais recente, pode tentar limpar os metadados com rpm-ostree cleanup -m
e então tentar novamente a instalação do`rpm-ostree`.
Alternativamente, você pode tentar fazer o rebase para qualquer ref updates
, como fedora/30/updates/x86_64
após o cleanup
operation.
For more information, see rpm-ostree#415.
Instalando pacotes em /opt
ou /usr/local
A instalação em /opt
costumava ser considerada um problema quando os usuários tentavam instalar o Google Chrome. Uma solução parcial foi implementada que permite aos usuários colocar o Google Chrome em camadas, no entanto, não é uma solução completa para aplicativos que escrevem dados mutáveis em /opt
.
This issue is tracked in rpm-ostree#233.
Using NVIDIA drivers
You can install the official NVIDIA binary drivers from the RPM Fusion repositories.
The NVIDIA binary drivers are not maintained by the Fedora Project and may sometimes not be available for the kernel version included in Fedora Silverblue. |
The Universal Blue project creates operating system images for Fedora Silverblue with the NVIDIA drivers included. The Universal Blue images are based on the official Fedora images with additional changes at their discretion. The Universal Blue images are not officially endorsed by the Fedora Project. Use them at your own discretion. |
-
First, ensure that your system is fully updated by running
sudo rpm-ostree upgrade
and rebooting. -
Then setup the RPM Fusion repositories following the documentation, including the two reboots.
-
Finally, install the drivers:
# 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 --append=initcall_blacklist=simpledrm_platform_driver_init # 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.
|
Thanks to Alex Larsson who made the required changes to the akmods
and kmodtools
packages. You can read more about the work that Alex did on his blog.
Out of tree kernel modules and drivers using DKMS
Fedora Silverblue currently does not have support for DKMS. See the upstream issue rpm-ostree#1091.
Instead, we recommend that you make kmods packages for out of tree kernel modules and submit them to the RPM Fusion repos. The kmods packages will then be used by akmods which is supported on Fedora Silverblue.
Adding external package repositories
This section discusses third-party software sources not officially affiliated with or endorsed by the Fedora Project. Use them at your own discretion. |
If you want to use RPM Fusion repositories, please follow the Enabling RPM Fusion repos section. |
Some sofware may only be available from a third-party repository. You can add an external repository manually on Fedora Silverblue by placing the .repo
file into /etc/yum.repos.d/
and the GPG key into /etc/pki/rpm-gpg/
. The following is a full example for setting up the Taiscale repo:
-
Fetch and install the repo config:
$ 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
-
Fetch and install the GPG keys:
$ 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
-
Replace the
gpgkey=
URL in the repo config by the path the GPG keys:$ 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 # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
Install the new packages with:
$ rpm-ostree install tailscale
Better support in rpm-ostree
for this use case is tracked in rpm-ostree#4014.
Problemas com SELinux
As users work with Fedora Silverblue day-to-day, it is possible that they have modified the default SELinux policy in an effort to workaround one or more problems related to SELinux. This is usually done when a user sees a SELinux denial in the journal. If this is the case and one wishes to revert back to the default SELinux policy, you can try these set of actions.
-
Verifique o estado da política 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
Se alguma coisa for retornada por este comando, então sua política SELinux foi modificada, estando diferente do padrão.
-
Copie a política SELinux padrão enviada na composição OSTree
$ sudo cp -al /etc/selinux{,.bak} $ sudo rsync -rlv /usr/etc/selinux/ /etc/selinux/
Depois de fazer isso, a saída de
ostree admin config-diff | grep policy
não deve mais indicar que a política foi modificada.Se sua política ainda parece ter sido modificada, você pode tentar a abordagem a seguir.
-
Remova a política SELinux; copie a política padrão
$ sudo rm -rf /etc/selinux $ sudo cp -aT /usr/etc/selinux /etc/selinux
Depois disso, o comando
ostree admin config-diff | grep policy
não deve retornar modificações.
Não é possível adicionar um usuário ao grupo
Due to how rpm-ostree
handles user + group entries, it may not be possible to use usermod -a -G
to add a user to a group successfully. Until rpm-ostree
moves to using systemd sysusers
, users will have to populate the /etc/group
file from the /usr/lib/group
file before they can add themselves to the group.
For example, if you wanted to add a user to the libvirt
group:
$ grep -E '^libvirt:' /usr/lib/group | sudo tee -a /etc/group $ sudo usermod -aG libvirt $USER
Você precisará fazer logoff e logon novamente para aplicar essas alterações. |
This issue is tracked in rpm-ostree#29 and rpm-ostree#49.
ostree fsck
relata arquivo corrompido
É possível acabar em uma situação em que um ou mais arquivos no disco foram corrompidos ou estão faltando. Neste caso, ostree fsck
relatará erros em certos commits. A solução alternativa neste caso é marcar todo o commit OSTree como parcialmente recuperado e, em seguida, extrair novamente o commit.
/boot/efi
somente leitura impede quaisquer atualizações
This issue is most commonly seen when users have installed Fedora Silverblue on Apple hardware. The /boot/efi
partition on Apple hardware is formatted as HFS+ and is not always resilient to power failures or other kinds of hard power events.
Since Fedora Silverblue now includes the hfsplus-tools
package in the base compose, it has become relatively easy for users to workaround this kind of error.
# umount /boot/efi # fsck.hfsplus /dev/sda1 # mount -o rw /boot/efi
See the rpm-ostree#1380 GitHub issue for additional details.
Unable to install Fedora Silverblue on EFI systems
Users have reported that they cannot install Fedora Silverblue on an EFI based system where they previously had another OS installed. The error that is often observed looks like:
ostree ['admin', '--sysroot=/mnt/sysimage', 'deploy', '--os=fedora-workstation', 'fedora-workstation:fedora/28/x86_64/workstation'] exited with code -6`
Existem algumas soluções alternativas possíveis:
-
During the install process, select "Custom Partitioning" and create an additional EFI partition. Assign the newly created EFI partition to
/boot/efi
. You will then be able to boot the previous OS(s) alongside Fedora Silverblue. If this workaround is not successful follow the below step. -
Reformat the EFI partition on the host during the install process. This can be done by selecting "Custom Partitioning" and checking the
Reformat
box when creating the/boot/efi
partition.
Choosing to reformat /boot/efi will likely result in the inability to boot any other operating systems that were previously installed.
Be sure that you have backed up any important data before using this workaround.
|
This issue is tracked in Bugzilla #1575957.
toolbox: failed to list images with com.redhat.component=fedora-toolbox
As of podman version 1.4.0 this workaround is not necessary.
Ensure podman is up to date by issuing rpm-ostree upgrade before attempting this workaround.
|
Ao emitir o comando toolbox list
, os sistemas que usam versões de podman
mais recentes que 1.2.0
, irão gerar o seguinte erro:
toolbox: failed to list images with com.redhat.component=fedora-toolbox
The following workaround might be useful for other toolbox errors caused by podman versions greater than 1.2.0 .
See Toolbox Github Repo
|
Como solução alternativa, é possível substituir os pacotes podman
mais recentes que a versão 1.2.0
emitindo:
$ 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
Reinicialize o sistema para aplicar as alterações.
Para referência, também é possível substituir o pacote seguindo estas etapas:
-
Baixe
podman-1.2.0-2.git3bd528e.fc30.x86_64.rpm
do Koji -
Remova
podman-manpages
executando:rpm-ostree override remove podman-manpages
-
Substitua o pacote
podman
atualmente instalado (usando o pacote que você baixou na primeira etapa) por:rpm-ostree override replace podman-1.2.0-2.git3bd528e.fc30.x86_64.rpm
Agora você pode reiniciar o sistema para que a alteração tenha efeito.
Para reverter esta solução alternativa, execute o seguinte comando:
$ rpm-ostree override reset podman; rpm-ostree override reset podman-manpages
Não é possível entrar em uma toolbox devido a erros de permissão
With certain versions of podman
, trying to enter a toolbox will result in errors. You can fix this by resetting the permissions on the overlay-containers with the following command.
$ sudo chown -R $USER ~/.local/share/containers/storage/overlay-containers
Isso redefinirá as permissões em seus contêineres e permitirá que você as insira novamente.
See the upstream podman issue: podman#3187.
Executando restorecon
You should never run restorecon on a Fedora Silverblue host.
See the following bug for details - https://bugzilla.redhat.com/show_bug.cgi?id=1259018
|
No entanto, se você fez isso, é possível se recuperar.
-
Inicialize com
enforcing=0
na linha de comando do kernel -
Crie um novo commit "fixo" localmente
-
Implante o novo commit "fixo"
-
Execute
restorecon
-
Reinicie
-
Faça uma limpeza
$ 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/41/x86_64/silverblue
$ sudo reboot
A advertência para essa recuperação é que seus pacotes em camadas serão removidos; você precisará retransmiti-los após a recuperação.
See this upstream comment for additional details: 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.
-
While the system is booting, interrupt the boot sequence at the GRUB2 menu by using the Esc key.
-
Select the boot entry that you wish to edit using the arrow keys.
-
Edit the selected entry with the e key.
-
Use the arrow keys to select the line beginning with
linux
,linux16
, orlinuxefi
. -
Go to the end of that line and append
init=/bin/bash
to the end of the line. -
Press Ctrl-x or F10 to boot the entry.
-
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 ›