Translate

Mostrando postagens com marcador Snapper. Mostrar todas as postagens
Mostrando postagens com marcador Snapper. Mostrar todas as postagens

segunda-feira, 24 de junho de 2019

Upgrade do openSUSE Leap para Tumbleweed

KInfocenter no openSUSE convertido em Tumbleweed a partir do Leap 15.0
openSUSE convertido em Tumbleweed a partir do Leap 15.1

Essa instalação do openSUSE Leap já completou 2½ anos. — Foi minha 2ª incursão fora do “universo Debian”, — após 10 anos limitado ao Kubuntu, Mint, Debian, KDE Neon.

O openSUSE Leap 42.2 foi instalado em Janeiro de 2017, — e ao longo desses anos, recebeu:


Continuava sólido, — com tantos abusos de um usuário médio. — E continua sólido, com mais esse upgrade para Tumbleweed.

  • Isto NÃO é um “tutorial”. — Apenas um registro, para lembrar o que fiz, — incluindo erros e ignorâncias.

Segui o roteiro indicado na página openSUSE: Tumbleweed upgrade:

  1. Atualizar o openSUSE Leap 15.1
  2. Mudar os repositórios do Leap 15.1 para os do Tumbleweed
  3. Executar # zypper dup — que é uma abreviação de “zypper dist-upgrade” — para migrar o sistema, da distribuição fixa para a rolling-release

Índice


  • Atualização do Leap, espaço e snapshots
  • Mudança dos repositórios
  • Upgrade para Tumbleweed
  • Pós Upgrade
  • Espaço e snapshots (2)
  • Packman e Codecs
  • Pré-visualizações no Dolphin
  • Grub ampliado
  • Espelhos (Mirrors)
  • Conclusão

Atualização do Leap, espaço e snapshots


Atividades de manutenção (BtrFS, Snapperd) ao iniciar o openSUSE (2018)

Nos primeiros 20 minutos após a última atualização, reiniciei 2 vezes o openSUSE Leap 15.1, — até me certificar de que não havia mais atividades de manutenção de BtrFS, Snapperd e afins, — uma vez que não conheço o funcionamento exato desses serviços.

Um exemplo de 2018 (Acima) - Essas atividades de manutenção podem ser observadas nos gráficos de uso de CPU, — e identificadas entre os Top 8 processos monitorados pelo Conky.

Às vezes, isso ocorre logo após o Boot. — Outras vezes, cerca de 20 minutos após o início da sessão KDE.

Espaço ocupado em disco após a última atualização do openSUSE Leap

Motivo sério, para preocupação, era o pouco espaço livre na partição-raiz.

A recomendação é de usar partição-raiz de 50 GiB, — pois são mantidos vários “instantâneos” (snapshots), — backups parciais, que permitem “voltar no tempo” e desfazer alterações recentes do sistema, em caso de algum problema.

Como ainda não conhecia nada disso, no início de 2017, utilizei uma partição de apenas 25 GiB, — e no momento do upgrade, 14,6 GiB encontravam-se ocupados, — em boa parte, por esses Snapshots (backups) do sistema:

$ date
dom jun 23 14:35:49 -03 2019

$ sudo snapper ls
   # | Type   | Pre # | Date                         | User | Used Space | Cleanup | Description  | Userdata
-----+--------+-------+------------------------------+------+------------+---------+--------------+--------------
  0  | single |       |                              | root |            |         | current      |
143* | single |       | qui 23 mai 2019 10:58:58 -03 | root | 161,54 MiB |         |              |
148  | pre    |       | dom 02 jun 2019 22:12:38 -03 | root |  82,65 MiB | number  | zypp(zypper) | important=yes
149  | post   |   148 | dom 02 jun 2019 22:20:09 -03 | root |  31,71 MiB | number  |              | important=yes
152  | pre    |       | qua 05 jun 2019 22:07:35 -03 | root |   9,43 MiB | number  | zypp(zypper) | important=no 
153  | post   |   152 | qua 05 jun 2019 22:07:54 -03 | root |   9,67 MiB | number  |              | important=no 
154  | pre    |       | qua 19 jun 2019 10:02:22 -03 | root |   9,64 MiB | number  | zypp(zypper) | important=yes
155  | post   |   154 | qua 19 jun 2019 10:14:10 -03 | root |  31,57 MiB | number  |              | important=yes
156  | pre    |       | dom 23 jun 2019 14:35:12 -03 | root |   4,80 MiB | number  | zypp(zypper) | important=no
157  | post   |   156 | dom 23 jun 2019 14:35:23 -03 | root |   1,31 MiB | number  |              | important=no

Ao reiniciar 2 vezes o openSUSE Leap, os serviços de manutenção automática descartaram apenas um par de Snapshots sem grande importância (152 e 153), — com pequena redução do espaço ocupado em disco, de 14,6 para 14,4 GiB.

Os tamanhos (Used space) indicados na tabela, — todos da ordem de “MiB”, — não refletem o espaço que de fato ocupam no disco.

