Translate

sexta-feira, 29 de junho de 2018

Upgrade do openSUSE Leap 42.3 para 15.0

openSUSE Leap 15.0 — após refazer algumas poucas configurações

O upgrade do openSUSE Leap 42.3 para 15.0 foi feito por meio de 5 comandos, — depois de eliminar o repositório Packman (único não-oficial que havia); — assegurar que tudo estava atualizado; — e abrir o máximo de espaço livre em disco:

1) No Konsole:

# cp -Rv /etc/zypp/repos.d /etc/zypp/repos.d.Old

# sed -i 's/42.3/15.0/g' /etc/zypp/repos.d/*

# zypper --gpg-auto-import-keys ref

# zypper patch --updatestack-only

Na verdade, o 3º e o 4º (acima) parecem redundantes, — depois de um, o outro não encontrou mais “nada a fazer”.

2) Por fim, no Terminal tty2 — (Ctrl+Alt+F2) — logado como Administrador (root):

# zypper dup

Nesta 2ª parte, recomenda-se encerrar todos os serviços desnecessários; fechar o máximo de aplicativos (de preferência, todos); — melhor ainda, encerrar a sessão de Usuário (ou, de todos os usuários); — mas… decidi arriscar.

Acompanhamento do download de pacotes durante o upgrade do openSUSE Leap

Alternando entre a sessão de Usuário, no tty7 (Ctrl+Alt+F7), e o Terminal tty2 em modo Root (Ctrl+Alt+F2), foi possível acompanhar alguns indicadores pelo Conky, — atividade de Rede e de CPU, Temperatura, Processos etc., — e ainda fazer fotos + Capturas de tela, navegar na web e nas redes sociais.

Apesar dessa “desobediência” às recomendações mais estritas, — bem como a outras, que não pude compreender muito bem, em poucas horas de leitura, — o upgrade transcorreu sem problemas.

Mas, antes, alguns preparativos.

Índice


  • Backup dos Repositórios
  • Remoção do Packman
  • Limpeza dos Repositórios
  • Abrindo espaço em disco
  • Upgrade, propriamente dito
  • Cronologia
  • Comparação de upgrades
  • Atualização do Grub (Mageia)
  • Problemas menores
  • Ainda sem fontes Verdana
  • Wine: CorelDraw, Dreamweaver, MS Word
  • Novo ícone no Menu KDE
  • Recomendações que não segui
  • Kernel 4.4 - em busca de tempos perdidos
  • Packman e video online
  • Remove PackageKit
  • Atualização por comandos
  • Snapper delete, Snapper LIMIT
  • Quadro comparativo
  • Referências
  • Making of
  • Wallpaper

Backup dos Repositórios


Renomeando o backup dos Repositórios do antigo openSUSE Leap 42.2

14:31 # mv repos.d.Old repos.d.Old-42.2

O primeiro passo foi renomear o antigo backup dos repositórios, — feito antes do upgrade anterior (42.2 para 42.3), — pois em breve o atual iria precisar desse nome para seu próprio backup:

Linux5:/etc/zypp # ls

apt-packagemap.d  credentials.d  multiversion.d  repos.d  repos.d.Old  services.d  systemCheck  systemCheck.d  vars.d  vendors.d  zypp.conf  zypper.conf

Linux5:/etc/zypp # mv repos.d.Old repos.d.Old-42.2

Isso não afetaria em nada o openSUSE Leap 42.3, — mesmo no caso de adiar o upgrade, — por isso podia ser feito com toda antecedência, enquanto reunia informações.

É neste momento, que deveria fazer o novo backup, — antes das alterações a seguir, — mas na hora isso passou batido, e só foi feito bem mais tarde.

Remoção do Packman


