Páginas

▼

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


às

Nenhum comentário:

Postar um comentário