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