Números (#), Apelidos (Alias), Nomes e status dos repositórios no Leap 42.3

15:14 # zypper rr packman.inode.at-suse

Remover o repositório Packman, — o único “de terceiros”:

# zypper rr packman.inode.at-suse

Removendo o repositório 'Packman Repository' .........[concluído]
Repositório 'Packman Repository' removido.

Note que neste comando foi usado o complicado “Apelido” (Alias) do repositório, — copiado do próprio Konsole, para evitar erros, — mas bastaria indicar o número, como vim a perceber depois:

# zypper rr 6

Naturalmente, foram localizadas as anotações do ano passado, — quando adicionei o repositório Packman, — pois o que foi feito uma vez, sempre poderia ser feito de novo, depois do upgrade:

  • # zypper ar -f -n packman http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap/ packman

No entanto, esse comando ficou desatualizado, — e precisou ser corrigido (adiante).

Limpeza dos Repositórios


Repositórios do openSUSE Leap 42.3 efetivamente utilizados

16:00 # zypper rr repo-debug
16:00 # zypper rr repo-debug-non-oss
16:00 # zypper rr repo-debug-update
16:00 # zypper rr repo-debug-update-non-oss
16:01 # zypper rr repo-source
16:01 # zypper rr repo-source-non-oss

Aproveitei para fazer uma limpeza, — remover todos os repositórios fora de uso (inclusive o Pendrive usado na instalação inicial, há mais de 1½ ano!), — para deixar tudo mais simples e claro.

Enfim, poderia ter feito essa limpeza toda com um comando só:

# zypper rr 5 6 7 8 9 10 11 12

Abrindo espaço em disco


Abrindo espaço em disco para o upgrade do openSUSE Leap

17:16 $ sudo zypper up
17:19 $ sudo snapper ls
17:21 $ sudo snapper delete --sync 193 194 195 196
17:28 $ sudo snapper delete --sync 197 198
17:33 # zypper clean
... (Restart) ...
18:45 # sudo zypper install calibre
18:49 $ sudo snapper ls
18:49 $ sudo snapper delete --sync 199 200 201 202

A partição de 25 GiB, — definida antes de conhecer o openSUSE, — é claramente inadequada.

A experiência mostra que deveria ter 50 GiB,  — e o upgrade anterior já havia mostrado certo risco de faltar espaço durante o processo.


No final da tarde, — com as dúvidas resolvidas, — foi feita uma última verificação de atualizações do Leap 42.3 (“nada a fazer”); e deletados 3 pares mais antigos de “instantâneos” (snapshots), para abrir espaço.

Com isso, o espaço ocupado caiu de 12,6 GiB para 11,0 GiB, — e o comando zypper clean não trouxe nenhum ganho adicional.

Como tinha havido uma atualização no início da tarde, este último par de “instantâneos” foi deixado, por precaução, até reiniciar o openSUSE e verificar se tudo estava Ok.

Após a reinicialização, ainda foi instalado o Calibre, — o que gerou mais dois pares de “instantâneos” e elevou o uso de espaço em disco para 11,3 GiB.

Ao eliminar esses últimos 4 pares de “instantâneos”, o espaço ocupado caiu para 10,9 GiB (depois voltou a 11,0 GiB), — um ganho pequeno, mas que talvez fizesse toda diferença, entre conseguir ou não completar o upgrade. — Era difícil prever quanto espaço seria ocupado.

Mudança dos Repositórios


Conferindo o trabalho do comando sed, — que não domino

20:09 # cp -Rv /etc/zypp/repos.d /etc/zypp/repos.d.Old
20:09 # sed -i 's/42.3/15.0/g' /etc/zypp/repos.d/*
20:11 # zypper lr -d

Com tudo preparado, — comandos conferidos e enfileirados num arquivo TXT, — foi feito o backup dos repositórios em uso até aquele momento (Leap 42.3):

# cp -Rv /etc/zypp/repos.d /etc/zypp/repos.d.Old

Em seguida, os repositórios foram alterados do Leap 42.3 para Leap 15.0, — tarefa bastante inglória, se você optar pelo trabalho braçal proposto (de modo confuso e vago) nas recomendações oficiais.

Da experiência anterior, eu sabia que isso poderia ser feito com um único comando, — mas ao analisá-lo para o adaptar à nova situação, me pareceu que tinha barras demais, nos lugares errados (embora tenha funcionado, na época!). — Sem compreender a “lógica” daquilo (acima de qualquer dúvida), preferi não arriscar.

Por falta de familiaridade com o comando sed, optei por procurar esse comando na web, — até encontrá-lo “pronto” (e testado):

# sed -i 's/42.3/15.0/g' /etc/zypp/repos.d/*

Em resumo, ele substitui os repositórios “42.3” por “15.0” na pasta onde estão definidos, — mas sempre é bom conferir o resultado, antes de disparar o upgrade.

Upgrade, propriamente dito


Início do upgrade do openSUSE Leap 42.3 para 15.0

20:12 # zypper --gpg-auto-import-keys ref
20:14 # zypper patch --updatestack-only
20:16 # zypper dup

Os 2 primeiros comandos (acima) talvez sejam redundantes.

O primeiro, usei no upgrade anterior, — e não encontrei nada “parecido” nas recomendações oficiais, — mas parece ter funcionado bem, mais uma vez:

# zypper --gpg-auto-import-keys ref
Baixando os metadados do repositório 'Repositório principal (Non-OSS)' .........[concluído]
Construindo o cache do repositório 'Repositório principal (Non-OSS)' ...........[concluído]
Baixando os metadados do repositório 'Repositório de atualização (Non-OSS)' ....[concluído]
Construindo o cache do repositório 'Repositório de atualização (Non-OSS)' ......[concluído]
Baixando os metadados do repositório 'Repositório principal (OSS)' .............[concluído]
Construindo o cache do repositório 'Repositório principal (OSS)' ...............[concluído]
Baixando os metadados do repositório 'Repositório principal de atualização' ....[concluído]
Construindo o cache do repositório 'Repositório principal de atualização' ......[concluído]
Todos os repositórios foram atualizados.

O segundo veio diretamente das recomendações oficiais, — e ao usá-lo agora (depois do outro), parece que não encontrou mais nada a ser feito:

# zypper patch --updatestack-only
Construindo o cache do repositório 'Repositório principal (Non-OSS)' .........[concluído]
Construindo o cache do repositório 'Repositório principal (OSS)' .............[concluído]
Carregando dados do repositório...
Lendo os pacotes instalados...
Resolvendo dependências de pacote...
Nada a fazer.

O terceiro é o que realiza, de fato, o upgrade:

# zypper dup

Os comandos seguintes situam bem o final do processo:

22:38 # zypper ps -s
22:42 # reboot

O comando # zypper ps -s apresentou uma longa lista de programas em atividade cujos pacotes não existiam mais, — inclusive login, systemd, polkit. — Além disso, o Gwenview já não abria, e por fim o Dolphin falhou em mudar de uma pasta para outra, ou apenas recarregá-la (F5).

Por isso, foi encerrada (Logout) a sessão de usuário no tty7, — e usado # reboot no terminal tty2, ainda logado como root.

Uma vez que o Menu de inicialização da máquina é controlado pelo Grub do Mageia, era necessário carregá-lo, para atualizar as entradas relativas ao openSUSE.

Cronologia


Tamanho do upgrade do openSUSE Leap 42.3 para 15.0

20:16 - NLu - # zypper dup
20:17 - NLu - 1489 upgrade;
                     595 downgrade;
                     718 new;
                     302 remove;
                      48 change vendor;
                        7 change arch
20:31 - oSU - Conky: Download 756 KiB/s
20:53 - NLu - Error: Abort, Retry, Ignore?
21:27 - NLu - Installing: 130 / 3040
21:32 - NLu - Installing: 520 / 3040
21:32 - NLu - Installing: 550 / 3040
21:36 - NLu - Installing: 1120 / 3040
21:43 - NLu - Installing: 1550 / 3040
22:04 - NLu - Installing: 1960 / 3040
22:15 - NLu - Installing: 2580 / 3040
22:27 - NLu - Installing: 3040 - Removing paterns
22:29 - NLu - Dracuts
22:32 - NLu - fetchmsttfonts
22:38 - NLu - MS TTF EULA
22:38 - NLu - Finished - # zypper ps -s
22:40 - oSU - Dolphin without preview (F11 right Panel: Info)
22:40 - oSU - Dolphin F5 - Oops
22:41 - oSU - Chromium - close
22:41 - oSU - tty7 (KDE) User Logout
22:43 - NLu - tty2 # Reboot
____________
oSU - Screenshots do openSUSE
NLu - Fotos de celular (Nokia Lumia)

Comparação de upgrades


Dados comparativos dos 2 upgrades do openSUSE Leap

Portanto, depois de uma tarde inteira revisando notas, pesquisando, lendo e fazendo os primeiros preparativos, — o # zipper dup, propriamente dito, fez tudo em pouco mais de 2 horas (das 20:16 às 22:38), — usando conexão de “10 Megas” (1,3 MiB/s).

Pode ter havido 1 ou 2 pequenas demoras, até perceber que o processo aguardava concordar com licenças openSUSE e Microsoft.

Além disso, houve um engasgo, — download parado, aguardando escolha entre “Abort, Retry, Ignore”, percebida às 20:53 (Retry!), — o que pode ter aumentado o tempo total em não mais do que 20 minutos, pois às 20:31 o Conky ainda indicava download contínuo a cerca de 756 KiB/s.

Com isso, o tempo total poderia ser bem semelhante ao do upgrade do Leap 42.2 para 42.3, em 2017 Aug. 03, — cuja duração foi de pouco menos de 2 horas (das 22:38 à 0:26).

Naturalmente, agora existem mais 2 pares de “instantâneos”, — e o espaço usado em disco pulou para 18,5 GiB (bem perto do máximo “real”, dentro dos 25 GiB teóricos), — mas convém testar mais alguns dias, antes de eliminá-los.

Atualização do Grub (Mageia)


Entrada do Grub do Mageia para o openSUSE Leap 15.0 — “e” para Edit / View

# date && update-grub && date
Qui Jun 28 22:47:13 -03 2018
Generating grub configuration file ...
Tema encontrado: /boot/grub2/themes/openSUSE/theme.txt
Imagem Linux encontrada: /boot/vmlinuz-4.9.56-desktop-1.mga6
Imagem initrd encontrada: /boot/initrd-4.9.56-desktop-1.mga6.img
Imagem Linux encontrada: /boot/vmlinuz-desktop
Imagem initrd encontrada: /boot/initrd-desktop.img
Encontrado KDE neon User Edition 5.13 (16.04) em /dev/sda1
Encontrado Debian GNU/Linux buster/sid em /dev/sda3
Encontrado Ubuntu 16.04.4 LTS (16.04) em /dev/sdb1
Encontrado openSUSE Leap 15.0 em /dev/sdb2
Encontrado PCLinuxOS em /dev/sdb3
Encontrado Linux Mint 18 Sarah (18) em /dev/sdc1
Encontrado Slackware 14.2 x86_64 (post 14.2 -current) em /dev/sdc2
Encontrado Arch Linux em /dev/sdc3
Encontrado MX 17 Horizon (17) em /dev/sdd1
Encontrado Devuan GNU/Linux ascii em /dev/sdd3
concluído
Qui Jun 28 22:48:16 -03 2018

  • Obs.: - O Grub do Mageia usa um Tema copiado do openSUSE.

22:48 - Mga - Mageia: # date && update-grub && date + mcedit
22:54 - NLu - Grub: edit - Leap 15.0 (view)
22:55 - NLu - Grub: Leap 15.0 advanced options
22:57 - NLu - openSUSE Leap15 - startup: Conky
22:59 - NLu - openSUSE Leap15 - startup: Panel Launcher icons Oops
____________
Mga - Screenshots do Mageia
NLu - Fotos de celular (Nokia Lumia)

Problemas menores


Primeira sessão do Leap 15.0, — ícones em branco no Painel e Conky com linhas muito espaçadas

Ao carregar o openSUSE Leap 15.0, ele estava praticamente pronto para continuar trabalhando “como na véspera” (ou, no início da tarde), — exceto por uns poucos e pequenos ajustes necessários:

  • Ícones do Lançador do Painel: em branco, mas funcionando. — Bastou remover os lançadores do YaST2, System settings, Chromium, Dolphin, Konsole, — e ao recolocá-los, voltaram a exibir os ícones.
  • Conky sem Verdana: letras menos legíveis e muito espaçamento vertical. — Desabilitadas 3 linhas (Linux10 a 12), por enquanto.
  • Google e redes sociais: logar de novo.
  • KWin do KInfocenter: reconfigurar Tamanho, Posição, Opacidade.
  • Alguns vídeos não funcionam no Google+, e nenhum no Facebook. — Solucionado após reinstalar o ffmpeg do repositório Packman, — dias depois.

Desativação de 3 linhas no ~/.conkyrc, — para caber na altura da tela

A altura excessiva do Conky foi provisoriamente solucionada pela desativação das 3 últimas linhas, — partições do SSD externo.

Ainda sem fontes Verdana


Reinstalação de fontes a partir de arquivos TTF existentes no Wine

1º Jul. 2018 - 23:23 # zypper rm fetchmsttfonts

2 Jul. 2018 - Após 4 dias, ainda não consegui fazer o Conky usar as fontes Verdana, — talvez por questão de prioridades. — Primeiro, foram testadas as soluções mais óbvias, como remover as fontes “oficiais” (fetchmsttfonts) e reinstalar Verdana por caminhos “alternativos” (arquivos TTF do Wine).

Ainda há 2 pistas a seguir, um pouco mais trabalhosas: — (a) Um aviso de erro durante o Boot; e — (b) Um aviso nas Notas de lançamento do Leap 15.

Wine: CorelDraw, Dreamweaver, MS Word


Para abrir o primeiro aplicativo do Wine, bastou aceitar a instalação do wine-mono

Uma vez que o Wine foi mantido (e seus aplicativos ficam na ~/home, que permanece), bastou clicar no Menu — e aceitar a instalação do wine-mono, que faltava, — para abrir CorelDraw, Dreamweaver e MS Word.

Apesar do aviso de que seria preferível instalar o wine-mono pelos canais específicos da distro, aceitar a oferta de o próprio Wine cuidar disso nunca trouxe qualquer problema perceptível.

Teste do CorelDraw com uma antiga “matriz”, — de onde podem ser exportados vários mapas

O CorelDraw, para começar, não teve qualquer dificuldade em “lembrar” (e encontrar) a última pasta com que havia trabalhado, — e abrir uma antiga “matriz” em camadas, — usada para exportar diferentes mapas temáticos de Brasília, sempre que algum deles precise ser atualizado.

Dreamweaver em atualização de cache, — tarefa que cansava o Windows em 2015

O Dreamweaver tampouco teve qualquer dificuldade em já abrir exibindo o último site com que havia trabalhado, conectar-se ao host, — e rapidamente atualizar o cache (15 mil arquivos; 5 mil páginas), — tarefa que, em 2015, já deixava o velho Windows com a língua de fora, neste mesmo hardware.

MS Word só não encontrou as antigas Macros do modelo Normal.dot

Apenas o MS Word, apesar de encontrar e abrir os “Documentos recentes”, não foi capaz de exibir as Macros existentes no modelo “Normal.dot” de 15 anos atrás, — a menos que sejam os velhos neurônios que esqueceram algum detalhe.

Novo ícone no Menu KDE


Atualização do ícone do openSUSE Leap 15 no Menu KDE

O antigo ícone no Menu KDE foi substituído pelo ícone institucional do openSUSE Leap 15, — bem mais sorridente, — comme il faut.

Recomendações que não segui


Grub do openSUSE (desconfigurado), com os snapshots abaixo da última distro

1) Backup:

