Byteria: Devuan 2 Beta KDE - Desastre e recuperação

Início do desastre com o KDE Plasma (testing) no Devuan 2 Beta

21 Abr. 2018 - O desastre com o KDE Plasma do Devuan 2 Beta foi causado, provavelmente, por alguma alteração na teia de dependências, — envolvendo dezenas de pacotes do PIM & Akonadi removidos 2 meses antes, — e de certo modo acabou funcionando como um “freio de arrumação”.

Ver “Release Candidate e mudança de status do KDE” (adiante)

Em resumo, as atualizações propostas pelo Synaptic implicavam em remover o próprio Synaptic e alguns pacotes críticos do KDE, Polkit, gerenciador de Rede etc.

Além de não “entender” muita coisa do GNU / Linux, eu devia estar com a atenção meio dividida entre outras questões, — Cooler entupido, Grub doido, Manjaro chucro, — mas, por mais que examine hoje aquele dilema, continuo sem imaginar o que poderia fazer naquela situação.

O Synaptic resistiu bravamente, até o final, — registrou até o log de sua própria remoção, — mas esperar que, em seguida, ainda abrisse o Histórico, para exibir a façanha… Bom, aí talvez já fosse querer demais.

Índice

Sem rede
Demolição do KDE em capítulos
Existe vida sem KDE
Recuperação do KDE
De volta para o futuro
Release Candidate e mudança de status do KDE
Outras configurações
PIM & uso inicial de RAM
Remoção do Akonadi
O caso do Debian testing

Referências

openSUSE - removendo Snapper, PIM, Baloo e Akonadi

Conky - configuração em andamento

Sem rede

Falha de Rede ao tentar reinstalar o Synaptic

12:55 - Ao tentar apt install synaptic, nenhum dos 4 pacotes previstos pôde ser obtido. — O mais provável é que fosse falha de Rede, afinal tinha acabado de remover network-manager, — mas se este fosse o caso, como reinstalar esse pacote… sem Rede?

Tampouco podia descartar a possibilidade de falha nos repositórios, — embora ainda não saiba como direcionar para um ou outro espelho (Mirror). — De qualquer modo, parece que são poucos, todos na Europa, exceto 1 no Chile (e nenhum no Brasil, por enquanto).

A experiência dos últimos 3 meses já tinha mostrado que, às vezes, a velocidade de acesso aos repositórios cai a níveis exasperantes. Várias vezes, também, um mero apt update (Reload, no Synaptic) já terminou em erro, — sem que houvesse qualquer falha de Rede (navegação normal), — e bastava tentar de novo algumas horas depois, para encontrar tudo normalizado.

Mas dessa vez, mesmo sem alcançar nenhum repositório, o apt install deixou um aviso alarmante, — uma tonelada de pacotes (praticamente todo o KDE Plasma, além do LibreOffice e mais alguma coisa!) “já não são necessários”, — “Utilize apt autoremove para os remover”.

LibreOffice “auto-removível” desde Fevereiro

A rigor, isso nem era novidade, — desde a remoção do PIM & Akonadi, em Fevereiro, o Synaptic já listava 208 pacotes “Removíveis” (incluindo todo o LibreOffice), que nem por isso deixavam de receber atualizações, — mas a apresentação desse dilema, agora, soou como um ultimato: não dava mais para ignorar.

Só que, agora, tratava-se de remover 300 pacotes, — mas isso ficou para a semana seguinte.

Em todo caso, minutos depois o Chromium confirmou que, de fato, estava sem Rede.

Demolição do KDE em capítulos

Colapso do KDE Plasma e Reboot pelo tty3

Em seguida, o Menu deixou de responder, — provavelmente, o KDE só estava funcionando por inércia (pré-carregado), e cada iniciativa que dependesse de um pacote removido, ia demolindo o ambiente, pedaço por pedaço.

Feito o Reboot, — por comando Root a partir do tty3, — o Devuan carregou com o Painel desmantelado, Menu inoperante; e o Conky em fundo preto, confirmando zero tráfego de Rede.

Nestas circunstâncias, as fotos de celular são muito pouco úteis, — quase todas mal focadas (letras miúdas), — exceto para datar os acontecimentos.

Não houve mais Capturas de tela, — mas não há registro de que tenha tentado fazê-las, — nem de que a tecla PrtScn ou o gnome-screenshot se recusassem a funcionar.

Existe vida sem KDE

Atualização do Grub, — com KDE desconchavado

22 Abr. 2018 - No dia seguinte, o Devuan voltou a ser carregado, — Painel desconjuntado, Menu fora de combate, Conky sobre fundo preto, — e não há registro de como consegui abrir Dolphin, Kate, Konsole (talvez pelos lançadores no Painel, que acabou se arrumando; mas o Menu não ressuscitou).

