Translate

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!)

Referências



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, chegando a 40 minutos, — 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”.

Nesses 10 meses, o Arch Linux passou do Kernel 4.9 para 4.14, — afora inúmeras revisões, quase semanais, — sem necessidade de atualizar o Grub.

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.


sexta-feira, 20 de abril de 2018

Manjaro 17.1.8 KDE - Live, install, config

Manjaro 17.1.8 KDE, — com Kernel 4.4, para testar a sobrevida do velho hardware

Manjaro foi minha primeira distro “não-debian”, — ao iniciar essa aventura, em 2017, — e só foi removido após a instalação do Arch, devido à necessidade de simplificar algumas “correções manuais” a cada atualização do Grub.

Gerenciamento de Kernels no Manjaro

Mas deixou saudades.

Além das demais qualidades, pesou seu gerenciamento de Kernels, com uma ampla gama de opções, do 3.16 até o 4.17, — muito conveniente para conferir se o velho hardware (Q3’08 = 3º Trim. 2008) se tornou, de fato, alérgico a novos avanços, — ou se algum “conservadorismo seletivo” lhe permitirá mais alguma sobrevida, sem abrir mão de atualizações do KDE e dos aplicativos:

  • P5KPL-AM-CKD-VISUM-SI
  • 2 × Intel® Core™2 Duo CPU E7300 @ 2.66 GHz
  • Intel® 82G33/G31 Express Integrated Graphics

Índice


  • ISO, download, K3b
  • Instalação
  • Detecção do Manjaro pelo Grub do Mageia
  • Atualização & configurações
  • Situação após 5 dias
  • Instalações abandonadas (2018)
As informações daquela primeira instalação do Manjaro (2017) estão reunidas em 4 relatos, — com mais 2 sobre o “multi-Grub” e 1 sobre essa aventura na “árvore” de distribuições Linux:

ISO, download, K3b


Imagens ISO do Manjaro disponíveis em 19 ~ 20 Abril 2018

19 Abr. 2018 - Do Manjaro 18, só estavam disponíveis ISOs Alpha1 datadas do dia 9, — ao passo que do Manjaro 17-1-8 havia ISOs mais recentes, do dia 16.

De qualquer modo, o upgrade não deve demorar, — e em se tratando de uma distro rolling-release, não faria muita diferença instalar uma ou outra.

Verificação sha1sum da ISO baixada

A ISO foi baixada 2 vezes pelo Torrent, — ambas aprovadas pela verificação sha1sum, — mas nas 2 vezes a gravação do DVD pelo K3b na velocidade mínima (4x) terminou em erro aos 97%.

Como já houve casos similares, com outras distros, — e naquela época os DVDs “com erro” funcionaram bem, — também fiquei com os DVDs “errados” de agora.

Este é o relato da 3ª instalação (11 Maio), — e no final segue um resumo das instalações anteriores (19 Abril e 5 Maio), com seus problemas.

Instalação


Opções do Menu de boot do Live Manjaro

2018-05-11 - O Menu de Boot do Manjaro permite já iniciar a sessão Live com todos os parâmetros de fuso horário, teclado, linguagem e drivers (free / nonfree), — ao contrário do que acontecia há 1½ ano, quando troca do fuso + sincronização das horas exigia senha 2 vezes. — Agora, nem foi preciso lembrar as senhas da sessão Live.

Esses dados são pedidos novamente, ao iniciar o Instalador, — embora ele já preveja as mesmas opções escolhidas agora.

Como selecionar ou descartar partições Swap?

O particionamento foi feito antes, — pelo GParted, numa sessão Live do Knoppix, — para atribuir as etiquetas (Label) “Linux11” e “Home11”, que facilitam a montagem padronizada entre as 12 distros.

Portanto, bastou escolher “Particionamento manual”, — e selecionar as 2 partições.

Desta vez, escolhi instalar o Bootloader, — no sdd, para não interferir no Grub do Mageia (sda) nem no do openSUSE Leap (sdb).

Infelizmente, não encontrei nenhum modo de escolher ou descartar partições Swap, — isso teve de ser feito depois da instalação, editando manualmente o arquivo /etc/fstab.

Usuário, Máquina, Senhas, Login, — última intervenção antes de instalar

A última intervenção do Usuário é inserir seu Nome, ID, senhas de Usuário e de Administrador (a menos que prefira só uma), Nome da máquina (Linux11), optar por Login automático ou não, — e conferir o resumo da instalação, apresentado a seguir. — É a última chance de evitar algum desastre por distração.

Resumo da instalação, — última chance de evitar algum erro