/etc
/var
/home

Em tese, é possível carregar um “instantâneo” (Snapshot) do openSUSE antes do upgrade, — dentro dele, rodar um # snapper rollback, — e assim voltar ao Leap 42.3.

Porém, na prática, o “instantâneo” não guarda as antigas configurações, — pelo menos, não 100%. — Para restaurá-las, precisaria ter feito esses backups.

Em tempo: - Para ter acesso aos Snapshots, é necessário usar o Grub do próprio openSUSE, — que nesta máquina é chamado a partir do MBR do 2º HDD (sdb): — Basta mudar o “Dispositivo de Boot”, no BIOS Setup.

O acesso aos Snapshots não está nas “Opções avançadas”, — mas no final do Menu, — embaixo da última distro.

A ilustração (acima), — configuração padrão, com um retângulo minúsculo, onde mal cabem as primeiras 4½ distros, — serve apenas para dar uma ideia do caminho até o último Snapshot do Leap 42.3.

Ainda não testei, — por enquanto.

Obs.: - Felizmente, tenho um ótimo backup da antiga configuração de Grub: — A cópia do Tema “openSUSE”, usada no Mageia. — Está fácil restabelecer um retângulo onde todas as distros apareçam ao mesmo tempo (sem necessidade de rolagem), com letras em tamanho bem legível e fotografável.