Em boa hora, acionei o gnome-screenshot pela tecla de atalho PrtScn, — e funcionou, — de modo que é possível conferir os indicadores desta sessão, com nitidez.

O objetivo, nesse dia, era apenas disparar um update-grub, — com os_prober previamente desabilitado (a partir do openSUSE), — o que reduziu o arquivo /boot/grub/grub.cfg de 552,2 KiB para 9,2 KiB, em 15 segundos.

O conserto geral do Grub era urgente, — e em certa medida, pré-requisito para poder cuidar do Devuan.

Recuperação do KDE

Confusão ao tentar um comando no Modo de recuperação (Recovery mode)

27 Abr. 2018 - Só na outra semana, finalmente foi carregado o Modo de recuperação (Recovery Mode), — que está longe de oferecer a mesma moleza do Ubuntu & derivados.

Após entrar com a Senha (para Manutenção), nem cheguei a completar o comando pretendido, — que pretendia ser apt-get install -f, — e o sistema já começou (ou continuou) a dar retorno de outras coisas, sem qualquer relação.

Removendo tudo que o apt queria, — basicamente, todo o KDE Plasma

Mas o histórico não deixa dúvida, — de fato apenas tentei atualizar o apt (sem rede!), — e já mandei remover aquilo tudo, que vinha sendo proposto, para deixar de repetir sempre a mesma ladainha, a cada passo que se tentava dar:

# ~~apt-get install~~
# ~~apt update~~
# apt autoremove
# reboot

Ativando e testando a Rede, para rodar o Tasksel

Embora tenha pesquisado e anotado vários comandos para configuração de Rede, apenas um funcionou, — e foi mais do que suficiente, para restabelecer a conexão.

Depois, bastou testar, — e rodar o Tasksel em seguida:

# dhclient eth0
# ping 8.8.8.8
# tasksel

Re-instalando o KDE pelo Tasksel

No Tasksel, foi selecionado apenas o KDE, — e para minha surpresa trouxe de volta o LibreOffice, — que, desde então, nunca mais o apt / Synaptic classificou como “Removível”… até remover o Akonadi outra vez.

Velocidade de Rede inferior à “conexão discada” da antiguidade

Infelizmente, o processo todo demorou mais de 1h10min (16:52 ~ 18:05), — com o Conky (tty7) indicando download em velocidade inferior à da Idade da Pedra.

Devuan 2 Beta com KDE reinstalado e (quase) todas as configurações intactas, — após 1h28min

Ainda no tty7, apenas foi encerrada a sessão (por Ctrl-Alt-Del + Enter), — feito novo Login, — e a nova sessão já exibiu o KDE inteiro, zerado, com (quase) tudo configurado como antes.

De volta para o futuro

Ao contrário do padrão original, o 1º usuário já não era Administrador

Foi necessário tornar a configurar alguns detalhes:

Reinstalar o Synaptic (pelo Apper) - download entre 28 ~ 43 KiB/s
Passar novamente o Compositor de OpenGL 2.0 para XRender
Desabilitar novamente a Carteira do KDE (KWallet)
Restabelecer o Usuário principal como Administrador (sudo)

Synaptic só abria por comando Root, desde Fevereiro

Cabe lembrar que desde a instalação do Devuan 2 Beta, em Fevereiro, o Synaptic jamais abriu pelo Menu, — simplesmente abortava, — e tinha de ser chamado por comando Root.

Agora, basta clicar no Menu, — entrar com a senha Root, — e abre normalmente.

Desabilitando a Carteira de senhas do KDE (KWallet)

Mas outras coisas também melhoraram, — como se várias implementações se tivessem alterado, de Fevereiro para cá, — e o “acidente de percurso” tenha funcionado como um “freio de arrumação”.

Desta vez, por exemplo, desabilitar o KWallet funcionou sem problemas.

Release Candidate e mudança de status do KDE

No Tasksel, KDE, Cinnamon e LXQt deixaram de ser apresentados como “Testing”

De fato, houve uma atualização do Tasksel (+data) em 16 Abril, — uma semana antes do desastre, — e é possível que aí tenham chegado algumas mudanças nas dependências dos pacotes, com as quais a situação anterior talvez fosse incompatível.

Aliás, parece ter havido alguma aceleração nas mudanças do Tasksel: — Uma única atualização, de Fevereiro até Abril, — e agora três, em cerca de 30 dias:

Apr 16 - tasksel (3.39+devuan1.6.1) to 3.39+devuan1.7
May 5 - tasksel (3.39+devuan1.7) to 3.39+devuan1.8
May 17 - tasksel (3.39+devuan1.8) to 3.39+devuan1.9

Em algum momento, — infelizmente, não percebido e não-documentado, — o Tasksel deixou de exibir a advertência de “Testing” para o KDE, o Cinnamon e o LXQt.

Embora o desastre tenha ocorrido em 21 de Abril, — possivelmente em decorrência de alterações trazidas pela atualização de 16 de Abril, — parece muito provável que já prenunciassem o RC oficialmente divulgado em 9 de Maio.

O anúncio frisa, especificamente, que o instalador “agora oferece uma variedade mais ampla de ambientes, incluindo XFCE, KDE, MATE, Cinnamon, LXQt”:

Devuan 2.0 ASCII Release Candidate
2018-05-09 22:26:51
We are happy to announce that the Devuan 2.0 ASCII Release Candidate is now available thanks to the support, feedback, and collaboration of the Devuan community. Devuan 2.0 ASCII Stable will be following soon.

The Devuan 2.0 ASCII RC installer now offers a wider variety of Desktop Environments including XFCE, KDE, MATE, Cinnamon, LXQT (with others available post-install). In addition, there are options for "Console productivity" with hundreds of CLI and TUI utils, as well as a minimal base system ideal for servers.

When installing from ISO, the expert install option offers a choice of SysVinit and OpenRC. Official ready-to-use Devuan 2.0 ASCII RC images are available for dozens of ARM boards and SOCs, including Raspberry Pi, BeagleBone, OrangePi, BananaPi, OLinuXino, Cubieboard, Nokia N900, and several Chromebooks, as well as for Virtualbox/QEMU/Vagrant.

Outras configurações

Desde a instalação do Devuan 2 Beta (Fevereiro), ficaram faltando 2 configurações, — que já são hábito antigo, nas demais distros instaladas, — mas ainda não havia aplicado no Devuan:

Remover PackageKit, — que verifica os repositórios, em horas inoportunas
Remover Unattended-upgrades, — que atualiza (alguns) pacotes sem pedir licença

Desinstalar PackageKit implicou na remoção do Plasma-Discover e do Apper. — Até gosto do Apper (embora prefira Synaptic), — mas evito sistematicamente o Plasma-Discover.

Por fim, faltava refazer:

Remover ~~PIM &~~ Akonadi (este último voltou a carregar 16 processos)

PIM & uso inicial de RAM

Processos Akonadi jamais usados, — carregados automaticamente a cada sessão

A reinstalação do conjunto PIM & Akonadi (completo) voltou a elevar o consumo inicial de Memória RAM, — com nada menos que 17 processos Akonadi rodando sem necessidade.

Antes do desastre:

2018-02-17 - 358 MiB - 2º Boot sem PIM & Akonadi
2018-02-17 - 355 MiB - PrtScn alterou: 357 MiB - ainda sem AutoLogin
2018-02-17 - 348 MiB
2018-02-21 - 342 MiB - PrtScn alterou: 343 MiB
2018-02-23 - 351 MiB - PrtScn alterou: 352 MiB
2018-03-03 - 365 MiB
2018-03-13 - 365 MiB - PrtScn alterou: 367 MiB
2018-03-19 - 365 MiB
2018-03-28 - 356 MiB - PrtScn alterou: 357 MiB
2018-04-01 - 371 MiB - PrtScn alterou: 372 MiB
2018-04-21 - 351 MiB - após PrtScn: 399… 352 MiB

Após a recuperação:

2018-04-27 - 514 MiB - PrtScn alterou: 517 MiB
2018-04-28 - 517 MiB
2018-04-30 - 502 MiB - PrtScn alterou: 503 MiB
2018-05-01 - 499 MiB - PrtScn alterou: 503 MiB
2018-05-05 - 501 MiB - PrtScn alterou: 503… 528… 502 MiB
2018-05-17 - 502 MiB - PrtScn alterou: 504 MiB

Após remover Akonadi-server:

2018-05-21 - 331 MiB - PrtScn alterou: 333 MiB… 358… 331 MiB
2018-05-21 - 330 MiB - PrtScn alterou: 331 MIB… 356… 331 MiB
2018-05-21 - 331 MiB - PrtScn alterou: 333 MiB… 356… 331 MiB
2018-05-22 - 332 MiB - PrtScn alterou: 333 MiB
2018-05-23 - 332 MiB - PrtScn alterou: 331 MiB
2018-05-23 - 331 MiB
2018-05-28 - 331 MiB - PrtScn-alterou: 336 MiB