Com todo cuidado, — e aguardando desaparecerem as notificações após cada Captura de tela pelo KDE Spectacle, — todas essas opções não tomaram mais do que 5 minutos.

Daí por diante, só resta assistir ao slideshow, — ou ir dar ração aos cachorros.

Comando grub-mount /dev/sdc3 (Arch): uso intenso e interminável de CPU

Como não havia necessidade de formatação, a primeira etapa foi “Unsquash filesystem”, — que durou pouco mais de 10 minutos, indicando avanço de 14% a 17% na barra de progresso, — com intenso e prolongado consumo de CPU pelo comando grub-mount /dev/sdc3 (partição do Arch Linux).

Daí, pulou para “Configure hardware”, — um breve momento de 74% na barra de progresso.

Na terceira etapa da instalação, grub-mount /dev/sdc3 (Arch) acumulou 28 + 10 minutos

A terceira etapa, — “Start procedures and passes ‘fw_type’ to other routine”, — durou quase 20 minutos, sempre indicando avanço de 88% na barra de progresso.

Nesta fase, o comando grub-mount /etc/sdc3 (partição do Arch Linux) foi duplicado, acumulando mais de 28 + 10 minutos, desde o início de cada um.

Uma rápida pesquisa indica inúmeras ocorrências desse problema do update-grub / grub-mount, — envolvendo dualboot com Arch Linux, Manjaro e Antergos, — embora também () com outras distros:


Etapa final da instalação do Manjaro, ainda com prolongado grub-mount da partição do Arch (sdc3)

A quarta etapa, — “Misc post install configurations”, — durou pelo menos 15 minutos com a barra de progresso estacionada em 92%.

Finalmente, o comando grub-mount chegou à partição de destino do Manjaro (sdd2), — mas sem largar a partição do Arch (sdc3), — com uso de praticamente 100% da CPU, e Temperatura de 62ºC em Core0.

19:44 - pt_BR
19:44 - Timezone
19:44 - Keyboard
19:45 - Partitioning
19:46 - Partition: Root
19:47 - Partition: Home
19:48 - Swap - nothing to do
19:48 - User, Password
19:49 - Installation - Summary
19:50 - Unsquash filesystem - 14%
20:00 - Unsquash filesystem - 17%
20:03 - Configure hardware - 74%
20:03 - Start procedures and passes "fw_type" to other routine - 88%
20:22 - Start procedures and passes "fw_type" to other routine - 88%
20:23 - misc postinstall configurations - 92%
20:38 - misc postinstall configurations - 92%
20:45 - Install Complete

Àquela altura, os cachorros começaram a uivar de fome, exigindo ração, — e não registrei o momento exato em que a instalação terminou, — qualquer coisa entre 54 minutos e 1 hora.

Sem o indevido prolongamento do grub-mount /dev/sdc3 (Arch Linhx), as etapas de 10 + 20 + 15 minutos se poderiam reduzir drasticamente, — e o tempo total ficaria na faixa de 21 a 24 minutos, — como observado em ocasiões anteriores (ver adiante).

Detecção do Manjaro pelo Grub do Mageia


Atualização do Grub do Mageia em 1’05’’

20:54 - Eu já havia atualizado todos os demais sistemas durante a tarde, — exceto o Mageia, que tinha anunciado centenas de pacotes novos (KDE + Apps). — Caso a mega-atualização incluísse revisão de Kernel, seu Grub automaticamente detectaria a nova instalação do Manjaro.

2018-05-12 - Pela manhã, com o Mageia reiniciado, — mas sem alterações no Kernel, — foi necessário atualizar manualmente seu Grub, para detectar a nova instalação do Manjaro.

6:25 - A atualização do Grub do Mageia demorou exatos 1’05’’, — para detectar as 12 distros.

Mais 5 minutos foram usados para examinar o /boot/grub/grub.cfg do Manjaro, — e copiar os parâmetros a serem manualmente adicionados no Grub do Mageia.

Na linha onde o Grub do Mageia chama o Manjaro com:

initrd /boot/intel-ucode.img

era necessário acrescentar manualmente:

initrd /boot/intel-ucode.img /boot/initramfs-4.14-x86_64.img

Atualização & configurações


Bem-vindo ao Manjaro! — Existem 279 atualizações disponíveis

6:36 - Diante do aviso de que havia 279 atualizações disponíveis, cometi uma enorme burrice, — esqueci de desabilitar imediatamente o “os_prober”, para evitar o grub-mount, — e o processo tomou nada menos que 52 minutos.