2) Checking passwd and group in /etc

Before upgrading the system, make sure that /etc/passwd and /etc/group do not contain any syntax errors. For this purpose, start the verification utilities pwck and grpck as root to eliminate any reported errors.

# pwck
usuário 'nm-openvpn': diretório '/var/lib/openvpn' não existe
usuário 'pulse': diretório '/var/lib/pulseaudio' não existe
pwck : nenhuma mudança
# grpck

Sim, fiz a verificação, — apenas o primeiro comando deu resposta, — mas não tinha a menor ideia do que fazer em seguida. Precisaria de mais alguns dias de muita leitura.

Portanto, não fiz nada, a respeito disso, — talvez nem fosse mesmo para fazer nada, — e após 4 dias, ainda não percebi consequências.

Kernel 4.4 - em busca de tempos perdidos


Antigo Kernel 4.4 nas Opções avançadas do openSUSE Leap 15.0

As “Opções avançadas” do Grub do openSUSE oferecem a possibilidade de carregar o Leap 15.0 com o Kernel 4.4.138, — herança do Leap 42.3.

openSUSE Leap 15.0 trabalhando normalmente com Kernel 4.4

Com ele, já foi possível trabalhar por mais de 20 horas (ao longo de 3 dias), sem qualquer inconveniente, — embora, também, sem qualquer vantagem perceptível.

