segunda-feira, 23 de abril de 2018

Multiple Linux distros dualboot Grub loop madness

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

De repente, o Grub enlouqueceu.

Atualizações de Grub (update-grub = grub-mkconfig), que se faziam em 1 minuto, começaram a demorar 10 minutos… depois 15 minutos…

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), — ou na fase final de instalação de uma nova distro (instalar bootloader).

No contexto do Synaptic, a demora se fez notar primeiro no KDE Neon, devido ao que parecem ser 2 ou 3 grub-mkconfig sucessivos, — acabando por totalizar 30 a 45 minutos, — e mais recentemente também no Kubuntu Bionic Beaver.

Isso não significa, necessariamente, que não houvesse demoras similares no Kubuntu 16.04 ou no Debian. — Pode, apenas, não ter chamado atenção. — Quanto ao Linux Mint, há 10 ou 12 meses não atualizava Kernel, por não ser sua política padrão (até Janeiro último, quando o Spectre-Meltdown inspirou exceções).

A mesma demora foi registrada no openSUSE Leap, — ao receber nova versão de Kernel pelo zypper up (47 minutos), — com a agravante de que, após reiniciar, a manutenção automática tornou a acionar grub-mkconfig (mais de 10 minutos).

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, depois de instalado no computador, configurar o grub2, via Control Center.

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.

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

Como o Menu de inicialização de uso diário é comandado pelo Mageia, — e é frequente executar grub-mkconfig por comando manual (apenas 1 vez), sempre que alguma distro recebe novo Kernel, — ficou a sensação de que ele fosse o mais rápido. Não tanto, na realidade.

Grub inchado


Numa hipótese de leigo (com limitados conhecimentos), em algum momento os scripts do Grub de uma distro (ou mais de uma) começaram a:

  1. Embaralhar dados de distros semelhantes (Neon e Kubuntu; Debian e Devuan)
  2. Gerar um número crescente de entradas desnecessárias, inchando seu grub.cfg

e os scripts do Grub de várias distros, — cujo trabalho é examinar o grub.cfg das demais distros para extrair e processar os dados de cada uma, — absorveram tais exageros, incluindo-os em seus próprios grub.cfg… que por sua vez foram lidos…

Em resumo, espalharam e multiplicaram ainda mais o número de entradas desnecessárias.

Essa retroalimentação mútua fez com que o grub-mkconfig de várias distros enfrentasse arquivos grub.cfg cada vez maiores, de outras distros, — inchando ainda mais seus próprios grub.cfg, num círculo vicioso, em ritmo exponencial.

Daí, por que um problema inicialmente pequeno (percebido em 2016) só começou a se tornar incômodo cerca de 12 meses depois, — e a ganhar dimensões assustadoras, com grande rapidez, após outros 10 meses.

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, — script responsável por extrair e processar dados do grub.cfg das demais distros:

GRUB_DISABLE_OS_PROBER=true

Desse modo, o grub-mkconfig (update-grub) de 10 distros vai cuidar apenas do que diz respeito a cada uma delas, — dados específicos, necessários para extração pelo Grub do Mageia e do openSUSE, para gerar os 2 únicos Menus de inicialização completos.

Notar que o Grub de quase todas as outras distros já estava configurado para não gravar “chamada” na trilha MBR (Master Boot Record) de nenhum HDD, — pois nenhum deles gera entradas capazes de carregar o openSUSE, por exemplo, — que alguns, aliás, nem detectam.

Com isso, o grub-mkconfig (update-grub) do Mageia e do openSUSE volta a examinar 10 arquivos /boot/grub/grub.cfg (ou /boot/grub2/grub.cfg) enxutos, — e sem entradas malucas.

Em todos os casos, o tempo de execução do grub-mkconfig se reduziu a cerca de 1 minuto, — ou menos.

ccc

Índice


  • Grub louco + Ventoinha suja (ou, E=mc²=Boom!)
  • Resumo de uma ignorância sobre o Grub

Registros anteriores


Grub embaralhado


Primeiro Neon identificado por si mesmo como “GNU Linux”, — e o segundo como “Neon”, em 2016

Embaralhamento de distros semelhantes 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 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, — e 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, entitulada “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 persistente, 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.

Grub demorado


Há vários meses (quantos?!), atualizações e remoções de Kernel pelo Synaptic começaram a incomodar pela demora, no KDE Neon, — e observei que esse processo incluía 2 etapas (ou serão 3? ou 4?), — com aparentes repetições do grub-mkconfig.

Levantar a época exata em que isso começou a acontecer (ou a incomodar) pode ser relevante, — considerando que o Devuan 1 foi instalado em Jul. 2017.
Caso se constate coincidência no tempo, isto não significa “falha do Devuan”. — A hipótese que parece mais provável é de “falha por semelhança” (o Debian já estava instalado). — Isso também explicaria por que o Grub embaralhou KDE Neon com o Kubuntu (que já estava instalado, na época).
Adiante, ficará clara a relação entre “embaralhamento” e “demora”, — esta, como consequência (cumulativa) daquele.

Por isso, no KDE Neon adquiri o hábito de sempre incluir a remoção do Kernel anterior (não “em uso”), na mesma operação que vai instalar uma nova versão, — caso contrário, após reiniciar, ele aparece como “Auto-removível”, — e removê-lo mais tarde significa outro trabalho, outra demora.

5 Fev. 2018 - Descobri que não tinha removido o Kernel 4.4.0-108, ao atualizar do 109 para o 112, duas semanas antes. — Emiti um berro de “Eu me odeio!”, pelo esquecimento, — e, só de raiva, fiz alguns Prints da nova demora (bendita raiva…).

No Histórico do Synaptic, essa remoção data das 18:04, — início da remoção do Kernel “108”.

Às 18:06, a captura de tela mostra o início da primeira passagem do grub-mkconfig (Core0: 59ºC), ainda detectando os 3 kernels. — Às 18:18, o início da segunda “passagem” (57ºC), detectando apenas os 2 kernels que iam ficar. — E às 18:27 o início de uma terceira “passagem” (62ºC).

Só aí, já se vão 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, — só voltei a printar às 18:58, quando o Conky da época (110 segundos) já não mostrava qualquer sinal de atividade de CPU, — nem documentei os intervalos entre cada “Found Mageia”… “Found Debian”… “Found Ubuntu”… etc.

É importante notar* que o Devuan 2 Beta só foi instalado 10 dias depois (15 Fev.). — Os motivos dessa observação ficarão claros mais adiante.

22 Fev. 2018 - Grande demora do grub-mkconfig no Bionic Beaver (daily-build), — ao atualizar do Kernel 4.13 para 4.15 (horas depois de instalado pela primeira vez no computador): — Cerca de 15 minutos (16:23~16:38).

Logo depois, no mesmo dia, o Grub do Mageia, — acionado sempre que alguma distro recebe atualização ou upgrade de Kernel, — se atualizou em cerca de 1 minuto.

