quinta-feira, 29 de junho de 2017

Escolhendo Grub entre vários Linux

Grub do Mageia, com seleção e carregamento automático da última distro Linux escolhida

A instalação de vários sistemas em paralelo (dualboot) criou uma situação em que já não basta usar o Grub para escolher qual Linux rodar. — Agora, também é preciso escolher qual distro deve controlar o Grub, — e quais não devem interferir.

Isso, porque existem particularidades em algumas distros, — afora situações específicas, — que dificultam o Grub de um Linux gerar as entradas corretas, no Menu de inicialização, capazes de carregar todos os outros.

Havendo vários HDDs, também é uma boa precaução ter vários Grub, — controlados por diferentes Linux. — Em caso de emergência, basta configurar a Bios para dar Boot por outro HDD.

Índice


  • Infância dos fatos
  • Fatos espinhosos
  • Caso 1 - Arch (intel-ucode)
  • Caso 2 - BtrFS sem “/boot” separado
  • Caso 3 - Neon com falha
  • Caso 4 - Slackware
  • A escolha de um Grub
  • Tema do Grub2 (gráfico)
  • Mini-catástrofes
  • Reorganização do Grub
  • Reconfiguração do Grub
  • Um por todos vs. Todos por um
  • Midnight Commander (mc)
  • mc + nano
  • Making of

Infância dos fatos


Longo confinamento a 3 distros — de um mesmo “tronco”, — Debian, Kubuntu e Linux Mint

Enquanto permaneci restrito ao Kubuntu (como sistema “principal”), e Debian ou Linux Mint (como “alternativo”), o Grub nunca apresentou maiores dificuldades, durante 7 anos (2009-2016). — Ubuntu baseia-se no Debian, Linux Mint baseia-se no Ubuntu, e todos se entendem razoavelmente.

A transição do Lilo para o antigo Grub (atual “legacy”) se fez sem grandes sustos, — e a passagem para o “Grub2” foi suavizada pela descoberta do Grub-customizer.

Nada, naquela época de moleza, exigiu rever 1 velha “crença” e 1 mau-hábito.

A “crença” de que o Windows precisava ser instalado sempre “na primeira partição do primeiro HDD”, — e de que o Boot precisava estar sempre “no primeiro HDD”.

Talvez de fato fosse assim, em um computador mais antigo (último upgrade em 2002), — onde precisava alterar a “pinagem” (jumpers), intercambiar os cabos de conexão etc., para inverter os HDDs. — E afinal, nem tenho mais Windows.

Seja como for, o velho & mau hábito de sempre instalar a “chamada” do Boot na trilha inicial (MBR) do “primeiro HDD” (sda) sobreviveu por inércia.

Representação esquemática das partes que compõem o Grub e sua localização no HDD

Lembrando que o Grub se divide em 2 partes bem distintas:

1) Uma “chamada” minúscula no MBR, — a trilha inicial do HDD de Boot, — com o mínimo de informações para dar prosseguimento ao processo.
Ou seja, indicar em qual partição buscar o resto. — Cada Linux grava a “chamada” para sua partição de sistema e, dentro dela, sua pasta /boot.
2) Um conjunto de arquivos, configurações etc., dentro da partição (ou partições) de sistema de cada Linux, — em especial, na sua pasta (ou partição/boot.

Esse mau-hábito parecia reforçado pelos instaladores do Kubuntu, do Linux Mint e do Debian, — de sempre (acho) sugerir a instalação da “chamada” do Grub em sda.

Ouço dizer que, ao instalar o Kubuntu usando “particionamento automático”, ele instala a “chamada” sempre no sda, sem mais perguntas. — Não sei. Como sempre usei “particionamento manual”, sempre pude escolher o HDD em cujo MBR seria gravada a “chamada” do Grub. E escolhia o sda. — No instalador do Debian, dizem que essa escolha é oferecida, mesmo quando se opta pelo “particionamento automático”.

Desse modo, entre crenças, mal-entendidos, tradições e quiproquós, até o mês passado — depois de 1 ano sem Windows, e 6 meses usando distros não-Debian, — quase todos os Linux instalados continuavam com o Grub configurado para gravar sua “chamada” na trilha inicial do sda.

Enquanto havia apenas Kubuntu, Mint e Debian, isso não causava maiores problemas, — era até divertido, ver uma distro tomar da outra o controle do Grub. — Na pior das hipóteses, aparecia algum Menu de inicialização com opções estranhas, ou meio embaralhadas (mas não tanto que inviabilizasse o Boot).

Desde 2016, parecem existir alguma interferência ou duplicidade, envolvendo Kubuntu e KDE Neon, e que resulta em entradas adicionais, com mistura de ambos (com indicação simultânea de ambas partições), mas sem deixar de oferecer também as entradas corretas. O problema pode ter sido ocultado pelo Grub-customizer (escrevendo instruções para não exibir as entradas ambíguas), e esta “varrida para baixo do tapete” persiste até hoje, de modo que, tais entradas nunca mais foram produzidas, mesmo usando “sudo update-grub”, no Neon, Kubuntu e Mint. No entanto, ainda aparecem no Menu gerado pelo Debian. — Essas entradas estranhas não aparecem nos Menus de inicialização gerados pelo Grub das distros “não-Debian”. É verdade que em algumas foi instalado o Grub-customizer (sendo possível ter corrigido através dele), porém não em outras. — Também é possível uma hipótese de que esse tipo de erro se tenha originado de antigos erros, usando Grub-customizer, e persista por sobrevivência em algum arquivo de configuração sobrevivente na /home do Kubuntu e do Mint. Porém, a /home do Neon e do Debian não contém “heranças” anteriores a 2016.

Nesse caso, bastava escolher outra distro, reinstalar seu Grub pelo Synaptic; — ou rodar o Grub-customizer; ou disparar um “sudo grub-install /dev/sda”. — Ele retomava o controle do Grub, e tudo voltava ao normal.

Até aí, as anotações, — com eventuais erros e enganos, — estão resumidas no relato de 2012 (revisado em 2016).

Fatos espinhosos


Uma deficiência na última linha do Grub do Mint impede o carregamento do Manjaro

Este ano, com a instalação de várias distros “não-Debian”, — e com um problema ainda não-resolvido, ao reinstalar o KDE Neon, — surgiram casos ou situações em que o Grub de alguns sistemas (ou de todos) não consegue gerar entradas capazes de carregar uma ou outra distro.

A priori, nada a ver com o Grub, em si, — mas com a estrutura de uma ou outra distro. — Talvez, por falta de alguns pacotes, facilmente instaláveis.

Já ocorreu descobrir que faltava instalar syslinux, extlinux ou os-prober, — para realizar alguma tarefa em uma distro. — Falta ver se todas as outras já têm (ou se precisam ter).

Em tese, “basta” descobrir quais pacotes estão fazendo falta. — Depois disso, terá sido óbvio desde o inícpio.

Caso 1 - Arch (intel-ucode)


Falha ao carregar o Manjaro a partir do Grub gerado pelo Linux Mint

Um caso bastante discutido, — e para o qual ainda não encontrei solução “definitiva”, — é o do Arch e alguns de seus “derivados” (como o Manjaro).

Até hoje, o Grub de todos os outros Linux testados gerou entradas com uma linha assim:

initrd /boot/intel-ucode.img

mas, para funcionar, tais linhas deveriam conter mais uma indicação:

initrd /boot/intel-ucode.img /boot/initramfs-XXXXXX.img

onde “XXXXXX” pode variar, em alguns casos, — ou não, em outros.

No Manjaro, — com 2 Kernel, após um upgrade deliberado, — “XXXXXX” variava, exigindo substituição caso-a-caso, nas entradas do /boot/grub/grub.cfg. Foi um motivo (entre outros) para eliminá-lo, depois de instalar o Arch:

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

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

Correção manual do Grub, por Busca & substituição global

No Arch instalado pelo Revenge Installer, — e talvez devido a opções pessoais, — “XXXXXX” ainda não apresentou variação, o que permite busca-e-troca global no /boot/grub/grub.cfg.

initrd /boot/intel-ucode.img /boot/initramfs-linux-lts.img

Se esta fosse a única dificuldade, o Grub do Arch (ou do Manjaro) seria o candidato natural, para deter o controle do Menu de inicialização, — sem necessidade de correções manuais.

Há várias sugestões para automatizar essa “correção”, em outras distros, — incorporando-a no processo de atualização do Grub, — mas nenhum indício de que alguma dessas “receitas” tenha alcançado ampla aceitação.

Enfim, o Arch instalado pelo Anywhere não tem nada disso, — e carrega pelo Grub de qualquer outra distro, sem a menor dificuldade. — Infelizmente, ainda não consegui, nele, coisas tão básicas como Teclado ABNT2 (configurado durante a instalação!), desativar o Kwallet, y otras cositas más.

Ainda cabe testar a instalação pelo Architect, — e mais adiante, instalar “na unha”, quando tiver aprendido o bastante, para valer a pena uma personalização detalhada.

Caso 2 - BtrFS sem “/boot” separado


Falha do Grub do openSUSE em gravar a opção escolhida, para repetir no próximo Boot

Carregar o openSUSE, — instalado em uma partição BtrFS, — parece fora do alcance do Menu de inicialização gerado pelo Grub de (quase) todos os demais Linux.

A exceção é o Grub do Mageia, — único que consegue carregar o openSUSE, — e isto sinaliza que não se trata de “missão impossível”, desde que se descubra o segredo.

Este problema é de origem “personalizada”. — Foi gerado por uma decisão pessoal, — de não criar uma partição /boot (ext4 “tradicional”) separada da partição-raiz (BtrFS).

É verdade que o Menu de inicialização gerado pelo seu próprio Grub consegue carregá-lo, — e se este fosse o único problema, seria o candidato natural, para deter o controle. — Chegou a ser adotado como padrão (até foi personalizado), e ainda é mantido como “alternativo”.

Porém, (ainda) não encontrei meio dele “lembrar” a escolha feita no Boot anterior, — mesmo com a configuração necessária no /etc/default/grub:

GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT="true"

O motivo é o mesmo: — Por não ter criado uma partição /boot (ext4 “tradicional”), separada da partição de sistema (BtrFS).

É que o Grub não grava em partição BtrFS, — enquanto o openSUSE não for carregado. — Portanto, durante o Boot, não pode salvar a opção escolhida, para lembrar na próxima inicialização.

Usá-lo no dia-a-dia significa ficar parado (e atento), na frente do computador, — ou carregará sempre openSUSE, ao final da contagem regressiva.

Caso 3 - Neon com falha


Reconfiguração do Grub para tentar automatizar o uso de “nomodeset” para o KDE Neon

Situação bem diversa, — inteiramente ocasional (a solucionar), — vem acontecendo desde a reinstalação do KDE Neon, que agora só carrega se “quiet splash” for substituído por “nomodeset”.

E disso não escapa nem seu próprio Grub, — mesmo reconfigurado para usar o parâmetro “nomodeset”.

Este problema também pode ser corrigido “manualmente”, — tanto em seu próprio /boot/grub/grub.cfg, quanto no de qualquer outro Linux, — por busca-e-substituição global:

Substituir

root=UUID=XXXXXX ro quiet splash $vt_handoff

por

root=UUID=XXXXXX ro nomodeset $vt_handoff

onde o uso do UUID evita afetar as entradas de outras distros instaladas.

Como se trata de um caso anômalo, — e há outros problemas, nas tentativas recentes de reinstalar o KDE Neon, — a prioridade é solucionar a falha existente nas várias tentativas de reinstalação.

Nada a ver com o Grub. — É a instalação do KDE Neon que precisa ser consertada (quando descobrir como).

Caso 4 - Slackware


“Panic” e “End trace” no Boot do Slackware a partir do Grub controlado por outra distro

A instalação do Slackware (14 Jul. 2017) mostrou a existência de mais um caso espinhoso.

Nas linhas onde o Grub do Mageia, — entre outros, — gera estes parâmetros:

linux /boot/vmlinuz-generic-4.4.75 root=/dev/sdc2

é necessário substituir “generic” por “huge”:

linux /boot/vmlinuz-huge-4.4.75 root=/dev/sdc2

Na forma original, o Boot do Slackware emite 2 mensagens de “panic” e termina em uma mensagem de “end trace”, — palavras-chaves que levaram à localização imediata da solução, numa postagem onde se relatava o problema no Grub gerado pelo Manjaro.

A escolha de um Grub


Grub original do Mageia, com letras grandes, — e metade do Menu fora do retângulo de exibição

Desse conjunto de obstáculos, — e de 2 ou 3 “desastres” mais ou menos chatos, — o Grub do Mageia acabou se destacando como o mais indicado, para esse conjunto de 7 distros instaladas (e mais algumas, já removidas).

Os principais motivos:

1) É o único que consegue carregar o openSUSE, — exceto o Grub do próprio openSUSE