A expectativa era de que, — sem reinstalar o suporte do Packman a vídeos online, — permitisse navegar em “Páginas” do Facebook, sem surtos de CPU e sem lentidão “meia-trava”.

Isso porque, ao instalar o openSUSE Leap 42.2 (Janeiro de 2017), por mais de 8 ou 9 meses ele se mostrou capaz de enfrentar o problema. — Depois, não mais.

As mudanças ficaram registradas no Quadro comparativo, — o que facilita levantar outros dados na sequência temporal de Capturas de tela, — e delimitar uma faixa específica de datas no histórico de pacotes (instalados, atualizados) do openSUSE Leap, para exame mais detalhado:

27 Jul. 2017 - openSUSE Leap ainda navegava bem no recurso “Páginas” do Facebook, mas não exibia vídeos

27 Jul. 2017 - Facebook “Pages” Ok — Videos online ainda inabilitados.

3 Ago. 2017 - Upgrade para Leap 42.3, — e instalação do ffmpeg do Packman. — Enfim, vídeos online.

13 Set. 2017 - Facebook “Pages” Ok, — com Vídeo online, desde 3 Ago. 2017

13 Set. 2017 - Facebook “Pages” ainda Ok — com vídeos online.

28 Set. 2017 - Experiências com Knoppix 8.1.

3 Out. 2017 - Registro do uBlock, — proveniente do Knoppix, — no Chromium do openSUSE Leap.

7 Out. 2017 - Últimas experiências com Knoppix 8.1, — cujo Chromium acabou por se provar inviável para absolutamente qualquer coisa (desktop=kde).

Registro de abuso de CPU e lentidão excessiva em “Página” do Facebook

10 Out. 2017 - Primeiros registros de atividade exagerada de CPU e lentidão ao navegar em “Páginas” do Facebook, no openSUSE Leap.

11 Out. 2017 - Novos registros de inabilidade do Chromium para enfrentar “Páginas” do Facebook, no openSUSE Leap.

23 Out. 2017 - A capacidade do openSUSE para enfrentar “Páginas” do Facebook se tornou incerta

23 Out. 2017 - openSUSE colocado “de molho” quanto à capacidade de enfrentar “Páginas” do Facebook.

19 Dez. 2017 - openSUSE Leap decididamente não mais capaz de enfrentar “Páginas” do Facebook

19 Dez. 2017 - Decididamente, o openSUSE Leap não conseguia mais navegar em “Páginas” do Facebook, sem um surto de atividade de CPU, — e lentidão, devagar-quase-travando.

Nesse retrospecto, agora, fica claro que a questão não era tão simples. — Os videos online foram habilitados em 3 Ago. 2017, — mas a capacidade de enfrentar as “Páginas” do Facebook só começou a falhar em Outubro, cerca de 2 meses depois.

Se esse levantamento destrói aquela hipótese, — ou seria melhor dizer aquela “vaga impressão”, — pelo menos delimita um período a examinar, no “Histórico de pacotes” (instalados, atualizados), além de sugerir o exame de possível interferência do uBlock na origem do fenômeno.

