quinta-feira, 17 de maio de 2018

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

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
  • PIM & uso inicial de RAM
  • Remoção do Akonadi
  • O caso do Debian testing

Referências



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

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

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

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

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.

— … ≠ • ≠ … —

Without-SystemD



Debian


sábado, 28 de abril de 2018

Limpeza do Cooler da CPU

Poeira de 2½ anos acumulada no Cooler da CPU

Dois anos e meio (30 meses) é tempo demais para deixar o computador sem uma limpeza, — em especial, na pacata região serrana ao norte de Brasília, — onde o trânsito de veículos na chamada “área verde” das quadras residenciais levanta toneladas de poeira no inverno seco do Planalto Central.

Felizmente, não gosto de tapetes, carpetes, cortinas, — cujas fibras em suspensão no ar são ativamente atraídas (eletricidade estática) e cujo emaranhado gera resistência mecânica, — e que não poupa sequer os ambientes fechados, com filtro de ar condicionado.

Essa demora se deveu a uma falsa tranquilidade, — de “ver” a temperatura da Mobo, CPU, Core0, Core1 só tocarem níveis “altos” uma vez ou outra (por curtos momentos), — e se manterem sempre bem longe dos níveis “críticos”, no dia-a-dia.

Mas o inesperado faz uma surpresa: — Surge uma tarefa que exige da CPU um esforço intenso e prolongado, — e você é obrigado a interrompê-la, ao perceber que o Cooler não está dando conta do recado.

A experiência deixou claro que o “problema” não começa só quando se constata aquecimento regular (em condições normais), — mas desde o momento em que o Cooler já não esteja pronto para fazer frente a uma situação excepcional, de aquecimento por longos períodos.

Índice


  • Retirada do Cooler
  • Limpeza do Cooler
  • Fixação do Cooler na placa-mãe
  • Talvez da próxima vez eu entenda
  • A conferir
  • Levantamento objetivo
  • Cooler de reserva
  • Temperatura “alta” e “crítica”
  • Grub louco + Cooler sujo (ou, E=mc²=Boom!)

Registros anteriores



Retirada do Cooler


Destravar e puxar os êmbolos para retirada do Cooler da CPU

Para soltar o Cooler da CPU, as fendas das 4 presilhas devem ser giradas no sentido anti-horário, até a posição tangente ao círculo, — para que o êmbolo possa ser puxado, liberando os pinos fixados à placa-mãe.

Tornar a travar o êmbolo (retraído) após a retirada do Cooler da CPU

Após retirar o Cooler da CPU, o manual orienta a restabelecer (reset) a trava dos êmbolos, — que se encontram retraídos (alongados) para fora das presilhas.

Posições radial (trava) e tangencial (destrava) das fendas do êmbolo

Para facilitar as anotações, o esboço ilustra:

  • À Esquerda - Fendas na posição radial (voltadas para o centro do Cooler) — mantêm a trava dos êmbolos. — Para destravá-los, girar a fenda no sentido anti-horário.
  • À Direita - Fendas em posição tangencial à circunferência do Cooler — destravam os êmbolos, permitindo puxá-los, para liberar as presilhas. — Para voltar a travá-los, girar a fenda no sentido horário.

Limpeza do Cooler


Limpeza incompleta do Cooler, — poucos segundos de jato de ar comprimido

Tal como se encontrava, a poeira acumulada simplesmente não permitia a passagem do ar pelas aletas de dissipação de calor, — portanto, o primeiro passo foi retirar o Cooler da CPU e levá-lo ao mesmo borracheiro onde fiz a limpeza em Out. 2015.




Importante! - Isto não é uma “orientação”, nem um conselho. — Ignoro tudo sobre compressores, filtros, impurezas, umidade, pressão etc. — Apenas vi um técnico razoavelmente estudado e sério fazer isso, uma vez (no meu antigo micro, com todos os componentes montados), e adotei essa prática. Hoje, só não levo o computador inteiro, por falta de carro. Fica chato, levar debaixo do braço.

Dessa vez, infelizmente, o borracheiro não tinha (ou não quis plugar) a pistola na mangueira de ar comprimido, — sugeriu um improviso, com uma chave avulsa, que exigia as duas mãos para disparar o jato de ar. — Nem pensar, jatear um Cooler solto, e ele sair voando.

O jeito foi pedir ajuda de um auxiliar (pouco afeito ao que seja limpeza de ventoinha, aletas etc.), — e o Cooler não ficou 100% limpo. — O resto da limpeza foi feita com um pincel, mais tarde, na medida do possível.

Uma espátula de massa de modelar pode não ser o ideal, — mas também funciona

A pasta térmica antiga foi raspada das superfícies de contato do Cooler e da CPU com uma espátula de plástico macio, — os resquícios foram tirados com um guardanapo de papel (que saiu preto), — e no lugar foi espalhada nova camada de pasta.

Fixação do Cooler na placa-mãe


Cooler recolocado na placa-mãe, sobre a mesa, — uma das poucas fotos de 2015

A fixação do Cooler foi feita com a placa-mãe em cima da mesa, — pois só fiz isso 2 vezes em 10 anos, e ainda me parece complicado (e inseguro) tentar com a Mobo aparafusada no fundo do chassi. — Mas, mesmo com a placa sobre a mesa, mais uma vez voltei a perder meia hora, só nessa tarefa.