Instalar um Bionic Beaver Beta2, — “ao lado” do “daily-build” (além do Xenial 16.04), — parece que era tudo quanto faltava para elevar E=mc² à enésima potência = Boom!

E vai ficando claro por que suspeito de “falha de Grub por (excesso de) semelhança”. — Mas, vamos em frente.

19 ~ 21 Abr. 2018 - Depois disso, houve vários casos em que atualizações envolvendo Kernel chegaram a tomar 40+ minutos, — até mesmo no openSUSE Leap, onde esse problema ainda não se havia mostrado (talvez por ocultá-lo):

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

Ao longo de tudo isso, o Mageia manteve sempre o melhor desempenho, — o que foi sorte grande, já que é meu “gerenciador de Grub”, — não passando de 11 ou 14 minutos, nos piores momentos, quando outros passavam de 40 minutos.

Por ser meu “gerenciador de Grub”, — portanto, o mais usado (e por comando intencional!), — o Mageia foi também o que deixou registros mais numerosos e detalhados.

Aliás, é menos incômodo monitorar um evento de 10 a 12 minutos, do que um de 45 ou 50 minutos.

Em 19 Abr., p.ex., ficou claro que a eliminação de 1 dos 2 Bionic reduziu bastante a confusão mental do Grub:

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 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 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 tempo (maior ou menor) foi gasto para encontrar cada distro finalmente exibida à direita, — ou para processar a distro anterior (após tê-la encontrado), — se é que me faço compreender.

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

Em suma, tudo apontava para o Bionic e para o Devuan como os maiores causadores de demora, — sem desprezar o Neon e o Debian (se a demora fosse do processamento após encontrá-los), — ou o Debian e o Xenial (se a demora fosse para encontrá-los).

Grub inchado


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

Ao longo desse exame, — e com a vaga impressão (como leigo!) de que o principal trabalho do grub-mkconfig seria de leitura e processamento dos arquivos /boot/grub/grub.cfg (ou /boot/grub2/grub.cfg) das “outras” distros (com uso abundante dos comandos sed e paste, entre outros), — finalmente foi feito um exame desses arquivos.

Uáu… — Alguma coisa estava muito errada.

No Kubuntu 18.04 Bionic Beaver LTS (daily-build), por exemplo, o arquivo /boot/grub/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.

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 arquivo grub.cfg do próprio Devuan (talvez o menos “culpado” disso tudo), tinha “apenas” 552 KiB, meras 9.676 linhas, — e apenas 722 strings “Devuan”.

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.

Sem menosprezar outros, que tenha deixado de copiar, 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 (nem preciso carregar o Mageia para atualizar o Grub que uso no dia-a-dia), — basta reiniciar o computador, deixar que o Grub do Mageia “lembre” que a última distro carregada foi o Arch Linux, — e ele carrega com o Kernel atualizado… “linux-lts” (sempre!).

“Se todos fossem iguais a você
Que maravilha viver”

Vinicius de Moraes

Shazam! — A solução


Como o visitante é mais inteligente do que eu, já percebeu, — vários parágrafos atrás, — que a solução era desabilitar o os-prober de todas as distros que não têm a função de “servidor de Grub”.

Com isso, Devuan só vai detectar a si mesmo… Neon só vai detectar a si mesmo… Bionic só vai detectar a si mesmo… — e assim por diante.

Nenhuma distro “sem função de gerenciador de Grub” perderá tempo detectando as outras, — e as distros que têm essa função não terão de ler nem processar 11 arquivos grub.cfg de 3 ou 5 GiB (milhares de linhas!). — Cada um cuida de si, sem perder tempo (e sem gerar confusão).

Apenas o Mageia terá de ler o grub.cfg (mínimo, simples!) dos outros. — Em vez de 3 ou 5 GiB, — arquivos de menos de \\\\

xx

Grub louco + Ventoinha suja (ou, E=mc²=Boom!)


Em qualquer situação, uma intensa atividade de CPU eleva um pouco a temperatura dos núcleos (Core0, Core1), — e isso vai se acumulando, com o passar do tempo, até que cesse aquele esforço, — mas, em condições normais de hardware, o Cooler da CPU deve neutralizar esse efeito ou, pelo menos, reduzi-lo a proporções aceitáveis.

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

A situação ameaçou virar catástrofe ao tentar instalar o Manjaro 17-1-8, a partir de sessões Live DVD, — felizmente, também 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 sem mais perda de tempo.

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 logo, sem esperar mais.

Depois disso, claro, a limpeza da ventoinha pulou para o topo das prioridades, — o que não significa, necessariamente, “na hora” (às 19h?), uma vez que depende de encontrar um borracheiro aberto, por perto; e exige 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. — Mas isso já é uma outra estória.

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, como diria Jack Stripper:

  1. Limpar a ventoinha
  2. Descobrir qual o problema do Grub

Um terceiro problema era possível, — interferência do Grub-customizer (instalado em algumas distros, em 2016), — mas, se fosse verdade, não haveria motivos para se manifestar somente nos últimos 2 ou 3 meses.

É claro que, na qualidade de leigo, não podia descartar 1.001 outras hipóteses, a priori, — SSD / HDD bichados, memória RAM bichada, raios cósmicos, despacho na encruzilhada, — ou até, que o aquecimento da CPU fosse a causa da demora do Grub, que por sua vez aquecia mais a CPU… num círculo vicioso.

Pedir socorro num Forum podia ser perigoso: — “Sem especificações do hardware não dá pra ajudar”… “Manda um pastebin do sistema”… “Pra que tanta distro?”… “Por que não usa VM?”… “Instala Gentoo e esquece o resto”… “Usa LXDE que é mais leve”… “Joga fora esse computador”… — Sim, deu medo, só de pensar.

Era preciso segurar a imaginação, — não atiçá-la, — nem correr sem rumo, em todas as direções.

Resumo de uma ignorância sobre o Grub


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

Não era a primeira vez que sentia necessidade de “entender” o Grub, — mas “entender” tem 300 significados diferentes, desde o novato absoluto até o fera-programador especializado em Grub. — Também não foi a primeira vez que tentei ler mais, e saí tão ignorante (e 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 bastante, conforme 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 tempo escrevendo o script adequado, — e ele faria tudo num segundo ;-)

xx

xxx

— … ≠ • ≠ … —

Ferramentas &tc.


sexta-feira, 20 de abril de 2018

Manjaro KDE - Live, install, config

Manjaro instalado KDE - com KInfocenter e Conky
Manjaro KDE instalado e parcialmente configurado, — com Conky e KInfocenter

Manjaro foi minha primeira distro “não-debian”, — ao iniciar essa aventura, em 1º Jan. 2017, — e sua remoção ocorreu, em grande parte, para simplificar as “correções manuais” necessárias após cada atualização do Grub, em um “multi-boot” dimensionado para até 12 sistemas lado-a-lado.

As informações daquela primeira instalação do Manjaro estão reunidas em 4 relatos, — com mais 2 sobre o “multi-Grub” e sobre essa aventura na “árvore” de distribuições Linux:


Ao longo dessa aventura, várias distribuições Linux acabaram removidas, após um tempo maior ou menor de uso mais ou menos regular, — enquanto outras foram mantidas até hoje. — E, das distros removidas, o Manjaro foi a que mais deixou saudades.

Acima de todas as demais qualidades, pesou bastante 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 se tornou, de fato, alérgico a novos avanços; e se algum “conservadorismo seletivo” lhe permitirá mais alguma sobrevida, sem abrir mão de atualizações em outras áreas.

Daí, a volta ao Manjaro, — por gosto e por cálculo.

20 Abr. 2018 - Este relato começa numa fase deliberadamente parcial das configurações:

  • O Compositor ainda é OpenGL 2.0, — padrão “automático” das instalações nesse hardware, — embora todas as demais distros já tenham sido manualmente configuradas para XRender
  • Não foi habilitado o Cubo, nem qualquer um dos demais efeitos “vistosos” porém supérfluos
  • Ainda não foi instalado nenhum outro Kernel, — permanece apenas o “original”
  • Ainda não foi habilitado, sequer, o repositório AUR

O objetivo é registrar os possíveis efeitos colaterais de cada um desses passos, — portanto, não faria sentido registrar só o resultado final, — tendo em vista o hardware antigo (Q3’08 = 3º Trim. 2008):

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

Para tornar as coisas ainda mais interessantes, foi constatado que a ventoinha do cooler da CPU já está completamente entupida, — o ar não tem como chegar ao dissipador, — mas aquele não era um bom momento para retirá-la e levá-la para um sopro de ar comprimido no borracheiro mais próximo, pois a recolocação exige praticamente desmontar o computador e montar de novo. Toma algum tempo.

ISO, download, K3b


19 Abr. 2018 - Do Manjaro 18, só estavam disponíveis ISOs Alpha1 do dia 9, — ao passo que do Manjaro 17-1-8 havia ISOs mais recentes, do dia 16, — e de qualquer modo, o upgrade não deve demorar. Sendo uma distro rolling-release, não faria muita diferença instalar uma ou outra.

O primeiro Torrent acabou em travamento total (Kubuntu Bionic), — só se concluiu após um Reset. — Depois disso, passou pela verificação sha1sum, mas a gravação do DVD pelo K3b terminou em erro aos 97%.

A ISO foi apagada, e feito novo Torrent (sem problemas), — também aprovado na verificação sha1sum, — e mais uma vez a gravação do DVD pelo K3b terminou em erro aos 97%.

Há um procedimento para conferir se a imagem ISO é isohybrid (fdisk -l), — ou seja, se pode ser usada para USB (Pendrive), — mas para DVD a única sugestão é usar a menor velocidade possível de gravação (com Brasero).

Como já houve casos similares, com outras distros, — e aqueles DVDs funcionaram bem, — foi usado o 2º DVD, e com ele foram rodadas 3 sessões Live.

O único problema a exigir 3 sessões não tem relação com a qualidade da ISO, nem do DVD, — mas (provavelmente) com o excesso de HDDs / SSD, dezenas de partições, 11 distros instaladas etc. — Em resumo, o mkconfig do Grub2 demora e superaquece a CPU, o que motivou abortar as 2 primeiras tentativas.

A instalação do PCLinuxOS, o Grub2 também terminou em erro por 2 ou 3 vezes, — até optar pelo Grub “legacy” (por não encontrar opção “sem bootloader”). — Depois disso, foram feitas 4 instalações do PCLinuxOS, sem problemas.

A terceira instalação do Manjaro, — sem Grub (além de desplugar 3 HDDs), — se concluiu em pouco menos de 25 minutos (com pausas para PrintScreen / fotos).

21:21:15 - Installer - 3rd Begin
21:24:17 - Slideshow - Begin
21:42:13 - Slideshow - Yet
21:45:56 - 3rd Install Finished - OK - [Total: 24’41’’]

Receava que, sem gerar grub.cfg durante a instalação, o Grub do Mageia não teria de onde extrair as informações necessárias para carregá-lo, — pois já houve um casso assim, de uma distro que só foi detectada depois de gerar seu próprio grub.cfg, — mas dessa vez, o Mageia fez milagre.

A entrada gerada pelo Grub do Mageia não ficou exatamente como esperado, — nada de intel-ucode.img, por exemplo, — mas carregou o Manjaro!

Bom… funcionou durante algumas horas, pelo menos, — e depois, não mais.

Para corrigir, foi carregada mais uma sessão Live DVD do Manjaro, — aplicada uma velha receita de recuperação do Manjaro, que inclui atualizar seu Grub, — e depois disso o Grub do Mageia finalmente gerou uma entrada conforme esperado, com direito a intel-ucode.img.

— … ≠ • ≠ … —

Não-debians


quarta-feira, 4 de abril de 2018

Chromium isn't your default browser

Chromium reclama e pede para ser o navegador-padrão, — todas as vezes que é aberto

A instalação do Konqueror (com mais alguns pacotes) parece ter sido a causa de o Chromium começar a reclamar que não é o navegador-padrão, — e perguntar se deseja torná-lo padrão, — todas as vezes que é aberto.

Você clica em Set as default, — e não adianta. — O Chromium torna a perguntar, todos os dias, a cada nova abertura.

Tentando tornar o Chromium navegador padrão, em suas configurações

Você vai nas configurações do Chromium, — clica e torna a clicar em Make default, — e também não adianta.

Confirmado: — Chromium era o navegador padrão (desde sempre, aliás)

Você verifica em System settings >> Applications >> Default applications, — e também lá o Chromium consta como navegador-padrão. — De fato, assim era… até a véspera.

Tudo isso já aconteceu antes, em outras distros instaladas aqui, — e acho que em algumas ainda acontece, — mas essa foi a primeira vez que a provável causa do problema ficou bem isolada e evidente, com absoluta clareza.

Isso ficou claro, em parte, devido a uma rotina mais rígida, de instalar poucos pacotes de cada vez, — apenas um aplicativo (e suas dependências), — sem misturar com outros aplicativos (e outras dependências), — e nunca misturar com as atualizações regulares.

Segundo o Histórico do Synaptic:

Commit Log for Sat Feb 24 07:18:23 2018
Instalados os seguintes pacotes:
• krusader (2:2.6.0-1)

Commit Log for Sat Feb 24 07:19:27 2018
Instalados os seguintes pacotes:
• kfind (4:17.12.2-0ubuntu1)
konqueror (4:17.12.2-0ubuntu3)
• libkf5konq-data (4:17.12.2-0ubuntu3)
• libkf5konq6 (4:17.12.2-0ubuntu3)

Commit Log for Sat Feb 24 07:52:58 2018
Instalados os seguintes pacotes:
• dolphin4 (4:16.04.3-0ubuntu1)
• libkonq5abi1 (4:16.04.3-0ubuntu1)

E ao ser aberto, — menos de uma hora depois, — o Chromium já começou a reclamar.

• 2018-02-24_08-10-10_Kbb-Chromium-isnt-default-browser