No entanto, a mera desativação do uBlock também não resultou na reversão do problema.

Obs.: - Cabe notar que este problema foi primeiramente notado no Debian (além do velho WinXP), pelo menos desde 2015, — muito antes de conhecer uBlock, — e afeta igualmente (ou mais) o Firefox / Iceweasel, neste hardware.

Nenhum pacote sem manutenção, a julgar pelo # zypper lifecycle

Cabe notar que o Kernel 4.4 não aparece no Gerenciador de pacotes do YaST2, — é como se não existisse. — Por isso, nada sugere que ainda venha a receber revisões.

O # zypper lifecycle não indica qualquer pacote sem manutenção, — mas se o YaST2 nem assinala a existência do Kernel 4.4, é difícil saber se o comando foi capaz de percebê-lo.

Opções avançadas do openSUSE Leap 15.0 no Grub gerado pelo Mageia

Curiosamente, nas “Opções avançadas” do Grub gerado pelo Mageia existe a possibilidade de carregar o Leap 15.0 também com o Kernel 4.4.132, mais antigo, — mas não há motivo para usá-lo.

Packman e video online


Substituição do ffmpeg “oficial” pelo do Packman

2 Jul. 2018 - Uma vez constatado que o mero uso do Kernel 4.4, — sem o ffmpeg do Packman, — não traz de volta a capacidade perdida de enfrentar “Páginas” do Facebook, não havia mais motivo para continuar impedido de ver a maior parte dos vídeos do Google+ e todos do Twitter e do Facebook.

Primeiro, o novo comando para instalar o repositório Packman, específico para o Leap 15.0, — depois refresh, — e tentar instalar o novo ffmpeg:

09:10 # zypper ar -cfp 90 http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.0/ packman
09:10 # zypper refresh
09:11 # sudo zypper install ffmpeg

Carregando dados do repositório...
Lendo os pacotes instalados...
'ffmpeg' já está instalado.
Existe um candidato à atualização para 'ffmpeg', mas ele é de um fornecedor diferente. Use 'zypper install ffmpeg-3.4.2-lp150.3.1.x86_64' para instalar este candidato.
Resolvendo dependências de pacote...

Nada a fazer.

09:13 # zypper install ffmpeg-3.4.2-lp150.3.1.x86_64
09:16 # zypper ps -s

Os seguintes processos em execução usam arquivos removidos:

PID  | PPID | UID  | Usuário | Comando  | Serviço
-----+------+------+---------+----------+--------
3230 | 2450 | 1000 | flavio  | chromium |     
3318 | 3230 | 1000 | flavio  | chromium |     
3347 | 3318 | 1000 | flavio  | chromium |     

Convém reiniciar estes processos.
Consulte 'man zypper' para informações sobre o significado dos valores na tabela acima.

Remove PackageKit


Remoção do PackageKit, — para desativar o Atualizador / Notificação de atualizações

8 Jul. 2018 - Para evitar a reinstalação de pacotes “recomendados”, — removidos por opção pessoal, — o comando zypper deveria ter esse formato (que usava diariamente no Tumbleweed):

# zypper dup --no-allow-vendor-change

Como isso não foi feito, o PackageKit voltou a se instalar durante o upgrade, — e dias depois botou as manguinhas de fora, exibindo no Painel uma notificação de atualizações.

Por coincidência, já tinha aberto o TXT para anotar o retorno (output) do zypper up do dia, — estava só aguardando alguns minutos, para não encavalar com eventuais tarefas agendadas de manutenção de BtrFS, Snapper, Grub etc., — muito comuns nos primeiros minutos da primeira sessão do dia.

Dado que as anotações sobre as remoções anteriores do PackageKit estavam dispersas em 2 pastas diferentes, — Leap e Tumbleweed, ambas de 2017, cada uma com inúmeros arquivos TXT e várias subpastas (e igual bagunça impera nos Bookmarks das 2 versões), — a nova remoção acabou sendo feita sem consulta.

Primeiro, foram removidos os pacotes diretamente relacionados ao PackageKit, — exceto um, que ameaçou com consequências meio assustadoras, — mas o resultado não foi completo.

Remoção do plasma5-pk-updates para desabilitar notificações do Atualizador

Após reiniciar, o aviso de atualizações permaneceu no Painel, — e reclamando a falta do PackageKit.

Uma pesquisa por “update” encontrou mais um arquivo suspeito, — e depois de também removê-lo desapareceram, tanto a reclamação, quando a notificação de atualizações. — Pelo menos, por enquanto.

Atualização por comando


Atualizador no Painel, — prático, — porém de leitura difícil (e meio inútil); impossível copiar

Embora o openSUSE tenha sido instalado em Janeiro de 2017, seu TXT de histórico de pacotes (pacotes_historico-zypper-up_Leap.txt) só começou em Outubro daquele ano, — pois até então, foi usado o “Atualizador”, diretamente a partir do aviso no Painel, — sem chance para selecionar e copiar a lista.

Aliás, até ler é difícil, além de pouco útil, já que as letras maiores dizem sempre a mesma coisa (openSUSE + números), — e as letras miúdas gastam mais da metade do espaço disponível para repetir “Recommended update for”. — Quando começa o que de fato interessa, três pontinhos, e acaba o espaço. E, sim, há um monte de espaço desperdiçado, à direita.

