quarta-feira, 16 de agosto de 2017

Slackware - instalação e aprendizado

Slackware 14.2 com Kernel 4.4 e KDE4

O Slackware 14.2 KDE foi instalado em 14 Jul. 2017, mas permaneceu quase sem uso por mais de 30 dias.

Veio sem LibreOffice (só Calligra), afora outros aplicativos que é normal não virem, — e instalar novos pacotes exige mais do que um “aprendizado rápido”. — Era difícil trabalhar nele e, portanto, difícil permanecer muito tempo.

Em 11 horas de trabalho, hoje, o que mais fez falta foi o KRename, pois sua versão do KSnapshot (KDE4) nomeia as Capturas de tela por mera numeração sequencial.

Usar KSnapshot já não é coisa banal, hoje em dia, — acionar 3 teclas, em extremidades diagonalmente opostas do teclado, passando por 1 clique do mouse num ponto exato da tela. — Talvez por isso, o número de Capturas está baixo (e muitos detalhes ficaram sem documentar).

Seria prudente tentar compensar com anotações no Caderno, — mas teria levado o dobro do tempo. — Escrever à mão é extremamente ineficaz.

A falta do Chromium também complicou o trabalho, — foi necessário exportar seus Bookmarks e importá-los no Firefox, semanas atrás, — mas isso teria de ser repetido a cada dia (nos 2 sentidos). Não é prático.

Estado do sistema ao concluir a primeira parte do relato

Afinal, encontrei tempo para investir no Slackware, — e os primeiros resultados recomendavam começar logo o registro das tentativas, — pois fogem ao que estou acostumado a fazer (e lembrar).

Por isso, a prioridade são essas últimas tentativas, — já que a instalação inicial e as primeiras configurações foram relativamente comuns.

O objetivo não é ensinar nada a ninguém, — muito menos, simular conhecimentos, — mas deixar um registro que permita, no futuro, entender a origem de prováveis erros, para corrigir.

Antes tarde do que nunca


slackpkg install d” para obter os compiladores, desprezados ao instalar o Slackware

O hábito de preferir informações mais recentes, — ou, mesmo, limitar as buscas ao último ano, — me privou de um ótimo tutorial e dos sábios conselhos oferecidos por Carlos E. Morimoto há 10 anos (ou mais).

Perderia bem menos tempo na instalação do Slackware, — selecionando logo todas as categorias (exceto Xfce), — e em seguida o modo “Full - Install everything”:

«Além de não ter a preocupação de ter de ficar imaginando quais pacotes você precisa ou não (acredite, nem quem trabalha diariamente com Linux conhece a função de todos os pacotes incluídos em uma distribuição atual), você vai ter uma facilidade muito maior em usar o sistema e, principalmente, instalar novos programas, pois todas as bibliotecas e outros componentes eventualmente necessários já estarão à mão» [Seleção dos pacotes].

Essa burrice ficou evidente ao pesquisar “Repositórios adicionais”, — para procurar coisas como Conky, Chromium, LibreOffice, KRename, — e me dar conta de que tudo isso vai depender de uma variedade de ferramentas de compilação, sobre as quais não faço a menor ideia.

Ok, parece que não sou eu quem terá de lidar com elas, — o processo é bastante automático, — mas as ferramentas (sejam quais forem) devem estar presentes.

Para isso, a melhor solução foi o comando “slackpkg install d”, — que instala tudo dessa “categoria”, de uma vez só, — a menos que você queira perder tempo escolhendo.

Atualização inicial


“slackpkg upgrade patches”

Primeiro, algumas providências preliminares, — acredito que atualizei as informações dos repositórios, instalei as atualizações disponíveis (patches) e, por fim, instalei algumas novidades surgidas nos repositórios (new).

Aproveitei para reinstalar o Gwenview, que sempre abortava ao tentar abrir uma Captura de tela, — mas não sei se foi isso que resolveu. — No final, abriu pelo Menu, e só depois disso passou a abrir (também) clicando nas imagens.

Antes, ainda, ir nas “Configurações do sistema → Associações de arquivos” e padronizar BMP, GIF, JPEG, PNG, TIFF, — Gwenview no topo e Gimp logo em seguida.