2) Se sua “chamada” no MBR for apagada, o Mageia pode ser carregado pelo Grub de qualquer outra distro, — e num minuto, gravar novamente sua “chamada” no MBR.

Se dependesse do Grub do openSUSE para carregá-lo, cada apagamento de sua “chamada” no MBR teria representado uma boa perda de tempo.

3) “Lembra” perfeitamente qual o último sistema escolhido, — e o carrega automaticamente, ao final da contagem regressiva, — o que é muito prático, para usar uma mesma distro Linux durante vários dias seguidos.

Alternar entre várias distros, várias vezes por dia, não traz qualquer vantagem ao trabalho, — pelo contrário, torna mais frequentes as atualizações de Kernel, — que obrigam a carregar o Mageia, para atualizar o Grub (e tornar a fazer as correções “manuais”).

O resto, — ter de corrigir “manualmente” as entradas do Arch e do KDE Neon, — também aconteceria com o Grub de qualquer outra distro.

São fatores “neutros”, portanto, — não influem na escolha do Grub “A” ou “B”. — E de qualquer modo, são correções fáceis e rápidas (principalmente depois que o Manjaro foi trocado pelo Arch).

Numa comparação informal com “tipos de sangue”, diria que se trata de escolher aquele que seja “o mais universal doador & receptor”, — ou seja, aquele que seja carregado pelo Grub de todas as outras distros (ou da maioria delas), — e cujo Grub seja capaz de carregar todas as outras distros (se possível). Após testar umas 20 distros em dualboot (não todas de uma só vez), o Mageia 6 sta2 foi quem levou o Oscar, e ainda segue imbatível. Façanha invejável, para uma comunidade com limitações de recursos e colaboradores.

Tema do Grub2 (gráfico)


Edição do tema do Grub para ampliar o retângulo do Menu de inicialização

Como a edição do Grub “gráfico” é trabalhosa, — os arquivos se espalham por várias pastas, e para ver o efeito é necessário gerar (atualizar), reiniciar o computador, — foi copiado o tema do Grub do openSUSE, cuja personalização já ia bem avançada.

As edições foram feitas em 2 arquivos e 1 pasta, — destacados nestas seções da árvore do sistema, — nos dias 20 e 21 Maio:

   |-boot
      |---grub2
             custom.cfg
             grub.cfg
             grubenv
         |-----fonts
         |-----i386-pc
         |-----locale
         |-----themes
            |-------dolphy
            |-------maggy
            |-------openSUSE
   |-etc
      |---default
             grub
      |---grub.d
             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
             README

Uma das principais modificações foi reduzir a fonte de letra e aumentar o retângulo central, — onde se apresentam as opções do Menu de inicialização, — para caberem 8+ distros, teste de memória etc., sem deixar coisas escondidas “abaixo da linha do horizonte”.

Mini-catástrofes


Efeito de um upgrade do Grub, — Menu “de fábrica”

Dois pequenos sustos, nos dias 16 e 28 Jun. 2017, levaram a reavaliar velhos hábitos, — bem como, a corrigir ideias erradas (ou superadas), — e finalmente sistematizar soluções que, até então, vinham sendo improvisadas aqui e ali, de modo disperso.

E mais do que apenas sistematizar as soluções adotadas, precisava sistematizar as ideias, — os motivos, e até o conjunto dos fatos observados, — pois já ia esquecendo alguns.

No dia 16, o Kubuntu recebeu um prosaico upgrade do Grub:

Commit Log for Fri Jun 16 02:25:30 2017

grub-common (2.02~beta2-36ubuntu3.9) to 2.02~beta2-36ubuntu3.11
grub-pc (2.02~beta2-36ubuntu3.9) to 2.02~beta2-36ubuntu3.11
grub-pc-bin (2.02~beta2-36ubuntu3.9) to 2.02~beta2-36ubuntu3.11
grub2-common (2.02~beta2-36ubuntu3.9) to 2.02~beta2-36ubuntu3.11

e foi o quanto bastou para re-gravar sua “chamada” no MBR do 1º HDD (sda), — em lugar da “chamada” para o Grub do Mageia.

Pior. Parece ter implantado um /boot/grub/grub.cfg “de fábrica”, — sem tomar a iniciativa de detectar outros sistemas existentes no computador. — O resultado foi um Menu de inicialização contendo apenas o próprio Kubuntu, suas próprias Opções avançadas, e Testes de memória.

No entanto, o mesmo upgrade havia sido feito no KDE Neon, meia-hora antes, — sem causar “desastre” algum:

Commit Log for Fri Jun 16 01:53:51 2017

grub-common (2.02~beta2-36ubuntu3.9) to 2.02~beta2-36ubuntu3.11
grub-pc (2.02~beta2-36ubuntu3.9) to 2.02~beta2-36ubuntu3.11
grub-pc-bin (2.02~beta2-36ubuntu3.9) to 2.02~beta2-36ubuntu3.11
grub2-common (2.02~beta2-36ubuntu3.9) to 2.02~beta2-36ubuntu3.11

Lembrasse o essencial do que já sabia, — resumido acima, — e não gastaria 10 minutos para restabelecer o controle pelo Grub do Mageia:

  • Carregar o Kubuntu
  • Rodar um “sudo update-grub
  • Carregar o Mageia pelo Menu de inicialização (atualizado) do Kubuntu
  • Re-gravar a “chamada” para o Grub do Mageia em sda
  • Aproveitar para atualizar o Menu de inicialização gerado pelo Grub do Mageia

Mas as ideias, fatos, motivos etc. estavam fragmentados, — e passava da meia-noite, quando todos os gatos parecem cachorros pardos, rosnando. — Para complicar, os avanços do KDE vêm desabilitando o uso do Krusader, Dolphin, Kate como Superusuário (Root) em várias distros, fazendo velhos hábitos tropeçarem a cada passo.

Quadro das distros atualizadas, após a revisão geral de 28 Jun. 2017

Tentei tudo o que não precisava tentar, — Live Arch Anywhere (como Rescue disk), Centro de Controle do Live Mageia 6 sta2, Live openSUSE (More → Rescue system), Mageia Classic Installer (Rescue → Re-install Boot Loader), — e só não foi pura perda de tempo, porque serviu para revisar o assunto de A a Z, documentar configurações e ferramentas usadas em cada distro, — além de aproveitar para fazer as atualizações de todas as distros não-utilizadas durante a semana.

Ficou claro que precisava reconfigurar o Grub das outras distros para gravarem no MBR do sdc, — de modo que apenas o do Mageia gravasse em sda, e só o openSUSE gravasse no sdb, — mas faltava descobrir como. — O comando “grub-install /dev/sdc” (que imaginava alterar essa configuração), na verdade faz apenas uma gravação isolada, sem evitar que continuem gravando em sda, no futuro.

Isso ficou claro, — e o assunto, mais urgente, — em 28 Junho, quando chegou a vez do upgrade de Grub no Debian:

grub-common (2.02~beta3-5) to 2.02-1
grub-pc (2.02~beta3-5) to 2.02-1
grub-pc-bin (2.02~beta3-5) to 2.02-1
grub2-common (2.02~beta3-5) to 2.02-1

Dessa vez, o susto não passou de marolinha, — o resumo já estava claro (e bem anotado). — Só faltava acabar com aquela chatice, de uma vez por todas.

Reorganização do Grub


Como havia 7 sistemas instalados, — e apenas 3 HDDs, — era preciso evitar que outros Linux interferissem no Grub controlado pelo Mageia.

As configurações precisavam ser planejadas de modo racional, para segregar o campo de atuação de cada um:

  • MBR do sdaGrub do Mageia (sda2)
  • MBR do sdbGrub do openSUSE (sdb2)
  • MBR do sdcGrub do Debian, Kubuntu, Mint, Neon, Arch

Associar o Grub do Mageia e do openSUSE ao MBR dos respectivos HDDs torna cada um deles “independente” de falhas no outro HDD.

Os demais 5 sistemas se revezam na “posse” da trilha inicial do sdc, — sem sobregravar as “chamadas” para o Grub do Mageia, em sda, — nem as chamadas para o Grub do openSUSE, em sdb.

Havia uma hipótese de deixar apenas 1 Grub gravando em sdc, — e os outros 4 simplesmente pararem de gravar (ver adiante), — mas isso deixaria o “último salva-vidas” dependente de apenas 1 distro, para se manter atualizado.

Poderia ficar excessivamente desatualizado, — caso não use aquela distro com frequência, — ao passo que 5 distros em “corrida de revezamento” garantem atualizações mais frequentes.

Reconfiguração do Grub


Usando “dpkg-reconfigure grub-pc” para redefinir qual MBR será gravada por cada Grub 

O caminho para fazer isso, — no Debian & derivados, — finalmente foi encontrado, depois de várias buscas sem resultados:

dpkg-reconfigure grub-pc

Opções oferecidas pelo “sudo dpkg-reconfigure grub-pc”