Portanto, o histórico de Janeiro a Outubro de 2017 precisa ser recuperado do /var/log/zypp/history, — atualmente com 20.430 linhas, — para resumir um pouco e facilitar a consulta a qualquer momento, inclusive a partir de outras distros.

Facilitando o controle num criadouro de distros

Isso pode não ter utilidade para 99% dos usuários Linux, — mas, neste caso particular, é o que se chama “uma mão na roda”. — Imagine, ficar abrindo dúzias de arquivos espalhados nos /var/log de 12 distros (afora as que já foram desinstaladas).

Atualmente, só continuam em uso os “atualizadores” do Mint (mintUpdate), pois o apt ignora as regras específicas dele, e poderia descaracterizá-lo, — e do Mageia (mgaapplet), até encontrar tempo para aprender a lidar com urpmi &tc. — No caso do Mint, o Synaptic facilita pesquisar o Histórico (e copiá-lo no mesmo formato do Kubuntu, Debian, Devuan, MX Linux, PCLinuxOS). — No mgaapplet, também é fácil copiar a lista de atualizações (e datá-las no Kate).

Snapper delete, Snapper LIMIT


Eliminação do último snapshot do openSUSE Leap 42.3, após 10 dias de teste

2018-07-08_20:44 $ sudo snapper delete --sync 144 145 146 147 148 149
2018-07-08_20:47 $ sudo snapper delete --sync 138 139
2018-07-08_20:49 $ sudo snapper delete --sync 150 153 151 152

Passados 10 dias desde o upgrade, — sem aparecer nenhum problema, — chegou a hora de deletar o último “instantâneo” (snapshot) do Leap 42.3, indicado pelos pares “138 139”, para trazer a um nível razoável o espaço ocupado na partição-raiz.

Primeiro, foram deletados outros “instantâneos” de menor importância (de 144 a 149), — mas isto reduziu muito pouco o espaço ocupado, — de 19,8 para 19,4 GiB.

Após deletar o último par do Leap 42.3, o espaço ocupado despencou para 12,2 GiB.

Deletar mais 4 pares reduziu o espaço ocupado para 12,0 GiB, — e atualizações regulares do dia-a-dia aumentaram pouco essa taxa:

 1 Jul. - 22:34 - 18,6 GiB
 2 Jul. -  9:14 - 18,9 GiB
          18:30 - 19,1 GiB
 8 Jul. - 20:44 - 19,8 GiB - snapper delete (I)
          20:46 - 19,4 GiB - snapper delete (II)
          20:48 - 12,2 GiB - snapper delete (III)
          20:50 - 12,0 GiB
11 Jul. - 18:58 - 12,3 GiB

Configurações do Snapper, — inclusive limitação do número de snapshots, — no openSUSE

Quando se tem uma partição-raiz de tamanho tão inadequado (25 GiB), é prático limitar um pouco o número de snapshots, — e deixar ao sistema a escolha de quais deletar primeiro, preservando os mais importantes.

Em 2017, cheguei a impor um limite de 2 snapshots “importantes” e 2 “comuns”, — mas depois de um ano concluí que 4 de cada um não causavam uso excessivo de espaço, — e dão um pouco mais de segurança:

2017-07-03_00:05 # snapper -c root set-config "NUMBER_LIMIT=2"
2017-07-03_00:05 # snapper -c root set-config "NUMBER_LIMIT_IMPORTANT=2"

2018-02-26_20:13 $ sudo snapper -c root set-config "NUMBER_LIMIT=4"
2018-02-26_20:13 $ sudo snapper -c root set-config "NUMBER_LIMIT_IMPORTANT=4"

Quadro comparativo


Comparativo dos sistemas Linux instalados em 28 Jun. 2018

28 Jun. 2018 - Durante o dia, foram atualizadas as distros, — em ordem “decrescente” (de Linux12 para Linux1, e por fim Linux2), — para no final atualizar o Grub do Mageia, que comanda o Menu de inicialização da máquina:

10:15 - Devuan
11:02 - MX Linux
11:27 - Arch Linux
12:01 - PCLinuxOS - (revisão de Kernel)
12:50 - openSUSE Leap 42.3 - (preparando upgrade)
18:00 - Debian testing
18:05 - KDE Neon*
18:13 - Mageia

A maior parte do dia foi passada no openSUSE Leap 42.3, — a preparar o upgrade para 15.0.

Nesse intervalo entre o início e o final da tarde, foram revisados os registros (não publicados) do upgrade do Leap 42.2 para 42.3, — e pesquisadas orientações (oficiais ou não) sobre o upgrade para o Leap 15.0.
____________
(*) Atualizações do KDE Neon também servem como “detector” de revisões de Kernel para o Kubuntu 16.04 e o Mint 18, — cujo KDE não “evolui” como o dele. — Se o Neon não recebe revisão de Kernel, não há mudanças no Kubuntu e no Mint a serem incorporadas pelo Grub do Mageia (ou a serem inseridas no Quadro comparativo).