Levantamento retrospectivo a partir do histórico de comandos fornecido pelo comando “history”, — aqui expurgado do que era irrelevante:

53 # slackpkg update gpg
54 # slackpkg update
66 # slackpkg upgrade patches
70 # slackpkg reinstall gwenview-4.14.3-x86_64-2
74 # slackpkg install-new
80 # slackpkg install d

Datando os comandos


Início da datação dos comandos no “/.bash_history

Depois de perder tempo tentando identificar pelas Capturas de tela o possível horário de cada comando, — fornecido pelo “history” apenas com a numeração sequencial, — deixei tudo de lado e fui caçar um jeito de datá-los automaticamente.

É um problema que já tomou muito tempo, em várias ocasiões. — Agora, a solução será aplicada nos demais sistemas já instalados, — bem como nos próximos:

2017-08-16_18:56:36 $ / # echo 'export HISTTIMEFORMAT="%F_%T "' >> ~/.bashrc
2017-08-16_18:56:38 $ / # source ~/.bash_profile

Ao que parece, o primeiro comando já faz essa configuração, — pois o segundo costuma retornar erro, — e mesmo assim, a datação passou a funcionar.

Foram usados, primeiro, como Usuário ($), — e depois, como Superusuário (#), — pois cada um tem seu próprio “/.bashrc” (achava eu), nas pastas “/home” e “/root”.

Infelizmente, só passou a preservar a data dos comandos executados daí por diante, — os anteriores serão sempre exibidos com o horário “atual”, a cada vez que disparar um comando “history”. — Portanto, o ideal é aplicar essa configuração o quanto antes. Se possível, logo após a instalação de cada nova distro.

Mais tarde, o formato de “hora-minuto-segundo” foi desmembrado, para substituir dois-pontos (colon) por traço, — padrão já adotado no nome-de-arquivo das Capturas de tela das demais distros:

echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc

Deletando o excesso de parâmetros (contraditórios) no “/.bashrc

Naturalmente, a repetição de comandos “echo” seguidos de “>>”, — que acrescenta a resposta ao final de um arquivo já existente, — deixou diferentes versões no “/.bashrc”.

Ao que parece, vale o último, — mas não custava nada apagar os anteriores. — Para isso, o arquivo foi localizado no Midnight Commander (mc) e editado (F4) rapidamente.

slackpkg reinstall kdei” para reinstalar os pacotes de idioma do KDE

Também foi pedida a reinstalação da categoria “KDEI”, — idiomas ou internacional, — e selecionados os pacotes de Português (pt) e Português do Brasil (pt_BR):

116  2017-08-16_20:06:22 # slackpkg reinstall kdei

Até agora, nenhuma certeza de que essas coisas tenham sido feitas corretamente, — por isso, é bom registrar, para exame posterior.

Instalação do Slackware


Em breve.

_________
Inicialmente publicado em 16 Ago. 2017, no Slackware 14.2 KDE, para desenvolvimento nos próximos dias e semanas.

— … ≠ • ≠ … —

quarta-feira, 2 de agosto de 2017

openSUSE - removendo Snapper, PIM, Baloo e Akonadi

Deletando manualmente snapshots que proliferam como coelhos no openSUSE. — Nem sinal do nº 258

• Este relato documenta:

1) A remoção do máximo dos pacotes que compõem o KDE-PIM, Baloo e Akonadi, — tal como “vieram”, automaticamente instalados com o openSUSE Leap 42.2 KDE, — exceto os necessários ao funcionamento de outros aplicativos, ou do sistema como um todo (“dependências”); e

2) A remoção / configuração “mínima (necessária)” para desabilitar o funcionamento do Snapper, — cuja função é gerar sucessivos “instantâneos” (snapshots) do Sistema, que permitem reverter (roll-back) passos “infelizes”, causados por atualizações, instalação de novos pacotes etc.

Mas o mais importante é que este relato documenta o “caminho de volta”, — para o caso de querer desfazer uma dessas 2 decisões.

KDE-PIM


Busca no Gerenciador de software do YaST2, ordenado pela 1ª coluna (status), — “instalados”