Para obter mais 1 GiB livre (e se possível, 2 GiB), deveria ter deletado manualmente todos os pares dos dias 2, 5 e 19 de Junho, — ou seja, desde o número 148 até o 155, para abrir mais espaço livre, — mas abusei do risco.

Kernels antigos, observados nas Opções Avançadas do Grub, antes do upgrade

Outra providência simples, para abrir mais algum espaço, seria remover os 2 Kernels mais antigos, — embora eu tenha a impressão de que eles desaparecem com a simples eliminação dos respectivos pares (pre, post) de Snapshots. — E de fato, um deles sumiu após o upgrade do Leap para Tumbleweed.

Não lembro de jamais ter removido um Kernel antigo do openSUSE. — E no entanto, eles não se acumulam.

Felizmente, não chegou a faltar espaço, — não ocorreu nenhum desastre, antes de se concluir o upgrade do Leap para Tumbleweed, — mas faltou pouco.

Por questão de segurança, também deveria ter criado um novo Snapshot “single”, com o estado atual (última atualização), — pois é para esse ponto que precisaria voltar, em caso de falha, — em substituição ao Snapshot 143*, que retorna ao final do upgrade anterior (início do Leap 15.1).

Mudança dos repositórios


Repositórios do openSUSE Tumbleweed e backup dos repositórios do Leap 15.1

A pasta com os repositórios do Leap 15.1 foi apenas renomeada, para ficar de backup, — e os repositórios do Tumbleweed foram adicionados pelos comandos:

# zypper ar -f -c http://download.opensuse.org/tumbleweed/repo/oss repo-oss
# zypper ar -f -c http://download.opensuse.org/tumbleweed/repo/non-oss repo-non-oss
# zypper ar -f -c http://download.opensuse.org/tumbleweed/repo/debug repo-debug
# zypper ar -f -c http://download.opensuse.org/update/tumbleweed/ repo-update

O Packman ficou excluído, nessa etapa, — só será adicionado depois do upgrade, — para limitar as possibilidades de falha.

Na falta de um pé-de-coelho, rodei mais 2 comandos, — cuja origem repousa entre velhos Bookmarks, — e que provavelmente tiveram apenas o valor psicológico de fazer figa com os dedos:

# zypper --gpg-auto-import-keys ref
Retrieving repository 'repo-debug' metadata .................................................................................[done]
Building repository 'repo-debug' cache ......................................................................................[done]
Retrieving repository 'repo-non-oss' metadata ...............................................................................[done]
Building repository 'repo-non-oss' cache ....................................................................................[done]
Retrieving repository 'repo-oss' metadata ...................................................................................[done]
Building repository 'repo-oss' cache ........................................................................................[done]
Retrieving repository 'repo-update' metadata ................................................................................[done]
Building repository 'repo-update' cache .....................................................................................[done]
All repositories have been refreshed.

# zypper patch --updatestack-only
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 5 items are locked and will not be changed by any action:
 Available:
  PackageKit PackageKit-backend-zypp PackageKit-branding-openSUSE PackageKit-gstreamer-plugin PackageKit-gtk3-module

Nothing to do.

O primeiro comando é um “zypper refresh”, — para obter informações de repositórios recém-adicionados, — com importação explícita das chaves de segurança (que não sei se é necessária, mas suponho que não faça mal).

O segundo comando deveria instalar correções que afetem o zypper e o gerenciamento de pacotes, mas não produziu qualquer efeito prático. — Aparentemente, não realiza upgrade (que muito provavelmente quebraria dependências em relação ao Leap); e tampouco poderia buscar remendos nos repositórios já eliminados. — De qualquer forma, o Leap já tinha sido totalmente atualizado.


Upgrade para Tumbleweed


Sumário das operações propostas pelo comando # zypper dup

O comando # zypper dup foi disparado no console virtual tty2 (CTRL+Alt+F2), logado como root, — sem fechar a sessão KDE no tty7 (CTRL+Alt+F7), — e propôs:

  13 patterns to upgrade
   2 products to upgrade
   6 packages to downgrade
   2 patterns to downgrade
   4 packages to change archictecture
2702 packages to upgrade
 267 new packages to install
 141 packages to remove

Download size: 2.46 GiB
Additional 1.1 GiB will be used

Imagino (não fotografei) que, lá no alto desse bloco com milhares de pacotes, houvesse uma mensagem sobre o que não seria alterado, — pois bloqueei vários pacotes manualmente, há muito tempo, pelo YaST2, — e continuam ausentes, após o upgrade:

The following 5 items are locked and will not be changed by any action:
 Available:
  PackageKit PackageKit-backend-zypp PackageKit-branding-openSUSE PackageKit-gstreamer-plugin PackageKit-gtk3-module

Monitoramento e anotações em tty7, enquanto executava zypper dup em tty2

