Solução de problemas

O Silverblue é uma forma radicalmente nova de implantar e gerenciar seu sistema operacional de desktop, então você pode ocasionalmente ter problemas ao passar por seu dia a dia. Abaixo estão alguns dos problemas mais comuns relatados e quaisquer soluções alternativas para esses problemas.

"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

Os usuários há muito tempo desejam usar suas placas de vídeo Nvidia em seus sistemas Silverblue. Felizmente, mudanças recentes nos pacotes akmods e kmodtools foram feitas por Alex Larsson para permitir a instalação normal dos drivers da Nvidia.

# rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia

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

Problemas com SELinux

Como os usuários trabalham com o Silverblue no dia a dia, é possível que eles tenham modificado a política SELinux padrão em um esforço para contornar um ou mais problemas relacionados ao SELinux. Isso geralmente é feito quando um usuário vê uma negação do SELinux no diário. Se este for o caso e você desejar reverter para a política SELinux padrão, você pode tentar este conjunto de ações.

  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

Esse problema é mais comumente visto quando os usuários instalam o Silverblue em hardware Apple. A partição /boot/efi no hardware da Apple é formatada como HFS+ e nem sempre é resiliente a falhas de energia ou outros tipos de eventos impactantes de energia.

Como o Silverblue agora inclui o pacote hfsplus-tools na composição base, tornou-se relativamente fácil para os usuários contornar esse tipo de erro.

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

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

Não é possível instalar Silverblue em sistemas EFI

Os usuários relataram que não conseguem instalar o Silverblue em um sistema baseado em EFI onde anteriormente tinham outro sistema operacional instalado. O erro que é frequentemente observado é o seguinte:

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:

  • Durante o processo de instalação, selecione "Particionamento personalizado" e crie uma partição EFI adicional. Atribua a partição EFI recém-criada a /boot/efi. Você poderá então inicializar o(s) sistema(s) operacional(is) anterior(es) junto com o Fedora Silverblue. Se esta solução alternativa não for bem-sucedida, siga a etapa abaixo.

  • Reformate a partição EFI no host durante o processo de instalação. Isso pode ser feito selecionando "Particionamento personalizado" e marcando a caixa Reformatar ao criar a partição`/boot/efi`.

A escolha de reformatar /boot/efi provavelmente resultará na incapacidade de inicializar qualquer outro sistema operacional que tenha sido instalado anteriormente. Certifique-se de ter feito backup de todos os dados importantes antes de usar esta solução alternativa.

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

A partir do podman versão 1.4.0, esta solução alternativa não é necessária. Certifique-se de que o podman esteja atualizado emitindo`rpm-ostree upgrade` antes de tentar esta solução alternativa.

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
A seguinte solução alternativa pode ser útil para outros erros do toolbox causados por versões do podman superiores a 1.2.0. Veja o repositório no GitHub do Toolbox

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

Com certas versões do podman, tentar entrar em uma toolbox resultará em erros. Você pode corrigir isso redefinindo as permissões nos contêineres de sobreposição com o seguinte comando.

$ 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

Você nunca deve executar restorecon em um host Silverblue. Veja o seguinte bug para detalhes - 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-atomic:fedora/30/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.

Veja este comentário upstream para detalhes adicionais - https://github.com/ostreedev/ostree/issues/1265#issuecomment-484557615