Não lembro (nem encontro registro) de ter utilizado regularmente os benefícios do PIM, Baloo-file, Akonadi-server & correlatos (ou seus antecessores), desde quando comecei a usar o Kubuntu e o Debian KDE, há mais de 8 anos (2009). — No entanto, estiveram ativos esse tempo todo, consumindo recursos (RAM, CPU) e reduzindo o proveito que poderia tirar do hardware, quando exigido para outros esforços.

Em 16 Mai. 2016, um comentário e um link numa comunidade me incentivaram a examinar o assunto, — e acabei removendo PIM, Baloo, Akonadi do Kubuntu, do Debian KDE, e dos demais sistemas instalados desde então.

Porém, naquela época, o procedimento básico foi marcar para remoção cada pacote de uma lista de “aplicativos finais” que não uso, — lista construída a partir de consultas ao site KDE e outras raras páginas localizadas sobre o tema:

  • kmail
  • kaddresbook
  • kontact
  • korganizer
  • knotes
  • kjots
  • kalarm
  • akonadi-server
  • baloo-utils

Agora, no openSUSE Leap, comecei a busca por palavras-chave mais abrangentes, — “kdepim”, “baloo”, “akonadi”, — com os resultados ordenados pela primeira coluna (status), para agrupar os “instalados” no topo.

A partir daí, marquei para remoção cada pacote encontrado, — um de cada vez, para verificar as consequências, caso-a-caso.

Opções quando a remoção de um pacote afeta outros: — remover todos, manter, quebrar

Clique com o botão direito do mouse, selecione “Remover”, — e caso isso implique em remover outros pacotes, aparece uma janela de diálogo com a lista completa, e 3 alternativas para "resolução do conflito”:

  • Remover os pacotes que dependem dele
  • Manter o pacote selecionado (e os que dependem dele)
  • Quebrar as dependências

Nesse diálogo, tenha cuidado de não clicar em “Cancelar”, — pois isso não cancela a remoção solicitada antes, — apenas deixa o conflito sem solução (e você, sem saber como voltar a ele).

Para recuar, o caminho correto é selecionar a 2ª alternativa, — “Manter” o pacote cuja desinstalação iria lhe criar problemas, — e clicar em “Tentar novamente”.

Cuidado com listas apenas parcialmente exibidas, — verifique se não existe “mais…

Tenha cuidado, também, com listas abreviadas ou incompletas, — com “mais…” escondido lá embaixo. — Ali mora o perigo.

Examine a lista, item por item. — Certifique-se de que não inclua nada vital ao sistema (Plasma workspace), nem algum aplicativo que você deseja manter (Dolphin, KFind, Okular, Ktorrent, Digikam, por exemplo).

Nestes casos específicos, recue, — e prossiga com a marcação dos demais pacotes encontrados.

Desativação da “Pesquisa de arquivos” (File search) nas Configurações do sistema (System settings)

É necessário ser tão radical? Nem tanto.

Desabilitar os serviços correspondentes, em várias seções das “Configurações do sistema” (KDE System settings), — como “Pesquisa de arquivos”(*), por exemplo, — é suficiente para que a maioria deles não carregue automaticamente, no início de cada sessão. Então, bastaria ter o cuidado de não clicar por distração no Kmail, Korganizer, Kalendar etc., para não acordar metade da tropa.

(*) Desativar “Pesquisa de arquivos” jamais afetou o mecanismo de pesquisa simples do Dolphin (Localizar), — nem o mecanismo de pesquisa avançada “Procurar arquivos / pastas” (KFind), — que continuam plenamente capazes de encontrar qualquer arquivo existente nos 3 HDDs + SSD externo (total 2,64 TB), por nome, extensão, tipo, data, tamanho, proprietário (User, Group) e/ou conteúdo (string dentro do arquivo), com a mesma velocidade de 2009 a 2016 (antes de começar a remover PIM, Baloo, Akonadi).

De início, foi o que fiz no openSUSE Leap 42.2, — como em outros sistemas acabados de instalar, — enquanto estes serviços ficaram quietos. Depois, começam os ajustes finos, e você acaba encontrando notificadores que resistem a desaparecer, e alguns serviços que insistem em ser carregados.

Depois de remover o que era possível, com as 3 palavras-chave, não foi necessário procurar o resto da antiga lista, — Kmail, Korganizer etc., — exceto para confirmar que já estavam desinstalados.