Instalação do Konqueror atribui a ele a prioridade na associação com arquivos *htm*

A causa específica foi localizada em System settings >> Applications >> File associations >> *htm*

Ao que tudo indica, foi a mera instalação do Konqueror que atribuiu a ele a prioridade para abertura de arquivos html, htmlh, xhtml, — uma vez que as primeiras configurações personalizadas não tocaram nessa área, — e outras só foram feitas bem depois do problema, que se manifestou em menos de 1 hora.

17 Abr. 2018 - Mais tarde, esse problema foi constatado em outra distro, — antes de instalar o Konqueror. — Em todo caso, a solução foi a mesma.

Reorganização da associação de arquivos HTML a diferentes aplicativos

Usando os botões Mover para cima e Mover para baixo, a prioridade dos diferentes aplicativos foi reorganizada, — de modo a colocar o Chromium no topo, — o que corresponde ao clique simples (ou duplo, conforme sua preferência) sobre qualquer arquivo desses 3 tipos, no Dolphin.

Os demais aplicativos associados ao tipo de arquivo podem ser facilmente utilizados pelo Menu de contexto (right-click), — na ordem aqui definida.

No caso dos arquivos htm ou html, o LibreOffice Writer foi colocado como segunda opção, — por ser uma das alternativas mais usadas para extrair trechos de páginas web que bloqueiam a cópia quando visitadas pelo Chromium, Firefox etc. — Salva-se a página e abre-se o arquivo html pelo editor de textos, que ignora esse bloqueio.

Outro aplicativo utilizado com certa frequência é o Kate, — para verificar detalhes do código de uma página salva anteriormente.

Opções menos utilizadas foram jogadas para baixo, — ou mesmo removidas, como no caso do Notepad (Wine), — para que nunca sejam chamadas por descuido.

Abrir o Konqueror parece exigir que ele seja o aplicativo-padrão para arquivos HTML

Infelizmente, esta solução criou outro problema, — pois abrir o Konqueror depende dele abrir o arquivo Bookmarks (html), como aplicativo-padrão, — e as coisas se complicam.

A ver, nos próximos dias.

• Essa instalação do Kubuntu 18.04 (daily-build) será substituída dentro de algumas horas, — com formatação da /home, para eliminar a “herança” de um PCLinuxOS experimental.

Navegador vs. gerenciador de arquivos


Embora seja um “navegador web”, o Konqueror também é um “gerenciador de arquivos”, — e já foi padrão (se não me engano) no Kurumin ou no Kubuntu, até vários anos atrás, — mas esse acúmulo de funções acabou por torná-lo mais complexo do que o desejável.

Optou-se por um aplicativo (simples!) para cada função, — de modo a desempenhá-la da melhor maneira possível, — e a partir de certo momento o Kubuntu passou a vir com o Dolphin.

Na época, essa guinada foi meio chocante.

Pessoalmente, — como mero usuário (e muito mais ignorante de Linux do que hoje), — me senti bastante perdido. Foi como se me tivessem tomado um belo brinquedo, em troca de outro, bem mais tosco.

Houve muito choro e ranger de dentes, nos foruns. — Depois, surgiram dicas de como adicionar pacotes e funcionalidades, — por meios, talvez, não tão “amigáveis”, a princípio.

Hoje, eu não saberia viver sem o Dolphin, — tornou-se a base da minha experiência de KDE, — e sua falta é um dos primeiros motivos a me desgostar do Xfce ou do Cinnamon, para dar apenas 2 exemplos de “escritórios” com os quais me sinto relativamente ambientado, no geral.

Tenho cada vez menos motivos para (ainda) instalar, configurar, abrir e usar o Konqueror, — cada vez mais abandonado, — e cada vez mais “amputado”, à medida em que o KDE 5 vai avançando.

Nunca, porém, como “navegador”, — isso foi uma das primeiras coisas que deixei de fazer, há vários anos. — Talvez, mesmo, desde quando ainda era um aplicativo padrão do Kubuntu.

— … ≠ • ≠ … —

Kubuntu


terça-feira, 3 de abril de 2018

Kubuntu 18.04 Bionic - back to Kernel 4.4

Kubuntu 18.04 Bionic Beaver com Kernel 4.4

Conforme relatado, o Kubuntu 18.04 LTS “development branch” (em desenvolvimento) foi instalado a partir da imagem ISO “daily build” 2018-02-21, com Kernel 4.13, — e no dia 22 já recebeu atualização para o Kernel 4.15, que se mostrou desastroso para o velho hardware de 2008.

Mas, — mesmo com o imediato retorno ao Kernel 4.13, — o Kubuntu 18.04 Bionic Beaver ainda ficou longe do ideal.

  • Sem som (desde a instalação)
  • Chromium reclama que não é o navegador-padrão (Chromium vs. Konqueror)
  • update-apt-xapian roda sem ser chamado e abusa da CPU por intermináveis minutos
  • Teclado continua sem acesso ao 3o. Nível
  • Teclado continua sem ativar NumLock no início da sessão
  • etc.

Alguns desses problemas podem ser herança da /home de um antigo PCLinuxOS experimental, — e já está planejado reinstalar o Bionic Beaver em breve, sem essa herança.

Mas o mais grave era o Chromium não conseguir enfrentar as tais Páginas do Facebook, — sem ficar lento, devagar-quase-travando (com surto de uso de CPU e algum aquecimento).

Nas distros em que isso ocorre, também é comum acontecer quando surge algum vídeo ou GIF animado (mesmo parado) na linha-do-tempo do Twitter ou do Google Plus, — e em mais 2 ou 3 circunstâncias, menos importantes, — mas as Páginas do Facebook são o indicador mais gritante, pois a navegação fica impraticável, até para rolar, ver e visitar os links mais relevantes.

Na falta de conhecimentos técnicos mais profundos, ficou claro que 2 ou 3 providências às vezes ajudam, — pelo menos, no caso específico deste hardware:

  • Mudar o Compositor de OpenGL2.0 para XRender (já faço isso há tempos)
  • Instalar ou substituir alguns pacotes relacionados a Intel-video, drivers etc.
  • Recuar do Kernel 4.9 (ou maior) para 4.4, — quando disponível nos repositórios

Acontece que no, momento, os repositórios do Kubuntu 18.04 Bionic Beaver só oferecem o Kernel 4.15, — e tudo indicava que o 4.13 só aparecia no Synaptic, porque ainda estava instalado aqui.

De fato, depois que foi desinstalado (adiante), desapareceu por completo. Não existe mais nos repositórios. Agora, está claro que não adiantava insistir. Nunca mais receberia atualizações.

É óbvio que o computador está com problema de junta, — junta tudo e joga fora, — mas… não é assim que age um usuário Linux (mesmo quando não sabe quase nada de Linux).

Escolha dos pacotes .deb para instalação do Kernel 4.4.116

Embora 99% dos resultados do Google para "Kernel install" se destinem aos que anseiam pelo mais novo Kernel (que ainda não chegou em sua distro), nem por isso deixam de ser úteis para quem queira seguir o caminho inverso, — instalar um Kernel antigo.

