Translate

sábado, 2 de setembro de 2017

openSUSE Tumbleweed - desastre e recuperação

openSUSE Tumbleweed recuperado e atualizado, depois de 49 dias

• Cerca de 26 horas depois de instalar o openSUSE Tumbleweed, — configurar tudo, atualizar os pacotes (inclusive Kernel), e instalar novos aplicativos, — a conexão web deixou de funcionar, para nunca mais.

2017-09-01 - 20:47 - Finishing installation
2017-09-02 - 21:08 - Tumbleweed working fine
2017-09-02 - 22:36 - CPU high activity & Freeze

“Nunca mais”, — até carregar um snapshot anterior do sistema, tal como era, 2 horas depois de instalado, — e isto só veio a ser feito agora, 50 dias depois.

Essa demora, — poder dispor de tempo sem limite, para pesquisar com calma, e ainda pensar em outras mil outras hipóteses a pesquisar, — foi possibilitado pela existência de várias distros instaladas em dualboot. Nada é urgente, e o trabalho não precisa ser interrompido.

Durante 50 dias, não foi encontrada nenhuma solução mais simples, — coisa difícil, sem conexão à internet: — Carregar outro sistema, pesquisar, anotar mil comandos e dicas, tornar a carregar o Tumbleweed para testar… e assim por diante.

Esta já era a 3ª instalação, — a primeira, em partições ext4; (a 2ª já não lembro como), — e por fim, em partições BtrFS e XFS, como manda o figurino.

Reinstalar pela 4ª vez não ensinaria nada.

Fato é que essa 3ª instalação do Tumbleweed está (quase) perfeita, — totalmente configurada, — e até hoje, não apresentou nenhum dos problemas surgidos nas 2 instalações anteriores.

“Apenas”, não conectava, — ou o Firefox, o Chromium, os comandos zypper não encontravam a conexão.

Quanto à causa, só posso especular que fosse consequência de mudar à força o hostname, — mas desfazer essa mudança manual não resolveu, — por isso, não se comprovou.

Em máquina com BIOS, bastou salvar o Grub do Tumbleweed na MBR de algum HDD ou SSD

Preferia, mil vezes, conseguir consertar o problema, — comprovar a causa e aprender, — por isso, adiei o rollback por tanto tempo.

De qualquer modo, fazer o rollback, — que só conhecia teoricamente, — acabou sendo o aprendizado positivo, neste caso.

Índice


  • Recuperação do Tumbleweed
  • Atualização & upgrade
  • Montagem de partições adicionais
  • Configuração do Grub
  • Liberando espaço
  • Conky & Sensors
  • Instalação & desastre - O começo (to do)

Recuperação do Tumbleweed


Último snapshot capaz de carregar o openSUSE Tumbleweed conectado à internet

21 Out. 2017 - O primeiro passo para a solução era instalar a chamada do Grub em alguma MBR, — para ter a opção de carregar seus snapshots anteriores, até encontrar o último “estado” em que era capaz de se conectar automaticamente à internet:

flavio.@Linux6:~> sudo grub2-mkconfig -o /boot/grub2/grub.cfg
[sudo] senha para root:
Generating grub configuration file ...
Tema encontrado: /boot/grub2/themes/openSUSE/theme.txt
Imagem Linux encontrada: /boot/vmlinuz-4.12.9-1-default
Imagem initrd encontrada: /boot/initrd-4.12.9-1-default
Imagem Linux encontrada: /boot/vmlinuz-4.12.8-1-default
Imagem initrd encontrada: /boot/initrd-4.12.8-1-default
Encontrado KDE neon User Edition 5.11 (16.04) em /dev/sda1
Encontrado Mageia 6 (6) em /dev/sda2
Encontrado Debian GNU/Linux buster/sid em /dev/sda3
Encontrado Ubuntu 16.04.3 LTS (16.04) em /dev/sdb1
Encontrado openSUSE Leap 42.3 em /dev/sdb2
Encontrado Linux Mint 18 Sarah (18) em /dev/sdc1
Encontrado Slackware 14.2 em /dev/sdc2
Encontrado Arch Linux em /dev/sdc3
Encontrado Devuan GNU/Linux 1 (jessie) em /dev/sdd3
concluído
 
flavio.@Linux6:~> sudo grub2-install /dev/sdc
Instalando para a plataforma i386-pc.
Installation finished. No error reported.

O segundo comando, — instalar a chamada do Grub no MBR do 3º HDD, — evita afetar as outras 2 opções de Boot, pelo Grub do Mageia (sda) ou, quando necessário, pelo Grub do Leap (sdb).

Dispondo então do Menu de inicialização gerado pelo próprio openSUSE Tumbleweed, foi possível testar os snapshots disponíveis, — carregando sessões read-only de cada um deles, — e ficou confirmado que o último plenamente funcional era o nº 13, de 2 Set. 2017, à 0:07 (3:07 UTC).