Quem trabalha na área, fixa o Cooler em 5 segundos, até de olhos fechados. — Já vi técnicos darem apenas uma olhada (para encontrar os furos e posicionar) e liquidarem o assunto em 4 cliques rápidos, — parece que só pelo tato.

Ação do pino central para expandir e fixar as presilhas (Cooler de reserva)

Em resumo, as presilhas de fixação são bipartidas e flexíveis, — passam com facilidade pelos furos da placa, — e depois disso o êmbolo permite empurrar um pino central em cada presilha.

Presilha bipartida com a cabeça encaixada, — e o êmbolo, que a expande e impede de soltar

Com o avanço do pino central, a ponta das presilhas se alarga e firma no lugar, — como uma bucha de parede.

Êmbolos inicialmente retraídos (alongados), — e as fendas no topo apontandas para o centro (posição radial)

Segundo a folha de instruções, — meros desenhos, sem legendas e sem texto explicativo, — desde o começo os êmbolos devem estar retraídos (alongados para fora das presilhas); — e as fendas viradas para o centro do Cooler (fendas em posição radial).

Nessa posição radial, o êmbolo encontra-se travado, — ou seja, não pode ser puxado para trás (alongamento). — Mas já estão soltos, desde o começo.

Apertar por um ressalto lateral, — e só depois pressionar o êmbolo

No desenho seguinte, primeiro as presilhas são encaixadas nos furos, — e só depois os êmbolos são pressionados para baixo, — empurrando os pinos que vão firmar a ponta das presilhas no local.

Importante - Fixar, primeiro, 2 presilhas em cantos opostos, — depois, as 2 presilhas na outra diagonal, — pois, se começar fixando 2 de um mesmo lado, o outro lado do Cooler pode ficar meio afastado da CPU.

Tudo isso, com as fendas sempre voltadas para o centro do Cooler, — vale dizer, na posição que trava o êmbolo, para ele não voltar a se soltar.

Com o avanço do êmbolo, o comprimento das presilhas fica no tamanho justo

Ao pressionar os êmbolos para o interior das presilhas, cada conjunto, — inicialmente alongado, — fica no comprimento justo para prender o Cooler sobre a CPU, sem qualquer folga ou balanço.

Talvez da próxima vez eu entenda


Manual da CPU + Cooler Intel© Core™2 Duo

Até aí, não existe mistério, — só faltava combinar com as peças.

Na prática, perdi um tempo enorme (pela 3ª vez!), tentando de várias maneiras, — a começar pelo que diz o manual (claro!), — mas ao iniciar este relato (6 dias depois), já não me sentia seguro para afirmar, com certeza absoluta, exatamente qual a maneira que acabou dando certo.

Sinal de que não anotei imediatamente, — de preferência, logo após conseguir fixar 2 presilhas, — e antes de fixar as outras 2 (para confirmar se anotei certo).

Quem sabe, da próxima vez lembro de anotar com exatidão, — e espero que essas notas de agora ajudem a identificar as alternativas tentadas, — e qual delas dará certo.

A conferir


Reorganização dos cabos desde 2015, — exceto pelo DVD Sata, 3º HDD, Fonte e poeira

Empurrar as presilhas pelo topo, — vale dizer, apertando o êmbolo, — várias vezes fez com que este avançasse e alargasse o pino inferior, antes dele passar pelo furo na placa; e aí, não tinha mais como passar.

Mais prático é empurrar cada presilha por um ressalto lateral, a meia altura, — e só depois de encaixá-la, pressionar o êmbolo para fixá-la no lugar.

Mas mesmo isso, falhou vezes sem conta.

O que “acho” que de fato funcionou foi trabalhar com os êmbolos destravados, até completar a fixação, — e travá-los em seguida.

Infelizmente, essa anotação só foi feita às 19:45, — quase 6 horas depois, — e exatamente nesses termos: — “acho”.

Levantamento objetivo


Emaranhado de cabos em 2009

O “Caderno de Informática” tem sido da maior utilidade, desde 2006, para lembrar configurações, aprendizados, ou a solução de problemas e dificuldades, — mas no caso específico da fixação do Cooler, não ajudou muito. — A atenção estava focada em não cometer erros na manipulação dos componentes, nem no cabeamento. Vai que explode? Anotações acabaram ficando para depois.

Além de vagas, imprecisas, as anotações também continham contradições. — Para preencher as lacunas, foi necessário recorrer às fotografias (relativamente bem organizadas), — e à “caderneta de campo”, onde é mais fácil localizar datas, trajetos e compra de peças (sim, as Notas Fiscais devem estar em algum lugar).

As 3 vezes em que fixei o Cooler na CPU, — sempre com a placa-mãe sobre a mesa, — foram:

  • 26 Mar. 2009 - Montagem do computador
  • 23 Out. 2015 - Limpeza do Cooler
  • 23 Abr. 2018 - Limpeza do Cooler

26 Mar. 2009 - A única anotação é de que o computador passou pelo “smoke test” sem explodir. — Não consta nem a hora, — e as primeiras fotos só foram feitas 3 dias depois. — Bola fora nº 1.

