Translate

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.

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


Postado por Mboaba às segunda-feira, abril 23, 2018
Marcadores: , , , ,

Nenhum comentário:

Postar um comentário

Assinar: Postar comentários (Atom)