Obs.: Números observados cerca de 1 minuto após o carregamento do KDE, — quando o uso de Memória RAM se estabiliza.

O primeiro número é a observação visual antes do PrtScn, — pois às vezes o gnome-screenshot interfere na Memória RAM antes da captura, e grava a imagem com um número alterado (exceto quando omitido, acima).

Entre a captura e o final da gravação, o gnome-screenshot ainda costuma elevar mais um pouco esse número (cerca de +25 MiB), retornando ao patamar inicial após cerca de +25 segundos.

Medição do uso de Memória RAM, — 1 minuto (↓) após o carregamento completo do KDE

Os gráficos de uso de CPU são de 2 minutos (120 pixels), — e o final da passagem do pequeno pico inicial pelo centro (↓) assinala 1 minuto após as notificações de carregamento completo do KDE, conexão de Rede etc.

Remoção do Akonadi

Remoção “apenas” do Akonadi-server, — um modo de remoção parcial do PIM

A primeira remoção do PIM, Baloo, Akonadi tinha sido feita logo na instalação do Devuan 2 Beta, em meados de Fevereiro, — e não causou nenhum desastre durante 2 meses.

21 Mai. 2018 - Diante da possibilidade de novos desastres, agora foi removido “apenas” o próprio Akonadi-server, — com suas dependências automáticas, — o que evitou gastar tempo à procura de vários itens, e no teste das dependências de cada um:

Efeitos da remoção “apenas” do Akonadi-server, — em comparação com a remoção de Fevereiro

Commit Log for Mon May 21 08:06:07 2018

Removed:

accountwizard
akonadi-server
akregator
kaddressbook
kde-config-mailtransport
kde-standard
kdepim-addons
kdepim-runtime
kdepim-themeeditors
kmail
knotes
korganizer
libkf5akonadicalendar5
libkf5akonadicontact5
libkf5akonadicore-bin
libkf5akonadimime5
libkf5akonadisearch-bin
libkf5akonadisearch-plugins
libkf5alarmcalendar5
libkf5calendarsupport5
libkf5eventviews5
libkf5gravatar5
libkf5incidenceeditor-bin
libkf5incidenceeditor5
libkf5kaddressbookgrantlee5
libkf5kdepimdbusinterfaces5
libkf5ksieveui5
libkf5libkdepim-plugins
libkf5libkdepim5
libkf5mailcommon-plugins
libkf5mailcommon5
libkf5mailimporter5
libkf5mailtransport5
libkf5messagecomposer5
libkf5messagecore5
libkf5messagelist5
libkf5messageviewer5
libkf5pimcommon-plugins
libkf5pimcommon5
libkf5templateparser5
libkolab1
task-kde-desktop

A lista é apenas um pouco menor, — mas remover “só” 1 pacote deu muito menos trabalho.

Agora, a lista dos “Auto-Removíveis” é de 240 pacotes, — inclusive todo LibreOffice, de novo.

O caso do Debian testing

Comparativo dos sistemas Linux instalados em 16 Mai. 2018

Só para referência, vale lembrar que o Debian foi instalado “Jessie” e transformado, — do modo mais atabalhoado possível, — em “Testing” (não “Stretch”). No devido tempo começou a se apresentar como “Stretch”, e atualmente como “Buster / Sid”.

No Debian testing, a remoção do PIM-Baloo-Akonadi foi tão completa quanto possível, — e nesses 20 meses, seu KDE evoluiu do KDE 5.8.0 até o KDE 5.12.5, — ao passo que o Devuan 2 Beta continua com o mesmo KDE 5.8.6 que tinha há 3 meses.

Não se trata de comparar a enormidade de recursos, desenvolvedores, testadores, mailing-lists, foruns etc. do Debian com o esforço heroico realizado pela brava comunidade do Devuan, — portanto, a constatação de que o Debian (mesmo sob tortura de um mentecapto) segue firme e forte, deve ser tomada única e exclusivamente como referência para análise. — Nada além disso.

Por outro lado, a recuperação (simples e fácil) do KDE Plasma foi uma demonstração cabal de solidez, consistência e capacidade de regeneração do Devuan 2 Beta, — mesmo cruelmente amputado e submetido às mais torpes torturas.

Tanto no Debian quanto no Devuan, a montagem automática de partições adicionais dos HDDs se faz pelo arquivo /etc/fstab, — e apenas as do SSD externo pelo udisks2, — via System settings >> Removable devices.

— … ≠ • ≠ … —

Byteria

Translate

quinta-feira, 17 de maio de 2018

Devuan 2 Beta KDE - Desastre e recuperação