Fotos talvez gerassem confusão, nessa data. Até por volta de 2006, evitava aplicar Horário de Verão na câmera, para facilitar a identificação do ângulo solar, em fotos externas, — e houve um intervalo de 2 ou 3 anos, sem bateria (nunca descobri onde ela fica, para substituir), e a datação foi irregular, até optar sempre pela hora “oficial”. — No celular, este foi o padrão, desde Fev. 2015.

Cooler já fixado à placa-mãe no início da tarde, — e chassi ainda sem limpeza

23 Out. 2015 - As anotações indicam que o Cooler foi retirado antes de 0:40, — levado ao borracheiro pela manhã (7:44 ~ 11:04), — e que “recolocar deu trabalho das 12h às 16h” (sinal de que não foram escritas antes dessa hora).

Reorganização dos cabos, — e placa-mãe ainda na mesa, — no final da tarde

Examinadas agora, as fotos dizem que não foi exatamente assim. — Às 13:54 o Cooler já estava fixado na placa, em cima da mesa (e não existe foto antes dessa hora!), — mas depois disso:

  • Foram retirados todos os demais componentes do chassi, inclusive o Painel frontal
  • Às 15:30, o chassi foi levado para uma limpeza na varanda
  • O gravador de DVD foi realocado na 3ª casa, do alto para baixo
  • Os 2 antigos HDDs foram realocados nas casas inferiores (transversais), para cabeamento pelo lado oposto
  • O Painel frontal foi recolocado às 17:10, — a placa-mãe continuava na mesa
  • A placa-mãe foi fixada no chassi (6 parafusos), ajustando os conectores ao painel de trás
  • A fonte de energia foi fixada no chassi
  • Os cabos Sata foram etiquetados nas 2 extremidades, para facilitar a vida
  • A disposição dos cabos foi reorganizada, — o interior do chassi ficou mais “espaçoso”
  • O computador só foi ligado por volta de 23:10

Portanto, a faixa “das 12h às 16h” nas anotações significa que “recolocar” não se referia só ao Cooler, — e mesmo assim, foi uma avaliação bem subjetiva.

Cooler fixado à placa-mãe desde o início da tarde, em Out. 2015

De fato, as fotos foram baixadas na época, mas só agora renomeadas no formato YYYY-MM-DD_HH-mm-SS, para um levantamento mais objetivo.

O celular mantém a hora sincronizada. O Horário de verão tinha começado 5 dias antes (18 Out. 2015); e a hora UTC dos dados Exif confere. — A única hipótese capaz de deslocar a faixa de tempo para 1 hora mais à frente (das 13h às 17h), é que as fotos tenham sido baixadas no antigo WinXP, que ainda estava instalado, e ele tenha interpretado como “UTC-03:00”, ao invés de “UTC-02:00”, pois suas definições de fuso horário permaneciam desatualizadas (a sincronização NTP só era feira pelo Linux), — mas verificar isso exigiria um estudo do ângulo solar em fotos externas do mesmo dia.

Por isso, sinto pouca firmeza nas anotações de 2015, que, — no que se refere à fixação do Cooler, — parecem mero resumo dos desenhos nas instruções do fabricante.

Anotações sem indicação horária, — prosseguindo abaixo das notas do dia seguinte

Foram escritas pelo menos 2 horas mais tarde, — ou talvez 9 horas depois… ou, até mesmo, no dia seguinte, — pois extravasam para a outra página (abaixo das anotações do dia 24).

A ter seguido exatamente o que sugerem os desenhos do manual de instruções, ficaria difícil entender esse trecho: — «Mesmo com a placa-mãe sobre a mesa, foi complicado entender a lógica das 4 presilhas e conseguir fixá-las todas, de modo que o Cooler encoste bem na CPU». — Não faria sentido.

Na verdade, a única coisa que faria sentido, era anotar exatamente qual o modo encontrado para fixá-las, — ao invés de abobrinhas genéricas. — Bola fora nº 2.

Ficou registrada, pelo menos, uma hipótese

23 Abr. 2018 - Foram anotadas: (a) A disposição dos fios e do conector do Cooler, ao retirá-lo; (b) A disposição dos demais cabos conectados à placa-mãe, ao retirá-la; e por fim, — sem indicação de hora, — (c) Um esboço da posição das fendas dos êmbolos, tal como “acho” que tinha feito para tornar a fixar o Cooler.

Está claro que, ao fazer essa última anotação, já não tinha certeza. — Mais uma bola fora. — Burrice 3 x 0 Anotações.

As fotos mostram apenas que às 19:35 a placa-mãe ainda estava aparafusada no chassi, — começava a desconectar os cabos, para retirá-la, — e às 20:25 o Cooler já estava bem fixado na placa-mãe, sobre a mesa.

Cooler de reserva


Cooler de reserva com suporte Intel 775

Ao começar a escrever, senti falta de mais algumas imagens, — tirei da caixa um Cooler novo, — até agora usado apenas para essas fotos.

Foi comprado por precaução (provavelmente nos últimos 2 anos), — pois a cada dia fica mais incerto encontrar peças para as especificações desse hardware, — mas o Cooler original continua macio e silencioso.

A qualidade ou durabilidade do Cooler de reserva ainda é uma incógnita. — O importante é resolver em caso de emergência num Sábado à noite, e se manter por mais alguns anos, — o que é mais do que se prevê para continuar usando um processador tão antigo.