Foi praticamente o mesmo tempo gasto na instalação do Manjaro no computador!
Ao contrário das vezes anteriores, desta vez fiz as atualizações pelo comando pacman -Syu, — e não pelo Octopi, — embora o resultado deva ser o mesmo, por princípio.
Nova demora com grub-mount logo na primeira atualização do Manjaro

06:33 - Wellcome to Manjaro!

06:35 - sudo pacman -Syu (start)
06:45 - KInfocenter (before updates)
07:02 - sudo pacman -Syu (start grub-mount)
07:17 - Keyboard (3rd Level)
07:17 - Compositor (was OpenGL 2.0)
07:17 - automount removable devices
07:19 - disable KWallet
07:19 - Users
07:19 - disable Filesearch
07:20 - Login manager
07:20 - startup Apps: Hello & Yakuake
07:20 - Restore Previous Session (SDDM)
07:21 - PrintScreen shortcuts
07:22 - Transparent oxygen (Window decoration)
07:23 - Compositor (set to XRender)
07:24 - Theme: Maia transparent (not found)
07:25 - sudo pacman -Syu (grub-mount, Yet)
07:26 - Kernel management (no action, now!)
07:27 - sudo pacman -Syu (complete)

Configurado e testado o acesso ao Terceiro nível do Teclado

Esse tempo só não foi totalmente desperdiçado porque aproveitei para documentar o sistema pelo KInfocenter, e adiantar uma série de configurações, — como habilitar o acesso ao 3º Nível do Teclado, mudar o Compositor para XRender, definir a montagem automática das demais partições, desabilitar a Carteira de senhas e a Pesquisa de arquivos, inverter os Atalhos para Captura de tela, aplicar nova Decoração de janelas, — além de examinar os Kernels disponíveis.

7:34 - Confirmada a montagem automática das partições adicionais, configurei o KDE Spectacle para gravar as Capturas de tela na partição XTudo, — de uso comum para todas as distros, — até mudar os Atalhos de teclado para usarem o gnome-screenshot.

7:45 - Instalados (pelo Octopi): — Chromium, Conky, Gnome-screenshot, KRename

7:53 - Instalado (pelo Octopi): — Midnight-Commander

Edição do /etc/default/grub pelo Midnight-Commander (mcedit) para desabilitar os_prober

8:05 - Edição do /etc/default/grub pelo Midnight-Commander (mcedit) para desabilitar os_prober.

8:06 - Update-grub em menos de 1 minuto, — sem “os_prober” / grub-mount.

Correção dos pontos de montagem (path) do Conky

8:16 - Corrigidos os pontos de montagem (path) do ~/.conkyrc

8:27 - Limpeza do cache de pacotes instalados, — ocupação da partição de sistema cai de 7,25 GiB para 6,33 GiB.

Desabilitando o excesso de Swap, — de 49,2 GiB para 4,25 GiB

8:43 - Edição do arquivo /etc/fstab para desabilitar o excesso de Swap, — de 49,2 GiB para 4,25 GiB.

Dias depois, constatei que ficou um erro para corrigir, — o “resume device” (hibernação) estava atribuído ao Swap do Devuan.

Instalação do Kernel 4.4 no Manjaro

8:54 - Instalado Kernel 4.4 em apenas 3 minutos, — graças à prévia desativação do “os_prober”.

Remoção do Kernel 4.14, — a partir de uma sessão com Kernel 4.4

9:24 - Reiniciado o sistema, — carregando o Kernel 4.4, — removi o Kernel 4.14 em cerca de 2 minutos.

Fontes Verdana instaladas a partir do Wine do Kubuntu

10:04 - Instaladas fontes Verdana a partir dos arquivos TTF existentes no Wine do Kubuntu 16.04 (Home4).

Datação dos comandos, a partir desse momento

20:08 - Configurada a datação dos comandos, — exceto os anteriores, que aparecerão sempre com a data e hora em que for disparado cada novo comando history.

Correção de resume=UUID para Swap11 em /etc/default/grub

2018-05-13 - Percebi que o parâmetro resume=UUID no arquivo /etc/default/grub ainda apontava para a partição Swap do Devuan (Swap12).

Esse parâmetro só é necessário quando se usa hibernação, — e várias distros não o criam, por padrão, a menos que o usuário decida usá-la (nunca usei), — mas se ele estiver presente, é melhor que aponte para a partição certa.

Em seguida, atualizei o Grub do Manjaro, — coisa de 37 segundos, sem os_prober:

[flavio@Linux11 ~]$ su
Senha:
[Linux11 flavio]# date && update-grub && date
dom mai 13 20:43:16 -03 2018
Generating grub configuration file ...
Plano de fundo encontrado: /usr/share/grub/background.png
Imagem Linux encontrada: /boot/vmlinuz-4.4-x86_64
Imagem initrd encontrada: /boot/intel-ucode.img /boot/initramfs-4.4-x86_64.img
Found initrd fallback image: /boot/initramfs-4.4-x86_64-fallback.img
Found memtest86+ image: /boot/memtest86+/memtest.bin
concluído
dom mai 13 20:43:53 -03 2018

De quebra, a “Imagem initrd encontrada” indica os parâmetros necessários para carregamento do Manjaro, — a serem incluídos no Grub do Mageia.

Grub do Mageia com o resume=UUID correto do Manjaro

Com isso, o Grub do Mageia já tem onde buscar os dados necessários, — e conclui a detecção das 12 distros em 1’05’’, — com o resume=UUID correto do Manjaro:

bash-4.3$ su
Senha:
[root@Linux2 flavio]# date && update-grub && date
Dom Mai 13 21:00:29 -03 2018
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 18.04 LTS (18.04) em /dev/sdd1
Encontrado Manjaro Linux (17.1.10) em /dev/sdd2
Encontrado Devuan GNU/Linux ascii/ceres em /dev/sdd3
concluído
Dom Mai 13 21:01:34 -03 2018

Completando a linha do Grub após intel-ucode.img com a imagem initrd

Ficava faltando completar a linha de chamada para carregar a imagem initrd do Manjaro.

Criando atalhos para Capturas de tela pelo gnome-screenshot

A essa altura, já passava da hora de substituir o KDE Spectacle, — com sua notificação intrusiva na tela, — pelo gnome-screenshot, mais leve e discreto.

Ajustes no Painel, — ainda sem Restart para ver se dará problema

2018-05-15 - Finalmente, consegui aplicar o tema Maia transparent, — que torna inteiramente transparentes o Menu, Painel, notificações etc. — Devia estar bem debaixo do meu nariz, e não encontrei antes por puro sonambulismo.

Uma das coisas que me incomodava neste Manjaro KDE eram algumas idiossincrasias no Painel:

1) - Havia um Widget de Lançadores (Launcher) com ícones do Firefox (deletado de cara) e do Dolphin, — e ao abrir o Dolphin, não aparecia o ícone correspondente na Barra de tarefas (Taskbar).

Os demais atalhos adicionados ao Painel, — System settings, Chromium, Konsole, — iam se alinhando antes dele, como itens avulsos (não como itens de um Widget de comportamento esquisito).

2) - Após vários dias, finalmente deletei, — não sei se o Widget, ou o atalho do Dolphin dentro dele, — e em seguida adicionei o Dolphin ao Painel. Agora, é um item “avulso”.

3) - A partir daí, sim, obtive o mesmo comportamento dos demais lançadores avulsos, — ao abrir qualquer um deles, surge outro ícone na Barra de tarefas. — Em resumo, uma clara separação entre o que é “lançador” e o que é “tarefa” (minimizada ou não).

Notar que as “tarefas” aparecem em tamanho menor, sublinhadas, — e o tema Maia transparent destaca em verde sólido a tarefa ativa, — enquanto as demais permanecem com fundo transparente (estejam minimizadas, ou não).

4) - Por fim, foram deletados da Área de notificações os ícones-atalhos da Lixeira e de Mostrar desktop, — coisas que não uso (nem tenho no Painel de nenhuma outra distro).

5) - O resultado é um Painel semelhante ao das demais distros, — o que facilita muito o trabalho, pois tudo está mais ou menos no mesmo lugar, e responde mais ou menos do mesmo modo.

Pela primeira vez, não encontro nas configurações da Barra de tarefas as opções de organizar por ordem alfabética, ou cronológica, ou manual, — mas funciona como na opção manual, adotada nas demais distros. — Mesmo que abra o Dolphin por último, basta arrastá-lo para a primeira posição, em seguida o Chromium, e assim por diante.

Obs.: - Mexer nessas coisas foi o que (aparentemente) causou um desastre no Painel, na instalação de 19 Abr. 2018.

Situação após 5 dias


Comparativo das distros Linux instaladas, ao final deste relato

O mero downgrade para o Kernel 4.4 não foi suficiente para tornar o Manjaro capaz de enfrentar o recurso “Páginas” do Facebook, — tal como não foi suficiente no Kubuntu 18.04 (daily-build), — nem no caso do openSUSE Leap, onde o Kernel 4.4 foi padrão desde o início.