O download começou após 16:01 (snapshot “pre”) e, — com uma conexão de “10 megas” (max.: 1,31 MiB/s), — se estendeu por cerca de 1 hora (média: +/- 0,7 MiB/s).

A instalação de 3.098 pacotes começou por volta de 17:10 e se concluiu às 18:26 (snapshot “post”), em um 2 × Intel® Core™2 Duo CPU E7300 @ 2.66GHz com 3,8 GiB RAM.

Exame posterior, pelo comando # rpm -qa --last, indica a hora exata da instalação do primeiro ao último pacote, em um total de 2975:

AdobeICCProfiles-2.0-156.3.noarch             dom 23 jun 2019 17:09:36 -03
...
q4wine-lang-1.3.11-1.4.noarch                 dom 23 jun 2019 18:17:22 -03

Esse tempo foi aproveitado para tirar fotos do tty2, fazer anotações no Kate e capturar telas para registrar os indicadores do Conky, — além de me divertir na internet.

Naturalmente, a certa altura o Gwenview não foi mais capaz de carregar as novas capturas, nem o Dolphin conseguiu mais exibir qualquer partição, — mas o Kate e o Gnome-screenshot continuaram gravando no HDD, até o fim, — e também depois do final, no tempo que ainda demorei, até reiniciar a máquina.

Ao final do upgrade, estavam ocupados 23,4 dos 25,0 GiB da partição-raiz, — ainda com 2 dos 3 Kernels herdados do Leap.

Mais tarde, desapareceu mais um dos Kernels herdados do Leap, — imagino que pela eliminação manual ou automática de pares de Snapshots. — O openSUSE jamais acumulou velhos Kernels, nesses 2½ anos.

Pós Upgrade


Entrada correta do Arch Linux, no Grub gerado pelo openSUSE Tumbleweed

A boa notícia é que o Grub do openSUSE Tumbleweed foi capaz de gerar a entrada correta do Arch Linux, — o que dispensa correção manual após cada atualização. — Isso é inédito, pelo menos dentro da minha experiência pessoal.

Naturalmente, o Restart não funcionou, — foi necessário usar o comando # reboot, — e a primeira sessão do Tumbleweed apresentou crash do Kwin, antes mesmo de acabar de carregar.

OpenGL 2.0 incompatível com o hardware

O motivo é que o KDE 5.16 configurou Compositor OpenGL 2.0, — situação já vista em outras distros, — e foi necessário passar para XRender, outra vez.

Talvez por isso, a primeira sessão carregou sem o Conky, — que teve de ser manualmente iniciado por comando, — mas nas sessões seguintes ele voltou a executar automaticamente.

A abertura automática do Conky foi definida há mais de 2 anos, ao configurar o KDE para “Restaurar a sessão salva manualmente”, — e em seguida “Salvar sessão” (Menu >> Power / Session), com o Conky em execução.

Tal como já ocorreu em outras distros, a nova versão do Dolphin também veio configurado para usar “propriedades” iguais de visualização em todas as pastas. — Mais uma vez, foi necessário restabelecer manualmente a opção de “lembrar as propriedades de visualização de cada pasta”.

Wine e seus velhos aplicativos em perfeito funcionamento

Wine só pediu alguns segundos para atualizar as configurações, — e já estava funcionando.

Espaço e snapshots (2)


Remoção tardia de Snapshots desnecessários

Finalmente, fiz o que deveria ter feito antes do upgrade: — Deletar os pares de Snapshots do dia 19, — e da última atualização do Leap, no início da tarde (23 Junho), uma vez que o Tumbleweed está funcionando sem problemas.

Os tamanhos indicados na tabela continuam da ordem de “MiB”, — exceto 1 que, de repente, pulou para nada menos que 7,13 GiB. — É quase toda a diferença do upgrade, entre os 14 GiB do Leap (pre 16:01) e os 21 GiB do Tumbleweed (post 18:26).

A essa altura, já haviam desaparecido os Snapshots dos dias 2 e 5 de Junho, — devido à limitação que configurei, no ano passado: ─ No máximo, 4 Snapshots “importantes” e 4 “não-importantes”:

  396  2018-02-26_20-13-05 sudo snapper -c root set-config "NUMBER_LIMIT=4"
  397  2018-02-26_20-13-31 sudo snapper -c root set-config "NUMBER_LIMIT_IMPORTANT=4"

Tanto os Snapshots eliminados automaticamente, quanto os deletados agora manualmente, eram de tamanho modesto, — e a ocupação de espaço em disco mostra uma redução de apenas 1,3 GiB, — de 22,6 para 21,3 GiB.

O passo seguinte será eliminar o Snapshot 143*, de Maio último, — que até o momento é “indestrutível”, por ser o “ponto inicial” (assinalado pelo asterisco). — Foi criado para marcar o início do Leap 15.1, e já não interessa voltar a ele.

Para isso, — na falta de um estudo mais aprofundado do Snapper, — usei uma estratégia empírica (tirada da mera observação), para tornar “corrente” o Snapshot número 159 (pós-upgrade).