A experiência tem mostrado que Teclado e Mouse Microsoft duram quase 10 vezes mais do que similares de baixo custo.

Temperatura “alta” e “crítica”


Indicações de temperaturas “altas” e “críticas” da Mobo, CPU, Core0, Core1

Depois de muito pesquisar na internet qual seria a temperatura “normal”, “exagerada” ou “perigosa”, — e deparar com os maiores disparates imagináveis, — acabei descobrindo que a orientação mais confiável e fácil de encontrar é fornecida pelo próprio hardware e seu firmware:

# sensors
atk0110-acpi-0
Adapter: ACPI interface
...
CPU Temp: +34.0°C  (high = +60.0°C, crit =  +95.0°C)
MB Temp:  +37.0°C  (high = +45.0°C, crit =  +95.0°C)
...
coretemp-isa-0000
Adapter: ISA adapter
Core 0:   +43.0°C  (high = +76.0°C, crit = +100.0°C)
Core 1:   +42.0°C  (high = +76.0°C, crit = +100.0°C)

Naturalmente, isso depende de instalar o lm-sensors (se não veio com a distro) e configurá-lo pelo comando # sensors-detect.

Grub louco + Cooler sujo (ou, E=mc²=Boom!)


Core0 a 99º Centígrados durante um interminável grub-mkconfig

O monitoramento pelo Conky já vinha sugerindo acúmulo de poeira no Cooler da CPU, — porém, nada que parecesse urgentíssimo. — Poucas vezes atingia 76º Centígrados, e não por muito tempo… enquanto o grub-mkconfig se limitou a 15 minutos, no máximo 30 minutos, rodando a partir do HDD.

A situação ameaçou virar catástrofe ao tentar instalar o Manjaro 17-1-8, a partir de sessões Live DVD, — felizmente, monitorando pelo Conky, para registro em capturas de tela. — As coisas sempre são um pouco mais forçadas, quando se roda uma sessão Live.

A fase de instalação do bootloader (grub-mkconfig) começou a demorar demais, — a temperatura alcançou 90ºC… 96ºC… 98ºC… e mal deu tempo de Cancelar a instalação.

O cancelamento do instalador demorou a interromper o processo. Ainda foi tentado # killall grub, mandinga, reza-braba, mas no final a prudência aconselhou Power Off imediato.

Com a máquina desligada, foram desplugados 2 HDDs, — com 6 das 12 distros instaladas (KDE Neon, Mageia, Debian, Kubuntu 16.04, openSUSE Leap, PCLinuxOS), — ficando apenas 1 HDD (Mint, Slackware, Arch) e 1 SSD externo (Bionic, Devuan) para serem examinados pelo Grub.

Mesmo assim, a segunda tentativa de instalação do Manjaro elevou a temperatura de Core0 a 92ºC, na etapa do grub-mkconf, — e foi abortada sem esperar mais.

Depois disso, claro, a limpeza do Cooler pulou para o topo das prioridades, — o que não significa, necessariamente, “na hora” (às 19h?), uma vez que dependia de encontrar um borracheiro aberto, por perto; e ainda exigiria mais algum tempo para retirar a placa, trocar a pasta térmica e tornar a colocar o cooler, em condições confortáveis de trabalho, de modo a excluir o risco de deixá-lo mal fixado.

De imediato, a solução foi instalar o Manjaro sem bootloader, — coisa de 25 minutos, bastante razoável nas circunstâncias (baixa taxa de transferência do DVD, hardware antigo).

Ficaram, portanto, 2 problemas bastante distintos, — a resolver por partes:

  1. Limpar o Cooler
  2. Descobrir qual o problema do Grub

— … ≠ • ≠ … —

Ferramentas &tc.


segunda-feira, 23 de abril de 2018

Grub enlouquecido com 12 distros Linux em multiboot

CPU chegando a 99º Centígrados durante um grub-mkconfig interminável

De repente, o Grub enlouqueceu.

Atualizações de Grub*, — que se faziam em 1 minuto, — começaram a demorar 5 minutos… depois, 10 minutos… 15 minutos…

* update-grub é um alias para grub-mkconfig -o /boot/grub/grub.cfg
* update-grub é um alias para grub2-mkconfig -o /boot/grub2/grub.cfg

Essa demora se tornou especialmente desagradável nos casos em que o grub-mkconfig é chamado por outro processo, — por exemplo, quando o Synaptic instala uma nova versão de Kernel (ou remove uma versão antiga), com repetições, — ou na fase final de instalação de uma nova distro (instalar bootloader) a partir de uma sessão Live, onde as condições são mais apertadas.

E para complicar, ficou evidente que o Cooler da CPU precisava de limpeza, — tanto mais urgente, porque a intensa e prolongada atividade do grub-mkconfig causava imenso aquecimento da CPU, — em alguns casos por mais de 40 minutos, sem qualquer alívio.

Índice


  • Grub & Synaptic
  • Grub, Zypper, BtrFS & Snapper
  • Grub & instaladores
  • Grub por comando
  • Grub inchado
  • Grub embaralhado
  • Grub & Os-Prober
  • Resumo de uma ignorância sobre o Grub

Registros anteriores



Grub & Synaptic


Remoção de Kernel 4.4.0-108 pelo Synaptic — 1º grub-mkconfig