Referências


Referência de repositórios adicionais para o Leap 15.0, — bem como para o 42.3 e o Tumbleweed

No upgrade anterior, tinha me limitado a seguir uma “receita pronta”, — de apenas 4 comandos, — publicada por Rafi X em uma comunidade openSUSE do Google+:

I started as root in GUI:

# cp -Rv /etc/zypp/repos.d /etc/zypp/repos.d.Old
# sed -i 's,42\.2,42.3,g' /etc/zypp/repos.d/*
# zypper --gpg-auto-import-keys ref

I run this as root in terminal (CTRL+ALT+F1)

# zypper dup

And after that i watch some videos in YouTube to relax.

Depois de pesquisar e ler durante a tarde inteira e o início da noite, foi praticamente isso que acabei por fazer agora, — com pequenas alterações, — mas não podia deixar de ler ao máximo, e verificar cada detalhe, para estar certo do que iria fazer:


Outras informações levadas em conta estão em algumas postagens anteriores, aqui mesmo:


Making of


Uso do KRename para renomear as fotos de celular pela data de criação

A cronologia pode ser obtida de vários arquivos de sistema, — na pasta /var/log, — mas aqui foram usadas outras fontes:

1) Capturas de tela pelo gnome-screenshot, nomeadas no formato:

gnome-screenshot -p -f "/(path)/$(date +%F_%H-%M-%S)_oSU.jpg"

2) Dados Exif das fotos de celular, usados para renomeá-las, — com o pyRenamer ou o KRename:

2.1) pyRenamer
{imageyear}-{imagemonth}-{imageday}_{imagehour}-{imageminute}-{imagesecond}_NL.jpg
2.2) KRename — preservando alterações feitas após a 15ª letra do nome original
[creationdate;yyyy-MM-dd_HH-mm-ss]_NL[$16-[length]]

Fotos e capturas de tela automaticamente enfileiradas em ordem cronológica

Com isso, fotos e capturas de tela, — reunidas em uma pasta, — se enfileiram cronologicamente.

Em seguida, basta examinar a sequência de imagens pelo Gwenview, — acrescentando indicações dos tópicos no final dos nomes, — e um comando para obter o levantamento completo:

$ ls -1 >> cronologia.txt

3) Comando history — com datação iniciada há cerca de 1 ano:

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

Wallpaper


Foto de Paraty (RJ), Brasil, 19 Mar. 2010, por Florian Höfer

Wide street in the touristy colonial city of Paraty, Rio de Janeiro state, Brazil, 19 March 2010, by Florian Höfer.

_____________
Publicado em 29 Jun. 2018, às 5:57; e desenvolvido até 2 Julho, no openSUSE Leap 15.0.

— … ≠ • ≠ … —

openSUSE



Não-debians


quarta-feira, 13 de junho de 2018

Plasma 5 KDE no MX Linux - uma experiência

Plasma 5 KDE quase pronto, — sem PIM-Baloo-Akonadi, — no MX Linux

MX Linux é uma implementação do Debian, — com base no antiX; — mas, ao contrário do Debian, ambos, sem SystemD.

Índice


  • ISO, Torrent, K3b
  • Instalador gráfico
  • cli-installer
  • xx
  • xx
  • xx

Referências



ISO, Torrent, K3b


Verificação md5sum da imagem MX-17.1_x64.iso

23 Mai. 2017 - Torrent da imagem MX-17.1_x64.iso (13-Mar-2018, 09:55 = 1.2G), — verificação de md5sum (online): 54619bb7ea08a9dae047580b559cc678 << MX-17.1_x64.iso; — e gravação em DVD pelo K3b.

Instalador gráfico


Instalador sem reação, coberto por pedaços de janelas que estiveram sobre ele

Foram feitas várias tentativas de instalação nos dias 23 e 24 de Março, sem sucesso, — devido a uma falha já discutida no Forum, — ao que parece, relacionada a certos modelos de vídeo (onboard Intel antigo, no caso).

Após selecionar as partições e clicar ¨Next", a janela do Instalador não reage mais, nem se atualiza. — Por isso, foram carregadas várias sessões Live MX Linux nos dias 23 e 24 de Maio, — com diferentes opções selecionadas em F6: Safe video, Failsafe, Nomodeset, Modesetting.

Mais tarde (depois de instalado pelo cli-installer), foram feitos 2 testes melhor controlados, na tentativa de se descobrir as causas deste problema, — que parece ser específico desse hardware:


O mesmo instalador funcionou sem problemas em sessão Live antiX

Ainda no dia 24 de Maio, o mesmo Instalador funcionou perfeitamente em sessão Live antiX, — que permaneceu instalado por 2 semanas, até ser substituído pelo MX Linux.

cli-installer


Parâmetros da sessão Live MX Linux

O que finalmente funcionou foi carregar nova sessão Live MX Linux (configurada apenas quanto ao Idioma e Fuso horário), — e utilizar o cli-installer em uma janela de Terminal, — para documentar por capturas de tela, além de copiar comandos e saídas:

— … ≠ • ≠ … —

Without-SystemD



    Debian's