A estratégia começou pela instalação de uma bobagem qualquer (KPat), — que gerou um novo par de pequenos Snapshots (160 e 161).

Selecionando o primeiro Snapshot do Tumbleweed, no Grub

Em seguida, reiniciar a máquina, — teclar “End”, para ir ao rodapé do Grub, — e escolher o Snapshot 159.

A identificação não é tão fácil, — o número não é apresentado, e as horas estão em UTC, — mas notar que é o primeiro (de baixo para cima) com Kernel 5.1.7, sempre ajuda.

Indicações do Snapper a rodar um Snapshot anterior, e após torná-lo “ponto inicial”

Ao carregar um Snapshot, ele aparece assinalado por um sinal de menos (159-), — enquanto o Snapshot “em uso” passa a ser assinalado por um sinal de mais (143+), em vez do asterisco.

Após o comando # snapper rollback, é criado um novo Snapshot “single”, — e o sinal de mais se transfere para ele (163+). — Agora, ele será o “ponto inicial”, que não pode ser deletado com um simples peteleco.

Note que isto só foi feito cerca de 20 minutos após iniciar a sessão, — para dar tempo de rodarem os serviços automáticos de manutenção.

Na falta de conhecimento exato de como essas coisas funcionam, evito tratar desses “assuntos sérios”, enquanto o Conky não indicar que cessou a atividade extraordinária. — Tome um café, veja os emails; não seja apressado.

Limpeza dos Snapshots desnecessários

Depois disso, a máquina ainda foi reiniciada mais 2 vezes, — e uma terceira vez pela manhã, — antes de finalmente deletar todos os Snapshots antigos, tornados obsoletos.

Com isso, a ocupação de espaço em disco desabou de 21,4 para 14,8 GiB.

No dia seguinte, já havia mais 3 pares de Snapshots, além do backup do 143

Não tenho dúvidas de que tudo isso pude ser feito em alguns minutos, com 2 ou 3 comandos Snapper, — mas até fazer esse levantamento, talvez não soubesse exatamente o quê procurar, no meio de tantos comandos. — Depois de feito e anotado, fica mais fácil pesquisar.

Agora, estudar como fazer tudo isso pela cartilha:


Packman e Codecs


Instalando VLC dos repositórios “oficiais”

Para limitar as possibilidades de falha, fiz upgrade sem o repositório Packman, — tal como nas vezes anteriores, — e agora aproveitei para estudar melhor sua inclusão no Tumbleweed.

Isso porque, no Leap 42.2, no Leap 42.3 e no Leap 15.0, a inclusão do Packman e a instalação de ffmpeg (+dependências) foi o suficiente para habilitar todos os vídeos no Chromium, — mas no Leap 15.1 isso já não bastou.

Na verdade, devo ter cometido algum erro no Leap 15.1, — ou talvez, o zypper tenha tido alguma mudança de comportamento padrão? — Como não era essencial, fui deixando o tempo passar, e acabei não investindo nisso por 30 dias, até fazer upgrade para o Tumbleweed.

Com a remoção do Packman, o upgrade “limpou” o problema, — talvez sejam aqueles 6 pacotes e 2 padrões que sofreram downgrade, — e posso tentar de novo.

Esse foco em “ffmpeg” se deve aos 8 anos de acomodação com o Kubuntu: — Ao instalar o Chromium, vem junto um pacote “chromium-codecs-ffmpeg”, que resolve tudo, — e você nem toma conhecimento da existência de VLC.

Agora, no Tumbleweed, segui outro caminho, e comecei por instalar o VLC dos repositórios oficiais. — Antes, nunca tinha instalado o VLC.

Com o VLC dos repositórios oficiais, só alguns vídeos passaram a ser exibidos. — Muito poucos vídeos, na verdade.

2019-06-24 14:59:26

# zypper install vlc
...

The following 24 NEW packages are going to be installed:
  gimp-plugin-aa libaa1 libavc1394-0 libcaca0 libcddb2 libchromaprint1 libdvbpsi10 libebml4 libixml10 libmatroska6 libprojectM3
  libprotobuf-lite19 libSDL_image-1_2-0 libshout3 libupnp13 libva-wayland2 libvlc5 libvlccore9 vlc vlc-codec-gstreamer vlc-lang
  vlc-noX vlc-qt vlc-vdpau

The following recommended package was automatically selected:
  vlc-lang

24 new packages to install.
Overall download size: 11,9 MiB. Already cached: 0 B. After the operation, additional 56,8 MiB will be used.
Continue? [y/n/v/...? shows all options] (y):

# rpm -qa --last