No contexto do Synaptic, a demora se fez notar primeiro no KDE Neon (creio que há 4 ou 6 meses), devido ao que parecem ser 2 ou 3 grub-mkconfig sucessivos (1 para cada Kernel?), — chegando a totalizar 30 e até 45 minutos, nas últimas semanas.

5 Fev. 2018 - Às 18:06, a captura de tela mostra o início do primeiro acionamento do grub-mkconfig (Core0: 59ºC), ainda detectando 3 kernels.

Início do 2º acionamento do grub-mkconfig pelo Synaptic

Às 18:18, a captura de tela registra o início do segundo acionamento (57ºC), — agora, detectando apenas os 2 kernels que iriam permanecer.

Início do 3º acionamento do grub-mkconfig pelo Synaptic

Às 18:27 o início de uma terceira “passagem” (62ºC).

Só aí, já se foram 21 minutos, — atribuíveis às primeiras 2 “passagens” do grub-mkconfig, — pois a maior demora ocorre depois, na detecção das outras 11 distros.

Nessa proporção, o processo pode ter durado alguma coisa entre 31 e 32 minutos (até 18:37 ou 18:38). — Infelizmente, não fiquei olhando, para ver o final.

A partir de 21 Fev. 2018, a demora chamou atenção também no Kubuntu Bionic Beaver (daily-build), — e piorou após instalar um segundo Bionic Beaver (Beta2), em 14 Mar. 2018, — lado a lado com o primeiro.

Depois disso, houve vários casos em que atualizações envolvendo Kernel chegaram a tomar mais de 40 minutos, — e não apresentou qualquer melhora, ao substituir 1 dos 2 Bionic Beaver pelo Manjaro, em 19 Abr. 2018.

Grub, Zypper, BtrFS & Snapper


Início de um demorado grub-mkconfig chamado pelo zypper, ao instalar novo Kernel no openSUSE

21 Abr. 2018 - Uma das mais longas demoras (fora do Bionic Beaver) foi registrado no openSUSE Leap, onde esse problema ainda não se havia manifestado de modo tão evidente, — até por não exibir explicitamente o comando grub-mkconfig e suas saídas de retorno, no Terminal.

Final de um demorado grub-mkconfig chamado pelo zypper, ao instalar novo Kernel no openSUSE

Uma sequência de capturas de tela (com nomes-de-arquivo no formato YYYY-MM-DD_HH-MM-SS) permite acompanhar todo o processo e delimitar sua duração:

       Leap    21 Abr. 2018

               zypper up - re-Grub

     15:57:51      ─   Começa
     16:20:34  22’43’’ Intervalo
     16:22:23   1’49’’ Recomeça
     16:44:37  22’14’’ Fim

         Diff    Sum 
     00:46:46  46’46’’

Manutenção automática do openSUSE, após reiniciar, — com novo grub-mkconfig

Após reiniciar, o openSUSE costuma realizar vários procedimentos de manutenção automática, em segundo plano, — BtrFS, Snapper e… Grub! — para reorganizar os Snapshots e atualizar o acesso a eles.

Em boa hora, já tinha desplugado o SSD externo, contendo Bionic Beaver, Manjaro e Devuan, — de modo a reduzir o número de distros a detectar, — mas, mesmo assim, o novo acionamento do grub-mkconfig demorou cerca de 14 minutos.

O momento do início e fim das atividades de CPU pode ser determinado com boa aproximação, desde quando esses gráficos do Conky foram redimensionado para 120 pixels (120 segundos).

No intervalo, foi editado o ~/.conkyrc, — pois a cada sessão os sensores Temp e Fan do openSUSE se alternam entre /sys/class/hwmon/hwmon0 e …hwmon1, — e ocultei também as partições do SSD externo, que já estava quase desistindo de usar.

Grub & instaladores


Falha do update-grub2 e crash do Draklive-installer, — após 12 minutos de intensa atividade da CPU

No contexto dos instaladores, houve vários crashes na fase final de instalação do PCLinuxOS, — que só pôde ser concluída após optar pelo “grub-legacy” (v.0.97, modo texto), — deixando para configurar o grub2, via Control Center, depois de instalado no HDD.

CPU chegando a 99º Centígrados durante um grub-mkconfig interminável

O problema se repetiu ao tentar instalar o Manjaro 17-1-8, — quando a intensa e prolongada atividade de CPU se somou a um acúmulo de sujeira no Cooler, levando a um nível perigoso de aquecimento, — e foi necessário abortar.

Naquela situação, o único jeito foi instalar o Manjaro sem bootloader, — e levar a ventoinha do Cooler ao borracheiro, logo cedo, na Segunda-feira.

Portanto, as maiores demoras se registraram quando o grub-mkconfig era acionado por outro processo (com 3 execuções consecutivas), — ou em sessões Live DVD; — e os menores tempos quando acionado por comando manual direto (apenas 1 execução).

Grub por comando


Cronometrando o comando update-grub no Mageia

Nos piores momentos, — com 2 Kubuntu Bionic Beaver instalados, — atualizações de Grub pelo Mageia chegaram a demorar de 12 a 14 minutos.

Isso porque, no Mageia, — que gerencia o Menu de inicialização usado no dia-a-dia, — o grub-mkconfig roda por comando manual.