Em resposta ao comando, o Konsole exibe uma interface “semi-gráfica”, e a primeira questão é sobre uma linha de comando do Grub antigo (legacy: “menu.lst”). — Foi apresentada em branco (esclarece que pode deixar vazia). — Me limitei a usar TAB para chegar ao “Ok” e prosseguir.

A segunda questão apresentada é sobre os parâmetros a serem usados na entrada-padrão do Menu, — “quiet splash”. — Mais uma vez, TAB para chegar ao “Ok”, sem alterar nada.

A terceira questão era a que interessava no momento, — em qual HDD cada Grub deve gravar sua “chamada”, — sendo possível escolher mais de um.

Usam-se SETAS (↓↑) para navegar entre as múltiplas escolhas, — ESPAÇO para marcar / desmarcar, — e TAB para chegar ao “Ok”.

Em todos os casos, foram oferecidos os 3 HDDs (o SSD estava desplugado), — além da partição onde cada sistema está instalado. — Esta última opção não é recomendada, e nem sei como se usa.

É possível configurar o Grub para não gravar “chamada” em parte alguma

Em um forum, alguém sugere gravar na partição, quando se deseja que o Grub não grave no MBR de nenhum HDD.

Parece mais lógico apenas desmarcar todas as opções, — e isso pode ser revertido, se necessário.

Um por todos vs. Todos por um


É interessante a sugestão dada no último quadro do “dpkg-configure grub-pc”, de instalar a “chamada” do Grub, — na verdade, de “um único Grub”, — em todos os HDDs.

No entanto, a experiência sugere que isso pode ser uma péssima ideia, — basta imaginar como fica, se você “perder” a partição para a qual todas as “chamadas” apontam.

Mas, se você tem 2+ Linux instalados em HDDs diferentes, — e mantém cada MBR apontando para o Grub de uma distro diferente, — bastará entrar na BIOS e configurar o Boot para outro HDD.

Em 1 minuto, você estará rodando o Linux sobrevivente, — ao invés de ficar um longo tempo procurando (e tentando pôr em prática) um modo de sair da enrascada.

Aliás, esse era um dos objetivos de sempre ter 2 Linux instalados “lado a lado” (dualboot), de 2009 a 2016. Um Linux “alternativo” oferece comodidade, em caso de pane no Linux “principal”. — Além, claro, de não precisar submeter seu “ambiente de produção” a experiências malucas, — tendo outro, que pode ser usado como “campo de provas”.

Apenas, — naquele período de 2009 a 2016, — não percebia a vantagem de ter 2 Menus de inicialização, chamados a partir de 2 HDDs. Pelo contrário, vivia sob a “crença” de que o Boot tivesse de ser feito sempre a partir do 1º HDD.

Midnight Commander (mc)


Verificação do /boot/grub2/grub.cfg (data, hora) e edição pelo mcedit do Midnight Commander

Com os crescentes obstáculos ao uso de Dolphin / Krusader / Kate / KWrite em modo Superusuário (Root), — e cada distro oferecendo (ou não) diferentes alternativas para contorná-los, — resolver problemas estava se tornando mais um problema. Nas horas mais inconvenientes.

Use Ctrl-Shift-V para colar expressões nos campos de busca e troca global do Editor do Midnight Commander

Alguns comportamentos e soluções diferentes são inevitáveis, aqui e ali, quando se tentam usar 7 distros, alternadamente, — mas, para lembrar algumas diferenças e seguir adiante sem perder tempo, convém que a maioria dos outros procedimentos seja tão padronizada quanto possível, para não criar uma confusão dos diabos.

Busca e troca global no editor de textos do Midnight Commander, com confirmação do número de ocorrências

Daí a escolha do Midnight Commander (mc), — isento das ameaças à segurança que pairam contra o uso de aplicativos com interface gráfica em modo Root.

É muito prático para localizar e editar arquivos de sistema, sem tropeçar em dúvidas como, — “/boot/grub/grub.cfg” ou “/boot/grub2/grub.cfg”, por exemplo. — A menos que você precise provar que faz tudo na unha.

mc + nano


Testes com Midnight Commander + Nano, — em tty e no Konsole

Diante de péssimas experiências vividas com o editor “vi”, — para desativar linhas catastróficas no /etc/fstab, quando impedem o Boot e levam a um “Emergency mode”, — aproveitei para testar o Midnight Commander também em tty (Ctrl-Alt-F1 / Ctrl-Alt-F7, no KDE Neon, no openSUSE).

Comando select-editor para mudar o editor de textos chamado pelo Midnight Commander (F4)

Ficou claro que o nano, — recomendado pelo próprio mc como “o mais fácil”, — é muito mais prático do que o editor interno (mcedit).

Em tty (no KDE Neon), a escolha é oferecida quando se chama o editor (F4) pela primeira vez, — mas pode ser mudada pelo comando “select-editor”.

No Arch instalado pelo Revenge, isso não aconteceu. — Em tty, o Midnight Commander não perguntou qual editor deveria usar, — e desconheceu o comando “select-editor”.

Para alternar entre o editor interno (mcedit) e o editor externo escolhido, chame o Menu dropdown (F9) para ir em OptionsConfigure e marque / desmarque “Use internal edit”.

No Konsole, a tradução desta opção em português aparece como “Conteúdo:” (sic, com dois-pontos).

Skins - Persiste certa dificuldade para encontrar skins (temas) que funcionem em todas as distros, e também no tty.

Temas de 256 cores são aceitos em algumas distros, — mas, não em outras, — e nunca no tty.

Resta procurar novos skins, — e suponho que devem ser colocados na partição do sistema, para ficarem disponíveis tanto para o Usuário quanto para o Superusuário (Root):

/usr/share/mc/skins/

Making of


Particionamento adotado para experimentar vários Linux “em paralelo” (dualboot)

Byteria é uma espécie de “caderno de anotações” das descobertas de um leigo, — um problema de cada vez, conforme as necessidades, sem nenhum “plano de estudos”, — e sem nenhuma pretensão de “ensinar” (muito menos, “ensinar tudo”).

Fica claro que aqui se trata de hardware antigo (anterior a 2009), — daí o uso de “Master Boot Record” (MBR). — Tecnologias mais recentes, por enquanto, interessam apenas com vistas a um futuro computador. Não são o dia-a-dia.

O sistema de arquivos BtrFS foi aceito, ao instalar o openSUSE, como única maneira de tomar conhecimento “concreto” do que é, para que serve, como funciona, consequências e implicações, — pois estava claro que 200 horas de simples leitura não iam levar a nada. — LVM fica para o futuro (se e quando interessar, coisa que no momento parece improvável).

Não havia motivo para alterar o planejamento, só para criar uma partição de Boot separada, no openSUSE. — Aliás, nunca teria percebido o problema, — nem, consequentemente, o aceno do Mageia, de que uma solução é possível.

Por que o Grub do Mageia consegue gerar uma entrada capaz de carregar o openSUSE, — e o Debian & derivados não conseguem? — As experiências vão sendo feitas no KDE Neon (sujeito a reinstalação), e apenas quando a solução for encontrada (e compreendida), será aplicada também no Debian, Kubuntu, Linux Mint.

Não há motivo para bagunçar todos, com mil experiências e tentativas, até o ponto de (depois) não ter certeza de qual pequeno detalhe, exatamente, resolveu a questão. — Deixando o Debian, o Kubuntu e o Linux Mint “intocados”, servirão mais tarde como “controle”, testando apenas 1 hipótese de cada vez.

Também falta descobrir comandos, — no Mageia, no openSUSE e no Arch, — equivalentes ao “dpkg-reconfigure grub-pc” do Debian & derivados. Porém isso não é urgente, uma vez que parecem já estar configurados para gravar a “chamada” de Boot em sda, sdb e sdc, respectivamente, — desde quando foram instalados (Arch e Mageia); ou agora, pelas interfaces gráficas que cada um oferece para isso (Mageia e openSUSE).

_________
Originalmente publicado em 29 Jun. 2017, e desenvolvido até 2 Jul. 2017.
••• Adicionadas notas sobre o Slackware em 15 Jul. 2017.

— … ≠ • ≠ … —

Não-debians


quarta-feira, 14 de junho de 2017

Escolhendo (e aprendendo) Linux conforme as necessidades

Aprendendo pela comparação de distros Linux e tentativas de obter desempenho similar

O que esse conjunto específico de distribuições Linux tem em comum (além do KDE) é certa “contemporaneidade”, — ou certa homogeneidade de repositórios, — independente das características próprias de cada uma.

Isto facilita “comparar” os diferentes sistemas, — e aprender um pouco mais, tentando levar todos ao maior grau possível de “usabilidade”.

Para “homogeneizar” os repositórios, foi necessário “apressar” algumas coisas, — transformar o Debian stable (Jessie) em testing (Stretch), desde Outubro 2016; — e substituir o Mageia 5 pelo Mageia 6 sta2, desde Maio 2017.

Com isso, eliminaram-se o Kernel 3.xx e o KDE 4.xx; — o Ksnapshot deu lugar ao KDE Spectacle como aplicativo-padrão; — a versão do Gnome-screenshot foi equalizada (com os recursos desejados); — e assim por diante.

Ao contrário do que poderia recear, versões em desenvolvimento, de teste, ou distros “rolling release”, não têm dado problema.

O Linux Mint “Sarah” Beta, por exemplo, foi o melhor “ambiente de produção” da série 18, — nem reinstalei após o lançamento. — Só “estragou” na migração para 18.1 “Serena”.

O KDE Neon, — instalado em Maio 2016, quando ainda nem se apresentava como uma “distribuição”, — também foi um dos sistemas mais “produtivos”, ao longo de 10 meses … até ser apagado, involuntariamente, num momento de distração. Acontece.

O que lamento, é não ter guardado aquelas imagens ISO do KDE Neon (Maio 2016), e do Mint 18 Beta (Agosto 2016), — usadas em Pendrive apagável, — ao passo que ainda guardo CDs do Kurumin de 2004.

Índice


  • Tempo de Boot e uso inicial de Memória RAM
  • Interferências agendadas
  • Reduzindo interferências
  • Conky vs. Htop
  • openSUSE
  • Mageia 6 sta2
  • Kernel
  • Google Earth (sem 3D)
  • Redes sociais
  • Observações
  • Não-debians [Menu]


  • O Knoppix, — Live Pendrive com Persistência, — não entra na comparação. É um ótimo conjunto de ferramentas de manutenção (com direito a Chromium sincronizado), mas incômodo para uso prolongado, quando se dispõe de apenas 4 GB RAM.

Tempo de Boot e uso inicial de Memória RAM


Tempo de carregamento (Boot) e uso inicial de Memória RAM nos Linux (configurados)

Isto não é uma comparação tecnicamente rigorosa, — apenas uma guia de pesquisa, para entender diferenças de comportamento, — e eventualmente obter, em um Linux, algo que outros mostram ser possível.

A essa altura, todas as distros já receberam um grande número de configurações personalizadas, — semelhantes, mas não 100% iguais.