vlc-vdpau-3.0.7.1-1.1.x86_64                  seg 24 jun 2019 15:00:36 -03
vlc-3.0.7.1-1.1.x86_64                        seg 24 jun 2019 15:00:33 -03
vlc-codec-gstreamer-3.0.7.1-1.1.x86_64        seg 24 jun 2019 15:00:32 -03
vlc-qt-3.0.7.1-1.1.x86_64                     seg 24 jun 2019 15:00:31 -03
vlc-lang-3.0.7.1-1.1.noarch                   seg 24 jun 2019 15:00:30 -03
vlc-noX-3.0.7.1-1.1.x86_64                    seg 24 jun 2019 15:00:26 -03
libvlc5-3.0.7.1-1.1.x86_64                    seg 24 jun 2019 15:00:24 -03
libupnp13-1.8.4-2.4.x86_64                    seg 24 jun 2019 15:00:24 -03
libmatroska6-1.5.0-1.3.x86_64                 seg 24 jun 2019 15:00:24 -03
libvlccore9-3.0.7.1-1.1.x86_64                seg 24 jun 2019 15:00:23 -03
libva-wayland2-2.4.0-1.3.x86_64               seg 24 jun 2019 15:00:23 -03
gimp-plugin-aa-2.10.12-1.1.x86_64             seg 24 jun 2019 15:00:23 -03
libshout3-2.4.1-2.5.x86_64                    seg 24 jun 2019 15:00:22 -03
libprotobuf-lite19-3.8.0-1.1.x86_64           seg 24 jun 2019 15:00:22 -03
libprojectM3-3.1.0-2.3.x86_64                 seg 24 jun 2019 15:00:22 -03
libixml10-1.8.4-2.4.x86_64                    seg 24 jun 2019 15:00:21 -03
libebml4-1.3.7-1.3.x86_64                     seg 24 jun 2019 15:00:21 -03
libdvbpsi10-1.3.2-1.5.x86_64                  seg 24 jun 2019 15:00:20 -03
libchromaprint1-1.4.3-1.8.x86_64              seg 24 jun 2019 15:00:20 -03
libcddb2-1.3.2-25.15.x86_64                   seg 24 jun 2019 15:00:19 -03
libcaca0-0.99.beta19.git20171003-2.4.x86_64   seg 24 jun 2019 15:00:19 -03
libavc1394-0-0.5.4-18.13.x86_64               seg 24 jun 2019 15:00:18 -03
libaa1-1.4.0-510.15.x86_64                    seg 24 jun 2019 15:00:18 -03
libSDL_image-1_2-0-1.2.12-10.15.x86_64        seg 24 jun 2019 15:00:17 -03

Até aí, não instalei ffmpeg. — Em vez disso, avancei para o VLC do Packman.

Após analisar várias páginas do openSUSE, — divergentes em certos detalhes, — acabei seguindo algumas dicas em “Additional package repositories”:

1) Adicionar apenas “pacman-essentials”, — e não todo o Packman, — para limitar as possibilidades de falha:

# zypper ar -cfp 90 http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials packman-essentials
Adding repository 'packman-essentials' ...........................................[done]
Repository 'packman-essentials' successfully added

URI         : http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials
Enabled     : Yes
GPG Check   : Yes
Autorefresh : Yes
Priority    : 90 (raised priority)

Repository priorities in effect:                                                                   (See 'zypper lr -P' for details)
      90 (raised priority)  :  1 repository
      99 (default priority) :  4 repositories

2) Em seguida, substituir o VLC dos repositórios oficiais pelo do Packman, — para evitar qualquer mistura de pacotes incompatíveis:

2019-06-26 17:53:54

# zypper dup --from packman-essentials --allow-vendor-change
Loading repository data...
Reading installed packages...
Computing distribution upgrade...

The following 13 items are locked and will not be changed by any action:
 Available:
  hplip hplip-debuginfo hplip-debugsource hplip-devel hplip-hpijs hplip-hpijs-debuginfo hplip-sane hplip-sane-debuginfo PackageKit
  PackageKit-backend-zypp PackageKit-branding-openSUSE PackageKit-gstreamer-plugin PackageKit-gtk3-module

The following NEW package is going to be installed:
  libvo-amrwbenc0

The following 49 packages are going to be upgraded:
  gstreamer-plugins-bad gstreamer-plugins-bad-lang gstreamer-plugins-ugly gstreamer-plugins-ugly-lang libavcodec57 libavcodec58
  libavdevice58 libavfilter7 libavformat57 libavformat58 libavresample4 libavutil55 libavutil56 libfaac0 libfaad2 libfdk-aac1
  libgstadaptivedemux-1_0-0 libgstbadaudio-1_0-0 libgstbadvideo-1_0-0 libgstbasecamerabinsrc-1_0-0 libgstcodecparsers-1_0-0
  libgstisoff-1_0-0 libgstmpegts-1_0-0 libgstphotography-1_0-0 libgsturidownloader-1_0-0 libgstwayland-1_0-0 libgstwebrtc-1_0-0
  libopencore-amrnb0 libopencore-amrwb0 libpostproc54 libpostproc55 libquicktime0 librtmp1 libsox3 libswresample2 libswresample3
  libswscale5 libvlc5 libvlccore9 libx264-155 libx265-169 libxvidcore4 sox vlc vlc-codec-gstreamer vlc-lang vlc-noX vlc-qt
  vlc-vdpau