Dessa vez, portanto, bastou seguir o caminho inverso, — eliminar as “dependências”, — e os aplicativos caíram por tabela.

O resultado final foi a remoção de nada menos que 136 pacotes:

akonadi-calendar-lang
akonadi-calendar-tools
akonadi-calendar-tools-lang
akonadi-import-wizard
akonadi-import-wizard-lang
akonadi-mime
akonadi-mime-lang
akonadi-notes-lang
akonadi-server
akonadi-server-lang
akonadi-server-sqlite
akregator
akregator-lang
baloo5
baloo5-file
baloo5-lang
baloo5-tools
calendarsupport
calendarsupport-lang
eventviews
eventviews-lang
grantleetheme
grantleetheme-lang
incidenceeditor
incidenceeditor-lang
kaddressbook
kaddressbook-lang
kalarmcal
kalarmcal-lang
kcalutils
kcalutils-lang
kdav
kdepim-addons
kdepim-addons-lang
kdepim-apps-libs
kdepim-apps-libs-lang
kdepim-runtime
kdepim-runtime-lang
kdepimlibs4
kidentitymanagement-lang
kimap-lang
kldap
kldap-lang
kleopatra
kleopatra-lang
kmail
kmail-account-wizard
kmail-account-wizard-lang
kmail-application-icons
kmail-lang
kmailtransport
kmailtransport-lang
knotes
knotes-lang
kontact
kontact-lang
kontactinterface-lang
kopete
korganizer
korganizer-lang
kpimtextedit
kpimtextedit-lang
ktnef-lang
libgravatar
libgravatar-lang
libkdepim
libkdepim-lang
libKF5AkonadiAgentBase5
libKF5AkonadiCalendar5
libKF5AkonadiMime5
libKF5AkonadiNotes5
libKF5AkonadiSearch
libKF5AkonadiXml5
libKF5AlarmCalendar5
libKF5CalendarSupport5
libKF5CalendarUtils5
libKF5EventViews5
libKF5GrantleeTheme5
libKF5Gravatar5
libKF5IdentityManagement5
libKF5IMAP5
libKF5IncidenceEditor5
libKF5KontactInterface5
libKF5Ldap5
libKF5Libkdepim5
libKF5LibkdepimAkonadi5
libKF5Libkleo5
libKF5MailCommon5
libKF5MailImporter5
libKF5MailImporterAkonadi5
libKF5MailTransport5
libKF5MailTransportAkonadi5
libKF5Mbox5
libKF5PimCommon5
libKF5PimCommonAkonadi5
libKF5PimTextEdit5
libKF5Syndication5
libKF5Tnef5
libkgantt-lang
libKGantt2
libkgapi-lang
libkleo
libkleo-lang
libkolab1
libkolabxml1
libKPimGAPICalendar5
libKPimGAPIContacts5
libKPimGAPICore5
libKPimGAPITasks5
libKPimKDAV5
libksieve
libksieve-lang
libmeanwhile1
libmysqlclient_r18
libmysqlcppconn7
libotr5
libqgpgme7
libqimageblitz4
libreoffice-base-drivers-mysql
libxerces-c-3_1
mailcommon
mailcommon-lang
mailimporter
mailimporter-lang
mariadb
mariadb-client
mbox-importer
mbox-importer-lang
messagelib
messagelib-lang
pim-data-exporter
pim-data-exporter-lang
pim-sieve-editor
pim-sieve-editor-lang
pimcommon
pimcommon-lang

conforme os registros em /var/log/zypp/history, — entre 1:49 e 1:57 de 4 Ago. 2017. — Na verdade, a seleção começou 10 minutos antes, por volta de 1:39.

Foi uma “limpeza” muito mais completa, — além de muito mais rápida, — do que a registrada no Kubuntu e no Debian KDE.

Pacotes restantes do KDE-PIM, Baloo, Akonadi, — necessários ao sistema, ao Dolphin, KFind etc.

Ao final, ficam alguns componentes do KDE-PIM. — Não é uma remoção 100% completa, — mas já deixa o sistema nitidamente mais leve.

Vale notar que houve 2 “ensaios” (com erros), — primeiro, em 2 Jul., no Leap 42.2; e mais tarde, em 29 Jul., no Tumbleweed. — Agora, no Leap 42.3, finalmente consegui evitar erros.

