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 # 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.

— … ≠ • ≠ … —

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


    segunda-feira, 4 de junho de 2018

    Slackware 14.2 KDE Plasma 5 - instalação

    Slackware 14.2 Live Plasma 5 KDE, instalado e configurado

    O Slackware Live Plasma 5 KDE (by Alien Bob) já tinha sido instalado em 2017-08, — e funcionou sem problema algum durante 9 meses, — mas foi escangalhado por falha humana durante uma atualização, na última semana.

    • Antes dele, também havia instalado o Slackware 14.2 “padrão” (KDE4).

    Essa terceira instalação é uma oportunidade para registrar todo o processo com mais detalhe e exatidão, — incorporando alguma coisa aprendida no último ano.

    Ao longo deste registro, também serão comparadas algumas diferenças entre a instalação pela ISO Live Plasma (by Alien Bob), — usada agora, — e a Install ISO, documentada em 2018-07 mas ainda não relatada.

    Índice


    • ISO, Download, K3b
    • Boot & Kernel
    • Preparação das partições
    • Instalador
    • Keymap
    • Add Swap
    • Um pequeno descuido
    • Target
    • Install
    • Configure
    • Ainda na sessão Live
    • Depois da instalação
    • Boot, grub-install & adduser / useradd
    • Configurações do KDE
    • Menu de inicialização
    • Montagem de partições adicionais
    • PIM, Baloo, Akonadi
    • Conky
    • Wallpapers e Busca no Dolphin

    Referências



    ISO, Download, K3b


    Foi utilizada a imagem slackware64-live-plasma5-current.iso de 2018-04-23 (4.2 GiB) baixada de Alien Base em 2018-06-01, — aprovada na verificação md5sum e gravada em DVD pelo K3b, — que notificou erro aos 98% (para variar).

    Boot & Kernel


    Tecle TAB para outras Opções, — antes de selecionar Teclado e Idioma

    Na tela inicial, o Menu de Boot oferece:

    • Start PLASMA Live — TAB to edit Options!
    • Non-US Keyboard selection
    • Non-US Language selection
    • Memory test
    • Boot from local drive

    Convém começar pelo TAB, — antes de selecionar Teclado e Idioma.

    Na Install ISO, aviso explícito de 2 minutos para verificar opções de Kernel teclando F2

    • Na Install ISO, isso fica mais evidente, — pelas explicações dadas antes de completar o Boot, — com menção à tecla F2 para ver quais são as Opções.

    Menu de sessões na tela de Login do Slackware Live Plasma5

    Após escolher “Brasil” para Teclado e Idioma, o restante do Boot leva à tela de Login, — senha: “live”, — onde se pode escolher entre sessões Lumina, LXQt, Plasma, Xfce ou Plasma (Failsafe).

    O Teclado ABNT2 funcionou com perfeição, — principalmente depois de configurar a tecla de acesso ao 3º Nível, — mas dessa vez o Fuso horário (TZ) se manteve sempre no padrão UTC.

    • A autenticação foi rejeitada várias vezes, mas faltou registrar se de fato foi tentada, — em System settings > Date & Time, — a mesma senha “live”, que o comando “su” orienta a usar no Konsole.

    Preparação das partições


    Preparação das partições para instalar o Slackware Live Plasma 5 KDE

    As partições de destino foram formatadas e rotuladas pelo GParted, na própria sessão Live Plasma 5 KDE, — antes de iniciar o setup2hd:

       sdc2  → ext4 → Linux8 → /
       sdc6  → ext4 → Home8  → /home
       sdc10 → swap → Swap8  → Swap

    Preparação das partições pelo cfdisk (2017)

    • No caso da Install ISO, isso pode ser feito pelo cfdisk ou pelo fdisk, — antes de iniciar o setup.

    Partições que formam o “Slot 8”, no 3º HDD

    Estas partições, — Linux8, Home8, Swap8, — são as mesmas onde o Slackware já tinha sido instalado duas vezes, ao longo de 2017.

    Não existe mistério cabalístico, nem ”numerologia”, nessas escolhas, — são apenas parte de um esquema de “slots” planejado no final de 2016 para instalar até 12 distros em dualboot (ou multiboot), — onde qualquer uma possa ser reinstalada ou substituída, sem afetar as demais.

    O “desenho” simétrico visa facilitar essa tarefa, — embora não garanta contra burradas.

    Instalador


    Mesmo instalador nas versões “Install” (2016) e “Live Plasma5” (2018) do Slackware

    No Konsole, o script de instalação “setup2hd” foi executado como super-usuário pelo comando:

    # /usr/local/sbin/setup2hd

    Embora apresente 5 itens em forma de “Menu” (além do Help e Exit), a experiência já mostrou que o caminho é começar pelo começo, — “Remap your Keyboard”, — pois os demais passos são automaticamente enfileirados, até completar a instalação.

    • Na segunda instalação do Slackware (2017-08), comecei pelo meio, — Target (só “para ver”), — e nunca mais consegui voltar ao “Menu”, para cumprir as etapas anteriores.

    No caso da Install ISO, você já está logado como Root desde o início, — e basta o comando:

    # setup.

    Keymap


    Seleção e teste do layout de Teclado ABNT2 (pt_BR)

    A seleção do layout de Teclado não apresenta dificuldade alguma, — no caso do Brasil, o “ABNT2” é único e inconfundível, — e o acesso ao 3º Nível passou no teste.

    Add Swap


    Percorrer (↓↑) e desmarcar (Space) as partições Swap que não devem ser usadas

    Tanto o setup2hd (Live) quanto o setup (Install ISO) pré-selecionam todas as partições Swap encontradas, mas ao contrário de outros instaladores, — que não dão aviso disso, e exigem muito trabalho para des-selecionar (sendo que alguns nem dão essa opção), — aqui é fácil e rápido percorrer (↓↑) e desmarcar (Space) as partições que já pertencem a outras distros.

    Isso merece muita atenção, — para quem está acostumado com instaladores onde basta “destacar” (highlight) e clicar Ok, — pois uma distração pode escangalhar suas outras distros, e dar trabalho para consertar depois.

    • Na primeira instalação (2017-07), fiz isso corretamente.
    • Na segunda instalação (2017-08), essa etapa foi pulada por desleixo; mas é fácil configurar uma partição Swap mais tarde, no /etc/fstab.
    • Agora, na terceira instalação, bastou um descuido, e isso custou horas de trabalho, para consertar, depois.

    Um pequeno descuido


    Se tiver outra distro, não clique em lugar algum antes de desmarcar sua partição Swap

    Atordoado ao perceber o descuido, tentei selecionar o texto para copiar, — não me pergunte para quê, — e isso valeu como um Ok.

    • De qualquer jeito, não havia opção de “Voltar”, — só restava matar o processo (ou Power Off, em último caso), — mas fica o lembrete sobre diferenças entre os instaladores gráficos, a que estamos acostumados ultimamente, e instaladores (entre outros scripts) que usam bibliotecas ncurses.

    Em um piscar de olhos, o instalador do Slackware altera os identificadores UUID e apaga os rótulos (Label) de todas as partições Swap que não tenham sido expressamente desmarcadas, — e faz isso de imediato, — agora mesmo.

    Não espera pelas etapas seguintes (Target partitions: Root, Home), para apresentar um resumo explícito, — com uma cambulhada de partições, — pedir confirmação, tornar a avisar etc.

    • Neste ponto, o processo foi interrompido (mas o estrago já estava feito!), — e iniciada outra sessão Live, para recomeçar a instalação. — Por isso, as Capturas de tela com horários bem diferenciados.

    Target


    Escolha da partição-raiz (Root), previamente formatada e rotulada

    Como a partição “Linux8” (sdc2) já estava formatada, bastou escolher e seguir adiante.

    Escolha e atribuição do ponto de montagem à partição /home

    O mesmo quanto à partição /home, — bastava escolher e atribuir o ponto de montagem.

    Resumo das partições de destino, — Raiz (Root) e /home

    Ao concluir a escolha das partições de destino (Target), é apresentado o sumário para aprovação.

    Swap simplesmente não aparece, — isso já ficou para trás.

    Install


    Fase de instalação, — “processing 25 Slackware Live modules”

    Devido à baixa taxa de transferência do DVD, a fase de instalação (Install) levou 1h 41min, — das 15:44 às 17:25 (UTC), — sem nenhuma atividade de Rede.

    Embora fale em “25 Slackware Live modules”, de fato foram instalados 22 dos 25 disponíveis.

    Configure


    Configurações oferecidas ao final da instalação do Slackware

    Das 4 configurações oferecidas imediatamente após a parte automática da instalação, 2 foram descartadas com toda segurança, — criação de um Pendrive de Boot e instalação do Lilo, — pois a experiência já mostrou que o Lilo não ajuda o Grub do Mageia a obter dados corretos do Slackware.

    Quanto ao Pendrive, pode ser substituído pelo DVD, — meio físico usado justamente para guardar por muitos anos. — O CD do Kurumin 7, por exemplo (gravado em 2008), foi usado novamente em 2016.

    • Add further Live modules - Não
    • Criar Pendrive de Boot - Não
    • Instalar Lilo - Não
    • Carregar GPM no Boot - Sim

    A primeira oferta ainda é uma sopa de letras meio incompreensível e, mais uma vez, também foi descartada, por enquanto.

    Seleção e cópia de textos / comandos com o Mouse, em tty2

    A quarta permite copiar comandos e respostas fora do ambiente gráfico, usando o mouse.

    Para configurar a Rede, dessa vez foi escolhido Network Manager

    Nas duas instalações anteriores, a Rede foi configurada com DHCP, — e na segunda não há lembrança de problemas. — Desta vez, foi selecionado Network Manager, e funciona bem há uma semana.

    Sem alterações nos “Startup services”

    Não há registro de que tenha alterado alguma coisa nos “Startup services” propostos, — a menos que CUPS estivesse inicialmente marcado. — Passou batido que NTPD estava desmarcado.

    Dessa vez, foram descartadas as “custom screen fonts”.

    Hora UTC no sistema e Fuso horário do Sudeste do Brasil

    Hora UTC no sistema, — Fuso horário do Sudeste do Brasil.

    Escolha do gerenciador de janelas

    Window manager, — xinitrc-plasma.

    Última configuração, — senha de Root

    Senha de Administrador (Super User).

    — “System configuration and installation is complete” —

    Ainda na sessão Live


    Ao sair do instalador, a data do sistema avançou um dia

    14:40 - (17:40 UTC) - O Reboot do Instalador foi descartado, — e o Relógio do sistema avançou um dia.

    Desativação do os_prober no arquivo /etc/default/grub, pelo editor do Midnight-Commander (mcedit)

    15:34 - (18:34 UTC) - Ainda na sessão Live, foi editado o arquivo /etc/default/grub pelo editor interno do Midnight-Commander (mcedit) em modo Root, para desabilitar os_prober, — de modo que, quando o Grub for instalado, cuide apenas das entradas referentes ao próprio Slackware, — necessárias para o Grub do Mageia obter os parâmetros a serem usados no Menu de inicialização* da máquina:

    GRUB_DISABLE_OS_PROBER=true

    • Notar que a partição “Linux8” estava montada como /setup2hd/, — e a edição ficou datada do dia “3”.

    16:33 - Depois que foi dispensado o Reboot do instalador, a única opção de saída era Logout. — Na tela de Login, também estavam desabilitadas as opções de Reiniciar ou Desligar. — Foi usado o comando Reboot pelo tty2.

    Depois da instalação


    Rotulando (Label) as partições Swap, de novo, no openSUSE (sem Swap)

    16:39 ~ 16:45 - O Menu de inicialização* não conseguiu carregar o Mageia, — embora nenhum dos dois tivesse mudado. — Por sorte, o openSUSE Leap acabou por carregar (sem Swap).

    Atribuição do novo UUID de “resume device” em /etc/default/grub

    16:55 ~ 19:01 - Pelo openSUSE, foi possível examinar e corrigir a situação, — causada pela mudança de UUID das partições Swap das 12 distros, — graças ao “File manager - Root mode”:

    • Rotular de novo todas as partições Swap (Swap1 ~ Swap12). — Esses rótulos (Label) não têm função, no caso do Swap, — mas ajudam muito no dia-a-dia.
    • Editar os arquivos /etc/fstab das outras 11 distros, com o novo UUID dos respectivos Swap.
    • Editar os arquivos /etc/default/grub das 4 distros que incluem “resume device” por padrão, — openSUSE, Mageia, PCLinuxOS, Manjaro, — com o novo UUID dos respectivos Swap.

    Busca por “resume” em um /boot/grub/grub.cfg com todas as distros instaladas na máquina

    Para conferir quais distros incluíam “resume device”, fiz uma busca por “resume” no /boot/grub/grub.cfg do Mageia.

    19:09 ~ 19:47 - Carregadas 3 distros para conferir o conserto geral, — e atualizar o Grub de cada uma, de modo a incorporar o novo UUID de “resume device”, — para que no final o Grub do Mageia pudesse extrair os dados corretos de cada uma.

    Carregado também o Slacware, para instalar e configurar o Grub, — de modo que o Mageia pudesse extrair seus dados e incluí-lo no Menu de inicialização*:

    1. Leap
    2. PCLinuxOS - 19:13
    3. Manjaro - 19:47
    4. Slackware - 19:55 — criar Usuário e instalar Grub
    5. Mageia - 21:38

    Em outras distros, — que não especificam “resume device” em /etc/default/grub, — ainda foi necessário pesquisar um pouco mais.

    Localizando os arquivos de configuração que faziam referência ao antigo UUID do Swap

    No caso do Devuan 2, a correção do UUID errado passou a ser feita automaticamente, pelo próprio sistema, — a cada atualização do Kernel, — usando o novo UUID, que havia sido manualmente corrigido em /etc/fstab:

    W: initramfs-tools configuration sets RESUME=UUID=18bbe3d4-502f-469f-8fdc-747db259e48d
    W: but no matching swap device is available.
    I: The initramfs will attempt to resume from /dev/sdd11
    I: (UUID=2c1de7d8-4558-4ea8-9f3b-41dcc00eadd9)
    I: Set the RESUME variable to override this.

    Para localizar os arquivos do sistema que mantinham o antigo UUID do Swap, foi usado o Krusader - Root mode, e a partir dele foi chamado o KFind, — para busca por “texto” no interior de todos os arquivos existentes na pasta /etc e suas subpastas. — Assim, foi fácil descobrir onde se encontra sua configuração de resume device:

    /etc/fstab-disk-manager-save
    /etc/initramfs-tools/conf.d/resume

    Uma vez editados ambos os arquivos, cessaram as mensagens de erro & correção automática a cada atualização de Kernel o Devuan 2.

    __________
    (*) - Menu de inicialização se refere sempre ao Grub controlado pelo Mageia, para carregamento de todas as distros. — Por esse motivo, o Mageia costuma ser carregado por último, para que seu Grub incorpore todas as eventuais atualizações das demais distros. — Por segurança, o Grub do openSUSE também gera um segundo Menu de inicialização, mas não foi necessário usá-lo (bastaria selecionar o 2º HDD como “Dispositivo de Boot”, no BIOS Setup).

    Boot, grub-install & adduser / useradd


    Boot e Login como Root no tty2

    19:52 - O Menu de inicialização* ainda apontava a antiga partição (UUID) e o antigo Kernel 4.9.37 do Slackware. — Teclado “e” para editar. — Alterado para Kernel 4.14.35. — “Ctrl+X” para executar.

    Contra toda expectativa, carregou, — mesmo com UUID errado.

    19:54 - Tela de Login gráfico (SDDM) do Slackware, — mas ainda não existia conta de Usuário.

    19:55 - Acessado tty2 (Ctrl+Alt+F2), — e feito Login como Root.

    Instalação do Grub e criação da conta de Usuário

    20:01 - Instalação do Grub, — necessário para que o Grub do Mageia extraia os dados corretos.

    20:16 - Criação da conta de Usuário pelo comando useradd. — Melhor seria adduser, — interativo, e bem mais amigável.

    20:17 - Login gráfico (SDDM).

    Slackware, enfim, logado como Usuário, em sessão Plasma 5 KDE

    20:18 - Sessão Plasma 5 KDE carregada, — indicando 23:18 (UTC).

    20:19 - Alteração do Fuso horário.

    20:21 - Configuração do Spectacle.

    20:22 - Sincronização NTP (pool.ntp.org).

    Configurações do KDE


    KDE Spectacle: salvar (com a hora correta) no Pendrive, provisoriamente

    Seguem-se configurações corriqueiras:

    20:24 - Dolphin: view properties
    20:26 - Wallpaper
    20:28 - Konsole: yellow transparency
    20:29 - Chromium - oops KWallet
    20:35 - Taskmanager
    20:35 - Bash: date History
    20:38 - Spectacle: Pendrive
    20:38 - clean Desktop: Home, Trash
    20:39 - Gwenview: Q to Quit
    20:41 - Dolphin Toolbar
    20:42 - Dolphin KWin: Size, Position
    20:42 - System settings original
    20:42 - System settings Icon view
    20:45 - Keyboard ABNT2 (pt_BR): 3rdLevel
    20:45 - Compositor - XRender
    20:47 - Removable devices: Automount external SSD partitions
    20:48 - disable KWallet

    Desabilitada “Pesquisa de arquivos”

    20:48 - disable File search

    Desabilitando buscas indesejadas

    Desabilitando busca de Contatos do PIM

    21:02 - SDDM: Auto Login

    Desabilitando carregamento automático de alguns serviços em segundo plano

    21:03 - Background services
    21:05 - Shortcuts PrintScreen
    21:06 - Desktop effects
    21:07 - Screen Corners Edges
    21:07 - disable Screen Locker
    21:08 - Power Management
    21:08 - Screen Energy Saving: 5 min
    21:09 - Theme: Maia transparent
    21:10 - Window decorations: Transparent Oxygen
    21:11 - KInfocenter: KWin settings

    Substituição do ícone do Manjaro, — trazido pelo tema Maia transparent

    21:12 - Menu icon: Slackware
    21:14 - KSysguard: no Akonadi process found
    21:16 - KSysguard transparency
    21:29 - Reboot: Fade

    Menu de inicialização


    Atualização do Menu de inicialização (Grub), pelo Mageia

    Por fim, foi atualizado o Menu de inicialização* da máquina, — pelo Grub do Mageia, — e conferido pelo editor interno do Midnight Commander (mcedit).

    Desmontando o Pendrive para desplugar, — e acabar com as mensagens de alerta a cada Boot

    21:43 ~ 23:46 - Teste de Boot do Devuan, Manjaro, antiX, Arch, Slackware, PCLinuxOS, Debian, KDE Neon.

    Só então lembrei de desplugar o Pendrive (com os arquivos trazidos da sessão Live), — que causava advertências meio assustadoras (e talvez demoras) durante o Boot, — o que, a princípio, confundiu o diagnóstico do verdadeiro problema:

    No Caching mode page found
    Assuming drive cache: write through

    Montagem de partições adicionais


    Montagem automática pelo System settings só funcionou para o SSD externo (USB)

    Tal como no Debian e no Devuan, a montagem automática pelo “System settings > Removable devices” só funcionou para as partições do SSD externo (USB), — e assumiu este padrão de caminhos (path):

    /run/media/$USER/[Label]

    Construção manual de blocos em /etc/fstab para montagem automática das partições adicionais

    A montagem das partições dos HDDs internos teve de ser construída, manualmente, no arquivo /etc/fstab, — com o parâmetro “user”, para dispensar autenticação, — e caminhos simplificados, no padrão:

    /media/[Label]

    Isso foi muito simplificado pelo padrão regular dos rótulos (Label), — e pelo modo de Edição > Seleção de blocos, do Kate, — chamado pelo Dolphin em modo Root (Menu > System > File manager - Super User Mode).

    Criação dos pontos de montagem para as partições adicionais

    Para funcionar, ainda era necessário criar manualmente os pontos de montagem, — o que também foi facilitado pelo padrão regular nos rótulos (Label).

    PIM, Baloo, Akonadi


    Finalizar 16 processos Akonadi, — antes de iniciar a instalação

    Entre as configurações feitas na sessão Live, — durante a etapa automática da instalação, — registra-se a finalização de 16 processos Akonadi.

    Nenhum processo PIM, Baloo ou Akonadi, — embora não tenham sido removidos da instalação

    Não há qualquer indício de que qualquer configuração da sessão Live se tenha transferido para o Slackware instalado no HDD, — mas tampouco nenhum desses processos jamais foi visto em atividade, depois da instalação.

    Tal como em várias outras distros, — das quais não foi necessário remover pacotes do PIM, Baloo, Akonadi, — parece que bastaram as Configurações do KDE (System settings) para mantê-las inativas.

    Consumo inicial de Memória RAM, — sem HP, — e sem interferência do KDE Spectacle

    O consumo inicial de Memória RAM fica em torno de 401 ~ 406 MiB, com o notificador HP no Painel, — e 369 ~ 371 MiB após fechar o notificador HP.

    O recurso do KDE Spectacle em retardo (delay) para flagrar uma camada ou menu de contexto eleva o uso inicial de Memória RAM a 455 MiB, — o que o torna inútil para flagrar números reais, — mas infelizmente o gnome-screenshot não foi encontrado no Slackbuilds.

    Com poucas dependências (ou talvez nenhuma), gnome-screenshot é um forte candidato a se procurar código-fonte e treinar compilação & chmod +x.

    Conky


    Caminhos para obter Conky no Slackbuilds, — anotados há meses, — e sempre adiados

    Já ia fazer um ano que a instalação do Conky estava na lista de coisas a fazer, — “bastava” baixar do Slackbuilds o Conky, bem como o imlib2 e o tolua++, e depois fazer algumas coisas, — que ainda não sabia bem quais eram, mas tinha esperança de entender.

    A terminologia é meio assustadora, — “compilar os builds”… “dar permissão de execução para os scripts”… chmod +x… — tudo isso, três vezes.

    E sempre fica alguma dúvida, — sobre algum detalhe “óbvio” (para quem explica).

    \\\\

    Em boa hora, resolvi pesquisar mais um pouco, e encontrei esses 3 pacotes (+Lua) já devidamente “construídos” e prontos para instalar.

    Bastou descomprimir, — entrar no diretório onde foram parar os arquivos e pastas descomprimidos, — e rodar 1 comando:

    2018-06-03_22-48-46 # installpkg *.tgz

    O simples fato de “ver” a disposição dos arquivos e pastas eliminou várias dúvidas sobre essa parte do processo.

    Agora, basta exercitar o chmod +x, e outras etapas anteriores, — por exemplo: quando você não encontra o que deseja, — e precisa começar pelo código-fonte.

    Adaptação do ~/.conkyrc original

    Ao configurar o antiX, pela primeira vez utilizei a parte de configurações do arquivo (oculto) ~/.conkyrc “original”, — ao invés de “trazer” de uma das outras distros um ~/.conkyrc já personalizado, — mas dessa vez, o “original” deu trabalho para aproveitar.

    Já fazia tanto tempo que me limitava a reaproveitar cópias pré-configuradas, que nem lembrava mais qual parâmetro soluciona cada detalhe.

    Comparação do ~/.conkyrc original com a versão editada, pelo KDiff3 do KDE Neon

    Uma comparação feita mais tarde pelo KDiff3 (no KDE Neon) identificou exatamente o quê foi preciso adaptar.

    Fontes Verdana instaladas a partir do Wine de outras distros, pelo KDE System settings


    Após instalar fontes Verdana:

    xftfont Sans:size=10
    >>
    xftfont Verdana:size=8

    Adaptação às cores e formas do Wallpaper, — maior ou menor destaque contra o fundo:

    xftalpha 0.2
    >>
    xftalpha 0.8

    Para obter transparência, desencavalar (sobreposições) e dar fluidez no tempo:

    # own_window_argb_visual yes
    >>
    own_window_argb_visual yes

    Para reposicionar:

    alignment top_right
    # alignment bottom_left
    >>
    # alignment top_right
    alignment bottom_left

    Para exibir corretamente caracteres UTF8:

    override_utf8_locale no
    >>
    override_utf8_locale yes

    Para que as janelas não grudem, ─ já que “yes” não foi aceito:

    use_spacer yes
    >>
    use_spacer right

    A seção “TEXT” foi trazida de outros ~/.conkyrc (backups).

    Obs.:

    Na maioria dos demais Conkyrc venho usando:

    xftfont verdana:pixelsize=10

    No antiX, inovei:

    xftfont Verdana:pixelsize=11

    E no Slackware também fiz outra inovação:

    xftfont Verdana:size=8

    A ver (calcular): — A proporção exata (matemática) entre “size” e “pixelsize”.

    Quadro comparativo


    Comparativo das distros instaladas em 10 Jun. 2018

    O comparativo ressalva que o Slackware ainda não está sendo atualizado regularmente, — pois isso não é tarefa banal, como nas outras distros instaladas. — Carece estudar mais.

    Wallpapers e Busca no Dolphin


    Detalhe (crop) de uma foto do céu de Brasília

    Foram testadas várias fotos (próprias) do céu de Brasília, — com diferentes formações de nuvens, desde 2003, — em especial, as que flagram rastros de condensação em elevada altitude, nas asas de jatos que fazem rotas sem escala, aproveitando a infraestrutura de suporte à navegação.

    Localização rápida de fotos digitais feitas desde 2003, pelo Dolphin

    Localizar tais imagens no meio de 25.000 fotos digitais tiradas desde 2003 é mais fácil do que parece, — desde que em cada grupo de fotos exista pelo menos uma renomeada com o acréscimo de palavras como “nuvens”, ou “aviao”; — e muito rápido pela Busca (CTRL+F) do Dolphin, mesmo desabilitando o “File search” (System settings) desde o primeiro dia, em todas as distros.


    Uma busca por “Bird” na partição “Armazem1”, — pelo Dolphin, — examina os nomes de 485.000 arquivos (de todos os tipos) em pouco menos de 1’20’’.

    \\\\

    É claro que isso pode ser feito em apenas 2 segundos, por comando, — mas sem a mesma rapidez posterior, de visualização das imagens, exame dos dados Exif, — e imediata abertura pelo Gwenview ou pelo Gimp:

    # cd /media/Armazem1/
    # date && ls -R | grep Esplanada && date
    qua jun 6 13:46:45 -03 2018
    Catedral-Brasilia-Esplanada-cotidiano.shtml
    Esplanada-Ministerios
    Esplanada-Ministerios-1959-estruturas-metalicas.shtml
    ...
    ligacao-Esplanada-Ponte-JK.shtml
    x-vert-Esplanada-Ferroviaria.htm
    PPCUB-Esplanada-Ferroviaria-Brasilia.jpg
    aeroporto-Vera-Cruz-aerea-Esplanada-Ferroviaria-Brasilia.jpg
    patio-ferroviario-Brasilia-Esplanada-Ferroviaria.jpg
    patio-ferroviario-Brasilia-SIA-SIN-Esplanada.jpg
    qua jun 6 13:46:47 -03 2018

    \\\\

    Na prática, basta procurar em duas pastas, — /media/Xtudo/Fotos-digitais (2016-2018) e /media/Armazem1/Fotos-digitais (2003-2015), — que somam menos de 25.000 arquivos.

    — … ≠ • ≠ … —

    Não-debians