The following package is going to be reinstalled:
  flash-player-ppapi

The following 40 packages are going to change vendor:
  gstreamer-plugins-bad         openSUSE -> http://packman.links2linux.de
  gstreamer-plugins-bad-lang    openSUSE -> http://packman.links2linux.de
  gstreamer-plugins-ugly        openSUSE -> http://packman.links2linux.de
  gstreamer-plugins-ugly-lang   openSUSE -> http://packman.links2linux.de
  libavcodec57                  openSUSE -> http://packman.links2linux.de
  libavcodec58                  openSUSE -> http://packman.links2linux.de
  libavdevice58                 openSUSE -> http://packman.links2linux.de
  libavfilter7                  openSUSE -> http://packman.links2linux.de
  libavformat57                 openSUSE -> http://packman.links2linux.de
  libavformat58                 openSUSE -> http://packman.links2linux.de
  libavresample4                openSUSE -> http://packman.links2linux.de
  libavutil55                   openSUSE -> http://packman.links2linux.de
  libavutil56                   openSUSE -> http://packman.links2linux.de
  libgstadaptivedemux-1_0-0     openSUSE -> http://packman.links2linux.de
  libgstbadaudio-1_0-0          openSUSE -> http://packman.links2linux.de
  libgstbadvideo-1_0-0          openSUSE -> http://packman.links2linux.de
  libgstbasecamerabinsrc-1_0-0  openSUSE -> http://packman.links2linux.de
  libgstcodecparsers-1_0-0      openSUSE -> http://packman.links2linux.de
  libgstisoff-1_0-0             openSUSE -> http://packman.links2linux.de
  libgstmpegts-1_0-0            openSUSE -> http://packman.links2linux.de
  libgstphotography-1_0-0       openSUSE -> http://packman.links2linux.de
  libgsturidownloader-1_0-0     openSUSE -> http://packman.links2linux.de
  libgstwayland-1_0-0           openSUSE -> http://packman.links2linux.de
  libgstwebrtc-1_0-0            openSUSE -> http://packman.links2linux.de
  libpostproc54                 openSUSE -> http://packman.links2linux.de
  libpostproc55                 openSUSE -> http://packman.links2linux.de
  libquicktime0                 openSUSE -> http://packman.links2linux.de
  libsox3                       openSUSE -> http://packman.links2linux.de
  libswresample2                openSUSE -> http://packman.links2linux.de
  libswresample3                openSUSE -> http://packman.links2linux.de
  libswscale5                   openSUSE -> http://packman.links2linux.de
  libvlc5                       openSUSE -> http://packman.links2linux.de
  libvlccore9                   openSUSE -> http://packman.links2linux.de
  sox                           openSUSE -> http://packman.links2linux.de
  vlc                           openSUSE -> http://packman.links2linux.de
  vlc-codec-gstreamer           openSUSE -> http://packman.links2linux.de
  vlc-lang                      openSUSE -> http://packman.links2linux.de
  vlc-noX                       openSUSE -> http://packman.links2linux.de
  vlc-qt                        openSUSE -> http://packman.links2linux.de
  vlc-vdpau                     openSUSE -> http://packman.links2linux.de

49 packages to upgrade, 1 new, 1 to reinstall, 40  to change vendor.
Overall download size: 35,4 MiB. Already cached: 0 B. After the operation, additional 13,3 MiB will be used.
Continue? [y/n/v/...? shows all options] (y):
...
There are some running programs that might use files deleted by recent upgrade. You may wish to check and restart some of them. Run 'zypper ps -s' to list these programs.

# zypper ps -s
The following running processes use deleted files:

PID   | PPID | UID  | User   | Command   | Service
------+------+------+--------+-----------+--------
4196  | 2276 | 1000 | flavio | chromium  |
4247  | 4196 | 1000 | flavio | chromium  |
4249  | 4196 | 1000 | flavio | chromium  |
4291  | 4247 | 1000 | flavio | chromium  |
15235 | 2276 | 1000 | flavio | gimp-2.10 |

You may wish to restart these processes.
See 'man zypper' for information about the meaning of values in the above table.

No core libraries or services have been updated.
Reboot is probably not necessary.

Isso já foi mais do que o suficiente para ver todos os vídeos encontrados no Youtube, Facebook, MeWe etc., ao longo de 24 horas.

Só no dia seguinte instalei o ffmpeg-4, — que não solicitou mais nenhuma dependência, — e tampouco fez qualquer efeito, que o leigo aqui consiga notar.

Pré-visualizações no Dolphin


Falhas de pré-visualização em “modo ícone” no Leap 15.0, em Novembro 2018