Fica claro, de passagem, que o upgrade reinstalou todo o KDE-PIM, Baloo, Akonadi.

Snapper


Particionamento previsto para atender à brincadeira por vários anos

Partições padronizadas de 25 GiB pareciam mais do que suficientes para cultivar um belo criadouro de Linux e passar vários anos apenas regando, adubando, podando, enxertando aqui e ali, — até que o openSUSE Leap 42.2, instalado em Janeiro, ameaçou “dobrar a meta” dentro de poucos meses. — E ainda nem tinha nele todos os aplicativos instalados no Kubuntu ao longo de mais de um ano.

  • 17 Jan. 2017 - Aos 27 minutos da primeira sessão, usava 5,37 GiB da partição-raiz.
  • 26 Jan. 2017 - Ao concluir a configuração básica, usava 7,33 GiB.
  • 9 Jun. 2017 - Atingiu 14,1 GiB, — consegui reduzir para 13,4 GiB (menos 0,7 GiB)
  • Depois disso, consegui reduzir para 11,0 GiB (menos 2,4 GiB, no mínimo)
  • 2 Jul. 2017 - Ao remover o PIM e reinstalar algumas coisas, foi de 11,0 GiB para 12,8 GiB. Consegui reduzir para 11,4 GiB (menos 1,4 GiB)
  • 3 Jul. 2017 - Consegui reduzir de 11,4 para 9,99 GiB (menos 1,5 GiB)

Somente nesses 4 episódios, — e deixando outros de lado, — o acúmulo eliminado manualmente já somava 6 GiB.

Ao iniciar o upgrade, em 3 Ago. 2017, o espaço usado já estava novamente em 11,5 GiB, — portanto, estaria em 17,5 GiB (pelo menos), caso não tivesse feito essas eliminações de pares de snapshots.

Durante o upgrade, o uso de espaço na partição-raiz chegou a 16,9 GiB, — ou seja, ultrapassaria 22,9 GiB, no mínimo.

Deletando pares de snapshots do openSUSE, — após atingir 17,0 GiB de espaço usado na partição

Felizmente, muito antes de chegar ao upgrade, comecei a entender, — na pele, — as implicações da partição BtrFS e dos “instantâneos” (snapshots) que, em tese, prometem desfazer (roll-back) qualquer desastre causado por alguma atualização, ou pela instalação de novos pacotes.

Na verdade, — como notou outro mortal, — nem saberia usar esse recurso, no caso de uma emergência.

Olhando os registros dos últimos 2 ou 3 anos, encontro poucos desastres onde esse recurso teria sido útil, — um triste upgrade do Linux Mint 18 “Sarah” Beta para 18.1 “Serena” (28 Jan. 2017), e uma infeliz atualização do Debian “Stretch”, quando ainda estava em desenvolvimento (30 Set. 2016).

Em suma, o “prêmio” cobrado por este “seguro” é desproporcional. — É um custo elevado, diário, permanente, — para um risco pequeno e de baixa ocorrência.

Estamos falando de um “usuário comum”, — com 1 máquina, — não de um “Administrador de sistema”.

Ter 2 ou 3 sistemas em paralelo (dualboot) é muito mais divertido. — O único problema é decidir “qual Linux usar hoje”. — É um preço que se paga com alegria e que retorna diariamente, na forma de aprendizado. De preferência, sem que se precise chegar a nenhum desastre.

Mas, o que significa “desastre”, — quando se tem vários sistemas em dualboot? — Se falha um, você usa outro.

Para quem gosta de brincar, sistema não há de faltar. — Mais valem 3 opções do que 1 “seguro”

Mesmo com o Linux Mint meio capenga, a partir de 31 Jan. 2017, — e coincidindo de deletar por acidente o KDE Neon, em 31 Mar. 2017, — ainda dispunha do Kubuntu 16.04 LTS (que nunca passou pelo risco de upgrade… embora hoje se apresente como “16.04.3”).

Ficou comprovado que 2 ou 3 Linux em paralelo, — se possível, em diferentes HDDs (e com mais de um Grub), — são um “seguro” bastante razoável, para um “usuário médio”.