Vale dizer, — roda apenas 1 vez, — não 3 ou 4 vezes.

19 Abr. 2018 - Logo após a substituição de 1 dos 2 Bionic Beaver pelo Manjaro, esse tempo desabou para “apenas” a metade, — cerca de 7 minutos:

Mageia      Dia 19 Abril (após Manjaro)

21:56:21     ─    date && sudo update-grub && date
21:58:04  1’43’’  Mageia + Found Neon & Debian
21:59:10  1’06’’  Found Kubuntu Xenial
21:59:13     3’’  Found Leap
21:59:22     9’’  Found PCLinuxOS
21:59:28     6’’  Found Mint
22:00:27    59’’  Found Slackware
22:00:29     2’’  Found Arch
22:00:32     3’’  Found Kubuntu Bionic
22:02:55  2’23’’  Found Manjaro
22:02:59     4’’  Found Devuan
22:03:17    18’’  Finished

    Diff   Sum
00:06:56  6’56’’

Esses dados seriam perfeitos, se apenas tivéssemos certeza se cada um desses tempos foi gasto para encontrar cada distro e dizer “Found”, — ou para processar a distro anterior (após tê-la encontrado).

Cronometrando update-grub por comando no Mageia

De qualquer modo, ficou claro que as 3 distros do SSD externo (Bionic, Manjaro, Devuan) eram responsáveis por 3 daqueles quase 7 minutos, — ou seja, todas as outras 9 distros exigiam “apenas” 4 minutos para serem detectadas (e processadas!) pelo grub-mkconfig do Mageia:

Mageia       Dia 21 de Abril (sem SSD)

17:33:21     ─    mkconfig
17:33:27     6’’  Found Mageia
17:33:38    11’’  Found Neon
17:34:56  1’18’’  Found Debian
17:35:58  1’02’’  Found Kubuntu Xenial
17:36:02     4’’  Found Leap
17:36:10     8’’  Found PCLinuxOS
17:36:14     4’’  Found Mint
17:37:15  1’01’’  Found Slackware
17:37:18     3’’  Found Arch & Finished

    Diff   Sum 
00:03:57  3’57’’

Chama atenção o brusco alívio da CPU durante a detecção do openSUSE, PCLinuxOS e Linux Mint em rápida sequência.

Grub inchado


Arquivo /boot/grub/grub.cfg descomunal, — quase 90.000 linhas, — com 7.000 entradas “Devuan”

22 Abr. 2018 - Dada a impressão (como leigo) de que o principal trabalho do grub-mkconfig é de leitura e processamento dos arquivos grub.cfg das “outras” distros, — com uso intensivo dos comandos sed e paste, entre outros, — finalmente fiz um exame desses arquivos.

Alguma coisa estava muito errada.

No Kubuntu 18.04 Bionic Beaver LTS (daily-build), por exemplo, o arquivo grub.cfg (gerado em 17 Abr.) tinha quase 90.000 linhas de código, — com mais de 7.000 strings “Devuan”, por exemplo, — no total de 5,5 MiB.

A primeira string “Devuan” aparecia logo no submenu do Debian (linha 462), e se repetia… Bom, eu contei até a 150ª repetição, só neste submenu do Debian. — Acho que já dá para imaginar o resto.

O arquivo grub.cfg do próprio Devuan, tinha “apenas” 552 KiB, — meras 9.676 linhas, — e apenas 722 strings “Devuan”.

Em segundo lugar, por ordem decrescente de tamanho (só entre os que lembrei de fazer backup), o arquivo grub.cfg do Manjaro (gerado na manhã de 22 Abr.) tinha 3,3 MiB, — e… sim! — Você já imaginou a loucura que havia dentro dele.

O grub.cfg do Linux Mint, — que esqueci de copiar, — estava com 2,4 MiB.

Felizmente, não tive a presença de espírito de guardar outros backups, — a sanidade mental agradece, — mas é garantido que, nessas 12 distros, poucas eram 100% inocentes.

O grub.cfg do Arch Linux brilha como um diamante de “estabilidade”, — impávido, sem qualquer alteração, há exatos 10 meses (16 Jun. 2017), — pelo simples fato de que todas as atualizações de Kernel se chamam (sempre!) “linux-lts”.

Quando o Arch Linux recebe nova versão de Kernel, ele nem perde tempo atualizando seu grub.cfg, — basta reiniciar, — e carrega com o Kernel atualizado.

Enfim, o Slackware não tinha absolutamente nada na pasta /boot/grub, — zero arquivos.

Isso abalou minha vaga impressão de que o grub-mkconfig precisasse encontrar um grub.cfg em cada distro, para saber como lidar com ela.

De fato, uma vez o Grub deixou de detectar uma distro que ainda não tinha grub.cfg, — e passou a detectá-la, depois que esse arquivo foi gerado.

Mas também detectou o Manjaro antes dele gerar seu próprio grub.cfg — e funcionou (sem a string intel.ucode.img)… pelo menos durante algumas horas. — Depois, falhou. Então, carreguei uma sessão Live e gerei o grub.cfg do Manjaro, que passou a ser melhor detectado pelo Grub do Mageia.

Grub embaralhado


Neon identificado por si mesmo como “GNU Linux”, — e outro, como “Neon”, — em 2016