Em Novembro de 2018, as pré-visualizações de arquivos no Dolphin do Leap 15.0 falhavam no “modo ícone” para arquivos .ePub e .cbr.

O repositório Packman tinha sido adicionado 4 meses antes (Julho 2018), — porém de modo muito tosco. — Na época, me limitei a substituir o ffmpeg, o que envolveu apenas 10 dependências, entre pacotes instalados ou substituídos.

Falhas de pré-visualização em “modo ícone” no Leap 15.1

Por motivos que não cheguei a investigar, no Leap 15.1 desapareceram as pré-visualizações em “modo ícone” também dos arquivos .kmz e dos vídeos .avi, .flv e .mp4.

Algumas pré-visualizações do Dolphin falham no “Modo Ícone”, mas funcionam no Painal Infor (F11)

Terminado o upgrade para Tumbleweed, permaneceu a mesma situação: — Pré-visualização desses arquivos no Painel Informações, e falha no “modo ícone”.

Falha completa de pré-visualização de vídeos, mesmo com Dolphin-plugins

Até as 16:00 do dia 26 Jun. 2019, o Dolphin do Tumbleweed não apresentava absolutamente nenhuma pré-visualização de vídeos .avi, .flv, .mp4, — embora essa opção estivesse habilitada, e o upgrade tivesse incluído kdesdk-thumbnailers e ffmpegthumbs, que são os requisitos específicos.

Nesse momento, já tinha instalado o VLC dos repositórios oficiais, — e até o dolphin-plugins, por via das dúvidas, — mas não o ffmpeg.

Pré-visualização de vídeos no Dolphin, com Packman-Essentials

Após a instalação do Packman-Essentials e a substituição do VLC, — envolvendo 51 pacotes novos ou substituídos, — finalmente o Dolphin passou a exibir pré-visualização de vídeos.

Só depois disso, instalei o ffmpeg.

Hipótese a examinar: — Talvez fossem as dependências do ffmpeg que possibilitaram pré-visualizar os vídeos no Dolphin, nas vezes anteriores (exceto no Leap 15.1), — e talvez agora essas dependências já foram supridas pelo VLC do Packman, uma vez que agora as pré-visualizações se resolveram com elas, o ffmpeg não trouxe mais nenhuma.

(No entanto, até onde pude constatar, não há indício de dependências comuns, e ignoro por que agora o ffmpeg não solicitou nenhuma).

Grub ampliado


Grub original do openSUSE, com espaço para 4 distros + Snapshots

O Grub do openSUSE vem limitado a um pequeno retângulo, onde caberiam 8 linhas com as entradas para até 4 distros (+opções avançadas) e uma 9ª linha onde caberia a entrada para o submenu dos Snapshots, no final.

Isso é mais do que suficiente para a maioria dos casos, — mas não quando se tem 12 distros. — Preciso de um retângulo para 25 linhas.

Grub ampliado para exibir 12 distros + submenu Snapshots, no final

Para isso, bastou recuperar o backup da personalização feita tempos atrás, — com direito a um fundo antigo, do Leap. — Esse backup do Grub está descrito no relato sobre o Mageia 7 beta2.

Acima - Nas 2 primeiras linhas, openSUSE Tumbleweed + opções avançadas, — e na última linha, o acesso ao submenu dos Snapshots.

Esse Grub do openSUSE Tumbleweed foi usado durante 2 dias, devido à necessidade de acesso aos Snapshots, — mas não é meu Menu de inicialização preferido, pois “não lembra” a última seleção. — Para isso, precisaria ter uma partição /boot separada, em formato ext4, pois o Grub não grava no formato BtrFS da partição-raiz.

Grub do Mageia, com direito a “lembrar” a última seleção

Terminadas as atividades com Snapshots, pude voltar ao Grub do Mageia, — que ainda “lembrava” a seleção do openSUSE, vários dias antes. — Naturalmente, sua atualização é feita após a das as demais distros, para detectar todas as mudanças.

Wicked vs. Network Manager


openSUSE com velocidade de download limitada, usando Network Manager

Ao testar uma conexão de “200 megas” (200 Mbps = 26,1 MiB/s, na prática), lembrei que tinha trocado o Wicked pelo Network Manager, muito tempo atrás, — como uma solução grosseira, para reduzir o tempo de Boot do openSUSE, — e isso estava limitando a velocidade de download, por algum motivo (provavelmente, configuração mal feita).

As velocidades de download não passaram de 4,05 MiB/s, — mesmo do servidor mais “próximo” de casa, — deixando óbvio que algo estava errado.

Conexão do openSUSE normalizada 8 dias mais tarde, ao voltar para o Wicked

Só 8 dias mais tarde, o problema foi solucionado, — de volta ao Wicked.

Com isso, a conexão realmente se tornou “200 megas”, no openSUSE, — mas teve pouco efeito, no que se refere ao download das atualizações.

Espelhos (Mirrors)


Velocidades de download de 436 pacotes em uma atualização do openSUSE, em 3’43’’