Todos os snapshots após 3:07 UTC de 2 Set. 2017 não eram importantes nem desimportantes

De fato, uma verificação das capturas de tela, fotos de celular e anotações em caderno mostrou uma falha total de snapshots do resto do dia 2 Set. 2017, — um período enorme, em que foram tentadas inúmeras configurações, instalados vários pacotes e pelo menos um repositório, entre 12:07 e 22:30, — quando ocorreu o aparente congelamento do sistema.

No entanto, só havia mais snapshots de 6 Set. em diante, — quando já estavam sendo feitas novas tentativas de entender e consertar o problema.

Outra coisa que ficou evidente, — confirmada pela documentação do openSUSE, — é que as sessões de snapshot são “ready-only”, pero no mucho.

Os snapshots incluem apenas as pastas mais essenciais do sistema, — estas, sim, não-graváveis, — mas, ao carregar a sessão, elas são combinadas com outras pastas, “atuais” (correntes) e, portanto, modificáveis.

Por isso, várias configurações já não são as mesmas do momento de cada snapshot. — A impressão é de que valem as configurações “atuais”, — com todas as correções tentadas desde então.

Em resumo, — cada tentativa de solucionar o problema modifica a “cena do crime”. — É mais fácil restaurar um snapshot antigo, do que desemaranhar o enredo para encontrar 1 erro e corrigir.

Rollback do openSUSE Tumbleweed, — num piscar de olhos

Confirmado e re-confirmado que o snapshot das 3:07 de 2 Set. 2017 era o último 100% funcional, ele voltou a ser carregado, e — dentro dele, — foi disparado o comando rollback:

# snapper rollback

Snapshots criados e deletados pelo rollback do openSUSE Tumbleweed

Vai ser rápido, não foi? — Nem deu tempo de levantar para ir buscar um café.

Dá impressão de que apenas grava um “gatilho” em algum lugar, — que orienta o quê e como será carregado da próxima vez, — e depois do próximo boot começa a “manutenção”, propriamente dita, em segundo plano, enquanto você trabalha ou se diverte. Mas, esta é só a “impressão” de um leigo.

Feito o rollback, era necessário reiniciar o sistema, para carregar a nova situação “corrente”, — com todos os direitos, — pelo Grub do próprio Tumbleweed.

Atualização & upgrade


Comparativo dos sistemas Linux instalados em 23 Out. 2017

Após verificar que os repositórios voltaram a ser apenas os 4 originais, foi feita uma atualização dos pacotes, — não um upgrade do sistema, como talvez devesse fazer:

localhost:/home/flavio. # zypper update
Carregando dados do repositório...
Lendo os pacotes instalados...

Os seguintes 2 aplicativos serão instalados:
  …
Os seguintes 172 pacotes NOVOS serão instalados:
  …
O seguinte padrão NOVO será instalado:
  …
Os seguintes 79 aplicativos serão REMOVIDOS:
  …
O seguinte padrão será REMOVIDO:
  …
Os seguintes 1756 pacotes serão atualizados:
…
Os seguintes 27 padrões serão atualizados:
…
O seguinte produto será atualizado:
  …
O seguinte produto será reinstalado:
  …
1756 pacotes a atualizar, 172 novos.
Tamanho total do download: 1,55 GiB. Já em cache: 0 B. Após a operação, 597,2 MiB adicionais serão utilizados.
Continuar? [s/n/...? exibe todas as opções] (s):

O comando foi dado à 0:50 do dia 22, e pela manhã a atualização estava terminada, com um aviso de que … “Existem alguns programas em execução que podem utilizar arquivos removidos pela atualização recente. Convém verificar e reiniciar alguns deles. Execute 'zypper ps -s' para listá-los”.

De acordo com o /var/log/zypper/history, o download deve ter durado até 1:36, quando começou a instalação de fato, que foi rápida. O processo todo terminou às 2:09:

2017-10-22 01:36:59 | command|root@localhost|'zypper' 'update' | 
2017-10-22 02:09:46 /var/adm/update-scripts/adobe-sourcecodepro-fonts-…

Mais tarde, foi feito o upgrade do sistema, que àquela altura envolvia pouca coisa, — e o log indica que durou 19 segundos:

localhost:/home/flavio. # zypper dup --no-allow-vendor-change
Aviso: Você está prestes a fazer uma atualização da distribuição com todos os repositórios habilitados. Certifique-se de que esses repositórios são compatíveis antes de continuar. Consulte 'man zypper' para mais informações sobre este comando.

Os seguintes 7 pacotes NOVOS serão instalados:
  …
Os seguintes 16 pacotes serão REMOVIDOS:
  …
