Solução de problemas
Fedora Atomic Desktops utilizam uma nova forma de implantar e gerenciar seu sistema operacional de desktop, portanto, você pode ocasionalmente encontrar problemas durante o seu dia a dia. Abaixo estão alguns dos problemas mais comuns relatados e suas soluções alternativas.
"Forbidden base package replacements"
Isso pode acontecer quando um pacote que está sendo adicionado por camadas depende de um pacote presente no sistema operacional base. Nesse caso problemático, o pacote adicionado por camadas requer uma versão mais recente do pacote dependente, que não está disponível no sistema operacional base.
Na maioria dos casos, aguardar uma versão mais recente do OSTree compose resolverá o problema. O pacote dependente será atualizado no compose e a instalação do pacote que seria adicionado por camadas será bem-sucedida.
No entanto, se você continuar a encontrar esse problema com uma versão mais recente do compose, tente limpar os metadados com rpm-ostree cleanup -m e, em seguida, execute novamente rpm-ostree install.
Alternativamente, você pode tentar fazer um rebase para qualquer referência de updates, como fedora/44/updates/x86_64, após a operação de cleanup.
Para mais informações, consulte rpm-ostree#415.
Instalando pacotes em /opt ou /usr/local
A instalação em /opt era um problema comum relatado por usuários que tentavam instalar o Google Chrome. Uma solução parcial foi implementada, permitindo que os usuários instalem o Google Chrome em camadas. No entanto, essa solução não é completa para aplicativos que gravam dados mutáveis em /opt.
Este problema está sendo acompanhado em rpm-ostree#233.
Usando drivers NVIDIA
|
O projeto Universal Blue cria imagens de sistemas operacionais com os drivers NVIDIA incluídos. As imagens do Universal Blue são baseadas nas imagens do Fedora Atomic Desktop, com alterações adicionais a seu critério. As imagens do Universal Blue não são oficialmente endossadas pelo Projeto Fedora. Use-as por sua conta e risco. |
Você pode instalar os drivers binários oficiais da NVIDIA a partir dos repositórios RPM Fusion.
| Os drivers binários da NVIDIA não são mantidos pelo Projeto Fedora e podem, às vezes, não estar disponíveis para a versão do kernel incluída em Fedora Atomic Desktops. |
-
Primeiro, certifique-se de que seu sistema esteja totalmente atualizado executando
sudo rpm-ostree upgradee reiniciando. -
Em seguida, configure os repositórios RPM Fusion seguindo a documentação, incluindo as duas reinicializações.
-
Por fim, instale os drivers:
# rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia # rpm-ostree kargs --append=rd.driver.blacklist=nouveau,nova-core \ --append=modprobe.blacklist=nouveau,nova-core \ --append=nvidia-drm.modeset=1 \ --append=initcall_blacklist=simpledrm_platform_driver_init # systemctl reboot
|
Ao usar a Inicialização Segura (Secure Boot), os drivers NVIDIA instalados localmente precisam ser assinados com uma chave local registrada usando o |
Agradecemos a Alex Larsson, que fez as alterações necessárias nos pacotes akmods e kmodtools. Você pode ler mais sobre o trabalho de Alex em seu blog.
Módulos e drivers do kernel fora da árvore usando DKMS
Fedora Atomic Desktops atualmente não oferecem suporte ao DKMS. Consulte a issue upstream em rpm-ostree#1091.
Em vez disso, recomendamos que você crie pacotes kmods para módulos do kernel externos à árvore e os envie para os repositórios RPM Fusion. Os pacotes kmods serão então usados pelo akmods, que é compatível com Fedora Atomic Desktops.
Adicionando repositórios de pacotes externos
|
Esta seção discute fontes de software de terceiros que não são oficialmente afiliadas ou endossadas pelo Projeto Fedora. Use-as a seu próprio critério. |
| Se você deseja usar repositórios RPM Fusion, siga as instruções na seção Habilitando os repositórios RPM Fusion. |
Alguns softwares podem estar disponíveis apenas em repositórios de terceiros. Você pode adicionar um repositório externo manualmente no Fedora Atomic Desktops colocando o arquivo .repo em /etc/yum.repos.d/ e a chave GPG em /etc/pki/rpm-gpg/. Segue abaixo um exemplo completo para configurar o repositório Taiscale:
-
Obtenha e instale a configuração do repositório:
$ 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 -
Obtenha e instale as chaves 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 -
Substitua a URL
gpgkey=na configuração do repositório pelo caminho das chaves GPG:$ sudoedit /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 ### ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -
Instale os novos pacotes com:
$ rpm-ostree install tailscale
Melhor suporte em rpm-ostree para este caso é rastreado em rpm-ostree#4014.
Problemas com SELinux
Ao trabalhar diariamente com Fedora Atomic Desktops, é possível que os usuários tenham modificado a política SELinux padrão para contornar um ou mais problemas relacionados ao SELinux. Isso geralmente ocorre quando um usuário vê uma negação do SELinux no registro de logs. Se esse for o caso e você desejar reverter para a política SELinux padrão, tente as seguintes ações.
-
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.30Se algum resultado for retornado por este comando, significa que sua política SELinux foi modificada em relação à padrão.
-
Copie a política SELinux padrão fornecida no OSTree compose
$ sudo cp -al /etc/selinux{,.bak} $ sudo rsync -rlv /usr/etc/selinux/ /etc/selinux/Após isso, a saída de
ostree admin config-diff | grep policynão deverá mais indicar que a política foi modificada.Se a sua política ainda parecer modificada, você pode tentar a seguinte abordagem.
-
Remova a política SELinux; copie a política padrão
$ sudo rm -rf /etc/selinux $ sudo cp -aT /usr/etc/selinux /etc/selinuxApós isso, o comando
ostree admin config-diff | grep policynão deverá retornar nenhuma modificação.
Não foi possível adicionar usuário ao grupo
Devido à forma como o rpm-ostree lida com entradas de usuário e grupo, pode não ser possível usar usermod -a -G para adicionar um usuário a um grupo com sucesso. Até que o rpm-ostree passe a usar o systemd sysusers, os usuários precisarão preencher o arquivo /etc/group com os dados 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 | sudo tee -a /etc/group
$ sudo usermod -aG libvirt $USER
| Você precisará sair e entrar novamente para que as alterações sejam aplicadas. |
Esta problema é rastreado em rpm-ostree#29 e rpm-ostree#49.
ostree fsck relata arquivo corrompido
É possível que ocorra uma situação em que um ou mais arquivos no disco estejam corrompidos ou ausentes. Nesse caso, o comando ostree fsck reportará erros em determinados commits. A solução alternativa, conforme descrito em workaround, consiste em marcar todo o commit do OSTree como parcialmente recuperado e, em seguida, executar o pull do commit novamente.
/boot/efi somente leitura evita atualizações de versão principal
Esse problema é mais comum quando os usuários instalam o Fedora Atomic Desktop em hardware da Apple. A partição /boot/efi em hardware da Apple é formatada como HFS+ e nem sempre é resistente a falhas de energia ou outros tipos de interrupções bruscas de energia.
Como o Fedora Atomic Desktops agora inclui o pacote hfsplus-tools no sistema base, tornou-se relativamente fácil para os usuários contornar esse tipo de erro.
# desmontar /boot/efi
# fsck.hfsplus /dev/sda1
# montar -o rw /boot/efi
Consulte a issue do GitHub rpm-ostree#1380 para obter detalhes adicionais.
Não é possível instalar o Fedora Atomic Desktop em sistemas EFI.
Usuários relataram que não conseguem instalar o Fedora Atomic Desktop em um sistema baseado em EFI onde outro sistema operacional estava instalado anteriormente. O erro mais comum é o seguinte:
ostree ['admin', '--sysroot=/mnt/sysimage', 'deploy', '--os=fedora-workstation', 'fedora-workstation:fedora/28/x86_64/workstation'] saiu com o código -6`
Existem algumas possíveis soluções alternativas:
-
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. Assim, você poderá inicializar o(s) sistema(s) operacional(is) anterior(es) juntamente com o seu ambiente de trabalho Fedora Atomic. Se essa solução alternativa não funcionar, siga os passos abaixo. -
Reformatar 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 opção de formatar |
Este problema está sendo acompanhado em Bugzilla#1575957.
toolbox: falha ao listar imagens com com.redhat.component=fedora-toolbox
|
A partir da versão 1.4.0 do |
Ao executar o comando toolbox list, sistemas que utilizam versões do podman posteriores à 1.2.0 gerarão o seguinte erro:
toolbox: falha ao listar imagens com com.redhat.component=fedora-toolbox
|
A seguinte solução alternativa pode ser útil para outros erros do |
Como solução alternativa, é possível sobrescrever os pacotes podman mais recentes que a versão 1.2.0 executando o seguinte comando:
$ rpm-ostree override --remove=podman-manpages \
substitua https://kojipkgs.fedoraproject.org//packages/podman/1.2.0/2.git3bd528e.fc30/x86_64/podman-1.2.0-2.git3bd528e.fc30.x86_64.rpm
Reinicie o sistema para aplicar as alterações.
Para referência, também é possível sobrescrever o pacote seguindo estes passos:
-
Baixe
podman-1.2.0-2.git3bd528e.fc30.x86_64.rpmde Koji. -
Remova o pacote
podman-manpagesexecutando o comando:rpm-ostree override remove podman-manpages. -
Substitua o pacote
podmanatualmente instalado (usando o pacote que você baixou na primeira etapa) da seguinte forma:$ рпм-остре оверриде реплаче подман-1.2.0-2.гицвд528е.фк30.х86_64.рпм
Agora você pode reiniciar o sistema para que a alteração entre em vigor.
Para reverter essa solução alternativa, execute os seguintes comandos:
$ rpm-ostree sobrescrever reset podman
$ rpm-ostree sobrescrever reset podman-manpages
Não foi possível acessar a caixa de ferramentas devido a erros de permissão.
Em certas versões do podman, tentar acessar uma caixa de ferramentas 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 dos seus contêineres e permitirá que você entre neles novamente.
Veja o problema original do podman: podman#3187.
Executando restorecon
|
Você nunca deve executar |
No entanto, caso isso aconteça, é possível se recuperar.
-
Inicialize o sistema com
enforcing=0na linha de comando do kernel. -
Crie um novo commit "corrigido" localmente.
-
Implante o novo commit "corrigido".
-
Execute
restorecon -
Reinício
-
Limpar
$ rpm-ostree status -b | grep BaseCommit
BaseCommit: 696991d589980aeaef5eda352dd7ad3d33c444c789c209f793a84bc6e7269aee
### Se o comando acima não exibir nenhuma saída, tente:
$ rpm-ostree status -b | grep Commit
Commit: 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
### No comando abaixo, Substitua:
### - x86_64 pela sua arquitetura de CPU
### - silverblue pelo nome da sua variante do Fedora Atomic Desktop
$ sudo ostree admin deploy fedora:fedora/44/x86_64/silverblue
$ sudo reboot
A ressalva para essa recuperação é que seus pacotes em camadas serão removidos; você precisará reinstalá-los após a recuperação.
Veja este comentário upstream para obter detalhes adicionais: ostree#1265.
Redefinindo senhas no Modo de Recuperação
Caso não se lembre da sua senha de usuário ou senha de administrador, você pode redefini-la seguindo os passos abaixo:
-
Enquanto o sistema estiver inicializando, interrompa a sequência de inicialização no menu GRUB2 usando a tecla Esc.
-
Selecione a entrada de inicialização que deseja editar usando as teclas de seta.
-
Edite a entrada selecionada com a tecla e.
-
Use as teclas de seta para selecionar a linha que começa com
linux,linux16oulinuxefi. -
Vá até o final dessa linha (pressionando Ctrl + e) e adicione
init=/bin/bash. -
Pressione Ctrl + x ou F10 para iniciar a entrada.
-
No prompt
bashresultante, execute os seguintes comandos:
# mount -t selinuxfs selinuxfs /sys/fs/selinux
# /sbin/load_policy
# passwd
# sync
# /sbin/reboot -ff
Se você quiser alterar a senha de uma conta de usuário, substitua o comando passwd por passwd <nome de usuário>.
Se você quiser alterar a senha de uma conta de usuário, substitua o comando passwd por passwd <nome de usuário>.
Want to help? Learn how to contribute to Fedora Docs ›