Solução de problemas

Silverblue is a radically 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.

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.

Usar drivers Nvidia

Users have long wanted to use their Nvidia GPUs on their Silverblue systems. Thankfully, recent changes to the akmods and kmodtools packages were made by Alex Larsson to allow for normal installation of the Nvidia 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

Você pode ler mais sobre o trabalho que Alex fez em seu blog.

Problemas com SELinux

As users work with 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.

  1. 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.

  2. 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.

  3. 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

Devido à forma como rpm-ostree lida com entradas de usuário + grupo, pode não ser possível usar usermod -a -G para adicionar um usuário a um grupo com sucesso. Até que rpm-ostree passe a usar systemd sysusers, os usuários terão que preencher o arquivo /etc/group do arquivo /usr/lib/group antes de poderem se adicionar ao grupo. Por exemplo, se você quiser adicionar um usuário ao grupo libvirt:

# grep -E '^libvirt:' /usr/lib/group >> /etc/group
# usermod -aG libvirt nome-de-usuário
Você precisará fazer logoff e logon novamente para aplicar essas alterações.

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 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 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

Consulte o relatório no link para obter detalhes adicionais.

Unable to install Silverblue on EFI systems

Users have reported that they cannot install 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.

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:

  1. Baixe podman-1.2.0-2.git3bd528e.fc30.x86_64.rpm do Koji

  2. Remova podman-manpages executando: rpm-ostree override remove podman-manpages

  3. 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.

Executando restorecon

You should never run restorecon on a 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.

  1. Inicialize com enforcing=0 na linha de comando do kernel

  2. Crie um novo commit "fixo" localmente

  3. Implante o novo commit "fixo"

  4. Execute restorecon

  5. Reinicie

  6. 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/36/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: https://github.com/ostreedev/ostree/issues/1265#issuecomment-484557615