Embaralhamento de distros semelhantes, — provável origem dessa proliferação de “entradas-fantasma”, — foi registrado (pelo menos) desde a instalação do KDE Neon, em Mai. ~ Jun. 2016.

Na primeira instalação, seu próprio Grub o identificou como “GNU / Linux”, — mas depois de instalar também uma segunda versão (User Edition vs. Development), ela foi identificada como “KDE Neon”.

Mistura de “GNU” e “Neon”, — com sdb1, sda1 e sda3, — nas opções avançadas do Kubuntu

Uma das instalações do KDE Neon foi substituída pelo Debian, dias depois, — mas o Grub gerado pelo Debian aumentou a confusão.

Nas opções avançadas do Kubuntu, apareceram fantasmas de 2 instalações do KDE Neon, — uma delas, intitulada “GNU / Linux”, — misturando sdb1, sda1 e sda3 de um modo escandaloso.

Ocultando entradas surreais pelo Grub-customizer, em 2016

Na época, essas entradas surreais foram apenas ocultadas pelo Grub-customizer, — aparentemente, com efeito duradouro, — mesmo quando o grub-mkconfig era chamado pelo Synaptic, ou manualmente, por comando direto.

Durante alguns meses, permaneceram apenas essas 4 distros, — e depois, 3 delas foram reinstaladas (Debian, Neon, Mint), — portanto, apenas o Kubuntu deve guardar traços daquele antigo Grub-customizer.

No Mageia, o Grub-customizer está instalado, — mas parece nunca ter sido usado, — pois não existe registro dele em ~/.config.

A eventual metástase dos embaralhamentos pode ter seguido mais ou menos estas etapas:

13 Jul. 2017 - Embora o KDE Neon fosse o primeiro a dar sinais de longa demora nas atualizações de Grub, — sempre pelo Synaptic, chamando sucessivos grub-mkconfig, — as coisas podem se ter agravado um pouco ao instalar o Devuan 1 “ao lado” do Debian.

21 Fev. 2018 - Há sinais de que a demora se agravou, bastante, ao instalar o primeiro Kubuntu Bionic “ao lado” do Kubuntu Xenial e do KDE Neon.

7 Abr. 2018 - A demora alcançou seu tempo máximo a partir da instalação do segundo Bionic.

No Mageia, — rodando só 1 vez, por comando:

bash-4.3$ date && sudo update-grub && date
Ter Abr 17 06:38:58 -03 2018
[sudo] senha para flavio:
Generating grub configuration file ...
Tema encontrado: /boot/grub2/themes/openSUSE/theme.txt
Imagem Linux encontrada: /boot/vmlinuz-4.14.30-desktop-3.mga6
Imagem initrd encontrada: /boot/initrd-4.14.30-desktop-3.mga6.img
Imagem Linux encontrada: /boot/vmlinuz-4.14.25-desktop-1.mga6
Imagem initrd encontrada: /boot/initrd-4.14.25-desktop-1.mga6.img
Imagem Linux encontrada: /boot/vmlinuz-4.9.56-1.mga6
Imagem initrd encontrada: /boot/initrd-4.9.56-1.mga6.img
Imagem Linux encontrada: /boot/vmlinuz-linus
Imagem initrd encontrada: /boot/initrd-linus.img
Imagem Linux encontrada: /boot/vmlinuz-desktop
Imagem initrd encontrada: /boot/initrd-desktop.img
Encontrado KDE neon User Edition 5.12 (16.04) em /dev/sda1
Encontrado Debian GNU/Linux buster/sid em /dev/sda3
Encontrado Ubuntu 16.04.4 LTS (16.04) em /dev/sdb1
Encontrado openSUSE Leap 42.3 em /dev/sdb2
Encontrado PCLinuxOS em /dev/sdb3
Encontrado Linux Mint 18 Sarah (18) em /dev/sdc1
Encontrado Slackware 14.2 em /dev/sdc2
Encontrado Arch Linux em /dev/sdc3
Encontrado Ubuntu Bionic Beaver (development branch) (18.04) em /dev/sdd1
Encontrado Ubuntu Bionic Beaver (development branch) (18.04) em /dev/sdd2
Encontrado Devuan GNU/Linux ascii/ceres em /dev/sdd3
concluído
Ter Abr 17 06:53:04 -03 2018

Tempo decorrido: 14’06’’ — o que poderia dar o triplo, se chamado pelo Synaptic ou Zypper.

19 Abr. 2018 - Deletar 1 dos 2 Kubuntu Bionic trouxe um bom alívio nas atualizações do Grub pelo Mageia, — pelo menos, até instalar o Manjaro:

bash-4.3$ date && sudo update-grub && date
Ter Abr 17 10:15:08 -03 2018
...
concluído
Ter Abr 17 10:23:18 -03 2018

Tempo decorrido: 8’10’’

E após remover um Kernel do Kubuntu Bionic restante:

Tempo decorrido: 6’50’’

Grub & Os-Prober


Desabilidando os-prober no /etc/default/grub de todas as distros, — exceto Mageia e openSUSE

Uma vez que apenas o Grub do Mageia (sda) é usado todos os dias, — e o Grub do openSUSE Leap (sdb) mantido como reserva, — a melhor solução foi dizer ao Grub das demais distros que se limite a cuidar de suas próprias entradas.