Escolhi a postagem Como instalar qualquer versão do Kernel Linux no Ubuntu manualmente, do Diolinux, por ser simples, — nada de compilar, — além de estar em português bem claro.

No link indicado do kernel-ppa/mainline, encontra-se o Kernel 4.4 até a versão v4.4.126, mas pareceu mais prudente usar a v4.4.116, — por mero achômetro, considerando que nos repositórios do Kubuntu 16.04 LTS, do Linux Mint 18 Sarah e do KDE Neon User Edition a revisão mais atual é 4.4.0-116. — Sim, existe aí um zero e um traço a mais. Será que explode?

Os 3 pacotes .deb indicados são, — para arquitetura amd64, — o arquivo "all" e os 2 arquivos "amd64":

  1. linux-headers…all
  2. linux-headers…amd64
  3. linux-image…amd64

A instalação se faz nessa ordem, — alfabética (coincidência ou não): primeiro "headers", depois "image", — daí a orientação do Diolinux de seguir "da esquerda para a direita" ("de cima para baixo", com o Dolphin no modo de visão Detalhado ou Lista).

Antes de prosseguir, — remova drivers proprietários.

Instalação dos pacotes do Kernel pelo QApt (Package Installer)

Ao invés de fazer duplo-clique em cada um (ou clique único, no caso do KDE), sondei com o botão direito do mouse, — e a única opção era Instalar com QApt (Package Installer). — É exatamente esse que o clique também chama.

Ignoro se o clique chamaria o Plasma Discover, caso não o tivesse desinstalado há tempos.

QApt Package Installer — arquivos incluídos no linux-headers_all

O QApt apresenta as informações em 3 abas, — Description, Details, Included files, — e pede a senha ao clicar Install package (confirmação).

O processo todo levou 15 minutos ou pouco mais, — sendo que a demora ocorre na instalação do terceiro arquivo (linux-image).

Esse tempo pode ter sido afetado por um fenômeno estranho: — O Notificador permaneceu ativo (fazendo sabe-se lá o quê) desde o início da sessão, 5 horas antes.

Carregando o Kubuntu Bionic com o Kernel 4.4, para testar

Ao reiniciar o computador, — Grub > Opções avançadas, — foi escolhido o Kernel 4.4, para testar.

Remoção completa do Kernel 4.13 do Kubuntu 18.04 Bionic Beaver (development-branch)

Depois de 1h 30min, ficou comprovado que agora o Chromium consegue enfrentar as Páginas do Facebook, — leve e ágil, — sem qualquer efeito colateral negativo.

Pelo Synaptic, então, foi completamente removido o Kernel 4.13 original, — de modo a ficar apenas o Kernel 4.4.

Conclusão (7 Abr. 2018)


Após vários dias de uso contínuo, o Kubuntu 18.04 com Kernel 4.4 foi “aprovado” para navegar pelo Chromium em Páginas do Facebook, — sem lentidão, sem trava, sem surto de uso de CPU, — ao lado do Kubuntu 16.04, do Linux Mint 18 KDE, do KDE Neon User Edition e do PCLinuxOS KDE.

• Essa instalação do Kubuntu 18.04 (daily-build) será substituída dentro de algumas horas, — com formatação da /home, para eliminar a “herança” de um PCLinuxOS experimental.

Essa constatação abre (ou confirma) um caminho para lidar com o problema, — inclusive em outras distros, não-derivadas do Ubuntu, — de modo a não ficar preso ao Xenial 16.04 LTS, devido ao hardware antigo.

Isso se tornou uma preocupação, desde que todas as versões intermediárias do Kubuntu começaram a apresentar esse problema, no hardware atual, — o que inviabilizaria migrar para o Kubuntu 18.04 LTS Bionic Beaver.

Encontrar uma dica simples, — e um repositório da própria Canonical, — facilitou o teste.

Fazer o mesmo downgrade de Kernel no Mageia, Debian testing, Slackware, Arch, Devuan etc., já são outros 500.

— … ≠ • ≠ … —

Kubuntu


sábado, 24 de fevereiro de 2018

Kubuntu 18.04 LTS (daily-build) - Install, config

Kubuntu 18.04 LTS* Bionic Braver (daily-build), já com Kernel 4.15

• O Kubuntu 18.04 LTS “development branch” (em desenvolvimento) foi instalado a partir da imagem ISO “daily build” 2018-02-21, com Kernel 4.13, — e no dia 22 já recebeu atualização para o Kernel 4.15.

Remoção do Kernel mais recente pelo Synaptic, — rodando Kernel anterior

Infelizmente, o Kernel 4.15 não funcionou tão bem, aqui, — talvez devido ao hardware muito antigo (2008), — fenômeno já observado também em outras distros, como PCLinuxOS (ao passar do Kernel 4.12 para 4.14).

Em resumo, a navegação no Google Plus, — que costuma ser leve e rápida, — ficou “pesada”, cheia de “meia-trava” (trava, demora). Também se tornou sofrível a navegação no Facebook, — e quando aparece um vídeo (parado!) no Feed, as coisas travam mais ainda.

O Kernel 4.15 foi então removido do Bionic Beaver, pelo processo corriqueiro: — Boot > Grub > Opções avançadas > Kernel anterior, — e remoção do mais recente pelo Synaptic.

Caso o Grub seja controlado por outra distro (dualboot), é necessário carregá-la em seguida, para atualizar o Grub.

Com isso, o funcionamento voltou ao “normal”, — embora não tão “perfeito” como o do Kubuntu 16.04 Xenial (Kernel 4.4), por exemplo, — mas não há outras opções de Kernel nos repositórios do Bionic Beaver.

Desativando w83627ehf em /etc/modules

• O driver w83627ehf configurado pelo comando “sudo sensors-detect” passou a provocar mensagens de erro “Failed to start Load Kernel Modules” durante o Boot. — A configuração foi desabilitada e as mensagens cessaram, — sem qualquer prejuízo aparente para o Sensors nem para o Conky.

• Após 5 dias, o som permanece mudo, — problema que não se registrava mais, nesse hardware, há vários anos.

Crash do LibreOffice ao exportar PDF

• LibreOffice fecha abruptamente ao tentar “Exportar como PDF”.

Foram tentados caminhos alternativos pela “impressora PDF”, — inclusive instalar mais alguns pacotes, — sem resultado algum, embora não provoquem crash.

Por causa disso, no dia 28 este relato passou a ser desenvolvido no Slackware.

Montagem automática de partições adicionais pelo KDE System settings > Removable devices

• Nos primeiros dias, a montagem automática de partições adicionais, — pelas Configurações do sistema (KDE System settings > Removable devices), — simplesmente não funcionou.

Este problema já vinha ocorrendo nas demais distros que chegaram ao KDE 5.12, — KDE Neon, PCLinuxOS, Arch Linux, — e nas quais ainda persistiu por mais algumas semanas.

