Essa foi a primeira vez que um upgrade do Fedora me fez temer o pior!
No velho PC, instalei o Fedora 30 e fiz upgrade para 31. Como era a primeira vez que estava domesticando de verdade o Fedora, levei eventuais desafios na conta de aprendizado. ─ No PC atual, instalei o Fedora 31; fiz upgrade para 32; e o upgrade para Fedora 33 transcorreu tão sem novidades, que nem valia a pena levantar o registro completo. ─ Em todos os casos, processo simples, suave e sem problemas.
O Fedora 34 foi lançado no final de Abril, portanto já tem 2 meses e meio ─ e imaginei que eventuais tropeços já se teriam resolvido.
Segui a sequência tradicional, de (a) atualizar; (b) instalar o plugin; (c) baixar todos os pacotes; e (d) reiniciar para instalar o upgrade antes de entrar no ambiente gráfico.
# dnf upgrade --refresh
# dnf install dnf-plugin-system-upgrade
# dnf system-upgrade download --releasever=34
# dnf system-upgrade reboot
Fui informado de que o pluguin já estava instalado (?), mas isso não era problema ─ só 1 pulga atrás da orelha.
Depois de apontar 75 pacotes sem correspondência, o download apontou um erro / problema com rdma-core:
...
No match for group package "lsvpd"
No match for group package "google-croscore-tinos-fonts"
Error:
Problem: rdma-core-35.0-1.fc33.i686 has inferior architecture
- rdma-core-35.0-1.fc33.x86_64 does not belong to a distupgrade repository
- problem with installed package rdma-core-35.0-1.fc33.i686
(try to add '--skip-broken' to skip uninstallable packages)
Não gostei da “solução” skip-broken ─ pesquisei um pouco e encontrei uma solução mais elegante. ─ Se é para quebrar, deixa que eu mesmo quebro:
# rpm -e --nodeps rdma-core
error: "rdma-core" specifies multiple packages:
rdma-core-35.0-1.fc33.x86_64
rdma-core-35.0-1.fc33.i686
# rpm -e --nodeps rdma-core-35.0-1.fc33.i686
# rpm -qa | grep 'rdma-core'
rdma-core-35.0-1.fc33.x86_64
Depois disso, baixou tudo que precisava baixar ─ só consegui anotar as últimas 1.078 linhas (de “mesa” em diante), porque estourou o limite de exibição configurado no Konsole ─ e aproveitei os 34 minutos do system-upgrade reboot para capinar um matagal ali.
Fig.1
Fig.2
Ao entrar no Fedora 34:
- O ambiente estava todo “nervoso”, o tempo todo dando a impressão de que ia pular… Tenso!
- Um dos 2 Conky sumia e voltava a cada 10 segundos
- Aplicativos do KDE esqueceram as configurações de Tamanho e Posição (Kwin)
- O mouse regrediu para o duplo-clique
- O gnome-screenshot se recusava a funcionar (tive de restabelecer o KDE Spectacle)
- Apareceu um notificador de atualizações, que eu esperava não ver nunca mais
Nas imagens (acima), os processos ligados ao Conky, segundo o filtro do KSysguard. ─ Na Fig.1, aparecendo os 2 Conky, durante 9 segundos. ─ Na Fig. 2, o momento em que a segunda instância do Conky desaparecia por 1 ou 2 segundos, ao executar uma série de comandos externos: free, top, neofetch, htop, inxi, screenfetch, cut, grep, a cada 10 segundos:
free ${alignr}${execi 10 free -m | grep Mem | cut -c 25-35} MiB
top ${alignr}${execi 10 top -E m -b -n 1 | grep buff | cut -c 41-50} MiB
neofetch ${alignr}${execi 10 neofetch --stdout | grep "Memory" | cut -c 8-15}
htop ${alignr}${execi 10 export TERM=xterm; echo q | htop | aha --line-fix | html2text | grep "/15" | cut -b 23-34}iB
inxi ${alignr}${execi 10 inxi --memory-short | grep used | cut -b 53-61}
screenfetch ${alignr}${execi 10 screenfetch -n -N | grep "RAM" | cut -c 7-13}
Não pude encontrar nenhuma explicação racional para os comandos rpm, sh e wc (?) aparecerem no filtro de processos ligados ao Conky, somando 14 processos no total.
Fig.3
A primeira instância do Conky também executa vários comandos externos, mas só 1 vez a cada 600 segundos. ─ Portanto, ele também desaparecia (Fig. 3), ─ mas acabei não documentando os processos nesses momentos, pois cada tentativa exigiria mais de 10 minutos de espera, sem nenhuma distração. Duas tentativas, 20 minutos; três tentativas, meia hora ─ às 12:44, 12:54 etc., pois o boot foi às 12:34:
${execi 600 neofetch --de_version on --stdout | grep "DE:"}
${execi 600 kf5-config --version | grep 'Qt\|KDE'}
${execi 600 konsole -v} ${execi 600 kate -v}
${execi 600 dolphin -v} ${execi 600 gwenview -v}
Fig.4
Eu não quis usar o "verificador de atualizações etc. ─ Prefiro sempre executar um comando, manualmente.
Ao executar o dnf upgrade (Fig. 4), ele substituiu 8 arquivos xorg-x11, ─ afora substituição / instalação / atualização de 5 pacotes iptables.
Mas…
─ Por que deixar esses 13 arquivos fora do upgrade ─ e precisar de uma “atualização” logo ao iniciar o Fedora 34 pela primeira vez? ─ Afinal, o 33 foi atualizado, e ainda tentei instalar o “plugin de upgrade”, portanto não havia razão para ele estar “desatualizado”.
Pesquisei o que pude imaginar ─ sobre Fedora 34 + Conky etc. ─ mas não encontrei nenhuma dica pertinente. Deixei o Fedora de lado e fui atualizar as outras distros que ainda faltavam.
Fig.5
Hoje, retomei a saga e tratei de remover:
- PackageKit (3 pacotes)
- Todo o Plasma-Discover (16 pacotes)
- Todo o Flatpak (54 pacotes)
Depois dessas remoções (e de mais uns 2 Reboot), os processos associados ao Conky se reduziram a 6. ─ Agora, nenhum rpm (mas pode ser só coincidência).
Fig.6
Por fim, acabei desconfiando do Plasma-Wayland ─ “suspeitei desde o princípio!” ─ fiz Logout, escolhi sessão Plasma-X11… e finalmente o ambiente gráfico amansou!
Agora, o Conky permanece aberto, tranquilo e infalível como Bruce Lee. ─ Nada de “pulinhos nervosos”.
O KDE Spectacle agora leva até meia hora para disparar ─ mas o gnome-screenshot voltou a funcionar, sem nenhuma hesitação.
Só, que… Agora, um simples Logout leva horas.
Em vez da tela de Login, vejo só um Teclado Virtual. ─ Ok, já vi mil dicas de como eliminá-lo (quando não precisava); isso deve ser fácil de resolver.
O Login também leva séculos.
Ao abrir o Dolphin, o Kate, o Gwenview, suas janelas ficam transparentes (vazias) durante um tempão, antes de finalmente serem preenchidas. ─ Isso não acontece com o Konsole, nem com o Chrome, nem com a calculadora KCalc.
Uma busca simples no Dolphin passou a demorar séculos.
Tentei baixar o anexo de um Gmail, e não ia. Clica, clica, clica!, cavalinho alazão. Finalmente, abriu o diálogo. Minutos depois, abre um segundo diálogo. Meia hora depois, ainda abre um quarto diálogo, um quinto diálogo…
Por enquanto, as coisas estão assim.
Não chegam a ser dificuldades enormes. A sessão atual já vai completar 4 horas, e não me sinto embaraçado. As atividades fluem razoavelmente.
Por princípio, deve ser possível reverter esse “avanço” do Fedora 34 em direção ao Wayland. Des-substituir os pacotes Xorg-X11 que foram substituídos ─ mas isto só deve ser possível após eliminar o Wayland que exigiu aquela substituição.
EDIT - Adicionei várias imagens para ficar mais claro.