O seguinte pacote será desatualizado:
  …
1 pacote a desatualizar, 7 novos, 16 para remover.
Tamanho total do download: 1,7 MiB. Já em cache: 0 B. Após a operação, 11,4 MiB será liberado.
Continuar? [s/n/...? exibe todas as opções] (s):

A intenção é não usar o widget “atualizador” do Painel (packagekitd). — E chama atenção o fato de que ele não tomou nenhuma iniciativa de buscar informações ou sugerir nada, — ao contrário do comportamento automático observado no Leap, logo após o primeiro Boot do dia.

No dia 24 Out. 2017, finalmente o “atualizador” do Painel (packagekitd) se manifestou, — pela primeira vez, — após vários zypper up / dup.

Montagem de partições adicionais


Usando Krusader em modo root para copiar uma configuração testada no Leap e em outras distros

As configurações perdidas no rollback, — portanto, suspeitas de envolvimento nas ocorrências, — vão sendo refeitas, uma por uma.

A primeira foi autorizar a montagem automática de partições adicionais sem pedir senha, — básico, para o trabalho diário, — pela cópia de um arquivo já testado no Leap e em outros sistemas.

Depois disso, udisks voltou a montar as partições adicionais, automaticamente, no início de cada sessão.

Configuração do Grub


Configurando o Grub do Kubuntu para não gravar na MBR do sdc

O Leap já completou 9 meses, sem nenhum acidente que exigisse rollback para um snapshot, — daí, a decisão de não habilitar o Grub durante a instalação do Tumbleweed, — afinal,  o Grub do Mageia (sda) tem atendido bem, e ainda tinha de reserva o Grub do Leap (sdb).

Agora, a experiência mostra que o Tumbleweed precisa de seu próprio Grub, para rápido acesso a seus snapshots.

Num primeiro momento, bastaram os 2 comandos (citados acima), para instalar sua chamada na MBR do sdc, — mas o KDE Neon, o Debian testing, o Kubuntu LTS e o Mint KDE também estavam configurados para gravar em sdc. — Portanto, a qualquer momento, uma atualização fortuita poderia sobrescrever o Grub do Tumbleweed.

Nessas 4 distros, bastou rodar um comando para desativar a gravação na MBR do sdc, — ou em qualquer outro lugar:

$ sudo dpkg-reconfigure grub-pc

Falta descobrir o comando equivalente no Arch, — mas até lá, os riscos já ficam bem reduzidos.

Ampliação do espaço vertical do Menu de inicialização

Também foi editado o arquivo /boot/grub2/themes/openSUSE/theme.txt, para ampliar o espaço vertical do Menu de inicialização, de modo a caberem até 12 sistemas (e demais opções), “acima do horizonte” (sem necessidade de rolagem).

Alterações no tema do Grub2 do openSUSE (e do Mageia) para ampliar o Menu de inicialização

Após 2 ou 3 upgrades, o Menu do Grub voltou a ficar espremido num espaço acanhado, — e foi necessário refazer a edição. — Depois disso, foi guardada uma cópia theme_Modificado.txt.

Liberando espaço


Partição do openSUSE Tumbleweed com 18,3 GiB ocupados após 3 upgrades

O rollback não afetou significativamente o espaço ocupado na partição do sistema, — 8,88 GiB, segundo o Conky do Arch, carregado pouco depois, — mas os upgrades elevaram esse número para 15,1 GiB na manhã do dia 23; e para 18,3 GiB na manhã do dia 25.

A experiência ensina que 18,3 GiB, — numa partição de apenas 25 GiB (recomendam-se 50 GiB), — já está perigosamente perto do limite.

Você nunca pode prever um upgrade (ou qualquer outra coisa) que venha a precisar de mais espaço do que o disponível, — e que está longe de ser a mera subtração aritmética desses 2 números.

openSUSE Tumbleweed usando apenas 9.02 GiB após a remoção de snapshots

Após carregar e tornar a carregar o openSUSE Tumbleweed várias vezes e testá-lo em várias tarefas, finalmente foram deletados os antigos snapshots, bem como os “não-importantes” mais recentes, — exceto o último par (nº 30 e 31).

Dos mais antigos, o nº 15 não pôde ser deletado, — por ser o “estado atual” do sistema, — referido no Grub do Mageia, por exemplo, embora não no Grub do próprio Tumbleweed.

Com isso, o espaço ocupado caiu para 9,02 GiB, — praticamente a metade. — Bastante compatível com os números do openSUSE Leap e das demais distros instaladas.

Conky & Sensors


Concky e Weather, — com um fundo adequado à leitura dos dados