Porém no Kubuntu 18.04 este problema acabou no dia 25. — De repente, as partições adicionais passaram a ser montadas automaticamente, no início da sessão.

A conferir, quais pacotes foram instalados ou atualizados, e quais configurações alteradas, durante a sessão anterior ao inesperado conserto.

03:51 - Início de sessão sem funcionamento do Automount. — Instalados vários novos pacotes. — Também houve 2 atualizações às 4:52 (inclusive udev) e às 16:40 (ver Histórico de pacotes, adiante). — Restart após 17:51 (uptime 14h).

• 17:57 - Início de sessão (Boot meio demorado). — Surpresa: Automount funcionou para algumas partições (que já estavam marcadas há tempos).

• 18:02 - Marcadas as demais partições para KDE Automount. Restart.

• 18:06 - Início de sessão com Automount de todas as partições adicionais.

Nas demais distros com KDE 5.12, o problema se resolveu “espontaneamente”, num período de 3 a 5 semanas mais tarde, — e o exame dos pacotes atualizados ou instalado em cada uma dessas 4 distros talvez permita distinguir qual deles aparece justo na véspera de todos os casos:

5 Março - o Arch voltou a montar partições adicionais no início da sessão, automaticamente.

13 Março - o PCLinuxOS voltou a montar partições adicionais automaticamente.

18 Março - o KDE Neon voltou a montar partições adicionais automaticamente.

Configurações residuais do Packagekit, Plasma Discover e Unattended-upgrades

• Foram desabilitadas notificações e atualizações automáticas, — pela remoção dos pacotes Unattended-upgrades, PackageKit, — e por tabela, do Plasma Discover.

Permanecem suas configurações residuais, — o que facilita reverter à situação anterior, caso sejam reinstalados.

Opções de atualização no Muon Package Manager

Dias depois, foi desmarcada — no Muon Package Manager — a opção de atualizar as informações dos repositórios, 1 vez ao dia (automaticamente), coisa que costumava ocorrer logo no início da sessão.

Infelizmente, não foram registradas as configurações iniciais do Muon, — logo após a instalação do Kubuntu Bionic Beaver, — pois talvez bastasse desabilitar ali as unattended-upgrades.

Reload diário automático afeta a RAM inicial e bloqueia “sudo apt update”

A rotina é registrar o tempo de Boot e o uso de memória RAM no início da sessão, — em seguida, conferir atualizações (manualmente) pelo sudo apt update / apt list --upgradable, — e por fim, aplicá-las pelo Synaptic, — para tomar conhecimento do que se passa.

Duas ou três vezes por semana, são carregadas e atualizadas as distros que não tenham sido usadas no trabalho diário.

Heranças (/home)


Primeira sessão do Kubuntu 18.04 instalado, — com a /home de outra distro

A instalação do Kubuntu 18.04 LTS foi feita com aproveitamento da pasta /home/flavio utilizada antes pela “duplicata” (experimental) do PCLinuxOS, — com os mesmos identificadores UID=1000, GID=1000, porém várias diferenças na estrutura de arquivos (ocultos) de configurações de usuário.

Outras 2 experiências poderão ser tentadas:

(a) Instalar com uma /home vazia; e

(b) Instalar com um clone da /home do Kubuntu Xenial, — para tirar várias dúvidas.

Ao carregar pela primeira vez, portanto, o Kubuntu 18.04 se apresentou com o Wallpaper antigo; — atalhos PrtScn chamando gnome-screenshot (ainda não instalado) e mandando salvar em pastas /media/LABEL (em vez de /media/flavio/LABEL); — e Painel com vários espaços vazios onde deveriam estar o Menu, Centro de Controle (Drakconf, do PCLinuxOS), Chrome etc.

Daí, porque o gnome-screenshot foi instalado logo nos primeiros 2 minutos, — era mais simples do que reverter os atalhos para o KDE Spectacle, — e os caminhos (path) da salvação alterados para o padrão de pontos de montagem do Kubuntu.

O primeiro passo foi verificar todas as configurações, — corrigir o necessário (página inicial do Dolphin, p.ex.), — e documentar o que já estava conforme desejado:

2018-02-22

10:35 - NL - Boot verbose Kubuntu BB
10:38 - Kubuntu BB Panel PCLOS
10:39 - Kubuntu BB Dolphin mount path
10:39 - Dolphin start page
10:40 - apt install gnome screenshot
10:43 - System settings shortcut PrtScn
10:45 - System settings Keyboard
10:47 - System settings Compositor
10:47 - System settings Preferred Language
10:47 - Localizatio Numeric Currency Time Formats
10:47 - System settings Spell checker dictionaries
10:47 - System settings Time Zone
10:48 - System settings KWallet
10:48 - System settings User
10:49 - KDE System settings Automount
10:49 - System settings File search
10:50 - System settings Search Bar
10:51 - System settings Background services - Applications Menu
10:51 - System settings Login Logout
10:52 - System settings Desktop effects
10:52 - System settings Screen Corners Edges
10:52 - System settings Screen Locking
10:52 - System settings Fonts
10:53 - System settings Font Management
10:58 - less var log dpkg Pacotes existentes
11:10 - edit Panel add widget Menu
11:12 - Kate memoria
11:13 - Menu SEM Recentes Frequentes
11:14 - Conkyrc MountPoint Path
11:19 - Conky
11:20 - apt install lmsensors
11:22 - Menu icon Kubuntu
11:25 - Synaptic atualizaveis
11:25 - Synaptic Locales All Recomenda
11:26 - Synaptic Reload
11:27 - Synaptic updates
11:38 - Synaptic Gimp
11:40 - Synaptic sources
11:41 - Synaptic Configs
11:42 - Synaptic ttf mscorefonts
11:45 - killall conky
11:45 - re Conky Verdana
11:49 - Save session
11:50 - Menu Wine Dreamweaver
11:51 - Restart
11:53 - Boot verbose Kubuntu
11:54 - Startup unmounted geral
11:56 - Gimp QApt Lang Support incomplete
11:57 - Gimp Wallpaper
12:03 - Conkyrc colors
12:05 - Drakconf no Painel
12:11 - Automount disable all
12:17 - Synaptic ScreenRuler
12:22 - Synaptic PackageKit Remove Discover
12:25 - Synaptic Unattended upgrades Remove
12:36 - Wallpaper crop KInfocenter
12:40 - Chromium
12:51 - Keyboard
14:48 - CPU Facebook Page slow
14:48 - Facebook group Ok
14:55 - Conkyrc Colors
15:04 - Nokia USB cable connect
15:06 - Download photos
15:07 - KInfocenter
15:09 - Synaptic pyRenamer
15:12 - sensors detect
15:14 - QApt Batch Lang
15:17 - KDE Automount - check again
15:18 - Restart
15:23 - Startup manually mount
15:26 - Open Directory with pyRenamer

Teste construtivista (“na real”)


Quadro dos sistemas Linux, logo após a instalação do Kubuntu Bionic Beaver

