Grub do Mageia, com seleção automática da última distro Linux escolhida
A instalação de vários sistemas em paralelo (dualboot, ou multiboot) criou uma situação em que já não basta eu usar o Grub para escolher qual Linux rodar. — Agora, eu também preciso escolher qual distro deve controlar o Grub, — e quais não devem interferir.
Isso, porque existem particularidades no Grub de algumas distros que o impedem de gerar as entradas corretas, no Menu de inicialização, para algumas das outras distros.
Havendo vários HDDs em hardware Bios (legacy) / MBR, também é uma boa precaução ter mais de um Grub, — controlados por diferentes distros Linux. — Em caso de emergência, basta configurar a Bios para dar Boot por outro HDD.
2020 - Estas anotações continuam válidas para meu novo hardware UEFI / GPT, com alguns detalhes adicionais.
Longo confinamento a 3 distros — de um mesmo “tronco”, — Debian, Kubuntu e Linux Mint
Enquanto me restringi ao Kubuntu (sistema “principal”), e Debian ou Linux Mint (como “alternativo”), o Grub não apresentou dificuldades. — Ubuntu baseia-se no Debian; Linux Mint baseia-se no Ubuntu — e todos se entendem.
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 — que hoje eu não recomendo.
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, em hardware Bios (legacy) / MBR:
1) Uma “chamada” minúscula no Master Boot Record (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 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.
Durante anos, achei que a “chamada” do Grub tinha de ser gravada no MBR do primeiro HDD. — Enquanto eu tinha apenas Kubuntu, Mint e Debian, isso não causava problemas, — era até divertido, ver uma distro tomar da outra o controle do Grub.
Nesse caso, bastava escolher minha distro “principal”, e executar o comando “sudo grub-install /dev/sda”. — Ela retomava o controle do Grub, e tudo voltava ao normal.
Fatos espinhosos
Uma deficiência na última linha do Grub do Mint impede o carregamento do Manjaro
Em 2017, com a instalação de várias distros “não-Debian”, surgiram casos ou situações em que o Grub de alguns sistemas não consegue gerar entradas capazes de carregar alguma outra distro.
A priori, nada a ver com o Grub, em si, — mas com a estrutura de umas e outras distros. — Quem sabe, por falta de alguns pacotes aqui e ali.
Caso 1 - Arch (intel-ucode)
Falha ao carregar o Manjaro a partir do Grub gerado pelo Linux Mint
Um caso bastante discutido é o do Arch e alguns de seus “derivados” (como o Manjaro).
O Grub de outros Linux costumava gerar entradas com uma linha assim:
initrd /boot/intel-ucode.img
mas, para funcionar, tais linhas deveriam indicar a localização do initramfs:
onde “XXXXXX” pode ser “linux”, “linux-lts”, “linux-zen” etc. — Se houver apenas um, basta uma busca-e-troca global, com esse acréscimo.
No Manjaro, — com 2 Kernel diferentes (opção minha), — “XXXXXX” exigia substituição manual (caso-a-caso), nas entradas do /boot/grub/grub.cfg — e na época achei mais simples eliminar o Manjaro, para agilizar a edição do arquivo, após cada atualização do Grub do Mageia:
Se esta fosse a única dificuldade, o Grub do próprio Arch (ou do Manjaro) seria o candidato natural, para ser o meu Menu de inicialização, — dispensando 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 não encontrei nenhum indício de que alguma dessas “receitas” tenha alcançado ampla aceitação.
Enfim, o Arch instalado pelo Anywhere não apresentou esse problema. — Carregava pelo Grub de qualquer outra distro, sem a menor dificuldade. — Mas eu preferi manter o Arch instalado pelo Revenge (atual Zen Installer).
Edit (2020) - Desde meados de 2019 (pelo menos), o Grub do openSUSE Tumbleweed se mostrou capaz de gerar as entradas completas para o Arch.
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, — parecia fora do alcance do Grub de (quase) todas as outras distros que já instalei.
A exceção era o Grub do Mageia, — único que conseguia carregar o openSUSE, — e isso mostra que não se trata de “missão impossível”, desde que eu descubra o segredo.
Esse problema foi causado por uma decisão minha — de não criar uma partição /boot (ext4 “tradicional”) separada da partição-raiz (BtrFS).
É claro que o Menu de inicialização gerado pelo Grub do próprio openSUSE consegue carregá-lo, — e se esta fosse a única questão, bastaria eu adotá-lo.
Porém, na época, não encontrei meio de ele “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 era o mesmo: — Por eu não ter criado uma partição /boot (ext4 “tradicional”), separada da partição de sistema (BtrFS).
É que o Grub não gravava em partição BtrFS (*), — até o openSUSE ser carregado. — Portanto, durante o Boot, não podia salvar a opção escolhida, para lembrar na próxima inicialização.
(*) Isso mudou. Tempos depois, o Grub passou a lidar com BtrFS.
Usá-lo no dia-a-dia significaria ficar parado (e atento), na frente do computador, — ou carregaria sempre openSUSE, ao final da contagem regressiva.
Edit (2020) - No novo hardware UEFI / GPT, adotei o Grub do openSUSE como meu Menu de inicialização, pois agora, ele salva e “lembra” a última distro que escolhi. — Porém, a resposta do Grub (setas para cima e para baixo) sempre foi lenta, no openSUSE — até que movi o Tema do Grub para a partição /home (em XFS).
Caso 3 - 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 mais um caso espinhoso.
Nas linhas onde o Grub do Mageia, — entre outros, — gerava estes parâmetros:
linux /boot/vmlinuz-generic-4.4.75 root=/dev/sdc2
eu precisava substituir “generic” por “huge”:
linux /boot/vmlinuz-huge-4.4.75 root=/dev/sdc2
Na forma original, o Boot do Slackware emitia 2 mensagens de “panic” e terminava em uma mensagem de “end trace”, — palavras-chaves que me levaram a encontrar esta solução.
Isso, porque o Slackware usava o Lilo, e não gerava o arquivo /boot/grub/grub.cfg, para ser lido pelo Grub do Mageia (ou do openSUSE). — Afinal, percebi que bastava instalar o Grub no Slackware, e gerar o /boot/grub/grub.cfg, para o Grub das outras distros passar a gerar as entradas corretas.
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 após 2 ou 3 “desastres” meio chatos, — escolhi o Grub do Mageia como o mais indicado, para aquele hardware Bios (Legacy) / MBR, com aquele conjunto de distros em dualboot (ou multiboot).
Os principais motivos:
1) O Grub do Mageia era o único que conseguia carregar o openSUSE, — exceto o Grub do próprio openSUSE
2) Se sua “chamada” no MBR fosse apagada, o Mageia podia ser carregado pelo Grub de qualquer outra distro, — e em 1 minuto, gravar novamente sua “chamada” no MBR.
3) O Grub do Mageia “lembrava” perfeitamente qual o último sistema escolhido, — e o carregava automaticamente, ao final da contagem regressiva, — o que é muito prático, para usar uma mesma distro Linux durante vários dias seguidos.
O resto, — ter de corrigir “manualmente” as entradas do Arch, — também aconteceria com o Grub de qualquer outra distro.
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, — copiei para o Mageia o tema do Grub do openSUSE, cuja personalização já ia bem avançada.
Alterei 2 arquivos e 1 pasta, — destacados nestas seções da árvore do sistema, — nos dias 20 e 21 Maio 2017:
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, me levaram a reavaliar velhas crenças — e a examinar as observações feitas ao longo dos anos, naquele hardware Bios (Legacy) / MBR.
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 que bastou para re-gravar sua “chamada” no MBR do 1º HDD (sda), — em lugar da “chamada” para o Grub do Mageia. — Pior. Um Menu de inicialização contendo só Kubuntu.
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 eu 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” para re-detectar as outras distros
Carregar o Mageia pelo Menu de inicialização (atualizado) do Kubuntu
Re-gravar a “chamada” do Grub do Mageia em sda
Mas minhas ideias, fatos, causas etc. estavam embaralhados, — e passava da meia-noite, quando todos os gatos parecem cachorros pardos, rosnando.
Tentei tudo o que não precisava tentar, — Live Arch Anywhere (como Rescue disk), 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 me obrigou a revisar o assunto de A a Z, documentar configurações e ferramentas usadas em cada distro etc.
Ficou claro que eu 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 do openSUSE no sdb); — só faltava descobrir como.
O comando “grub-install /dev/sdc”, na verdade faz apenas uma gravação isolada, — sem evitar que continuem gravando em sda, no futuro.
Isso ficou ainda 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 eu acabar com aquela chatice, de uma vez por todas.
Reorganização do Grub
Como havia 7 sistemas instalados, — e apenas 3 HDDs, — eu precisava 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 sda ← Grub do Mageia (sda2)
MBR do sdb ← Grub do openSUSE (sdb2)
MBR do sdc ← Grub do Debian, Kubuntu, Mint, Neon, Arch
Associar o Grub do Mageia e do openSUSE ao MBR dos respectivos HDDs tornaria cada um deles à prova de “falhas no outro HDD”.
Os demais 5 sistemas se revezariam 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 meu “último salva-vidas” dependente de apenas 1 distro.
Poderia ficar excessivamente desatualizado, — caso aquela distro não atualizasse seu Kernel com frequência, — ao passo que 5 distros em “corrida de revezamento” garantiriam atualizações mais frequentes do “terceiro Grub”.
Reconfiguração do Grub
Usando “dpkg-reconfigure grub-pc” para redefinir qual MBR será gravada por cada Grub
Finalmente, encontrei o caminho para fazer isso, — no Debian & derivados, — 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 deveria gravar sua “chamada”.
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 própria partição onde cada sistema está instalado. — Esta última opção não é recomendada, e nem sei como se usa.
Simplesmente marquei o Kubuntu, o KDE Neon, o Mint KDE e o Debian KDE para gravarem suas “chamadas” do Grub sempre no sdc.
Configuração do Grub no Mageia Control Center
No Mageia, foi ainda mais fácil configurar o “dispositivo de boot” (sda), graças ao Mageia Control Center (MCC).
Infelizmente, não encontro nenhum registro de como consegui configurar o openSUSE para gravar a “chamada” do Grub no MBR do sdb. — Só sei que consegui.
Não descobri como fazer essa reconfiguração no Arch Linux — pois eu ainda não tinha aprendido a instalar o Arch “na unha“.
Midnight Commander (mc)
Verificação do /boot/grub2/grub.cfg (data, hora) e edição pelo Midnight Commander
Ctrl-Shift-V para colar nos campos de busca e troca global
Daí a escolha do Midnight Commander (mc).
Busca e troca global no editor de textos do Midnight Commander
É 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?
_________
Originalmente publicado em 29 Jun. 2017, e desenvolvido até 2 Jul. 2017.
••• Adicionadas notas sobre o Slackware em 15 Jul. 2017.
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”.
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 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.
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.
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:
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”.
Arch Linux KDE após instalação (gráfica) pelo Revenge Installer
Instalei o Arch Linux 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, embora não parecesse tão “árduo”, e nem tão “assustador” quanto o Arch.
Ao instalar e usar o Manjaro, — e depois o Antergos, — não aprendi quase nada, que tenha sido útil nestes 6 dias. — Além disso, 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 fiz a instalação 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
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
Mirrors & mirrors
Quadro comparativo
Limpeza geral
Revenge Installer
Quase 2 anos depois
Documentação e cronometragem
Wallpaper [créditos]
Não-debians [Menu]
Download, gravação e boot
Verificação da imagem ISO do Revenge Installer
Baixei a imagem “revenge_installer-2017.03-x86_64.iso” da página do Revenge Installer, e verifiquei 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 fiz Capturas de tela, — nem sei se existe esse recurso. — Apenas fiz fotos 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.
Fui 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
Formatei as partições Linux9 (sdc3) e Home9 (sdc7), — para eliminar até mesmo as configurações do Kubuntu Zesty Zapus, que testei desde Outubro.
Pretendia usar também Swap9 (sdc11), mas não precisava 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 que adotei, — e resumo listas longas 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, passei o controle do MBR do sdb 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).
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, abri 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.
Infelizmente, não era possível usar “busca e troca global”, — pois afetaria as entradas para o Manjaro, — que precisam do mesmo acréscimo, porém com 2 Kernel diferentes:
Portanto, a busca & substituição teve de ser conduzida “caso a caso”, — examinar visualmente cada ocorrência, — e confirmar quando se tratava do Arch Linux.
• Seis dias depois, eliminei o Manjaro, o que simplificou esta correção manual, — necessária após cada atualização do Grub (controlado pelo Mageia).
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, configurei 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, meu 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”.
Ainda não desinstalei o Plasma Discover, 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, instalei 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, me vi na situação oposta, de precisar completar manualmente o KDE (ao invés de remover excessos). — Várias coisas ainda não funcionam nele: 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 se transformasse num castigo, logo no início, — tipo: “vá para o cantinho-do-estudo e só saia de lá depois de aprender tudo”, — pratiquei 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 acertei nada menos que 10 pacotess em 19 tentativas:
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 usei alguns comandos para documentar o estado do sistema, antes de descaracterizá-lo demais:
Todos esses arquivos TXT foram parar na “/home” do usuário, — exceto os gerados por “su”, que foram para “/root”.
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 copio os nomes, para usar com o pacman, em outra janela do Terminal.
Assim, instalei mais 3 pacotes, necessários de imediato:
Menu de contexto adicionado ao Konqueror (e ao Dolphin) pelo kim4
O kim4, — já usado em outras distros, — 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, observe o grau de compactaçãoado no KDE Neon em Setembro 2016.
Atualmente, o KDE Spectacle oferece opção de gravar as Capturas em diversos formatos, inclusive JPG (e o grau de compactação). — O histórico no Github dá impressão de que essa opção apareceu em 15 de Abril. — Desabituado de usá-lo, eu 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 eu 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”:
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 me 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:
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 eu tenha tentado reconfigurar esse atalho.
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).
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 é espinhoso.
Habilitei mais tarde a partição Swap, — 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.
Eu 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.
Autorização para montagem de partições adicionais, sem pedir senha
Não encontrei essa dificuldade no Manjaro, — mas encontrei 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, achei mais simples 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).
Talvez essa alteração seja um “quebra-galho”, — inaceitável para um administrador de sistema, do ponto de vista da segurança etc. — Não sei se é.
“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”
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, — mas no Synaptic todas essas operações de filtragem, exame, “montagem de comando”, teste, correção, aplicação final, poderiam ser feitas numa fração desse tempo.
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 acionar 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.
Mirrors & mirrors
Download de atualizações em velocidade da idade da pedra lascada
7 Abr. 2018 - Depois de 10 meses instalado, um dia a velocidade de download dos pacotes caiu abaixo da pré-histórica “linha discada”.
Uma atualização de apenas 43 pacotes (download: 286 MiB) tomou toda a noite de um Sábado, — das 18:25 até depois das 23:00 (pelo menos), — com velocidades na faixa de 10 K/s a 20 K/s, salvo raros momentos.
Arquivo /etc/pacman.d/mirrorlist gerado durante a instalação do Arch Linux pelo Revenge
Um exame do arquivo /etc/pacman.d/mirrorlist mostrou que ainda era o mesmo gerado durante a instalação, às 16:22 GMT de 3 Jun. 2017.
Esse arquivo continha 50 mirrors do mundo inteiro, — todos habilitados, ou seja, sem “#” no início de cada linha, — e nenhum do Brasil.
Usufruir de um pool de mirrors ao redor do mundo inteiro é ótimo, — se lembrarmos que o PCLinuxOS, por exemplo, recomenda expressamente jamais habilitar mais do que 1 único mirror, pois diferentes servidores podem ser atualizados em horários diferentes, com risco de misturar diferentes versões dos pacotes e suas dependências, — mas neste caso, em particular, após 10 meses o pool acabou deixando de dar certo.
Ou todos os 50 mirrors engasgaram ao mesmo tempo, — no dia 7, e de novo no dia 16 Abr. 2018, — ou… sei lá.
A documentação do Arch Linux oferece graduação, mestrado e doutorado, a partir de páginas como estas:
a absoluta liberdade de escolher mirrors do mundo inteiro ou só do Brasil
a dica de habilitar a opção “Use mirror status”
o lembrete de substituir “$arch” por “i686” ou “x86_64”, conforme o caso
Pacman Mirrorlist Generator
Após escolher somente espelhos do Brasil, — eliminar um deles, que não cumpriu o status, — e optar pelo uso de 1 único, para teste, — o resultado foi um arquivo bem mais enxuto:
##
## Arch Linux repository mirrorlist
## Filtered by mirror score from mirror status page
## Generated on 2018-04-16
##
## Brazil
# Server = http://pet.inf.ufsc.br/mirrors/archlinux/$repo/os/x86_64
# Server = http://br.mirror.archlinux-br.org/$repo/os/x86_64
Server = http://archlinux.c3sl.ufpr.br/$repo/os/x86_64
# Server = http://mirror.ufam.edu.br/archlinux/$repo/os/x86_64
# Server = http://linorg.usp.br/archlinux/$repo/os/x86_64
pacman -Syu de volta à velocidade máxima da conexão local
Depois disso, o pacman -Syu voltou a funcionar na velocidade máxima permitida pela conexão de “10 megas“ (1,3 MiB/s).
Examinando agora o backup do antigo mirrorlist, verifico que não incluía a UFPR. — Na verdade, não incluía nenhum espelho localizado no Brasil.
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 têm destacado 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.
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 1 ou 2 dias depois.
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 encerrei a experiência com o Fedora, com o Sabayon, e com uma segunda instalação do Mageia (Mageia “B”).
Em resumo, formatei 10 partições, — Raiz e Home dessas 5 distros, — 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.
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 do LFS, Gentoo, TrueOS, — era tudo o que não estava na minha programação. 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.
Abril de 2019 - Faltando 60 dias para completar 2 anos da instalação do Arch (by Revenge), algumas constatações merecem registro:
1) Arch Linux é a distro que menos deu problemas, entre as 20+ instaladas até hoje, — o que é “uma pena”, pois não dá nenhum pretexto para instalar de novo. 😕
2) Em meados de 2017, instalar KDE “não-completo” ainda parecia um tanto quanto problemático, — e por isso, não hesitei em remover a 2ª instalação (Arch Anywhere). — Hoje, após várias experiências malucas, isso já não assusta. Sim, é “uma pena”, o Arch não dar nenhum pretexto para reinstalar.
3) Só tenho usado o pcurses de raro em raro, — para agilizar a verificação dos pacotes instalados, ou de “quais existem”. — Ao invés de lamentar a falta de um aplicativo GUI, acabei fazendo o caminho inverso em outras distros (openSUSE, Mageia, Sabayon), nas quais troquei o aplicativo GUI pelos comandos.
4) Algumas versões mais tarde, o Gwenview voltou a aceitar “Esc” para fechar, — tal como nas versões mais antigas. — O problema ficou restrito a 2 ou 3 distros que mantêm versões intermediárias.
5) No início de 2019, as dificuldades com “Páginas” do Facebook desapareceram de quase todas as distros (exceto Debian), — independente do Kernel de cada uma. — Como o Slackware se manteve inalterado nos 3 meses anteriores, a única hipótese que resta, é que a melhoria ocorreu nos códigos do próprio Facebook.
6) O uso do uBlock em todas as distros eliminou 99% dos problemas de uso abusivo de CPU por anúncios (inclusive em vídeo) nos grandes portais.
7) Com o tempo, deixou de ter importância, ter ou não ter um “Gerenciador de arquivos (GUI) em modo Root”. — Uma parte das necessidades foi suprida pelo Midnight-Commander (mc), — e outra parte, pelo Kate / KWrite, que pede senha ao salvar arquivos fora da permissão do usuário.
8) O Konqueror também acabou sendo cada vez menos utilizado, — em parte, pela integração de recursos (como converter PNG em JPEG) ao Dolphin, — e em parte, pelo uso do KFind e do FileLight em separado.
9) A velha versão do CorelDraw funcionou perfeitamente, ainda em Agosto 2017. — Levou mais 2 meses para descobrir que o segredo para rodar o velho Dreamweaver era Paciência: — esperar das 17:40 até 19:50, em Outubro daquele ano, para abrir pela primeira vez. — Depois disso, abre em poucos segundos.
10) GoogleEarth saiu do Quadro Comparativo pelo triste motivo de que aquela versão deixou de ser aceita, nas poucas distros em que conseguia rodar, — KDE Neon, Kubuntu, Mint 18 (todas 16.04 Xenial). — A menos que adote uma placa de vídeo, o mais simples será utilizar Marble; e/ou recursos a serem pesquisados no OsGeoLive, e transplantados para as demais distros, na medida do possível.
Tudo isso, — além do aprendizado lento, gradual e seguro, — “limpou” a maior parte das dificuldades que tinha com distros “não-buntu”, há 2 anos.
Às vezes, me surpreendo de passar semanas sem usar o KDE Neon (agora, 18.04 Bionic Beaver), Kubuntu 16.04 ou Mint KDE 18, — que eram meus “salva-vidas”, há menos de 2 anos.
Pelo visto, a estratégia de instalar distros e mantê-las por longo tempo, — de modo a “ver” como são, a médio e longo prazo, — foi uma abordagem mais prática do que ficar pulando de distro em distro, ou fazer avaliações apressadas com sessões Live, ou ceder à exigência de um estudo abstruso, antes de começar a engatinhar.
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.
Provavelmente, desconectei o cabo USB antes de concluir a exclusão dos arquivos no celular — e após 2 ou 3 vezes, perdi um cartão de Memória. — Isso também me ocorreu com a câmera digital Sony, mas seu formatador interno conseguiu recuperar o cartão de Memória.
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 listei 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 fiz desde o 1º Login no Arch Linux KDE.
Wallpaper
Maré alta em uma rua do centro histórico de Parati
“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).
Apenas rotacionei a imagem (-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, cortei a imagem para restabelecer o formato retangular; redimensionei para 1024 pixels de altura; e cortei as laterais (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.