A configuração de maior impacto é a remoção do conjunto de aplicativos que compõem o PIM, — Personal Information Manager, — mas parece provável que ainda fiquem resquícios.

O KDE Neon e o “Arch (b)” já vieram sem PIM, — portanto, não têm “resquícios” a eliminar, — e batem todos os outros, quanto ao menor uso inicial de Memória RAM, com exceção do Debian, que tem 1 diferença (adiante).

Também são desativados “Pesquisa de arquivos” (File search) e “Carteira do KDE” (Kwallet), além de outros serviços, como:

  • Notificador de mudança de URLs remotas
  • Atualização das pastas de pesquisa
  • Gerenciador de impressão
  • Servidor do Write (mensagens locais)
  • Touchpad

No Arch, não foi instalado suporte a impressora, — mas nos outros, ainda não foi desinstalado (caso exista), — exceto no Mageia, onde hplip se destacou à vista.

O tempo de Boot de cada sistema Linux é uma medida um tanto arbitrária, — o momento em que é exibida a área de trabalho completa, com Painel, wallpaper, e (em alguns casos) a notificação de que foi estabelecida a conexão web, — com alguma variação do “tempo humano de resposta”.

A medida de uso de Memória RAM tomada logo que o ambiente é carregado não é a mais correta, — pois ainda há bastante atividade de CPU, e só depois o uso de Memória RAM diminui, — até se estabilizar, após mais alguns segundos, caso não ocorra qualquer ação do usuário, nem acionamento automático de algum serviço agendado.

Interferências agendadas


Agendamento da verificação de atualizações no antigo Linux Mint 17.3 Cinnamon

No antigo Linux Mint Cinnamon (já removido), há tempos encontrei a configuração do tempo de espera (“20”) para a verificação de atualizações, após o início da sessão.

Agendamento da verificação de atualizações, no mintUpdate

Na atual instalação do Linux Mint 18 “Sarah” KDE, a verificação de atualizações está agendada para 10 minutos após o início da sessão, — e novamente a cada 2 horas, — por opção pessoal.

No Mageia, a configuração (original) é de verificar atualizações 5 minutos após o Boot e novamente a cada 3 horas.

No Debian, é comum o Painel já aparecer indicando atualizações, — dando a impressão de que a verificação foi feita durante o carregamento do sistema, — mas outras vezes isto só ocorre alguns minutos depois.

No openSUSE, a verificação de atualizações costuma ter início quase sem demora, logo após carregar a primeira sessão do dia.

unattended-upgrades menos de 3 minutos após carregar o Zesty Zapus

Ao que parece, todos eles apenas verificam, e avisam, — mas posso estar enganado.

No Kubuntu Zesty Zapus (já removido), atualizações “de segurança” ocorriam sem perguntar nem avisar nada, deixando o sistema extremamente lento, devagar-quase-travando (unattended-upgrades); e somente as demais eram notificadas no Painel.

Na instalação atual do KDE Neon (2017), “unattended-upgrades” não está instalado; e não existem registros de atividade anterior.

No Kubuntu 16.04 LTS, /var/log/unattended-upgrades registra atividade regular desde sua instalação, em Abril 2016, — porém nunca chamou atenção.

Na atual instalação do Linux Mint 18 “Sarah” KDE, os registros parecem repetir, — invariavelmente, — “Sem pacotes encontrados que podem ser atualizados sozinhos e sem dependendo de auto-remoções”.
Em princípio, imagino que todos ofereçam alguma possibilidade de configurar o momento de iniciar a verificação, — além da frequência etc., — mas isso ainda está para ser examinado.

Aqui, o importante era evitar atividades disparadas nos primeiros 3 minutos de carregamento, — para isolar eventuais distorções no uso de Memória RAM.

Manutenção do sistema de arquivos BtrFS, pouco após iniciar a sessão do openSUSE

No openSUSE, — único instalado com sistemas de arquivo não-tradicionais (BtrFS e XFS), — também é comum disparar manutenção, desfragmentação etc., provocando lentidão geral (quase travando), cerca de 10 minutos após o início da primeira sessão do dia.

Mas, há alguns registros dessa atividade, bem antes dos 10 minutos, — a descobrir por quê.

Reduzindo interferências


Para diminuir as diferenças introduzidas artificialmente, foram desabilitados alguns aplicativos que eram carregados automaticamente no início de cada sessão, — mas não por igual em todas as distros instaladas:

  • Dolphin - que era carregado automaticamente em todos os sistemas, porém com número desigual de abas (3~5), — e exibindo pastas muito diferentes, em cada Linux, — algumas com poucos arquivos, outras com centenas de arquivos
  • KSysguard - que era carregado em todos os Linux instalados
  • Xsensors - que era carregado em vários dos Linux
  • Psensor - que era carregado só em alguns sistemas

Persiste 1 diferença, cujo efeito não foi verificado: — Todos os sistemas carregam com 16 partições adicionais montadas automaticamente, pelo udisks2, — com exceção do Debian, onde a montagem automática de partições adicionais (ainda) é feita pelo /etc/fstab, usando os identificadores UUID.

Conky vs. Htop


Tempo de Boot e uso inicial de Memória RAM, segundo Conky e Htop

Para começar, foram feitos testes carregando automaticamente o Conky e o Htop, no início de cada sessão, — exceto no Linux Mint 18, onde não consegui.

Os números indicados pelo Conky e pelo Htop foram muito semelhantes, — com pequenas diferenças de ciclo de atualização, — exceto no openSUSE, onde apresentaram uma discrepância espantosa.

Naturalmente, a abertura automática do Htop / Konsole eleva o uso inicial de Memória RAM.

  • Forçar tamanho e posicionamento padronizado do Konsole (pelo Kwin), para não cobrir o Conky, também afetou os resultados obtidos, — mas isto só foi comprovado depois.

Os dados dessas experiências usando Conky + Htop foram mal-monitorados, nos casos do Kubuntu e do Linux Mint.

No Kubuntu, o Kwin não conseguiu forçar o posicionamento do Konsole, — o Htop abriu sempre sobreposto ao Conky, sendo necessário arrastá-lo manualmente em seguida, para uma segunda Captura de tela.

No Linux Mint, não cheguei a conseguir que o Htop fosse aberto automaticamente no início de cada sessão, — era necessário abrir o Konsole e chamar o Htop manualmente, em seguida. — Neste caso, os primeiros números não incluem o Htop / Konsole.

Nos 2 casos, estas ações foram realizadas logo após a primeira Captura de tela, — e só mais tarde foi constatado que o Gnome-screenshot costuma ocupar cerca de 25 MiB da Memória RAM, durante cerca de 21 segundos. — Portanto, os dados da segunda Captura estavam viciados. Era necessário um intervalo maior.

De qualquer modo, esse primeiro levantamento já foi suficiente para identificar as maiores demoras do Boot e alto consumo inicial de Memória RAM, — no openSUSE e no Mageia. — Algumas causas foram identificadas e, dentro do possível, eliminadas.

openSUSE


Uso inicial de Memória RAM diminui (Conky) / aumenta (Htop), — e se reduz a diferença entre eles

Somente no openSUSE, houve discrepância digna de nota, — Conky indicando uso de Memória RAM cerca de 100 MiB maior do que no Htop, no primeiro momento, — mas entender isso, é coisa que fica para o futuro.

Tal como nos demais, a atividade de CPU cai drasticamente, alguns segundos após o carregamento do sistema.

No openSUSE, porém, ocorre apenas uma leve redução na indicação de Memória RAM pelo Conky, — contra um leve aumento no uso indicado pelo Htop, — e a discrepância entre eles se reduz para 50 ~ 60 MiB.

Exceto, claro, quando se inicia uma verificação de atualizações, — ou uma manutenção do sistema de arquivos BtrFS, — coisas que costumam acontecer após o 1º Boot do dia.

uptime Conky   Htop

1m 26s   528   437 MiB - Forçar posição e tamanho do Konsole (Kwin)

1m 43s   549   448 MiB - Forçar posição e tamanho do Konsole (Kwin)
3m  0s   528   470 MiB
4m  0s   622   575 MiB - updates available

1m 28s         432 MiB - Livre posicionamento do Konsole
1m 34s   533   449 MiB - Konsole arrastado

1m 28s   537   437 MiB - única leitura

1m 25s   529   434 MiB - Livre posicionamento do Konsole
3m  0s   516   457 MiB
4m  0s   516   457 MiB

Principal candidato a ser causa da demora de Boot do openSUSE

Quanto ao tempo excessivo de carregamento do openSUSE, deve-se a um “start job is running for wicked managed network interfaces”, — com demora de 32 ~ 36 segundos, — e que também promete tomar algum tempo para solucionar (de preferência, sem provocar danos colaterais).

Mageia 6 sta2


Remoção do hplip no Mageia

Chamou atenção o alto uso inicial de Memória RAM pelo Mageia 6 sta2, — ainda não examinado em profundidade.

A remoção do suporte a impressora HP (hplip), — bem como a desativação de alguns serviços de segundo plano, — já permitiram alguma redução no uso inicial de Memória RAM.

Falhas de configuração de Virtual Console e início de Software RAID no Boot do Mageia

Também foi eliminada uma configuração de “ABNT2” para o console virtual, que dava mensagens de erro na inicialização (não afetou a acentuação no tty); — e desativado o monitoramento de RAID:

# systemctl disable mdmonitor.service

Eliminando configuração em /etc/vconsole.conf que gerava mensagem de erro no Boot

Essas duas configurações apenas eliminaram mensagens de erro durante o Boot, — sem efeitos visíveis no tempo de carregamento ou no uso inicial de Memória RAM:

uptime Conky   Htop

1m 17s   618   618 MiB

1m 17s   605   584 MiB
2m  0s   596   596 MiB
2m 30s   599   599 MiB
3m  0s   571     - MiB - fechado Htop

- fechados alguns serviços no System settings → Inicialização e desligamento
- removido hplip etc.

1m 20s   583   582 MiB
2m  0s   554   554 MiB
2m 38s   524     - MiB - fechado Htop
3m  0s   524     - MiB

- editado /etc/vconsole.conf (FONT e KEYMAP em branco, agora)

1m 15s   580   580 MiB
2m  0s   554   554 MiB
2m 30s   555   554 MiB
3m  0s   532     - MiB - fechado Htop
3m 30s   524     - MiB

- Konsole com acentuação completa, inclusive Left-Win
- tty com acentuação, exceto Left-Win, que volta ao KDE
- systemctl disable monitor-service

1m 11s   576   574 MiB
2m  0s   550   550 MiB
3m  0s   524     - MiB - fechado Htop

xxxxx

Kernel


No KDE Neon e no Linux Mint 18 “Sarah”, — ambos reinstalados, com problemas que antes não existiam, — o Kernel foi substituído por versões mais antigas, na tentativa de voltar aos bons tempos.

Nas 2 instalações do Arch Linux, optei por Kernel LTS. — Podia ter feito opções diferentes, para comparar, — mas as diferenças do KDE (completo ou básico) talvez ficassem menos nítidas.