Instalar o Kubuntu 18.04 LTS* Bionic Beaver daily-build foi um modo de não perder tempo com teste Live do Beta, nem teste Live do Beta2, nem teste Live do lançamento, — e muito menos, colocar em risco um Kubuntu 16.04 LTS* confiável e produtivo. — O novo Kubuntu foi instalado “ao lado” dele (dualboot).

Na prática, a instalação substitui vários testes, — mais trabalhosos do que compensadores, devido à curta duração (além de não serem “a mesma coisa”), — por um investimento mais consistente, ao longo de 2 meses:

Alpha 1           - Jan.,  4
Alpha 2           - Feb.,  1
daily-build.......  Feb., 21
Beta 1            - Mar.,  8
Final Beta        - Apr.,  5
Release Candidate - Apr., 19
Release           - Apr., 26

Quadro dos sistemas Linux instalados, 4 dias depois (26 Fev. 2018)

O objetivo é começar a enfrentar desde já os eventuais problemas do próximo Kubuntu 18.04 LTS*, — até deixá-lo 100% produtivo.

No mínimo, isso evita incertezas, — sempre presentes numa transição como essa, — e torna mais fácil a curva de aprendizado, readaptações, desafios.

E, na pior das hipóteses, fica preservado o velho e bom Kubuntu 16.04 LTS*.

* LTS = Long Term Service (Suporte de Longo Prazo). - São versões do Ubuntu / Kubuntu com 3 ou 5 anos de atualizações de segurança, — enquanto os lançamentos intermediários têm vida útil bem mais curta, de apenas 9 meses (3 trimestres), o que não chega a compensar o investimento em instalação, ajustes, aprendizado, pesquisa e solução de problemas. — Daí o pouco tempo dedicado ao Kubuntu 16.10 Yakkety Yak (Live, Install crash); ao Kubuntu 17.04 Zesty Zapus (Install, Clone / Move, Fix); e ao Kubuntu 17.10 Artful Aardvak (Live).

Slots modulares


Particionamento dos HDDs internos / SSD externo e seu uso por distros Linux

Isso foi possibilitado pelo particionamento dos HDDs e SDD em “slots” modulares compostos de 3 partições, cada (Raiz, /home, Swap), numerados de Linux1 a Linux12. — O Kubuntu 18.04 entra no slot Linux11, substituindo uma duplicata (experimental) do PCLinuxOS.

A rigor, as mudanças, problemas e desafios, nem são mais surpresas, — boa parte dessas novidades já se vêm manifestando no KDE Neon, no Debian testing, no Arch Linux, no PCLinuxOS.

A chamada “instabilidade”, — na verdade: fluidez, mudança constante, — há muito tempo também já deixou de ser um bicho-de-sete-cabeças.

  • O KDE Neon foi instalado ainda no início de seu desenvolvimento, e trabalhou muito bem, durante 9 meses (até ser destruído por acidente).
  • O Mint 18 KDE foi instalado ainda na fase Beta, e também trabalhou muito bem durante meses (até o upgrade para 18.1).
  • O Mageia 6 foi instalado ainda na fase sta2 (estabilização, anterior ao RC), e continua firme após 11 meses.
  • O Debian foi convertido em Testing há 1 ano e 4 meses, — muito antes do lançamento do Stretch. — Já virou Buster / Sid (nunca será estabilizado), e até hoje deu menos problemas do que algumas instalações anteriores do Jessie.
  • O Arch Linux é uma distro “rolling release”.
  • O openSUSE Tumbleweed também é “rolling release” e se mostrou muito sólido. — Só foi substituído porque enjoei de tantas atualizações, — e era redundante mantê-lo lado a lado com o openSUSE Leap. Bastava um. Optei pelo mais “calmo”, que desde o começo funcionou melhor e deu muito menos problemas. Além disso, já tinha investido muito mais nele.

Instalação


KSysguard e Watch Sensors para monitorar a instalação do Kubuntu 18.04 Bionic Beaver

A instalação do Kubuntu 18.04 LTS Bionic Beaver (development-branch) não apresentou novidades em relação às instalações anteriores do Kubuntu 17.04, do 16.04 LTS, do 14.04 LTS, ou do 12.04 LTS, — o Ubiquity segue as mesmas etapas, com as mesmas opções.

As únicas diferenças registradas, ao longo desses anos, decorreram de

  • passagem da conexão de 1 megas para 10 megas (1,28 MiB/s), antes de 2016;
  • aumento no número de partições (+HDD interno, +SSD externo) e de distros instaladas;
  • uso de CD / DVD ou USB

Em 2016, foi usado Pendrive (USB), — porém agora optei por DVD (para guardar), e isso deve exigir mais tempo ao copiar arquivos localmente.

O acréscimo de +1 HDD, +1 SSD, — com inúmeras partições e várias distros em "dualboot", — exige mais tempo a verificar espaços livres e a detectar outros sistemas na instalação do Grub; — além de mais trabalho manual para que cada nova distro não use as partições Swap das demais.

09:27 - Installer - English
09:27 - Installer - Portuguese
09:27 - Keyboard Layout
09:28 - Download updates / Third party software (Yes, yes)
09:28 - Unmount /dev/sdb?
09:29 - Dolphin - Unmount sdb
09:29 - Unmount /dev/sdb? (Yes) - Detecting partitions and free spaces (8 minutes)
09:33 - Active wired connection (verify)
09:34 - sudo apt install lm-sensors
09:36 - watch sensors (Konsole + KSysguard)
09:37 - Manual Partitioning
09:39 - Grub - MBR /dev/sdd
09:40 - Root partition - Format
09:41 - Home partition
09:42 - Swap partition
09:42 - Disable other Swap partitions
09:45 - Disable other Swap partitions (3 minutes)
09:45 - Root, Home, Swap partitions
09:46 - Write partitions to Disk? (Partitioning: 9 minutes)
09:46 - Localization (Time Zone)
09:47 - Copying files... 17%
09:52 - Copying files... 74% - PrintScreen fail (smartphone photo)
09:52 - PrintScreen Ok (5 minutes)
09:53 - User Name, Password, Auto-Login
09:54 - Slideshow — Grub from 9:59 to 10:09
10:14 - Slideshow (20 minutes)
10:14 - Install - Finish

Portanto, o tempo total foi de 47 minutos, — dos quais:

  • 08 minutos detectando partições existentes e espaços livres
  • 09 minutos no Particionamento manual, — dos quais:
  • 03 minutos des-selecionando 11 partições Swap (das demais distros)
  • 05 minutos copiando arquivos
  • 20 minutos na instalação propriamente (Slideshow), — dos quais:
  • 10 minutos verificando outros sistemas e atualizando Grub
  • 42 minutos nessas 4 etapas
  • 05 minutos em todas as demais etapas — de fato, há muito pouco a decidir e fazer

Com uma conexão rápida e apenas 1 HDD vazio, deve ser rapidíssimo.

Vale registrar que em algumas distros, como o Mageia, a atualização do Grub é 4 vezes mais rápida. — Leva apenas 2 minutos, — contra 8 minutos (ou mais) no Kubuntu 18.04, no KDE Neon e outras.