Lentidão, mini-congelamentos e abuso de CPU, em “Páginas” do Facebook

O mero acesso a uma “Página” do Facebook faz disparar o uso de CPU, — a simples rolagem vertical sofre mini-congelamentos e demoras (meia-trava), — e a resposta a qualquer clique do mouse exige uma dose cavalar de paciência.

Em resumo, é impraticável usar o Manjaro por dias e dias consecutivos, — a menos que se abra mão de administrar uma ou várias “Páginas” no Facebook, — e este foi um caso excepcional, para registrar este relato.

Ainda não foi encontrada a explicação para as Capturas de tela do usuário-padrão pertencerem a UID=1000 e GID=1001, — pois este último número não existe no arquivo /etc/login.defs, — e as pastas na /home do usuário-padrão são todas 1000:1000.

Instalaçõess abandonadas (2018)


Core0 a 99ºC na primeira tentativa de instalação, em 19 de Abril de 2018

  • 1ª instalação: - 19 Abr. 2018
  • 2ª instalação: - 5 Mai. 2018
  • 3ª instalação: - 11 Mai. 2018 - Ok!

As primeiras tentativas de instalação do Manjaro 17.1.8 começaram em Abril, — e foram prejudicadas por 3 problemas, que acabaram tendo de ser resolvidos em primeiro lugar:


2018-04-19 - Por isso, a 1ª instalação só se completou na 3ª tentativa, — após desplugar os 3 HDDs, e sem incluir bootloader, para evitar o grub-mount.

Manjaro sem Painel, — tentando trabalhar pelo Yakuake

2018-04-21 - Dois dias depois, o Manjaro carregou sem Painel ou Menu, — situação chata, para quem não é “fera” o Linux, — e apresentou “congelamentos”, às vezes demorados.

Instalação posterior do bootloader, a partir de uma sessão Live DVD

2018-04-22 - O bootloader foi instalado mais tarde, — a partir de uma sessão Live DVD.

# mkdir /mnt/manjaro
# mount /dev/sda2 /mnt/manjaro
# cd /mnt/manjaro
# mount -t proc proc proc/
# mount -t sysfs sys sys/
# mount -o bind /dev dev/
# chroot . /bin/bash
# dhcpcd eth0
# dhcpcd enp1s0
# pacman -Syy
# pacman -Syu
# pacman -S udev
# pacman -S mkinitcpio
# pacman -Sy linux
# mkinitcpio -p linux

Mas os problemas continuaram, — a interface KDE se deteriorou cada vez mais, — embora o sistema, em si, estivesse Ok, pois o KDE carregou sem problemas, na conta de um “segundo usuário”, criado para verificar a situação.

Este segundo usuário recebeu UID=1001 / GID=1001, — o que poderia, até, sugerir uma “causa” para o que viria a acontecer na 3ª instalação (atual), onde estes números são 1000:1001, — mas isso parece improvável, dado que, nesse meio tempo, foram feitas 2 formatações da partição Home11.

Embora pretendesse solucionar os problemas, acabei por desistir, — depois de várias tentativas, — e optar pela reinstalação.

2018-05-05 - A segunda instalação ficou quase perfeita, — exceto por 2 pequenos problemas:

  • Rejeitava sistematicamente a chave GPG ao tentar instalar o Kernel 4.4, — e nenhuma das soluções encontradas nos Foruns foi capaz de solucionar.
  • A formatação durante a instalação deixou as partições sem as etiquetas (Label) “Linux11” e “Home11”, — e nem o GParted do Knoppix conseguiu aplicá-las, — mas o resultado foi estragar a instalação.

2018-05-11 - Por fim, o Manjaro foi instalado pela 3ª vez, — com todas as configurações, conforme o relato acima, — e continua firme, em uso diário, até hoje (2018-05-16).

2018-05-16 - Não houve mais atualizações, nesses 5 dias. — É possível que elas se estejam acumulando para a transição ao Manjaro 18. — A conferir.

Em tempo: - As 3 instalações foram feitas com o mesmo DVD.

Wallpaper


Pirenópolis (GO), em Março de 2015, by Tiago Caramuru

Foto de Pirenópolis (GO), por Tiago Caramuru, em Mar. 2015, — sem qualquer edição de imagem.

___________________
Inicialmente publicado em 20 Abr. 2018 (após a 1ª instalação); e desenvolvido dias 12 a 17 Mai. 2018 (após a 3ª instalação), no Manjaro.

— … ≠ • ≠ … —

Não-debians