Google Earth (sem 3D)


Não existe pressa em tentar essa façanha em sistemas ainda pouco conhecidos. — Por ser pouco usado, é suficiente tê-lo em 2 sistemas, — e carregar 1 deles, quando necessário.

São grandes as chances de conseguir instalar o GoogleEarth também no KDE Neon, — isso já foi feito, no ano passado, — mas prevalece a expectativa de reinstalar (ou “consertar”) o próprio KDE Neon, em busca da mesma qualidade de antes, e isso não estimula investir muito em povoá-lo de aplicativos, por enquanto.

Redes sociais


Nada menos que 4 sistemas, — KDE Neon, Kubuntu, Mint 18 “Sarah” e Arch Linux, — permitem enfrentar as redes sociais (em especial, “Páginas” do Facebook), 3 ou 4 vezes por dia, com direito aos vídeos, sem cair num atoleiro de abuso de CPU.

Outros 2, — Mageia e openSUSE, — também permitem isso, desde que não faça questão de assistir alguns vídeos. O dia até rende mais.

Assistir vídeos da web, — e não poder enfrentar as “Páginas” do Facebook, — não tem utilidade. É um velho problema no Debian, que nunca consegui solucionar.

Observações


Essa não é uma comparação “técnica” de distribuições Linux, — mas, apenas, o levantamento de algumas dificuldades enfrentadas por um usuário específico (leigo, 8 anos no Kubuntu), com um conjunto específico de tarefas, em um hardware limitado (E7300 Intel Core2 Duo 2,66 GHz video onboard, 4 GB).

São omitidas inúmeras outras tarefas, que não apresentam dificuldades, nem diferenças relevantes entre as distros instaladas.

A seleção seguiu critérios mutáveis, ao longo do tempo, — Kubuntu, Debian e Linux Mint há 8 anos; KDE Neon a partir de 2016; os demais, a partir de 2017, — começando pela capacidade de enfrentar a instalação (Arch por último, com instaladores gráficos) e filtrando as que apresentaram poucas perspectivas de uso pessoal (retirados Fedora, Manjaro, Antergos, Sabayon).

O objetivo é dispor de distros de “troncos” diferentes (não-Debian), — e de preferência, não-sujeitas a “decisões proprietárias”.

— … ≠ • ≠ … —

Não-debians


domingo, 4 de junho de 2017

Arch Linux KDE - Instalação (gráfica) e configuração

Arch Linux KDE após instalação (gráfica) pelo Revenge Installer
Arch Linux KDE após instalação (gráfica) pelo Revenge Installer

O Arch Linux foi instalado de improviso, — sem estudo nem preparação, — como forma de começar a entender, na prática, o significado de todas aquelas explicações áridas e um tanto assustadoras do passo-a-passo ortodoxo.

Motivação, por assim dizer. — Muita gente começa a aprender um idioma, “falando” (como as crianças), para depois se interessar pelos “detalhes”, — mas pouca gente iria muito longe, se fosse convencida de que o único “método” é começar pelo estudo da gramática, flexões, declinações, análise sintática etc.

No caso do Arch Linux, essa inversão do “método ortodoxo” foi possibilitada pelo Revenge Installer, — um “instalador gráfico”, descoberto por acaso, num comentário em um Grupo Google.

Após 6 dias de uso contínuo do Arch Linux, no trabalho regular, as principais constatações são um pouco surpreendentes:

  • É uma delícia.
  • Funciona (e atende minhas necessidades principais) muito melhor do que o Debian, — que venho tentando dominar há mais de 8 anos, e que nunca pareceu tão “árduo”, e nem de longe “assustador”.
  • Instalar e usar o Manjaro, — e depois o Antergos, — não me havia feito avançar 1 milímetro, em direção ao Arch Linux. Neles não aprendi quase nada, que tenha sido útil nestes 6 dias. Nenhum deles “funcionou” tão bem, — nem atendeu tão bem às minhas necessidades principais, de uso cotidiano.

Está claro que ainda falta aprender quase tudo, — e conseguir instalar Google Earth, Wine etc., de uso menos frequente.

Estes 6 dias de trabalho no Arch Linux estão longe de significar um avanço espetacular, — mas, mesmo sem reler aquelas instruções “áridas” e assustadoras, elas agora fazem sentido. Tornaram-se compreensíveis e “lógicas”.

Vale observar que a instalação foi feita em uma partição “tradicional”, ext4, — e sem partição separada de /boot, — para não complicar o que não precisava ser complicado, nessa experiência inicial.

Índice


  • Download, gravação e boot
  • Particionamento
  • Configurações
  • Construção do sistema
  • Instalação, propriamente dita
  • Documentação e cronometragem
  • Grub, Grubs
  • Atualizações: Plasma Discover
  • Pacman
  • Pcurses
  • Discover, pcurses, pacman
  • Habilitando a partição Swap
  • Montagem automática de partições adicionais
  • Baloo_file, Akonadi, PIM
  • Limpeza do cache de pacotes
  • Quadro comparativo
  • Limpeza geral
  • Revenge Installer
  • Wallpaper [créditos]
  • Não-debians [Menu]

Download, gravação e boot


Verificação da imagem ISO do Revenge Installer

A imagem “revenge_installer-2017.03-x86_64.iso” foi baixada da página do Revenge Installer, e verificada por sha1sum e md5sum. (No dia seguinte, foi lançada nova revisão).

A mídia utilizada foi DVD, — gerado pelo K3b na menor velocidade disponível (4x), — para ter sempre à mão, pois também é uma “Live” de recuperação (recue disk).

Menu de Boot do Revenge Installer

A opção do Menu que interessava, neste caso, era “Boot Revenge Installer”.

Tela de boas-vindas ao Revenge Installer, — verificar conexão internet

O primeiro passo é certificar-se de ter uma conexão internet ativa (canto superior direito), — além de lembrar que é possível abrir um Terminal e usar a sessão Live como um CD de recuperação (Rescue).

As horas são indicadas em UTC, — e não vi como alterar isso, — mas é fácil traduzir em horário local (UTC-3).

De qualquer modo, não foram feitas Capturas de tela, — nem sei se existe esse recurso. — As fotos foram feitas por celular, com horário local nos dados Exif.

Recursos do Revenge Installer, no Desktop 2, durante a instalação pelo Desktop 1

Só bem mais tarde, — já na fase automática da instalação, propriamente dita, — lembrei de explorar o que mais havia por ali:

(a) Era possível configurar o Tema (canto superior direito), o que talvez facilitasse fotos mais nítidas; e

(b) A qualquer momento, é possível mudar da área de trabalho Desktop 1 para Desktop 2 (canto superior esquerdo).

Particionamento


Lembretes após optar pelo particionamento manual e selecionar a unidade (sdc)

O passo seguinte é optar entre particionamento automático, — que deleta todas as partições do HDD escolhido, — ou particionamento manual, para escolha das partições a serem usadas (caso já estejam prontas), com direito a todas as operações oferecidas pelo GParted (caso necessário).

Optei pelo particionamento manual, — foram apresentados os HDDs detectados (sda, sdb, sdc), — selecionei sdc.

Foi então avisado que, daí para frente, o instalador não formatará nenhuma partição, — para isso, deve-se clicar “Yes”, e usar o GParted.

Também lembra que o instalador suporta usar partições separadas de “/boot”, “/home” e Swap, — bem como Swap em arquivo dentro da partição raiz (“/”), se preferir.

Formatando as partições Linux9 e Home9 no GParted

Foram formatadas as partições Linux9 (sdc3) e Home9 (sdc7), — para eliminar até mesmo as configurações do Kubuntu Zesty Zapus, testado desde Outubro.

Pretendia usar também Swap9 (sdc11), mas não era necessário formatá-la.

A lista de partições

Descartei usar partição “/boot” separada; — escolhi a partição Root (“/”); — em seguida escolheria a partição (ou arquivo) Swap; — e por fim a partição “/home”.

Porém, ao exibir “todas” as partições, a lista terminava em sdc9, — e não existe botão de “Voltar”. — Só “Ok” ou “Cancelar”.

Analisando agora, com calma, fica claro que a lista incluía as partições estendidas dos 3 HDDs (sda4, sdb4, sdc4), — mas nenhuma partição com número lógico superior a 9. — Portanto, “Voltar” não resolveria nada.

De qualquer modo, Swap nunca foi problema crucial, numa instalação, — é até comum, mais tarde, ter de desabilitar um excesso de partições Swap, que diferentes instaladores selecionam sem perguntar.

Neste caso, bastaram 2 comandos, mais tarde, — “mkswap /dev/sdc11” + “swapon /dev/sdc11”, — e acrescentar 1 linha ao arquivo “/etc/fstab”.

Portanto, parece uma falha do instalador, — oferecer partições estendidas, e não detectar mais de 9 partições por HDD, — mas neste caso, felizmente, causou apenas a perda de 2 ou 3 minutos.

Configurações


As telas seguintes oferecem uma série de opções corriqueiras em qualquer instalação:

  • Idioma - pt_BR.UTF8
  • Teclado - br
  • País / Zona - America
  • Sub-zona - Sao_Paulo
  • Relógio do sistema - UTC (ou Local Time)
  • Hostname - Linux9
  • Usuário - [username]
  • Senha Root - •••••••••••• [repetir]
  • Senha de Usuário - ••••••• [repetir]

Construção do sistema


Opções de Kernel para o Arch Linux, no Revenge Installer

A partir daqui, o instalador oferece uma série de opções que significam a construção de um sistema personalizado, conforme as necessidades de cada usuário.

São oferecidos 4 tipos de Kernel, por exemplo, — corrente, LTS, de segurança, e “Zen” (?).

Seleção de interface gráfica para o Arch Linux, no Revenge Installer

Para abreviar o registro, vão em negrito as opções adotadas, — e listas longas são resumidas com “…”, omitindo outras, não-escolhidas.

  • Kernel
  • Linux
  • Linux-LTS
  • Linux-Grsec
  • Linux-Zen
  • Instalar suporte Yaourt para Arch User Repository (AUR) - Sim
  • Instalar suporte a impressora - Não
  • Ambiente gráfico
  • Plasma
  • Plasma-KDE-Applications
  • Internet
  • Chromium
  • Filezilla
  • Media
  • Gimp
  • VLC
  • Office
  • LibreOffice-fresh (?)
  • Utilitários
  • htop
  • GParted
  • Finalizar

Enquanto você não se escolher “Finalizar” (Finished), o botão “Ok” te leva sempre de volta a uma das Categorias acima, — você pode marcar e desmarcar os itens, quantas vezes quiser.

  • Instalar Bootloader - Sim
  • sda (Grub do Mageia)
  • sdb (Grub do Arch Linux)
  • sdc (Grub do openSUSE)

Clique “Yes” para começar a instalação, ou “No” para abortar.


  • Mais tarde, o controle do MBR do sdb foi passado para o openSUSE.