Uma atualização de 436 pacotes, com download de 339 MiB, permitiu calcular a média de 1,52 MiB/s, ao longo de 3’43’’, — ao invés dos 26,1 MiB/s, que são o limite real dos “200 megas” (200 Mbit/s).

    Final: uptime 25’45’’ - 45’’ = 25’00’’
   Início: uptime                  21’17’’
Diferença:                          3’43’’

Esse tempo inclui uma demora inicial, — que desde então, tem sido constante em todas as requisições, inclusive, no dia-a-dia do Chromium. — Problema ainda a resolver (1 coisa de cada vez).

Em tese, as atualizações deveriam ser baixadas de um dos 4 espelhos do Brasil

Teoricamente, haveria um redirecionamento (MirrorBrain) para um servidor da rede de espelhos (mirrors) do openSUSE, mais próximo e veloz, — mas na prática, isso não estava funcionando, por aqui.

Uma hipótese razoável, é que o redirecionamento detectasse desatualização (ou outras falhas) nos espelhos mais próximos, — conforme o relato a seguir.

Espelhos locais costumam oferecer apenas os repositórios OSS e Non-OSS

Ao editar os repositórios pelo YaST2 >> Software >> Software Repositories, vi que os espelhos (mirrors) mais próximos costumam oferecer apenas OSS e Non-OSS, — mas não Debug, nem Update, e muito menos Packman.

Portanto, teria de misturar pacotes vindos de diferentes servidores, — e torcer para que estejam sempre sincronizados, sob risco de misturar versões incompatíveis.

Após 3 dias, não tinha encontrado nenhuma orientação simples e clara, — talvez porque se supõe que ninguém precisaria mexer com esse tipo de coisas.

No entanto, consegui entender 2 ou 3 coisas:

Rede de espelhos do Packman, — só Europa e China

Packman sempre teve procedência separada, — e o zypper administra bem as incompatibilidades. — Como habilitei apenas “Packman Essentials” e instalei apenas VLC e ffmpeg, o número de pacotes a baixar é pequeno, e não há de atrasar tanto o download do conjunto das atualizações.

Debug é recomendado apenas para “usuários avançados”, — e nem deveria estar habilitado. — Sim, ignoro de onde veio isso, e desde quando. Apenas vim substituindo as versões, a cada upgrade, conforme as melhores e mais confiáveis receitas-de-bolo.

Enfim, tudo indica que Update só é usado em casos especiais, — em que se prefere que os pacotes não passem por espelhos (mirrors), — e Update-Non-OSS parece só existir para o Leap, não para o Tumbleweed.

Alteração dos espelhos (mirrors) e obtenção das chaves GPG

Com base nisso, apenas desabilitei Debug, — alterei OSS e Non-OSS para o espelho da UFPR, — e obtive as chaves GPG.

Velocidade de download do zypper com espelho (mirror) dentro do País

Depois disso, uma atualização de 83 pacotes fez o download de 420,8 MiB em cerca de 38’’, — com picos de 17,7 a 24,4 MiB/s (pelo menos).

Para manter consistência com o registro anterior, deve-se computar a “demora inicial”, — que agora foi de 7 ou 8 segundos:

420,8 MiB / 46 segundos = 9,15 MiB/s

Após o download, a instalação dos pacotes levou mais 9’14’’, — mas para isso, o remédio é comprar um hardware (CPU) mais adequado aos tempos atuais.

Enquanto durou a “experiência”, foram feitas atualizações nos dias 4, 7, 10, 17, 21 e 25, — sem que tenha percebido qualquer problema. — O openSUSE continuou sólido.

Espelho C3SL do openSUSE Tumbleweed vazio, em 28 Setembro 2019

28 Set. 2019 - O comando # zypper dup acusou irregularidades:

  • Repository 'repo-non-oss' is invalid.
  • Repository 'repo-oss' is invalid.
  • Some of the repositories have not been refreshed because of an error.

Ao examinar o espelho da UFPR, constatei que Tumbleweed não tinha nenhuma pasta OSS ou Non-OSS. — Estava absolutamente vazio.

No espelho da UFAM ainda encontrei Tumbleweed, mas tive a impressão de que estava há muito tempo sem atualização. — Posso estar enganado.

Restabeleci então os repositórios originais, — e uma atualização de 390 pacotes baixou 333,8 MiB em cerca de 6 minutos, ou 360 segundos, — média de 0,93 MiB/s.

Conclusão


Quadro das distros Linux instaladas no Domingo anterior ao upgrade

xxx

Quadro das distros Linux instaladas, logo após o upgrade

xxx

Quadro das distros Linux instaladas, uma semana após o upgrade

xxx

__________________
• Publicado em 24 Jun. 2019
• Desenvolvido até 29 Set. 2019

— … ≠ “•” ≠ … —

openSUSE



Não-debians


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 do Leap 42.2 para 42.3 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.

— … ≠ • ≠ … —

openSUSE



Não-debians