A grande diferença em relação à instalação do Kubuntu 16.04 LTS em 34 minutos pode ser atribuída a:

  • 41 partições em 4 HDDs / SSD a examinar, — e poucas em 2 HDDs naquela época
  • 11 partições Swap a desabilitar, — e nenhuma naquela época
  • Pendrive naquela época vs. DVD agora

Na “Preparação”, os 8 minutos de detecção de partições e espaços livres ficam marcados por intensa atividade de CPU, — e nenhuma atividade de rede, — desde a ordem de tentar desmontar sdb8 (previamente desmontado no Dolphin) até a apresentação das partições existentes e da proposta de como dar um jeito de arrumar espaço.

Esses 8 minutos foram aproveitados para conferir no Painel se havia conexão ativa (sim), — instalar rapidamente o lm-sensors, — e rodar watch sensors numa janelinha do Konsole, de modo a monitorar o aquecimento e outros indicadores.

A ver, por que a instalação do Kubuntu 17.04 Zesty Zapus levou apenas 21 minutos.

Histórico de pacotes


ISO: bionic-desktop-amd64.iso - de 2018-02-21

Instalação concluída em: 2018-02-22 às 10:14

Primeira sessão: 2018-02-22 às 10:38 - Wallpaper e Painel do PCLinuxOS (herança /home)

apt install


23  2018-02-22_10:40:03 sudo apt install gnome-screenshot
30  2018-02-22_11:16:35 sudo apt install conky-all
33  2018-02-22_11:20:21 sudo apt install lm-sensors                                                   
36  2018-02-22_11:23:27 sudo apt install synaptic

Synaptic


Thu Feb 22 11:28:31 2018 - Updates - KDE 5.12.1 para 5.12.2

Thu Feb 22 11:36:57 2018 - Install - Chromium

Thu Feb 22 11:38:27 2018 - Install - Gimp

Thu Feb 22 11:42:21 2018 - Install - ttf-mscorefonts-installer

Thu Feb 22 12:17:22 2018 - Install - ScreenRuler

Thu Feb 22 12:23:56 2018 - Remove - Packagekit, Plasma-Discover

Thu Feb 22 12:25:21 2018 - Remove - Unattended-Upgrades

Thu Feb 22 15:08:11 2018 - Install - KRename

Thu Feb 22 15:08:55 2018 - Install - pyRenamer

Notify > Script > QApt Batch Installer (Lang Pack incomplete)
2018-02-22 15:52:35 install gimp-help-common:all <none> 2.8.2-0.1
2018-02-22 15:52:36 install gimp-help-pt:all <none> 2.8.2-0.1

Thu Feb 22 16:21:07 2018 - Updates - Kernel 4.15.0-10 (4.15.0-10.11)

Sat Feb 24 07:14:24 2018 - Updates - Apps (4:17.08.3-0ubuntu2) to 4:17.12.2-0ubuntu1

Sat Feb 24 07:18:23 2018 - Install - Konqueror, KFind

Sat Feb 24 07:52:58 2018 - Install - Dolphin4

Sat Feb 24 07:59:42 2018 - Remove - Akregator

Sat Feb 24 09:34:02 2018 - Remove - Kernel 4.15.0-10

Sun Feb 25 04:52:55 2018 - Updates - udev (235-3ubuntu3) to 237-3ubuntu3 (...)

Sun Feb 25 04:57:08 2018 - Install - fuse2fs

Sun Feb 25 05:10:15 2018 - Install - fuseiso

Sun Feb 25 05:13:11 2018 - Install - fuseiso9660

Sun Feb 25 05:21:00 2018 - Install - kde-service-menu-fuseiso

Sun Feb 25 05:30:08 2018 - Install - libkonqsidebarplugin4a

Sun Feb 25 05:34:32 2018 - Install - konq-plugins

Sun Feb 25 05:41:34 2018 - Install - k4dirstat

Sun Feb 25 06:09:23 2018 - Install - kdiff3

Sun Feb 25 06:12:36 2018 - Install - ffmpeg

Sun Feb 25 16:40:25 2018 - Updates - ippusbxd, printers

Sun Feb 25 17:15:27 2018 - Install - bzip2-doc, p7zip-rar, unar

Sun Feb 25 18:21:58 2018 - Install - printer-driver-cups-pdf

Sun Feb 25 18:55:17 2018 - Install - hunspell, libreoffice-lightproof-pt-br

Mon Feb 26 17:59:25 2018 - Updates - ...

Tue Feb 27 08:11:22 2018 - Updates - ...

Tue Feb 27 11:16:34 2018 - Install - mc

Wallpaper


Goiás (velho) e a Serra Dourada ao amanhecer

Goiás (velho) e a Serra Dourada, by Josue Marinho, ao amanhecer (6:41), 3 Abr. 2016.

Não foi encontrado Gimp na sessão Live DVD, durante a qual foi usada a imagem original.

Depois de instalado no HDD, o Gimp foi usado para aplicar alguns ajustes: Colors > Auto > White balance, Stretch contrast, Stretch HSV e (talvez) Color enhance.

Esses 4 ajustes automáticos são tentados nessa ordem, recuando em qualquer um deles que faça mais do que apenas “limpar” algum excesso de infra-vermelho, ultravioleta (como faria um bom filtro físico ou de software na câmera); ou alguma “perda” por lentes de menor qualidade relativa. Mas a decisão é subjetiva, claro.

Enfim, a imagem foi cortada (Crop) para eliminar a faixa inferior com a data e a hora; Exportada (Ctrl-E); e aplicada à Área de trabalho no formato Scaled and Cropped para evitar distorção (corte do excedente nas laterais).

Configuração final do Conky no arquivo (oculto) ~/.conkyrc

Para que a primeira linha do Conky ficasse legível contra o fundo quase branco, foi utilizada uma cor diferente nessa linha (fechando o atributo no final):

${color cornsilk2}${font verdana:size=24}Kubuntu 18.04${font}${color}

Mais tarde substituído por um tom um pouco mais “dourado”:

${color palegoldenrod}${font verdana:size=24}Kubuntu 18.04${font}${color}

Para destaque do restante, contra inúmeras cores no fundo:

# Default colors and also border colors
default_color mintcream
default_shade_color cornsilk4

A escolha de mintcream dá um tom levemente azulado que ajuda a distinguir as letras e gráficos contra diferentes cores de fundo. Neste caso, o sombreamento preto (ou default) parece afinar as letras, dificultando a leitura; — ao passo que qualquer tom mais claro do que cornsilk4 parece inchar demais as letras, deixando-as meio borradas (apesar do maior destaque).

Mesmo cornsilk4 ainda deixava as letras borradas (apesar do maior destaque) e mais tarde foi substituído por gray20:

default_shade_color gray20

Obs.: Os scripts do Conky ainda não foram convertidos para a sintaxe da versão 1.10.

— … ≠ • ≠ … —

Kubuntu