Instalação, propriamente dita


Iniciar a instalação, de fato, do Arch Linux, pelo Revenge Installer

A 2ª parte do processo, — a “instalação”, propriamente dita, — é inteiramente automática, e se realizou em 41 minutos (13:21~14:02).

Desse tempo, os primeiros 11 minutos parecem ter sido de avaliação das fontes de software (mirrors) e, talvez, mais algum preparativo.

Os registros em /var/log/pacman.log indicam que foram instalados 1.054 pacotes em 30 minutos (13:32 ~ 14:02).

Documentação e cronometragem


Celular plugado (cabo USB), escolha a opção em minúsculas, — “gerenciador de arquivos”

O processo completo de instalação do Arch Linux, com KDE-applications e mais um punhado de aplicativos, — usando o Revenge Installer e uma conexão web de “10 megas” (1,3 MiB/s), — demorou 1h 30min (12:32 às 14:02).

A maior parte do tempo, — 49 minutos (12:32~13:21), — corresponde à fase inicial, de ações e opções determinadas manualmente pelo usuário:

• Particionamento manual

• Configurações

• Construção do sistema

O tempo gasto nessa primeira fase poderia ser dividido entre: (a) dúvidas de quem nunca lidou com Arch Linux; e (b) dificuldades de fotografar letras brancas em tela preta, com a janela do escritório fechada (devido ao sol da tarde).

As fotos de celular foram baixadas no Arch Linux KDE pelo Kamera.

Ao plugar o celular Nokia Lumia (WindowsPhone WP8) pelo cabo USB, escolha a opção totalmente em minúsculas, — abrir com o “gerenciador de arquivos”, — pois a outra jamais deu certo, em nenhuma das 12 distros (com KDE), experimentadas até hoje.

Selecione todas as fotos do celular que deseja baixar, — arraste-as para uma pasta no HDD, — e responda “Copiar” (que não afeta os arquivos de origem, no celular).

Umas 2 ou 3 vezes em que escolhi “Mover”, — implicando deletar as fotos no celular, após a cópia para o HDD, — isto causou danos à memória do smartphone.

Uso do KRename para renomear as fotos de celular para o padrão YYYY-MM-DD_HH-mm-SS

As fotos baixadas do celular Nokia Lumia WP8 foram, então, renomeadas (pelo KRename) para se adequarem ao padrão utilizado nos nomes-de-arquivo das Captura de tela, — de modo a se alinharem pela ordem cronológica.

O sufixo “_NL”, — de Nokia Lumia, — distingue-os de “M” (Mint) ou “MgA” (Mageia).

O padrão usado no KRename preserva qualquer “observação” que já tenha acrescentada ao final do antigo nome-de-arquivo, — da 16ª posição em diante (exceto “.extensão-de-arquivo”).

Levantamento das Fotos e Capturas de tela do download da ISO até o 1º Login do Arch Linux

As fotos da instalação, até o primeiro Login, — bem como as Capturas de tela, desde o download da ISO, até as atualizações / correções posteriores do Grub, — foram reunidas em uma pasta chamada “1_Instalacao”, cujo conteúdo foi listado para um arquivo TXT:

    ls -1 > 1_instalacao.txt

Este arquivo “1_instalacao.txt” é a base para a cronologia do “Live Revenge Installer”.

Outro arquivo semelhante, — “2_instalado.txt”, com as Fotos e Capturas posteriores, reunidas em outra pasta, — permite levantar tudo o que foi feito desde o 1º Login no Arch Linux KDE.

Grub, Grubs


Correção manual do Grub do Mageia, para carregar o Arch Linux

Como o Grub de uso corrente pertence ao Mageia, era necessário atualizá-lo, — pelo comando “sudo update-grub”, — para reconhecer o Arch Linux KDE acabado de instalar em sdc3 (onde antes estava o Kubuntu Zesty Zapus).

Em seguida, foi aberto o arquivo “/boot/grub/grub.cfg” gerado pelo próprio Arch Linux, — para ver quais parâmetros ele usa para seu carregamento, — a fim de comparar com as entradas geradas pelo Mageia.

Onde o Grub gerado pelo Mageia diz:

    initrd /boot/intel-ucode.img

o Grub gerado pelo Arch Linux diz mais:

    initrd /boot/intel-ucode.img /boot/initramfs-linux-lts.img

Infelizmente, não era possível usar “busca e troca global”, — pois afetaria as entradas para o Manjaro, — que precisam de substituição da mesmíssima string, porém com acréscimo de 2 Kernel diferentes:

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

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

Portanto, a busca & substituição teve de ser conduzida “caso a caso”, — examinar visualmente cada ocorrência, confirmar quando se tratava do Arch Linux, — mas introduzir uma das outras substituições, nos casos referentes ao Manjaro.

• Esta correção manual, — necessária após cada atualização do Grub (controlado pelo Mageia), — foi bastante simplificada, 6 dias depois, com a eliminação do Manjaro.

O primeiro, — e último, — Login manual no Arch Linux KDE

Depois, disso, o Grub, — gerado pelo Mageia, — carregou com sucesso o Arch Linux KDE, acabado de instalar.

O primeiro Login a gente nunca esquece, — em especial, se também foi o último Login manual. — Data e hora já se apresentam no fuso local (UTC-3).

Login automático em “Configurações do sistema → Inicialização e desligamento”

Dentro de 20 minutos, foi definido o Login automático, — nas “Configurações do sistema” (System settings) do KDE.

Quando há visitas que precisem usar o computador, prefiro desarmar o Login automático do Linux Mint KDE, — muito mais “amigável” para qualquer visita, — já devidamente “afinado”, e com 2 browsers (Firefox e Chromium), GoogleEarth etc.

Atualizações: Plasma Discover


Perda de tempo, — e uso abusivo de CPU, — com o Plasma Discover

No Arch Linux KDE acabado de instalar, o primeiro passo foi procurar o “notificador de atualizações”, para ver se o Menu de contexto (right-click) ofereceria algo como “recarregar” (reload) informações dos repositórios.

Não oferece. — As 2 únicas opções são “Ver Atualizações” e “Configurações das Atualizações”.

Por “Configurações”, entenda-se “criar atalho”, — nada mais.

E por “Ver Atualizações”, entenda-se “abrir o Plasma Discover”.

Jamais gostei do Muon Discover, — “lojinha multicolorida”, — mas, pelo menos, ele encontrava muitas coisas (nem tudo!), e não consumia CPU feito um desesperado. Não deixava o computador devagar-quase-travando.

Aqui, porém, o Plasma Discover “consome” CPU desvairadamente, causa “meia-trava” no computador, — e não encontra nada de útil. — Se candidata a ser a maior inutilidade jamais inventada.

Após 1 semana, esse “notificador” não se manifestou 1 única vez. — Só descobri atualizações, nos momentos em que lembrei de rodar o comando “sudo pacman -Syu”.

  • O Plasma Discover ainda não foi desinstalado, devido à possibilidade de que faça falta para alguns mecanismos do KDE, — como “Obter novos temas”, por exemplo. — Falta examinar com calma.

Nada a reclamar do Arch Linux, — nem do Revenge Installer, — por esse presente de grego.

Na hora de escolher Ambiente gráfico (“DE”, desktop environment), optei por “Plasma-KDE-Applications”, — em vez de apenas “Plasma”. — Fiz por merecer as vantagens e desvantagens decorrentes dessa decisão.

  • No 6º dia, foi instalado outro Arch Linux (em outra partição), — agora, usando o instalador gráfico Arch Anywhere, com a única opção de instalar um KDE “enxuto”. Então, criou-se a situação oposta, de precisar completar manualmente o KDE (ao invés de remover excessos). — Várias coisas ainda não funcionam: teclado PT-BR (ABNT2), login automático (SDDM) etc.

Pacman


Uso do pacman pelo método empírico, — saber o nome dos pacotes, — ou sonhar e jogar

A informação corrente é de que o Arch Linux não tem um “gerenciador de pacotes” (software) com interface gráfica, — embora possam ser usados alguns, que não são “oficiais”. — Pelo contrário, encoraja-se o usuário a usar o pacman, por linhas de comando em um Terminal.

Para um novato total, o problema de usar apenas comandos é descobrir os nomes dos pacotes existentes, — pois nem sempre são iguais aos que existem em outras distros.

Tinha de haver um modo mais inteligente de “procurar” aplicativos, do que sonhar com um nome, — e apostar no bicho, para ver se acerta a sorte grande, — ou procurar no Google, um pacote de cada vez, para compor o comando pacman.

Para não deixar que a brincadeira, logo de cara, já se transformasse num castigo, — “vá para o cantinho-do-estudo e só saia de lá depois de aprender tudo”, — foi praticado o tiro-ao-alvo-no-escuro, com razoável sucesso, nas horas restantes do primeiro dia.

Um comando “history | grep 'pacman' > history-pacman.txt” permite avaliar que houve nada menos que 10 acertos em 19 tentativas, — ou 10 em 17, se descontarmos 2 variações para tentar “cercar o bicho”:

    1  sudo pacman -Syu
    2  sudo pacman -S octopi
    6  sudo pacman -S pacmatic
   13  sudo pacman -S pcurses
   15  sudo pacman -S kalu
   17  sudo pacman -S gnome-packagekit
   25  sudo pacman -S rigo
   26  sudo pacman -S wine
   27  sudo pacman -S krusader
   29  sudo pacman -S konqueror
   31  sudo pacman -S kdiff3 krename
   33  sudo pacman -S pyrenamer
   34  sudo pacman -S imagemagick
   36  sudo pacman -S conky
   38  sudo pacman -S winehq
   39  sudo pacman -S screenruler
   40  sudo pacman -S screen-ruler
   47  sudo pacman -S psensor
   48  sudo pacman -S xsensors

Com isso, a brincadeira pôde avançar bastante, — tendo apenas o cuidado de não mexer com repositório AUR, por enquanto, para não escangalhar o brinquedo logo no primeiro dia.

O KRename, por exemplo, permitiu adiantar o levantamento das Fotos e Capturas de tela.

Também foram usados alguns comandos para documentar o estado do sistema, antes de descaracterizá-lo demais:

   11  pacman -Qe > instalados.txt
   23  pacman -Qent > instalados-explicitamente.txt
   45  cat /etc/pacman.d/mirrorlist > mirrorlist.txt

Todos esses arquivos TXT foram parar na “/home” do usuário, — exceto os gerados por “su”, que foram para “/root”, — de onde foram movidos, depois, para a pasta de registro dessa experiência.

Pcurses


Pesquisando pacotes de manipulação de imagens nos repositórios de software com pcurses

Embora instalado logo nas primeiras horas, o pcurses exigiu um pouco mais de leitura, antes de se tornar útil, naquilo que mais fazia falta, — pesquisar os pacotes existentes, para descobrir seus nomes.

O básico, para começar, é:

/ - para iniciar o campo de pesquisa
/n:[string] - para pesquisar nos nomes dos pacotes [Enter]
/c:[string] - para pesquisar nas descrições dos pacotes [Enter]
/nc:[string] - para pesquisar nos nomes e nas descrições [Enter]
- para colocar um pacote na fila (Queue)
Tab - para alternar entre a lista e o Queue
- para remover um pacote da fila
C - esvazia a fila
r - recarrega informações dos pacotes
c - limpa o campo de pesquisa
h - Help (Referência rápida)
q - sair do Pcurses (antes de fechar o Terminal)

kim4 encontrado no pcurses, filtrando pacotes com “menu” (contexto) na descrição

Por enquanto, evitei usá-lo para instalar os pacotes descobertos, — apenas “ver” os nomes, e em seguida instalar por comando, em outra janela do Terminal.

Assim, foram instalados mais 3 pacotes, necessários de imediato:

   95  sudo pacman -S filemanager-actions
   97  sudo pacman -S kim4
  124  sudo pacman -S gnome-screenshot

Menu de contexto adicionado ao Konqueror (e ao Dolphin) pelo kim4

O kim4, — já usado em outras distros (e esquecido na hora do tiro-ao-alvo), — permitiu converter as primeiras 227 Capturas de tela, do formato PNG para JPG, de uma tacada só, — ou seja, sem aquele limite de 200 arquivos, observado no KDE Neon em Setembro 2016.

  • Atualmente, o KDE Spectacle oferece opção de gravar as Capturas em diversos formatos, inclusive JPG. — O histórico no Github dá impressão de que isto apareceu em 15 de Abril. — Desabituado de usá-lo, ainda não havia percebido essa possibilidade em outras distros, nem percebi no primeiro dia com o Arch Linux.

Atalhos para Captura de tela pelo gnome-screenshot

E o gnome-screenshot permitiu substituir o KDE-Spectacle, — passando a gravar Capturas de tela sem notificação visual (dispensável).

Com o pcurses, portanto, tornou-se desnecessário procurar um “gerenciador de software com interface gráfica”.

Discover, pcurses, pacman


7 Jun. 2017 - Após 4 dias, — e sem receber nenhuma “notificação de atualizações” (Plasma Discover), — bastou esbarrar na tecla “1”, dentro do pcurses, para descobrir que havia, sim, 3 atualizações disponíveis.

Tal como veio, o arquivo “/etc/pcurses.conf” especifica alguns atalhos numéricos, — que o “pcurses -h” refere apenas genericamente, como “1 a 0”:

1=@clearfilter,filterupdates
2=@clearfilter,filterinstalled
5=@pacmanrefresh
6=@pacmansync
7=@pacmanremove

Traduzindo:

1 - Exibe (filtra) as atualizações disponíveis

5 - Recarrega as informações dos Repositórios.

6 - Instala os pacotes colocados na fila (Queue).

Além do “pcurses -h”, — pois não tive resultados com “man pcurses”, — vale a pena baixar os arquivos README e CONCEPT do GitHub.

Porém, depois de “aplicar” aquelas 3 atualizações indicadas pelo pcurses, disparei um comando “pacman -Syu”, — só por desconfiança, — e descobri que, na verdade, havia nada menos que outras 65 atualizações disponíveis.

Portanto, — a menos que todas aquelas 65 atualizações tenham surgido no curto intervalo de alguns minutos, — não convém se fiar muito, mesmo no pcurses.

Desmembrando a Ajuda do pacman por “capítulos” (operações)

Diante disso, procurei uma abordagem para começar a me familiarizar melhor com o pacman, item por item, sem submergir num caos de opções embaralhadas:

  162  pacman -h
  198  pacman -h -R > pacman-h-R.txt
  199  pacman -h -S > pacman-h-S.txt
  200  pacman -h -D > pacman-h-D.txt
  201  pacman -h -F > pacman-h-F.txt
  202  pacman -h -Q > pacman-h-Q.txt
  203  pacman -h -T > pacman-h-T.txt
  204  pacman -h -U > pacman-h-U.txt

Arch Linux segundo KInfocenter, após upgrade e Restart

••• 8 Jun. 2017 - A hipótese de 65 pacotes atualizáveis surgidos de uma hora para outra não deve ser descartada sem exame.

No dia seguinte (8 Jun.), — ainda sem nenhuma notificação do Plasma Discover, — um comando “pacman -Syu” começou por fazer uma perguntinha boba. “Substituir wxgtk por extra/wxgtk2?”

Respondi que sim (sem exigir a presença de um advogado), e se apresentou um upgrade de 255 pacotes, — incluindo atualização de Kernel para linux-lts-4.9.31, — que levou 14 minutos (1,3 MiB/s).

Com isso, a “versão da Qt” passou de 5.8 para 5.9, os aplicativos passaram de 17.04.1-2 para 17.04.2-1, — e Gwenview deixou de fechar teclando Esc, embora a configuração desse atalho continue lá, e até tenha sido refeita. — Foi restabelecida sua função original (Modo de navegação), ainda não encontrada em parte alguma das configurações, para desabilitar.

  • Essa mudança de comportamento do Gwenview também ocorreu depois, no KDE Neon, após atualização dos aplicativos de 17.04.1 para 17.04.2, mantendo Qt 5.7.

Num primeiro momento, o painel Informações (F11) do Dolphin também parou de exibir visualização das imagens, — mas isso voltou a funcionar normalmente, após reiniciar (Restart), já com o Grub atualizado para o novo Kernel.

Habilitando a partição Swap


Criação da partição Swap e edição do arquivo /etc/fstab

Uma das poucas “falhas” observadas durante a instalação, é que o Revenge Installer não apresentou sdc11 entre as partições existentes, para selecionar como Swap.

De qualquer modo, criar, habilitar ou desabilitar partições Swap não é nenhum problema espinhoso.

A partição Swap foi habilitada mais tarde, — no Terminal, como root (“history” com outra numeração), — e a própria resposta do comando já forneceu o identificador UUID, a ser usado no arquivo /etc/fstab.

    6  mkswap /dev/sdc11
    7  swapon /dev/sdc11

Ainda sem encontrar “modo root” do Dolphin ou Krusader, acabei descobrindo que basta clicar no /etc/fstab pelo Dolphin-usuário, editar normalmente (como se fosse dono) e mandar salvar, — então, é pedida senha, e tudo é só alegria.

  • Ainda não tinha percebido essa facilidade, em outras distros. — Já vi não abrir, ou abrir mas não salvar — Falta verificar se isso está mudando [ver “Restrições ao modo root”, no Comparativo de sistemas].

Montagem automática de partições adicionais


Configurações do sistema → Dispositivos removíveis

Pelas configurações originais dessa instalação do Arch Linux, a montagem de partições adicionais, — clicando pelo Dolphin, por exemplo, — exigia senha.

Portanto, a mera marcação nas Configurações do sistema → Dispositivos removíveis, não era suficiente para fazer a montagem automática de partições adicionais, no início de cada sessão.

Autorização para montagem de partições adicionais, sem pedir senha

Essa dificuldade não foi encontrada no Manjaro, — mas foi encontrada no Antergos, também baseado no Arch Linux. — Portanto, valia a pena verificar se a solução usada no Antergos resolveria a dificuldade aqui, também.

Em resumo, tratava-se de criar um arquivo “/etc/polkit-1/rules.d/99-udisks2.rules”, e colar nele o seguinte conteúdo, — para habilitar a montagem de partições sem a exigência da senha de Root:

// Allow udisks2 to mount devices without authentication
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.udisks2.filesystem-mount-system" || action.id == "org.freedesktop.udisks2.filesystem-mount" || action.id == "org.freedesktop.udisks2.filesystem-mount-system-internal") { return polkit.Result.YES; } });

Ainda sem encontrar “modo root” do Dolphin ou Krusader, o mais simples foi usar o openSUSE para fazer essa operação.

Início do Arch Linux com as partições adicionais montadas automaticamente

Depois disso, o Arch Linux finalmente carregou com todas as partições adicionais automaticamente montadas no início da sessão.

Com o Dolphin (3 abas), KSysguard, Xsensors, Conky, +20 partições montadas, — e já sem Baloo_file, — o sistema carregou em 44 segundos, ocupando 0,40 GiB RAM (segundo KSysguard) ou 565 MiB RAM (segundo o Conky).

Claro que essa alteração é um “quebra-galho”, — provavelmente, inaceitável para um administrador de sistema, do ponto de vista da segurança etc. — “Você que está em casa, nos assistindo, não tente fazer isto sem a supervisão de um adulto irresponsável”.

Baloo_file, Akonadi, PIM


Baloo_file fechou sozinho, ao desabilitar a “Pesquisa de Arquivos”

7 Jun. 2017 - Após 4 dias trabalhando no Arch Linux, ainda não houve necessidade de desinstalar o KDE-PIM — Personal Information Manager.

A única providência foi desabilitar a “Pesquisa de arquivos”:

Menu K → Configurações do sistema → Pesquisa → [_] Ativar a Pesquisa de arquivos

Imediatamente, o “baloo_file” desapareceu da Tabela de processos do KSysguard.

KOrganizer na Tabela de processos do KSysguard

Até o momento, a Tabela de processos do KSysguard não indicou atividade de nenhum banco de dados (MySQL, MariaDB), Akonadi ou PIM, — com exceção do “korgac” (KOrganizer).

Ao “Sair” do KOrganizer, — pelo Menu de contexto sobre as Notificações, — esse Processo também fecha e desaparece do KSysguard. Mas volta na sessão seguinte, a menos que seja desabilitado de vez.

Montagem de um comando para remoção do KDE-PIM

9 Jun. 2017 (0:11 ~ 1:08) - Praticando 1 hora de exercício de remoção do PIM, — pelo método construtivista / lapidador:

  • Filtrar por grupo (/g:kdepim), no pcurses
  • Examinar os pacotes
  • Copiar seus nomes para um “bloco de notas”
  • Montar o comando de remoção
  • Testar o comando de remoção
  • [while not “Ufa…!”]
  • Receber avisos sobre más consequências colaterais
  • Retirar do comando 1 ou 2 pacotes causadores de encrenca
  • Testar de novo o comando de remoção
  • [da capo]
  • Ufa…!

pacman -Rs [PIM packages] … Ufa!

A experiência demonstrou que o pacman é (pelo menos) tão inteligente quanto o apt, — e que é possível fazer todas essas operações de filtragem, exame, “montagem de comando”, teste, correção, aplicação final, — em uma fração desse tempo, pelo Synaptic.

# pacman -Rs kmail kaddressbook kontact korganizer knotes kalarm akonadi-calendar-tools akonadi-import-wizard akonadiconsole akregator