A re-instalação do Conky foi ficando para depois, por vários motivos: (a) Envolvia repositórios fora do padrão; (b) Não lembrava como tinha feito antes; (c) Imaginava ter de examinar o arquivo de log para checar eventuais mensagens de erro na vez anterior; (d) Imaginava ter de reler várias páginas.

Na verdade, bastou abrir o primeiro Bookmark guardado (só havia mais um), escolher “Tumbleweed”, — e a instalação já foi oferecida de bandeja. — Tudo se resolveu em 3 minutos, das 13:25 às 13:28, embora a maior parte desse tempo se deva à leitura antes dos cliques.

De acordo com o log do zypper, durou menos de 1 minuto:

2017-10-25 13:27:40|radd |http-download.opensuse.org-08aa4642|http://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/|
2017-10-25 13:28:13|radd |http-download.opensuse.org-bd976a6e|http://download.opensuse.org/repositories/server:/monitoring/openSUSE_Tumbleweed/|
2017-10-25 13:28:14|command|root@localhost|'/usr/bin/ruby' '/usr/lib/YaST2/bin/y2start' 'OneClickInstallWorker' '--arg' '/tmp/YaST2-07681-L7WsHv/oneclickinstall.xml' 'qt' '-name' 'YaST2' '-icon' 'yast'|
2017-10-25 13:28:31|command|root@localhost|'/usr/bin/ruby' '/usr/lib/YaST2/bin/y2start' 'OneClickInstallWorker' '--arg' '/tmp/YaST2-07681-L7WsHv/oneclickinstall.xml' 'qt' '-name' 'YaST2' '-icon' 'yast'|
2017-10-25 13:28:32|install|libImlib2-1|1.4.10-1.3|x86_64||download.opensuse.org-oss|***KEY***|
2017-10-25 13:28:32|install|libircclient1|1.9-1.5|x86_64||download.opensuse.org-oss|***KEY***|
2017-10-25 13:28:32|install|liblua5_1-5|5.1.5-14.2|x86_64||download.opensuse.org-oss|***KEY***|
2017-10-25 13:28:33|install|libmicrohttpd12|0.9.55-1.2|x86_64||download.opensuse.org-oss|***KEY***|
2017-10-25 13:28:33|install|libxmmsclient6|0.8-2.5|x86_64||download.opensuse.org-oss|***KEY***|
# 2017-10-25 13:28:33 lua51-5.1.5-14.2.x86_64.rpm installed ok
# Additional rpm output:
# update-alternatives: using /usr/bin/lua5.1 to provide /usr/bin/lua (lua) in auto mode
# 
2017-10-25 13:28:33|install|lua51|5.1.5-14.2|x86_64||download.opensuse.org-oss|***KEY***|
2017-10-25 13:28:33|install|imlib2-loaders|1.4.10-1.3|x86_64||download.opensuse.org-oss|***KEY***|
2017-10-25 13:28:34|install|libtolua++-5_1-1|1.0.93-16.11|x86_64||http-download.opensuse.org-bd976a6e|***KEY***|
2017-10-25 13:28:34|install|conky|1.10.6-6.2|x86_64|7882:ruby|http-download.opensuse.org-08aa4642|***KEY***|

Efeito imediato da instalação do Sensors no Conky

Por fim, foi instalado o Sensors (pelo YaST2), — e no mesmo instante o Conky extraiu as strings de temperatura para exibição:

${alignr}Vcore ${alignr}${execi 10 sensors | grep -A 0 'Vcore' | cut -c 20-25} V
${alignr}+3.3 ${alignr}${execi 10 sensors | grep -A 0 '+3.3 Voltage' | cut -c 20-25} V
${alignr}+5 ${alignr}${execi 10 sensors | grep -A 0 '+5 Voltage' | cut -c 20-25} V
${alignr}+12 ${alignr}${execi 10 sensors | grep -A 0 '+12 Voltage' | cut -c 20-25} V

Um wallpaper mais adequado facilita a leitura das informações.

Instalação & desastre


openSUSE Tumbleweed instalado como devia, — sistema em partição BtrFS e /home em XFS

O relato dessa 3ª instalação do openSUSE Tumbleweed, — bem como das configurações realizadas nas primeiras 26 horas, antes do “desastre”, — exige o levantamento de outro conjunto de fotos, capturas de tela e anotações em papel (Caderno de informática), e será feito por último, em breve.

________________
Inicialmente publicado às 21:23 do dia 2 Set. 2017, — pouco antes do “desastre” (com apenas 1 ou 2 imagens), — mas desenvolvido somente de 21 a 25 Out. 2017, após a recuperação (rollback / recovery).

— … ≠ • ≠ … —

openSUSE



Não-debians


Postado por Mboaba às sábado, setembro 02, 2017
Marcadores: , ,

Nenhum comentário:

Postar um comentário

Assinar: Postar comentários (Atom)