Nos respectivos arquivos /etc/default/grub, editar (ou acrescentar) essa linha, — que desabilita os-prober, — o script responsável por extrair e processar dados do grub.cfg das demais distros:

GRUB_DISABLE_OS_PROBER=true

No openSUSE Leap, o arquivo /etc/default/grub apresentava "false" entre aspas:

GRUB_DISABLE_OS_PROBER="false"

Desse modo, o grub-mkconfig de 10 distros vai cuidar apenas do que diz respeito a cada uma delas, — e o tempo de execução se reduz drasticamente:

      9’’  Neon + senha
     15’’  Debian + senha
      9’’  Kubuntu 16.04 + senha
      9’’  PCLinuxOS (su)
      7’’  Mint + senha
      6’’  Slackware (su)
     13’’  Arch (su)
     25’’  Bionic + senha
     37’’  Manjaro (su)
     15’’  Devuan (su)

  • Obs.: - Nesses tempos, deve-se considerar, também, o uso de menu de texto ou gráfico (além do tema).

Arquivos grub.cfg finalmente pequenos e simples

Os arquivos grub.cfg dessas 10 distros voltam a ser simples e pequenos, — na maioria dos casos, cerca de 10 KiB (ou bem menos), — e quando passa de 20 KiB já chama atenção, para ser examinado.

Isso constitui um grande alívio, — a cada atualização (ou remoção) de Kernel pelo Synaptic ou pelo Zypper, — ou a cada atualização de versão do Grub ou de seu tema, — e também ao instalar uma nova distro, com bootloader.

grub-mkconfig do Mageia e do openSUSE encontra 10 arquivos grub.cfg pequenos, — e sem entradas malucas, — que consegue processar rapidamente, sem queimar os miolos.

Nos dois casos, — Grub2 com menu gráfico, — o tempo de execução do grub-mkconfig se reduziu a pouco mais de 1 minuto:

   1:15’’  Mageia (su)
   1:06’’  Leap (su)

Resumo de uma ignorância sobre o Grub


Scripts em /etc/grub.d de diferentes distribuições Linux

Não foi a primeira vez que senti necessidade de “entender” o Grub, — mas “entender” tem 300 níveis diferentes, desde o novato absoluto até o super-fera.

Também não foi a primeira vez que tentei ler mais, — e saí tão confuso quanto antes.

Para “entender” o Grub é preciso, no mínimo, saber lidar muito bem com scripts e estar muito bem familiarizado com comandos como o sed, por exemplo, — depois estudar com atenção uma série de arquivos com até 300 linhas, cada, — e que variam e se multiplicam, com as distros:

$ ls -1 /media/$USER/Linux1/etc/grub.d >> ~/etc-grubd-Distros.txt

(de Linux1 a Linux12)

Linux1 - KDE Neon

00_header
05_debian_theme
10_linux
20_linux_xen
20_memtest86+
30_os-prober
30_uefi-firmware
40_custom
41_custom

Linux2 - Mageia

00_header
01_users
06_grub-customizer_menu_color_helper
10_linux
20_linux_xen
20_ppc_terminfo
30_os-prober
40_custom
41_custom

Linux3 - Debian testing

00_header
05_debian_theme
10_linux
20_linux_xen
20_memtest86+
30_os-prober
30_otheros
30_uefi-firmware
40_custom
41_custom

Linux4 - Kubuntu 16.04

00_header
05_debian_theme
10_linux
20_linux_xen
30_os-prober_proxy
31_memtest86+
32_uefi-firmware
40_custom
41_custom

Linux5 - openSUSE Leap

00_header
00_tuned
10_linux
20_linux_xen
20_memtest86+
30_os-prober
40_custom
41_custom
80_suse_btrfs_snapshot
90_persistent
95_textmode

Linux6 - PCLinuxOS

00_header
01_users
10_linux
20_linux_xen
20_ppc_terminfo
30_os-prober
40_custom
41_custom

Linux7 - Linux Mint

00_header
05_debian_theme
06_mint_theme
10_linux
10_linux.dpkg-dist
10_lupin
20_linux_xen
20_memtest86+
30_os-prober
30_uefi-firmware
40_custom
41_custom

Linux8 - Slackware

00_header
10_linux
20_linux_xen
30_os-prober
40_custom
41_custom

Linux9 - Arch Linux

00_header
10_linux
20_linux_xen
30_os-prober
40_custom
41_custom

Linux10 - Bionic Beaver (daily-build)

00_header
05_debian_theme
10_linux
20_linux_xen
20_memtest86+
30_os-prober
30_uefi-firmware
40_custom
41_custom

Linux11 - Manjaro

00_header
10_linux
20_linux_xen
30_os-prober
40_custom
41_custom
60_memtest86+

Linux12 - Devuan

00_header
05_debian_theme
10_linux
20_linux_xen
30_os-prober
30_uefi-firmware
40_custom
41_custom

Aliás, se tivesse investido mais tempo no aprendizado de comandos e scripts, nem precisaria gastar tanto tempo fazendo esse levantamento de modo manual. — Bastava gastar um tempo escrevendo ½ dúzia de scripts adequados, — e eles fariam tudo num segundo ;-)

— … ≠ • ≠ … —

Ferramentas &tc.