Pacotes (17) kalarmcal-17.04.2-1 kdav-17.04.2-1 kdepim-runtime-17.04.2-1 kontactinterface-17.04.2-1 libkolab-1.0.2-3 libkolabxml-1.1.6-4 xerces-c-3.1.4-1 akonadi-calendar-tools-17.04.2-1 akonadi-import-wizard-17.04.2-1 akonadiconsole-17.04.2-1 akregator-17.04.2-1 kaddressbook-17.04.2-1 kalarm-17.04.2-1 kmail-17.04.2-1 knotes-17.04.2-1 kontact-17.04.2-1 korganizer-17.04.2-1

Tamanho total removido: 78,68 MiB

Ainda que veja 1.000 páginas ensinando um comando, é sempre bom conferir o significado:

pacman -h -R

uso: pacman {-R --remove} [opções] <pacote(s)>

         -s, --recursive        remove as dependências desnecessárias

Devido ao método trabalhoso, a experiência ficou nisso, — 3 comandos “aprovados”, 56 pacotes removidos, — até descobrir se, por acaso, não haverá um “meta-pacote”, cuja remoção produza o “serviço completo”.

Não houve impacto no uso de recursos, — “baloo_file” (Pesquisa de arquivos) já estava desativado, e o resto não veio programado para entrar em operação sem ser chamado, — mas serviu para algumas coisas:

  • Ver como as coisas funcionam
  • Eliminar uma série de notificadores, gatilhos e menus
  • Reduzir as chances de “chamar” o PIM por distração

Limpeza do cache de pacotes


Limpeza do cache de pacotes desinstalados

Acostumado a simplesmente configurar o Synaptic para esvaziar o cache de pacotes baixados (após serem instalados), já estava incomodado de ver o Arch Linux, — um sistema “enxuto”, instalado 6 dias antes, e ainda quase sem acréscimos, — ocupar mais espaço do que o Kubuntu, com mais de 1 ano, e lotado de aplicativos.

O primeiro comando visa apenas otimizar as informações acumuladas sobre os pacotes, — agilizando o acesso à base de dados, verificação de dependências etc., — e não produziu nenhum efeito visível no espaço ocupado em disco:

# pacman-optimize

O segundo comando começa por eliminar informações de pacotes desinstalados, antes de otimizar, — e consta que não é isento de riscos, — mas liberou quase 1 GiB na partição do sistema:

# pacman -Sc && pacman-optimize

Nada que se diga, “esvaziou a partição”, mas é instrutivo saber o motivo de tanto espaço ocupado, — são guardadas sucessivas versões dos pacotes instalados, facilitando recuar de algum mau passo, — e ter uma ideia de como se pode fazer isso (ou limitar o número de versões guardadas), e assim por diante.

Quadro comparativo


Comparativo das funcionalidades já obtidas nos diversos sistemas Linux instalados

O Arch Linux KDE, — com o Chromium incorporado durante a instalação, — desde o primeiro instante mostrou incomum leveza, maciez e velocidade para navegar em “Páginas” do Facebook (não me refiro ao Feed, Perfis, Grupos).

Após 6 dias, ainda não “hesitou” sequer uma fração de segundo, a qualquer rolagem vertical, — nem sofreu um único momento de uso abusivo de CPU. — Enfrenta essa tarefa, melhor do que o Linux Mint 18 “Sarah” KDE; e a impressão subjetiva é de que enfrenta isso um pouco melhor, até, do que o Kubuntu ou o KDE Neon.

Ao mesmo tempo, ainda não deixou de exibir nenhum tipo de vídeo do Facebook ou do Youtube.

Como a navegação em “Páginas” do Facebook é necessária pelo menos 3 ou 4 vezes ao dia, — e nessas horas, é chato não poder assistir alguns dos vídeos que aparecem, — a galhardia demonstrada pelo Arch Linux + Chromium dispensa alternar para outra distro, durante vários dias seguidos.

Por comparação, o Manjaro, — depois de 5 meses, — segue no Grupo B, dos que só fazem uma coisa, ou só a outra.

  • Obs.: - Outros portais e sites conseguem, sim, provocar uso abusivo de CPU e causar lentidão no Chromium / Arch Linux. — No 4º dia, isto ocorreu ao visitar uma página do Estadão (O Estado de S. Paulo). Porém não tenho necessidade de visitá-lo, e bastou fechar aquela aba do Chromium. — Os sites 24/7 e Diário do Centro do Mundo (entre outros) também se vêm destacando como grandes consumidores de CPU, talvez pelo abuso de anúncios invasivos, porém não chegam a travar o Chromium durante longos segundos.

Longas demoras para digitar uma palavra, ou colar um link

27 Jun. 2017 - Neste momento, a navegação em “Páginas” do Facebook tornou-se totalmente impraticável no Arch Linux. — A dificuldade começou há alguns dias. — Hoje mostrou-se quase absoluta.

CPU a todo vapor, e longa demora para acessar o link da postagem

Há demoras intermináveis para tudo, — liberar o cursor na área de texto, — colar um link, — eliminar 2 de 3 fotos apresentadas na “prévia” da postagem, — publicar, — acessar o link da postagem (data / hora), — até sair da “Página”.

Abuso de CPU desaba quando se abre a postagem fora da “Página” Facebook

O abuso de CPU só termina quando, finalmente, você consegue sair da “Página”, — clicando na data / hora da postagem, para vê-la em separado.

Print    Demora  Evento
  
10:42:14         Escreva algo
10:42:34    20s  “Boituva” - 20 segundos
10:42:52    18s  Colar Link - 18 segundos
10:43:00    08s  Buscando prévia: + 8 segundos
10:43:15    15s  Exibe prévia: + 15 segundos
10:44:13    58s  Elimina 1 de 3 fotos: + 58 segundos
10:44:56    43s  Elimina 1 de 2 fotos: + 43 segundos
10:45:45    49s  Selecionar texto: + 49 segundos
10:45:56    11s  Copiar texto: + 11 segundos
10:46:37    41s  Publicar: + 41 segundos
10:48:47  2m10s  Copiar Link da postagem: + 2 minutos 10 segundos
10:49:08    21s  Copiar Link: + 21 segundos
10:49:20    12s  Copiar Link: + 12 segundos
10:49:58    38s  Copiar Link: + 38 segundos
10:50:06    08s  Página parou de responder: + 8 segundos
10:50:12    06s  Abre postagem fora da “Página” Facebook … Ufa!
  
          7m58s  Tempo total da postagem + cópia do Link

Com isso, a postagem em uma “Página” chega a tomar 8 minutos, — a menos que você deixe para copiar o Texto + Link da postagem depois de conseguir sair da “Página”. — Estratégia sugerida por esta análise a posteriori.

Esta guinada percebida no Arch Linux, — depois de vários dias de ótimo desempenho, — desperta a ideia de que tudo é muito “líquido”. Não se passa 1 dia, sem que o Facebook introduza mudanças em alguns de seus milhares de “códigos”, — e o sistema que hoje enfrenta maravilhosamente bem pode se tornar o mais lento amanhã.

Para comparação, bastaram 7 minutos para localizar e visitar 16 Grupos, — com o cuidado de selecionar apenas aqueles, em cujo tema a postagem poderia se enquadrar, — e fazer 16 compartilhamentos.

Fica patente que, — se você procura 10 “Páginas” para se manter informado, — poderia gastar a manhã inteira, apenas tentando percorrê-las, rolando até a última postagem das últimas 12 horas.

A alternativa é ficar somente no “Feed de notícias”, — onde você não tem nenhum controle sobre o que vai ver ou deixar de ver, — e ter fé em que, se o mundo acabar, talvez a notícia lhe seja exibida dentro de 1 ou 2 dias.

Wine e GoogleEarth parecem pedir um adiamento, até aprender mais, — mas, como são de uso menos frequente, justifica-se alternar para o Kubuntu ou Linux Mint, quando necessário.

Limpeza geral


Eliminação do Fedora, Manjaro, Antergos e Sabayon, com GParted no Knoppix

••• 8 Jun. 2017 - Os ótimos resultados obtidos no Arch Linux, — muito mais promissores do que os obtidos, até agora, no Manjaro e no Antergos (ponto de vista pessoal), — levaram a encerrar (por enquanto) a experiência com estes últimos.

Também foi encerrada a experiência com o Fedora, com o Sabayon, e com uma segunda instalação do Mageia (Mageia “B”).

Em resumo, foram formatadas 10 partições, — Raiz e Home dessas 5 instalações, — usando o GParted do Knoppix personalizado, com direito ao Chromium, para conferir as anotações.

Correção do Grub gerado pelo Mageia, para carregar o Arch Linux

A eliminação do Manjaro facilitou bastante a correção manual do Grub, — sob controle do Mageia (MBR do sda). — Agora, basta fazer uma substituição global para todas as entradas referentes ao Arch Linux, e outra para o KDE Neon.

Funcionalidades já obtidas nos sistemas Linux remanescentes

Com isso, fica mais fácil aprofundar o conhecimento dos 7 sistemas restantes, — bem como a manutenção e as configurações ainda não encontradas, — além de gastar menos tempo, a cada vez que um sistema recebe atualização de Kernel.

Revenge Installer



Enfrentar a instalação do Arch Linux, — ou a do TrueOS, — era tudo o que não estava no programa. Pelo menos, não em menos de 6 ou 12 meses, no mínimo.

No entanto, uma postagem de Swapnil Bhartiya, — Why you should run Arch Linux on your system, — recebeu um comentário com link para o projeto do Revenge Installer, cujo vídeo (acima) esclareceu mais do que todas as leituras explicativas, ilustradas por inúmeras Capturas de tela.

Procurando saber mais, encontrei o artigo Installing Arch Linux Using Revenge Graphical Installer, — por sinal, com link para um artigo sobre outro instalador gráfico, Arch Anywhere – An easy way to install a fully custom Arch Linux system. — De repente, havia mais facilidades do que dificuldades.

Terminada a instalação, no dia seguinte foi anunciada uma nova versão do Revenge Installer.

Wallpaper


Maré alta em uma rua do centro histórico de Parati

Maré alta em uma rua do centro histórico de Parati, by Leandro Neumann Ciuffo, 2011.

“A vila, diziam, tinha sido construída obedecendo a um engenhoso plano que compreendia o uso da maré para a limpeza das ruas. Com a enchente o arruamento alagava-se, e a vazante levava a sujeira para o mar, lavando as pedras” (O Retrato do Rei, Ana Miranda).

A imagem foi apenas rotacionada (-2,20°) no Gimp, para colocar na vertical as portas e janelas da parte central da foto. — Isso já tinha sido feito na sessão Live de reinstalação do Linux Mint 18 “Sarah” KDE (29 Abr. 2017).

Agora, a imagem foi cortada para restabelecer o formato retangular; redimensionada para 1024 pixels de altura; e as laterais cortadas (crop) em 1280 pixels de largura.

______________
Relato publicado inicialmente à 0:15 de 4 Jun. 2017 e desenvolvido até 7 Jun., no Arch Linux KDE.
••• Anotações adicionais em 8 Jun. 2017.
••• Anotações adicionais em 27 Jun. 2017.

— … ≠ • ≠ … —

Não-debians