E dispunha do openSUSE Leap 42.2, que, apenas 9 dias depois de instalado, — de 17 para 26 Jan. 2017, — já se colocava entre os “Top 3” no desempenho das tarefas essenciais do dia-a-dia.

Foi uma das mais gratas surpresas, — tamanha e tão rápida “usabilidade”, num sistema que jamais tinha visto antes, — após 7 anos limitado ao Kubuntu / Mint / Debian.

Deletando manualmente snapshots que proliferam automaticamente. — Nem sinal do nº 258

Portanto, pesquisei sobre o Snapper, — e deletei manualmente vários pares de snapshots, — até optar por desativar este serviço.

Limitando a proliferação de “instantâneos” (snapshots) no openSUSE

Primeiro, algumas providências para limitar o número de “instantâneos” (snapshots).

# snapper -c root set-config "NUMBER_LIMIT=2"
# snapper -c root set-config "NUMBER_LIMIT_IMPORTANT=2"

Desabilitando o uso do Snapper no openSUSE

Depois (pensando bem), desativar o Snapper, — editando USE_SNAPPER="yes" para "no", na última linha do arquivo “/etc/sysconfig/yast2”.

Normalmente, faria isso chamando “Dolphin - modo Root” pelo Menu K e clicando no arquivo para editá-lo com o Kate ou KWrite.

Porém, como se têm reforçado advertências contra o uso de aplicativos gráficos como Superusuário (Root), — e em várias distros essa opção já foi até eliminada do Menu, — padronizei o hábito de fazer esse tipo de trabalho pelo editor (F4) do Midnight-Commander (mc / mcedit, ou mc / nano).

Desinstalando “snapper-zypp-plugin” do openSUSE

Por fim (pensando melhor ainda), acabei por desinstalar o snapper-zypp-plugin, para acabar com a geração automática de pares de “instantâneos” (snapshots) do sistema, a cada atualização / instalação / remoção de pacotes.

Sim, porque você abre o Gerenciamento de software do YaST2, — desinstala 1 pacote, ou 100 pacotes, — e o espaço usado na partição-raiz… dá um salto.

Desinstalar esse plugin foi uma decisão de “usuário comum” (average user), — muito longe das responsabilidades de um Administrador de sistema. — Trata-se de um recurso poderoso. Apenas, nem sempre vale o “custo”, para um simples mortal.

Ao fazer upgrade do openSUSE 42.2 para 42.3, alguns pacotes removidos voltaram a se instalar e funcionar automaticamente, — todo o KDE-PIM, Akonadi, Baloo, — e o snapper-zypp-plugin.

Tudo bem, voltei a removê-los, — exceto snapper-zypp-plugin (por enquanto), — e a deletar 3 novos pares de shapshots. Já estava bem adestrado nessa arte.

Descoberta do “unreferenced snapshot” nº 258, completamente desgarrado

A decisão de não tornar a desinstalar o snapper-zypp-plugin, — por enquanto, — acabou justificada pela descoberta de um snapshot desgarrado (unreferenced snapshot), de nada menos que 6,19 GiB,

Isso, quando já estavam deletados todos os outros snapshots, — exceto nº 0 (sistema atual); e nº 1 (inicial, inapagável), — numa limpeza radical, tresloucada, porém ainda com resultados frustrantes.

O snapshot nº 258 só foi descoberto, quase por acaso, ao revisar a documentação de referência sobre o assunto (ver abaixo), — na dica “Deleting unreferenced snapshots”, sob o item 3.5.4 - Deleting snapshots.

Como o usuário não tem acesso à pasta (oculta) /.snapshots, ele só pôde ser examinado no Midnight-Commander, aberto pelo Root.

Por algum motivo, falta um arquivo XML com os meta-dados, — ou faltam os meta-dados no arquivo XML, — e o Snapper não “vê” aquele snapshot.

Snapshot nº 258 na Listagem, 2 dias depois, — mas não na Tabela (ver Imagens anteriores)

O snapshot nº 258 não aparece em nenhuma das tabelas geradas pelo comando snapper -ls, — usadas, até então, como guia para deletar pares de snapshots. — Só aparece (desde aquela época) em comandos de listagem de pastas / arquivos, como ls /.snapshots -al:

flavio@Linux5:~> su
Senha:
Linux5:/home/flavio # ls /.snapshots -al
total 4
drwxr-x--- 1 root root  54 Jul  3 08:01 .
drwxr-xr-x 1 root root 166 Jan 17  2017 ..
drwxr-xr-x 1 root root  32 Jan 17  2017 1
drwxr-xr-x 1 root root  16 Jun  7 21:03 258
drwxr-xr-x 1 root root  66 Jul  1 00:29 302
drwxr-xr-x 1 root root  98 Jul  1 00:29 303
-rw-r----- 1 root root 408 Jul  3 08:01 grub-snapshot.cfg

Linux5:/.snapshots # cd /.snapshots
Linux5:/.snapshots # du -sh 1
7,0G    1
Linux5:/.snapshots # du -sh 258
6,2G    258
Linux5:/.snapshots # du -sh 302
6,2G    302
Linux5:/.snapshots # du -sh 303
6,2G    303
Linux5:/.snapshots # du -sh grub-snapshot.cfg
4,0K    grub-snapshot.cfg

Obs.: - Por princípio, os tamanhos indicados pelo comando du -sh [number] não se somam aritmeticamente, — pois há repetições, no caso dos pares “pre / post” (antes e depois de cada atualização ou instalação). — Note que a soma ultrapassaria os 25 GiB da partição.

A propósito:

flavio@Linux5:~> du --help

Summarize disk usage of the set of FILEs, recursively for directories.

Mandatory arguments to long options are mandatory for short options too.
  -h, --human-readable  print sizes in human readable format (e.g., 1K 234M 2G)
  -s, --summarize       display only a total for each argument

Barra de progresso empacada e nenhuma atividade de CPU, — 18 minutos após concluir a atualização

Assim, foi possível identificar sua data de 7 Jun. 2017, às 21:03.

Trata-se de uma atualização que parecia empacada. — Aliás, tudo empacou naquela sessão. — O carregamento do openSUSE demorou quase 2 minutos. — A manutenção programada do BtrFS começou logo após o início da atualização (download), — e tudo ficou devagar, quase travando.

O arquivo /var/log/zypp/history indica que os 3 pacotes da atualização foram instalados com sucesso, em apenas 4m 30s, — completados meio minuto antes das 21:03, — mas a barra de progresso continuou empacada na metade do caminho por mais 26 minutos (sem nenhum indício de atividade de CPU no Conky ou no KSysguard), — e às 21:29 reiniciei o sistema. — O novo boot demorou cerca de 3m30s; e um reload do atualizador indicou que estava tudo atualizado.

Nota: - Talvez fosse interessante “afastar” (no tempo) os agendamentos do Notificador de atualizações e da Manutenção BtrFS, — para evitar encavalamento. — É verdade que, uma vez adquirida consciência disso, bastaria não autorizar as atualizações, até ter certeza de que a Manutenção não irá começar. Mas, sem saber quantos minutos esperar, como ter certeza?

Fato é que, após 6 meses, ainda não encontrei a configuração desses 2 agendamentos, no YaST2. — Resta ir à luta no Google, — e ter sorte de adivinhar as palavras-chave corretas.

Por outros motivos, — monitorar o tempo de Boot e o uso inicial de Memória RAM, — também seria interessante afastar ambos agendamentos para 10 minutos uptime, pelo menos.

Deletando “unreferenced snapshot” no openSUSE

Para deletar o snapshot nº 258 (agora), foram usados esses 2 comandos:

# btrfs subvolume delete /.snapshots/258/snapshot
Delete subvolume (no-commit): '/.snapshots/258/snapshot'

# rm -rf /.snapshots/258

Ou seja, — primeiro, deletar o “subvolume btrfs”; depois, o diretório. — Nada de apenas deletar a “pasta” pelo Midnight-Commander.

Com isso, o espaço usado desabou de 14,5 GiB para 8,31 GiB, — o menor tamanho, desde 11 Fev. 2017 (quando a instalação do “freshplayerplugin” elevou a marca de 8,29 para 8,35 GiB). — Uma redução espantosa, de 6,19 GiB, numa tacada só.

Depois disso, pode-se dizer que voltei a ter fé na Humanidade, — onde se incluem os desenvolvedores e colaboradores do Snapper.


Leap e Tumbleweed - Cronologia


Avanços obtidos com Leap (BtrFS) e Tumbleweed (ext4), no conjunto de sistemas Linux instalados

Na prática, as coisas se passaram com mais cautela do que pode parecer, pelo relato acima:

1) openSUSE Leap 42.2 foi usado regularmente por quase 5 meses, — ainda com folga suficiente, — antes do uso de espaço em disco se tornar alarmante.

2) KDE-PIM, Baloo, Akonadi foram desinstalados após longa observação, — já na fase de “ajuste fino”, — com direito a erros e correções.

3) openSUSE Tumbleweed foi instalado quase 5 meses depois, — em outra partição, formato ext4 “tradicional” (sem risco de snapshots), — e serviu para mais alguns testes & ensaios que hesitava em arriscar no Leap.

4) openSUSE Tumbleweed foi usado para testar a instalação de ffmpeg, — tinha um receio meio supersticioso de que pudesse afetar a leveza com que o Leap enfrentava o recurso “Páginas” do Facebook, — embora o repositório Packman já estivesse habilitado (mas sem uso) no Leap.

5) Só no final, arrisquei o upgrade do Leap 42.2 para 42.3, — com o novo DVD gravado, pronto para reinstalar, no caso de não dar certo. — Não havia como fugir ao risco. A versão anterior ficará sem suporte 6 meses após o lançamento da nova. Se ficar, o bicho come.

17 Jan. 2017 - (Leap 42.2) - Instalado em partição BtrFS (sdb2).

17 Jan. 2017 - (Leap 42.2) - Após 27 minutos do primeiro Boot, havia instalado apenas o Conky + 5 dependências (704 KiB baixados; 2,24 MiB instalados). Estavam ocupados 5,37 GiB da partição-raiz (3:39).

26 Jan. 2017 - (Leap 42.2) - Usados 7,33 GiB da partição-raiz, ao dar por encerrada a fase inicial de configuração (20:17).

9 Jun. 2017 - (Leap 42.2) - Deletados pares de snapshots “não-importantes”, com redução do espaço usado de 14,1 GiB para 13,4 GiB (21:35 ~ 22:00).

2 Jul. 2017 - (Leap 42.2) - Removido KDE-PIM, Baloo e Akonadi. — Por falta de atenção, acabaram removidos também vários pacotes necessários, como Amarok, K3b, Kdepasswd, Kdialog, Kdnssd, Kget, Kfind, Konqueror etc., reinstalados em seguida (21:20 ~ 22:24).

3 Jul. 2017 - (Leap 42.2) - Deletados pares de snapshots “importantes”, exceto os 2 últimos, com redução do espaço usado na partição-raiz de 11,4 GiB para 9,99 GiB (8:00 ~ 8:05).

3 Jul. 2017 - (Tumbleweed) - Instalado em partição ext4 “tradicional” (sdd2), para teste e comparação (19:36 ~ 22:05).

29 Jul. 2017 - (Tumbleweed) - Removido KDE-PIM, Baloo e Akonadi. — Por falta de atenção, acabaram removidos também alguns pacotes necessários, como Digikam e Kgpg, reinstalados em seguida. — Entre uma coisa e outra, o arquivo ~/.xsession-errors acumulou 2.533 linhas, num total de 292 KiB (19:40 ~ 20:00).

3 Ago. 2017 - (Tumbleweed) - Habilitado repositório Packman e instalado ffmpeg (19:33).

3 ~ 4 Ago. 2017 - (Leap 42.2) - Upgrade para 42.3, usando uma “receita” simples de 3 comandos em tty1, enquanto continuava trabalhando normalmente em tty7 (22:38 ~ 0:26, conexão 1,3 MiB/s).

4 Ago. 2017 - (Leap 42.3) - Removido KDE-PIM, Baloo e Akonadi (1:36 ~ 1:56).

4 Ago. 2017 - (Leap 42.3) - Instalado ffmpeg (10:57).

__________
• Publicado inicialmente em 2 Ago. 2017, no openSUSE 42.2, e desenvolvido até 6 Ago. 2017 no openSUSE Leap 42.3.
• O registro de datas + horas facilita localizar Fotos e Capturas de tela, — além das anotações no “Caderno de informática”, — caso precise verificar mais algum detalhe.

— … ≠ • ≠ … —

Não-debians


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