segunda-feira, 30 de janeiro de 2017

Consertando Kubuntu 17.04 Zesty após uma estranha atualização

Kubuntu 17.04 Zesty Zapus (development branch) sem Painel e sem Menu, após uma estranha atualização •

Uma atualização muito estranha deixou o Kubuntu 17.04 Zesty Zapus (development branch) fora de ação durante 1 semana, — até encontrar tempo e inspiração para consertá-lo.

Em resumo, carregava sem Painel e sem Menu, — ou carregava completo, mas logo começava a piscar, e desapareciam o Painel e o Menu.

Em algumas tentativas de carregamento, Painel, Menu etc. desapareciam, voltavam, e tornavam a desaparecer, — em rápida sequência, — mas o que prevalecia era, sempre, o desaparecimento.

Contexto anterior


Esse problema aconteceu em meio ao turbilhão do “Remanejamento de sistemas Linux ao reparticionar discos”, — durante o qual, o Zesty Zapus foi movido de uma partição para outra, o identificador UUID foi alterado, e o Kernel foi reinstalado para incorporar o novo UUID.

No entanto, parece pouco provável que aquela movimentação toda tenha qualquer responsabilidade nesse problema, — exceto, talvez, de modo bastante indireto.

12 Jan. 2017 - A reinstalação do Kernel provou ser a solução para incorporar o novo identificador UUID.

18:26 - Editado manualmente a entrada do Zesty Zapus no Grub, — com o novo UUID, — para que pudesse ser carregado.

18:50 - Uma vez carregado com sucesso o Zesty Zapus, o Kernel ativo (mais recente) foi reinstalado, via Synaptic, para incorporar o novo identificador UUID.

Commit Log for Thu Jan 12 18:50:29 2017

Reinstalados os seguintes pacotes: [resolver root=UUID no Grub]

linux-generic (4.9.0.11.15)
linux-headers-4.9.0-11 (4.9.0-11.12)
linux-headers-4.9.0-11-generic (4.9.0-11.12)
linux-headers-generic (4.9.0.11.15)
linux-image-4.9.0-11-generic (4.9.0-11.12)
linux-image-extra-4.9.0-11-generic (4.9.0-11.12)
linux-image-generic (4.9.0.11.15)
linux-libc-dev (4.9.0-11.12)

19:10 - Atualizado o Grub, para obter automaticamente, — do próprio Kernel do Zesty Zapus, — seu novo identificador UUID.

Synaptic definiu que apenas 76 dos 77 pacotes seriam atualizados

Depois disso, o Kubuntu 17.04 Zesty Zapus foi carregado com sucesso, — sem necessidade de correção manual do Grub.

Origem (provável) do erro


O pacote não-selecionado pela opção “Marcar todas as atualizações” exige decisão do usuário

19:56 - Após recarregar as informações dos repositórios, o Synaptic detecta 77 pacotes atualizáveis (+3 para instalar), — mas a opção “Marcar todas as atualizações” seleciona apenas 76 pacotes.

20:00 - O pacote automaticamente ignorado pela opção “Marcar todas as atualizações” levaria a desinstalar algumas sobrevivências do Plasma4, — por isso, teria de ser marcado por decisão consciente do usuário:

plasma-workspace 4:5.8.5-ubuntu2 (Plasma Workspace for KF5)

Plasma Workspace for KF5. Workspaces provide
support for KDE Plasma Widgets, integrated search,
hardware management and a high degree of customizability.

THIS WILL REMOVE YOUR KDE Plasma 4.

Infelizmente, não foi feita a simulação de marcar manualmente esse pacote, — e perdeu-se a oportunidade de registrar exatamente quais pacotes do Plasma4 seriam afetados, — pois depois disso, nunca mais o dilema voltou a se apresentar.

Mas, vamos por partes.

Lembrança ruim


Havia motivos para não querer decidir precipitadamente sobre a remoção de pacotes do Plasma4.

Algumas semanas antes, uma atualização do KDE Neon tinha removido vários pacotes do Plasma4, — e seu Konqueror ficou “aleijado” até hoje:

Commit Log for Mon Dec 19 16:30:50 2016 — [KDE Neon]

Removidos completamente os seguintes pacotes: *** [Konqueror amputado] ***

dolphin4
kde-baseapps-bin
kde-baseapps-data
konqueror-nsplugins
libappstreamqt1
libindi1
libjpeg-progs
libjpeg9
libkexiv2-11v5
libkexiv2-data
libkonqsidebarplugin4a
libkprintutils4
libnova-0.14-0
libokularcore7
libpoppler-qt4-4
libqimageblitz4
libqmobipocket1
libtidy-0.99-0

Desde esse dia, o Konqueror do KDE Neon deixou de exibir o Painel lateral (F9), — nem existe isso na sua Barra de menus, — perdeu a funcionalidade de converter arquivos PNG, JPEG, TIFF etc., e não oferece mais a montagem de imagens ISO.

Portanto, havia motivos para adiar a questão, — pois ainda faltava conferir e corrigir várias coisas urgentes, após a movimentação de sistemas de uma partição para outra, mudança de identificadores UUID etc.

Zesty bichado


Recovery mode instalava um pacote, — e desinstalava, — sem resolver o problema

Uma vez que o pacote não foi automaticamente incluído ao “Marcar todas as atualizações”, podia-se imaginar que sua instalação não fosse “obrigatória”, — segundo a visão de um leigo sobre o apt / Synaptic, que costuma brecar inconsistências. — Mas, faltava combinar que o Zesty Zapus ainda está em desenvolvimento.

Só que, depois disso, o Zesty Zapus nunca mais foi o mesmo, — pelo menos até ser consertado.

Várias vezes foi carregado o Recovery mode (Grub → Opções avançadas) e rodado “Consertar pacotes quebrados” (dpkg), — mas o resultado era apenas instalar um pacote, que logo em seguida era removido, — e não resolveu o problema.

KRunner (Alt-F2)


Konsole aberto por comando (via Alt-F2), para baixar as informações dos repositórios

Só no dia 19 finalmente foi encontrado tempo para tentar solucionar o problema, — torcendo muito para que, nesse meio tempo, alguma “correção de bug” já houvesse removido dos repositórios aquele dilema sem saída.

A falta de Menu foi driblada usando o KRunner (Alt-F2) para chamar o Konsole e/ou o Synaptic por comando.

Atualização Qt 5.6.1 para 5.7.1, pelo Synaptic

Lá estava, de novo, o pacote plasma-workspace 4:5.8.5-0ubuntu2, — que dessa vez, foi selecionado automaticamente, no meio de outros 200 (Qt 5.7.1), pelo “Marcar todas as atualizações” do Synaptic, — e não exigiu remover Plasma4.

Segundo o Histórico do Synaptic, foram removidos apenas 2 pacotes:

Commit Log for Thu Jan 19 12:28:57 2017

Removidos os seguintes pacotes:

libqalculate5-data
libqalculate5v5

Usando KRunner (Alt-F2) para reiniciar o computador, pelo comando reboot

Por fim, o KRunner (Alt-F2) foi usado para disparar o comando reboot, — a fim de verificar o resultado.

Zesty Zapus normalizado, — e Konqueror com todas as suas funcionalidades

Depois disso, o Kubuntu 17.04 Zesty Zapus (development branch) voltou a carregar normalmente, — e o Konqueror não perdeu nenhuma de suas funcionalidades.

Dois dias depois, o Kernel recebeu atualização, — de 4.9.0-11 para 4.9.0-12.

Por quê um Kubuntu em construção?


Sistemas pioneiros, instáveis ou em desenvolvimento podem ser pouco produtivos, para um leigo

Imagens ISO “daily-build” de sistemas ainda em construção são disponibilizadas principalmente para desenvolvedores, e/ou para usuários dispostos a testar, — com conhecimentos suficientes para fornecer um feed-back minimamente aproveitável. — Nenhuma das 2 hipóteses é o caso, para um leigo nesses assuntos.

O Kubuntu 17.04 Zesty Zapus (development branch) foi instalado em 27 Out. 2016, basicamente, porque calhou de o instalador do Yakkety Yak não funcionar, aqui, naquele momento específico. — Não tem Yak, vai Zap.

O objetivo inicial era não ficar alheio à evolução do Kubuntu, — e depois de 2 anos, ser pego de surpresa por novidades radicais, no próximo LTS.

De certo modo, — observar o futuro, — também tem sido a maior utilidade do KDE Neon, com seu KDE “rolling-release”, — e do Debian testing (não “Stretch”!).

Para um leigo, não são muito produtivos, — nem, com frequência, muito confiáveis.

Dessa falta de confiabilidade, porém, tem vindo um aprendizado interessante e, — por que não?, — útil.

Enfim, desde os primeiros dias do ano, foi disponibilizada a versão Alpha1, — e nos últimos dias, a versão Alpha2. — A versão final está prevista para 13 de Abril.

— … ≠ • ≠ … —

sábado, 28 de janeiro de 2017

Upgrade para o Linux Mint 18.1 “Serena” KDE

Upgrade do Linux Mint para 18.1 Serena
Upgrade do Linux Mint para 18.1 Serena levou apenas 11 minutos

O upgrade do Linux Mint 18 “Sarah” KDE para 18.1 “Serena” levou apenas 11 minutos, — mesmo parando para atender à recomendação de ler as páginas “Release notes” e “What’s new”.

Esse upgrade implicou na atualização de apenas 28 pacotes, — além da instalação de 2 novos, — e após reiniciar o computador, o Centro de Informações do Sistema (KInfocenter) não apresentou qualquer mudança em relação ao quadro anterior.

••• Surto de CPU por Kwin_x11 - Ver no final

Características do Linux Mint 18.1 KDE Beta em Live USB, há 2 semanas, — só o Kernel era “novo”

Isso já era mais ou menos esperado, desde o teste Live USB com a versão Beta, há 2 semanas.

Lançada a versão final do Linux Mint 18.1 “Serena” KDE, a página “What’s new” também não apresentava grandes novidades, para quem tinha o Linux Mint 18 “Sarah” KDE, com as atualizações em dia.

Portanto, não havia nenhum grande motivo para fazer esse upgrade, — exceto acompanhar a evolução do Linux Mint.

O início e o final do processo estão resumidos na image inicial (no alto). — O processo e outros detalhes estão nos tópicos a seguir:

  • Preparação
  • Upgrade
  • Log das alterações
  • Kernel, à parte
  • apt & Synaptic
  • KDE, à parte
  • Kwin surtado
  • Histórico da instalação

Preparação


Atualizações do Linux Mint 18 KDE, — antes do upgrade para 18.1

O primeiro passo, — antes do upgrade, — foi aplicar todas as atualizações que ainda faltavam ao Linux Mint 18 “Sarah” KDE.

Por mero hábito, as informações dos repositórios foram buscadas pelo “apt update”, — e a aplicação foi feita pelo Synaptic, — cujo Histórico registra:

Commit Log for Sat Jan 28 01:35:46 2017


Atualizados os seguintes pacotes:

apt (1.2.18) to 1.2.19
apt-transport-https (1.2.18) to 1.2.19
apt-utils (1.2.18) to 1.2.19
firefox (50.1.0+linuxmint1+serena) to 51.0.1+linuxmint1+serena
firefox-locale-en (50.1.0+linuxmint1+serena) to 51.0.1+linuxmint1+serena
firefox-locale-pt (50.1.0+linuxmint1+serena) to 51.0.1+linuxmint1+serena
libapt-inst2.0 (1.2.18) to 1.2.19
libapt-pkg5.0 (1.2.18) to 1.2.19
virtualbox-guest-dkms (5.0.24-dfsg-0ubuntu1.16.04.1) to 5.0.32-dfsg-0ubuntu1.16.04.2
virtualbox-guest-utils (5.0.24-dfsg-0ubuntu1.16.04.1) to 5.0.32-dfsg-0ubuntu1.16.04.2
virtualbox-guest-x11 (5.0.24-dfsg-0ubuntu1.16.04.1) to 5.0.32-dfsg-0ubuntu1.16.04.2

Upgrade


Início do upgrade para Linux Mint 18.1 “Serena”

Fechado o Synaptic, foi usado right-click no ícone do Gerenciador de atualizações (mintUpdate) para abri-lo.

Na Barra de menu, “EditarAtualizar para Linux Mint 18.1 Serena”.

1:45 - Uma nova versão do Linux Mint está disponível.

1:45 - Por favor, leia as Notas de versão.

1:49 - Por favor, olhe as novas funções introduzidas na nova versão.

Aviso de riscos que novas versões sempre podem trazer etc.

1:50 - Aviso. — Novos lançamentos fornecem correções de erros e novas funções, porém algumas vezes podem introduzir novos problemas etc. — Ok, conheço os riscos e quero atualizar.

1:50 - Baixando informações dos repositórios.

1:50 - Volta a exibir o Aviso, — mas já não é clicável. — Parece mera falta de coisa melhor para mostrar.

1:51 - Baixando pacotes.

1:53 - Aplicando as alterações.

1:55 - Volta a exibir o Aviso, — mas não é clicável. — Parece mera falta de coisa melhor para mostrar.

1:55 - Seu sistema operacional foi atualizado com sucesso. Por favor, reinicie seu computador para que todas as mudanças tenham efeito.

Log das alterações


KDE, Frameworks, Qt, Kernel, — antes do upgrade do Linux Mint para 18.1 “Serena”

De acordo com o arquivo /var/log/apt/history.log, as operações realizadas foram:

Start-Date: 2017-01-28  01:52:11
Commandline:
/usr/sbin/synaptic --hide-main-window --non-interactive --parent-window-id 77594627 -o Synaptic::closeZvt=true --progress-str Por favor aguarde, isto pode levar algum tempo --finish-str Atualização concluída --set-selections-file /tmp/tmp2q96sbfj
Install:
mint-backgrounds-serena:amd64 (1.1, automatic)
iso-flag-png:amd64 (1.0.1, automatic)
Upgrade:
mint-translations:amd64 (2016.06.25, 2016.12.12)
mint-y-icons:amd64 (1.0.3, 1.0.4)
apturl-common:amd64 (0.5.2+linuxmint3, 0.5.2+linuxmint4)
mint-themes-gtk3:amd64 (3.18+8, 3.18+11)
mint-themes:amd64 (1.4.7, 1.4.8)
gdebi-core:amd64 (0.9.5.7ubuntu1, 0.9.5.7xmint4)
mintsources:amd64 (1.6.0, 1.6.4)
mintsystem:amd64 (8.2.9, 8.3.0)
ttf-mscorefonts-installer:amd64 (3.4+nmu1ubuntu2, 3.6)
gdebi:amd64 (0.9.5.7ubuntu1, 0.9.5.7xmint4)
mint-artwork-common:amd64 (2.0.9, 2.1.0)
apturl:amd64 (0.5.2+linuxmint3, 0.5.2+linuxmint4)
apturl-kde:amd64 (0.5.2+linuxmint3, 0.5.2+linuxmint4)
mint-common:amd64 (1.2.6, 1.2.7)
mint-meta-core:amd64 (2016.07.23, 2016.11.28)
mintdrivers:amd64 (1.3.3, 1.3.4)
mint-info-kde:amd64 (2016.01.11, 2016.11.02)
nvidia-prime-applet:amd64 (1.0.5, 1.0.6)
mint-meta-kde:amd64 (2016.07.23, 2016.11.28)
mintbackup:amd64 (2.2.4, 2.2.7)
mintstick:amd64 (1.2.8, 1.3.1)
mintupload:amd64 (4.0.8, 4.0.9)
mintupdate:amd64 (5.1.0.4, 5.2.0)
mint-y-theme:amd64 (1.0.9, 1.1.5)
bash:amd64 (4.3+linuxmint3, 4.3+linuxmint4)
mint-artwork-kde:amd64 (2.0.27, 2.0.28)
base-files:amd64 (18.0.2, 18.1.0)
mint-x-icons:amd64 (1.3.9, 1.4.0)
End-Date: 2017-01-28  01:54:57

KDE, Frameworks, Qt, Kernel, — depois do upgrade do Linux Mint para 18.1 “Serena”

É o mesmo que consta do Histórico do Synaptic, — exceto que este considera a hora da concordância com os “riscos” (Aviso), disparando o processo, — e coloca os pacotes em ordem alfabética, — além de jogar para baixo os 2 novos pacotes que, na verdade, foram instalados primeiro.:

Commit Log for Sat Jan 28 01:50:53 2017


Atualizados os seguintes pacotes:

apturl (0.5.2+linuxmint3) to 0.5.2+linuxmint4
apturl-common (0.5.2+linuxmint3) to 0.5.2+linuxmint4
apturl-kde (0.5.2+linuxmint3) to 0.5.2+linuxmint4
base-files (18.0.2) to 18.1.0
bash (4.3+linuxmint3) to 4.3+linuxmint4
gdebi (0.9.5.7ubuntu1) to 0.9.5.7xmint4
gdebi-core (0.9.5.7ubuntu1) to 0.9.5.7xmint4
mint-artwork-common (2.0.9) to 2.1.0
mint-artwork-kde (2.0.27) to 2.0.28
mint-common (1.2.6) to 1.2.7
mint-info-kde (2016.01.11) to 2016.11.02
mint-meta-core (2016.07.23) to 2016.11.28
mint-meta-kde (2016.07.23) to 2016.11.28
mint-themes (1.4.7) to 1.4.8
mint-themes-gtk3 (3.18+8) to 3.18+11
mint-translations (2016.06.25) to 2016.12.12
mint-x-icons (1.3.9) to 1.4.0
mint-y-icons (1.0.3) to 1.0.4
mint-y-theme (1.0.9) to 1.1.5
mintbackup (2.2.4) to 2.2.7
mintdrivers (1.3.3) to 1.3.4
mintsources (1.6.0) to 1.6.4
mintstick (1.2.8) to 1.3.1
mintsystem (8.2.9) to 8.3.0
mintupdate (5.1.0.4) to 5.2.0
mintupload (4.0.8) to 4.0.9
nvidia-prime-applet (1.0.5) to 1.0.6
ttf-mscorefonts-installer (3.4+nmu1ubuntu2) to 3.6

Instalados os seguintes pacotes:

iso-flag-png (1.0.1)
mint-backgrounds-serena (1.1)

Kernel, à parte


Características do Linux Mint 18 Sarah na antevéspera, — mantidas após o upgrade para 18.1 Serena

É verdade que uma instalação nova, — ou reinstalação, — teria introduzido nova versão do Kernel (4.4.0-53).

Porém, no upgrade, — assim como nas atualizações comuns do dia-a-dia, — atualizar Kernel sem motivo não é recomendado pela equipe do Linux Mint.

Aliás, não recomendam, sequer, a migração do 18 “Sarah” para 18.1 “Serena”, — a menos que você tenha um motivo para isso.

“Se funciona, não conserte”, — é a recomendação do Linux Mint, — mas a decisão é do usuário.

No Linux Mint, Kernel não é um “corredor-de-matadouro”, — mas um cardápio de opções

Ao invés de uma “linha do tempo”, — como se todos os usuários devessem substituir o Kernel a cada nova versão, feito boiada no matadouro, — no Linux Mint, isso é oferecido como um cardápio.

O usuário pode examinar todas as versões de Kernel oferecidas, — várias delas, não-adotadas nos instaladores do Linux Mint, — e analisar os relatos de bug de cada uma.

A qualquer momento, você pode escolher qualquer uma, entre várias versões de Kernel, — mais nova ou mais antiga, — e o upgrade do 18 “Sarah” para 18.1 “Serena” não se intromete nisso.

apt & Synaptic


Pela primeira vez, o Synaptic inclui Kernel na categoria Instalado (Atualizável)

Fiel a essa recomendação, — que se reflete na Política de Kernel do Linux Mint, — uma atualização para o Kernel 4.4.0-34, feita aqui sem pensar (20 Ago.), foi revertida dias depois, e o sistema permanece até hoje com o Kernel 4.4.0.21.

Isso é facilitado por uma alteração do Synaptic pela equipe do Linux Mint. — Não existe o item “Marcar todas as atualizações”, — e novas versões do Kernel não são incluídas entre elas.

Agora, pela primeira vez, — na minha experiência pessoal, — o Synaptic passou a exibir uma nova versão de Kernel na categoria Status → Instalado (atualizável).

É possível que isso também acontecesse após outros upgrades anteriores de “versão-de-ponto”, — e não tenha visto, apenas, porque nunca tinha feito isso.

Mas se persistir, vai tornar incômodo evitar a atualização do Kernel, — a menos que abandone o hábito de recarregar informações dos repositórios por apt update, para em seguida aplicar pelo Synaptic.

No Gerenciador de atualizações (mintUpdate), isso não é problema. — Versões de Kernel são apresentadas numa classificação que, por default, não se aplica automaticamente, — a menos que o usuário altere as Preferências.

KDE, à parte


Isto não significa que o Linux Mint KDE tenha parado no tempo. — Pelo contrário, uma mega-atualização surpreendente, de nada menos que 518 + 31 pacotes, deu um salto do KDE 5.6.5 para 5.8.4, — e em menos de 3 semanas, outra atualização levou ao KDE 5.8.5.

Portanto, se o upgrade para Linux Mint 18.1 “Serena” parece modesto, é porque o sistema vinha sendo regularmente atualizado, — e as grande novidades já estavam instaladas.

A verdade é que ambientes gráficos como KDE, Cinnamon, MATE, Xfce, LXDE, Gnome etc. são projetos independentes, uns dos outros, — cada um com seu próprio “timing”, — e só por acaso um deles daria um grande passo à frente, justo no momento em que o Ubuntu lança sua nova versão semestral, ou no momento em que o Linux Mint lança uma nova “versão-de-ponto”.

No caso do KDE, uma cooperação com a equipe do Kubuntu permitiu ao Linux Mint acelerar a implementação do KDE 5.8.

Em resumo, KDE também é um assunto específico, — e o upgrade do 18 “Sarah” para 18.1 “Serena” não tem relação com isso.

••• Kwin_x11 surtado


Problemas com kwin_x11, após 2 dias

31 Jan. 2017 - Após 2 dias, registrou-se um surto de uso de CPU pelo kwin_x11. — Na prática, não impede o trabalho, porém eleva a temperatura, — além de algum incômodo para consertar detalhes (Dolphin fora de lugar, Conky não abre sozinho etc.).

1º Mar. 2017 - Na falta de solução para o surto de uso de CPU pelo kwin_x11, foi (re)instalado o Linux Mint 18.1 KDE, — porém, sem formatar a partição-raiz (“/”), nem a “/home”. — O problema permaneceu, praticamente sem alteração.

8 Mar. 2017 - O problema foi quase totalmente resolvido, “sozinho”, após uma atualização com erro, — porém, é difícil saber se o “conserto” foi causado pela atualização, ou pelo erro.

Com isso, o Linux Mint 18.1 KDE continuou carregando sem as transparências do Conky, do Tema e da Decoração de janelas. — Era necessário “re-aplicar” o Compositor (XRender), para a transparência voltar a fazer efeito. — Nenhum surto de uso da CPU pelo kwin_x11, nem antes nem depois dessa re-aplicação do Compositor (XRender).

29 Abr. 2017 - Reinstalado Linux Mint 18 “Sarah” KDE. — Permaneceu o problema de carregar sem transparência (Conky, Tema), até “re-aplicar” manualmente o Compositor (XRender). — Algumas páginas carregadas de vídeos de propaganda apresentaram surto de uso de CPU (mas não o Feed do Facebook).

3 Mai. 2017 - Finalmente, foi obtido que o Linux Mint 18 “Sarah” KDE voltasse a carregar com as transparências (Tema, Conky) e sem outros erros, que haviam surgido nesses dias. — Problemas ainda foram registrados, eventualmente, entre os dias 14 e 18, mas no final do mês já parecia normallizado.

2 Jun. 2017 - Ainda não foi feito o levantamento das anotações, fotos e Capturas de tela, para tentar saber, — agora ou no futuro, — exatamente o quê pode ter ocorrido, ou quais ações poderiam ter contribuído (ou não) para solucionar os problemas.

Histórico da instalação


O antigo Linux Mint 17.3 Cinnamon foi instalado em 19 Jan. 2016, com formatação da partição do sistema (“/”), — antes usada por um antigo Kubuntu, — porém sem formatar a partição “/home”, que mantém a herança de vários sistemas anteriores.

O Linux Mint 18 “Sarah” KDE foi instalado ainda na versão Beta, em 20 Ago. 2016, — sem formatar a partição do sistema (“/”), que portanto, manteve várias pastas e arquivos do sistema anterior, — coisa que não se recomenda fazer.

Ao ser lançada a versão final do Linux Mint 18 “Sarah” KDE, um exame de seus pacotes mostrou que a instalação Beta já estava atualizada, — por isso, não houve reinstalação.

Portanto, o atual upgrade para 18.1 “Serena” foi feito em cima do 18 “Sarah” (inicialmente) Beta, — permanentemente atualizado:


Datas de referência


— … ≠ • ≠ … —

Linux Mint


sábado, 21 de janeiro de 2017

Consertando o Manjaro após erro em atualização

“Unable to find root device”, após uma atualização tumultuada do Manjaro
“Unable to find root device”, — após uma atualização tumultuada do Manjaro

19 Jan. 2017 - Algum erro ou falha durante uma atualização de 199 pacotes fez com que o Manjaro não pudesse mais ser carregado.

Ainda não está claro exatamente qual a origem do erro, — nem se foi do sistema (trava), ou humano (precipitação).

Neste relato:

  • Registros do erro
  • Testando e descartando possibilidades
  • Consertando o Manjaro

Para um histórigo mais abrangente:


Registros do erro


Aviso de 191 atualizações e comando “Atualizar sistema”, — “199 pacotes precisam ser recuperados”

13:12 - Disparado o comando de atualização do sistema.

Conflito entre xorg-server e (vários) xf86-input

13:13 - Antes mesmo de iniciar a atualização, o Manjaro avisou que xorg-server e xf86-input-acecad estavam em conflito, — e perguntou se deveria remover este último.

Rápida pesquisa deu a entender que o conflito envolvia vários xf86-input, — e que ele podia ser removido, não era mais usado etc. — Alguém até pergunta por que ele ainda não foi eliminado.

13:22 - Assim, — embora a resposta-padrão (Enter) fosse “Não”, — foi dado comando para remover, sim.

13:22 - Dependência cíclica detectada, — “lib32-harfbuz será instalado antes de sua dependência lib32-fretype2”. — Nada a decidir.

13:24 - Observados comportamentos estranhos no ambiente gráfico. — Difícil capturar a tela em flagrante.

13:25 - Baixando linux44-4.4.41-1-x86_64, — uma atualização de Kernel, — de 4.4.39-1-Manjaro para 4.4.41-1-Manjaro.

Atualização estacionada ao final de 20 / 199, — sem sinais de atividade de CPU ou rede

13:38 - Depois de baixados todos os pacotes, a atualização estacionou (sabe-se lá desde quando) em 20 / 199, — “atualizando pacman-mirrorlist [100%]”. — Nenhuma indicação de atividade de CPU, nem de tráfego de rede.

Exame posterior do arquivo /var/log/pacman.log não deixa claro se alguma coisa ainda estava acontecendo, até o processo ser interrompido e reiniciado manualmente.

[2017-01-19 13:08] [PACMAN] Running 'pacman -Sy'
[2017-01-19 13:08] [PACMAN] synchronizing package lists
[2017-01-19 13:13] [PACMAN] Running 'pacman -Su'
[2017-01-19 13:13] [PACMAN] starting full system upgrade
[2017-01-19 13:34] [ALPM] transaction started
[2017-01-19 13:34] [ALPM] removed xf86-input-joystick (1.6.2-6)
[2017-01-19 13:34] [ALPM] removed xf86-input-acecad (1.5.0-9)
[2017-01-19 13:35] [ALPM] upgraded lib32-gcc-libs (6.2.1-1 -> 6.3.1-1)
[2017-01-19 13:35] [ALPM] upgraded gcc-libs-multilib (6.2.1-1 -> 6.3.1-1)
[2017-01-19 13:35] [ALPM] upgraded libpng (1.6.27-1 -> 1.6.28-1)
[2017-01-19 13:35] [ALPM] upgraded harfbuzz (1.3.4-1 -> 1.4.1-1)
[2017-01-19 13:35] [ALPM] upgraded fontconfig (2.12.1-3 -> 2.12.1-4)
[2017-01-19 13:35] [ALPM-SCRIPTLET] updating font cache... done.
[2017-01-19 13:35] [ALPM] upgraded sqlite (3.15.2-1 -> 3.16.2-1)
[2017-01-19 13:35] [ALPM] upgraded xcb-proto (1.12-2 -> 1.12-3)
[2017-01-19 13:35] [ALPM] upgraded libelf (0.167-1 -> 0.168-1)
[2017-01-19 13:35] [ALPM] upgraded libxml2 (2.9.4+12+ge905f08-2 -> 2.9.4+12+ge905f081-4)
[2017-01-19 13:35] [ALPM] upgraded mesa (13.0.2-2.1 -> 13.0.3-1)
[2017-01-19 13:35] [ALPM] upgraded gmp (6.1.1-1 -> 6.1.2-1)
[2017-01-19 13:35] [ALPM] upgraded libsystemd (232-6 -> 232-7)
[2017-01-19 13:35] [ALPM] upgraded libutil-linux (2.28.2-2 -> 2.29-2)
[2017-01-19 13:35] [ALPM] upgraded util-linux (2.28.2-2 -> 2.29-2)
[2017-01-19 13:35] [ALPM] upgraded systemd (232-6 -> 232-7)
[2017-01-19 13:35] [ALPM] upgraded mpfr (3.1.5-1 -> 3.1.5.p2-1)
[2017-01-19 13:35] [ALPM] upgraded linux44 (4.4.39-1 -> 4.4.41-1)
[2017-01-19 13:35] [ALPM-SCRIPTLET] >>> Updating module dependencies. Please wait ...
[2017-01-19 13:35] [ALPM] upgraded sed (4.2.2-4 -> 4.3-1)
[2017-01-19 13:35] [ALPM] upgraded python (3.5.2-3 -> 3.6.0-1)
[2017-01-19 13:35] [ALPM] upgraded pacman-mirrorlist (20161101-1 -> 20170112-1)
[2017-01-19 13:39] [ALPM] transaction interrupted

Retomando a atualização, — 179 pacotes, — download zero

13:39 - Interrompida e reiniciada a atualização, — agora, com o Chromium fechado. — “179 arquivos precisam ser recuperados (Tamanho do download: 0,00 Bytes)”.

Atualização concluída, — sem nenhum aviso fora do normal

13:42 - Concluída a atualização, — sem nenhum aviso fora da normalidade.

No entanto, o exame retrospectivo do arquivo /var/log/pacman.log mostra que, nesta retomada da atualização (parte II), não se realizaram as operações complementares à atualização de Kernel, — como se isso já estivesse feito, — e não estava.

A última vez, tinha sido em 10 Jan. 2017:

[ALPM] running '98-linux44.hook'...
[ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux44.preset: 'default'
[ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-4.4-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-4.4-x86_64.img
[ALPM-SCRIPTLET] ==> Starting build: 4.4.39-1-MANJARO
[ALPM-SCRIPTLET]   -> Running build hook: [base]
[ALPM-SCRIPTLET]   -> Running build hook: [udev]
[ALPM-SCRIPTLET]   -> Running build hook: [autodetect]
[ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[ALPM-SCRIPTLET]   -> Running build hook: [block]
[ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[ALPM-SCRIPTLET]   -> Running build hook: [keymap]
[ALPM-SCRIPTLET]   -> Running build hook: [plymouth]
[ALPM-SCRIPTLET]   -> Running build hook: [resume]
[ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[ALPM-SCRIPTLET] ==> Generating module dependencies
[ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-4.4-x86_64.img
[ALPM-SCRIPTLET] ==> Image generation successful
[ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux44.preset: 'fallback'
[ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-4.4-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-4.4-x86_64-fallback.img -S autodetect
[ALPM-SCRIPTLET] ==> Starting build: 4.4.39-1-MANJARO
[ALPM-SCRIPTLET]   -> Running build hook: [base]
[ALPM-SCRIPTLET]   -> Running build hook: [udev]
[ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[ALPM-SCRIPTLET]   -> Running build hook: [block]
[ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[ALPM-SCRIPTLET]   -> Running build hook: [keymap]
[ALPM-SCRIPTLET]   -> Running build hook: [plymouth]
[ALPM-SCRIPTLET]   -> Running build hook: [resume]
[ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[ALPM-SCRIPTLET] ==> Generating module dependencies
[ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-4.4-x86_64-fallback.img
[ALPM-SCRIPTLET] ==> Image generation successful

13:43 - Registro de que o arquivo /bot/grub/grub.cfg não foi atualizado, — permanecia com data da antevéspera, quando tinha sido atualizado manualmente.

Analisando agora, em retrospecto, parece possível que um comando “sudo update-grub”, naquela hora, fosse útil, — mas também é possível que não bastasse. — Em todo caso, ainda falta aprender os comandos para consertar pacotes quebrados e outras inconsistências.

18:11 - Atualizado o Grub do openSUSE.

18:23 - Manjaro não carrega, a partir do Grub do openSUSE.

Testando e descartando possibilidades


Nada atualizado na pasta /boot do Manjaro

20 Jan. 2017 - Teste com o Grub do próprio Manjaro (desatualizado).

Para isso, a BIOS foi configurada para Boot a partir do terceiro HDD (sdc), — em cujo MBR se encontra a chamada para o Grub do Manjaro. — Não funcionou para carregar o Manjaro (mas funcionou para carregar o KDE Neon, por exemplo).

17:00 - Tentativa de carregar o Recovery Mode do Manjaro, — igualmente sem resultado.

Também não carregou o Kernel anterior (Opções avançadas → 4.4.39). — Falta identificar as fotos dessa tentativa.

Entradas principais do grub.cfg não fazem referência à versão do Kernel

Pelo KDE Neon, não foi possível identificar qualquer referência específica à versão do Kernel, — seja no /boot/grub/grub.cfg do Manjaro (desatualizado), — seja no /boot/grub2/grub.cfg do openSUSE (atualizado).

Ao que parece, só há referências específicas ao Kernel, nas entradas para o Kernel anterior (Opções avançadas). — Além disso, os identificadores UUID estavam corretos. — Portanto, nada que precisasse ou pudesse ser consertado por esse lado.

No entanto, ficou claro que, na pasta /boot do Manjaro, nada chegou a ser atualizado no dia 19, — initramfs tinha data do dia 10, linux44 e vmlinuz tinham data do dia 9.

Consertando o Manjaro


Queimando DVD com a ISO do Manjaro, para ter à mão, se voltar a ser necessário

21 Jan. 2017 - Pesquisa de poucos minutos por Manjaro + “unable to find root device” mostrou grande número de perguntas e pedidos de socorro, — em geral “RESOLVIDAS”, — mostrando tratar-se de acidente bem conhecido e de fácil solução.

A primeira “receita” examinada para consertar o sistema, — “Fixing Manjaro Linux Boot Error - Unable to find root device”, — acabou resolvendo de primeira.

16:06 - Uma vez que o Pendrive utilizado para instalar o Manjaro já tinha sido regravado para instalar o openSUSE, a opção foi queimar um DVD, — para ter à mão, caso volte a ser necessário.

TXT com o roteiro para consertar o Manjaro, em sessão Live DVD

Para agilizar o conserto, a “receita” foi copiada a gravada em um arquivo TXT, — a ser aberto na sessão Live DVD, sem necessidade de usar Firefox.

Desnecessário dizer que não conhecia boa parte dos comandos e parâmetros dessa “receita”, — exceto alguns, mais elementares.

Os 2 primeiros são básicos, — criar um ponto de montagem, e montar a partição de sistema (raiz) do Manjaro existente no computador. — Bastou substituir a partição indicada na “receita” pela partição usada aqui:

mkdir /mnt/manjaro
mount /dev/sdc2 /mnt/manjaro

O ponto de montagem talvez seja arbitrário, — mas não ganharia nada tentando usar outro, só de teimoso.

Conferindo o caminho (path) da montagem da partição sdc8

Dos comandos seguintes, apenas o primeiro era conhecido, — colocar-se “dentro” da partição-raiz do Manjaro instalado, para disparar dentro dele os outros 3 comandos, — absolutamente esotéricos:

cd /mnt/manjaro
mount -t proc proc proc/
mount -t sysfs sys sys/
mount -o bind /dev dev/

Copiando a interface de rede para substituir o “eth0” da receita

Erro e correção da interface de rede

Dos 2 comandos seguintes, o segundo retornou mensagem de erro, — sendo então repetido, após substituir “eth0” por “enp1s0”:

chroot . /bin/bash
dhcpcd enp1s0

Já havia usado pacman -Sy, — agora pacman Syy, — mas ainda falta descobrir a diferença

Comando pacman -S mkinitcpio

Nem tudo pode ser perfeito, — mas resolveu, mesmo assim

Dos comandos “pacman” sabia, apenas, que são de gerenciamento de pacotes (package management) no Arch Linux, — base do Manjaro, — mas os parâmetros eram mistérios:

pacman -Syy
pacman -Syu
pacman -S udev
pacman -S mkinitcpio
pacman -Sy linux
mkinitcpio -p linux

O comando da 6ª linha deu erro, — estava escrito “mik”, — e era intuitivo que o correto devia ser “mk”, de “make”.

Leituras superficiais, — procurando um modo simples de refazer “vmlinuz”, para atualizar referências após clonar vários sistemas e alterar o identificador UUID das novas partições [ver “Grub e root=UUID conflitante - II”], — já haviam passado alguma noção do que seja “initcpio”, ou para quê serve.

Era de supor que “pacman -Sy linux” e “mkinitcpio -p linux” pertencessem ao reino daquelas funções pesquisadas na semana anterior.

Por fim, sair do Terminal, — e/ou do modo root, — e reiniciar o computador, para testar se agora o Manjaro carregaria corretamente:

exit
reboot

Utilizando o Grub do openSUSE, — sem atualização, — para carregar o Manjaro consertado

Naturalmente, é de se supor que, agora, o Grub do Manjaro seja capaz de carregá-lo, — ainda nem foi testado, — mas havia outra dúvida para tirar a limpo.

Uma vez que a entrada referente ao Manjaro não faz referência alguma à versão do Kernel, o Grub do openSUSE talvez já pudesse carregá-lo, — sem necessidade de atualização.

Manjaro carregado com Kernel 4.4.41-1, após o conserto

E de fato o Manjaro carregou sem problema algum, a partir do Grub (não-atualizado) do openSUSE.

Manjaro carregado com Kernel 4.4.41-1, — e todos os aplicativos usados no início deste relato

xxx

Log do Pacman


Apenas os arquivos initramfs e grub.cfg apresentam data e hora desta atualização

Exame posterior, — ao longo deste relato, — indicou que apenas os arquivos initramfs e grub.cfg apresentavam data e hora do “conserto” do Manjaro.

Com o log do Pacman, isso poderá ajudar a entender melhor o que de fato aconteceu durante o processo.

[2017-01-21 16:37] [PACMAN] Running 'pacman -Syy'
[2017-01-21 16:37] [PACMAN] synchronizing package lists
[2017-01-21 16:37] [PACMAN] Running 'pacman -Syu'
[2017-01-21 16:37] [PACMAN] synchronizing package lists
[2017-01-21 16:37] [PACMAN] starting full system upgrade
[2017-01-21 16:37] [PACMAN] Running 'pacman -S udev'
[2017-01-21 16:38] [ALPM] transaction started
[2017-01-21 16:38] [ALPM] reinstalled systemd (232-7)
[2017-01-21 16:38] [ALPM] transaction completed
[2017-01-21 16:38] [ALPM] running '98-linux44.hook'...
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux44.preset: 'default'
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-4.4-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-4.4-x86_64.img
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Starting build: 4.4.41-1-MANJARO
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [autodetect]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [keymap]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [plymouth]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [resume]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-4.4-x86_64.img
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Image generation successful
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux44.preset: 'fallback'
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-4.4-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-4.4-x86_64-fallback.img -S autodetect
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Starting build: 4.4.41-1-MANJARO
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [keymap]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [plymouth]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [resume]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-4.4-x86_64-fallback.img
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Image generation successful
[2017-01-21 16:38] [ALPM] running 'systemd-sysusers.hook'...
[2017-01-21 16:38] [ALPM] running 'systemd-tmpfiles.hook'...
[2017-01-21 16:38] [ALPM] running 'udev-hwdb.hook'...
[2017-01-21 16:38] [PACMAN] Running 'pacman -S mkinitcpio'
[2017-01-21 16:38] [ALPM] transaction started
[2017-01-21 16:38] [ALPM] reinstalled mkinitcpio (22-1)
[2017-01-21 16:38] [ALPM] transaction completed
[2017-01-21 16:38] [ALPM] running '98-linux44.hook'...
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux44.preset: 'default'
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-4.4-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-4.4-x86_64.img
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Starting build: 4.4.41-1-MANJARO
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [autodetect]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [keymap]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [plymouth]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [resume]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-4.4-x86_64.img
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Image generation successful
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux44.preset: 'fallback'
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-4.4-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-4.4-x86_64-fallback.img -S autodetect
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Starting build: 4.4.41-1-MANJARO
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [keymap]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [plymouth]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [resume]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2017-01-21 16:38] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-4.4-x86_64-fallback.img
[2017-01-21 16:38] [ALPM-SCRIPTLET] ==> Image generation successful
[2017-01-21 16:38] [ALPM] running 'systemd-tmpfiles.hook'...
[2017-01-21 16:39] [PACMAN] Running 'pacman -Sy linux'
[2017-01-21 16:39] [PACMAN] synchronizing package lists
[2017-01-21 16:39] [ALPM] transaction started
[2017-01-21 16:39] [ALPM] reinstalled linux44 (4.4.41-1)
[2017-01-21 16:39] [ALPM-SCRIPTLET] >>> Updating module dependencies. Please wait ...
[2017-01-21 16:39] [ALPM] transaction completed
[2017-01-21 16:39] [ALPM] running '98-linux44.hook'...
[2017-01-21 16:39] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux44.preset: 'default'
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-4.4-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-4.4-x86_64.img
[2017-01-21 16:39] [ALPM-SCRIPTLET] ==> Starting build: 4.4.41-1-MANJARO
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [autodetect]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [keymap]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [plymouth]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [resume]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[2017-01-21 16:39] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2017-01-21 16:39] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-4.4-x86_64.img
[2017-01-21 16:39] [ALPM-SCRIPTLET] ==> Image generation successful
[2017-01-21 16:39] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux44.preset: 'fallback'
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-4.4-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-4.4-x86_64-fallback.img -S autodetect
[2017-01-21 16:39] [ALPM-SCRIPTLET] ==> Starting build: 4.4.41-1-MANJARO
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [keymap]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [plymouth]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [resume]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2017-01-21 16:39] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[2017-01-21 16:39] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2017-01-21 16:39] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-4.4-x86_64-fallback.img
[2017-01-21 16:39] [ALPM-SCRIPTLET] ==> Image generation successful
[2017-01-21 16:39] [ALPM] running '99-grub.hook'...
[2017-01-21 16:39] [ALPM-SCRIPTLET] Generating grub configuration file ...
[2017-01-21 16:39] [ALPM-SCRIPTLET] Plano de fundo encontrado: /usr/share/grub/background.png
[2017-01-21 16:39] [ALPM-SCRIPTLET] Found Intel Microcode image
[2017-01-21 16:39] [ALPM-SCRIPTLET] Imagem Linux encontrada: /boot/vmlinuz-4.4-x86_64
[2017-01-21 16:39] [ALPM-SCRIPTLET] Imagem initrd encontrada: /boot/initramfs-4.4-x86_64.img
[2017-01-21 16:39] [ALPM-SCRIPTLET] Found initrd fallback image: /boot/initramfs-4.4-x86_64-fallback.img
[2017-01-21 16:39] [ALPM-SCRIPTLET]   WARNING: Failed to connect to lvmetad. Falling back to device scanning.
[2017-01-21 16:40] [ALPM-SCRIPTLET] Encontrado KDE neon User Edition 5.8 (16.04) em /dev/sda1
[2017-01-21 16:40] [ALPM-SCRIPTLET] Encontrado Debian GNU/Linux (9.0) em /dev/sda3
[2017-01-21 16:40] [ALPM-SCRIPTLET] Encontrado Ubuntu 16.04.1 LTS (16.04) em /dev/sdb1
[2017-01-21 16:40] [ALPM-SCRIPTLET] Encontrado Linux Mint 18 Sarah (18) em /dev/sdc1
[2017-01-21 16:40] [ALPM-SCRIPTLET] Encontrado Ubuntu Zesty Zapus (development branch) (17.04) em /dev/sdc3
[2017-01-21 16:40] [ALPM-SCRIPTLET] Found memtest86+ image: /boot/memtest86+/memtest.bin
[2017-01-21 16:40] [ALPM-SCRIPTLET] concluído
[2017-01-21 16:47] [PACMAN] Running 'pacman -Sy'
[2017-01-21 16:47] [PACMAN] synchronizing package lists

_______________
Relato produzido e publicado no Manjaro, das 19:00 do dia 21 à 1:00 do dia 22 Jan. 2017; e complementada entre 11:00 e 12:00 do dia 22.

— … ≠ • ≠ … —

Não-debians


terça-feira, 17 de janeiro de 2017

openSuse Leap 42.2 - Instalação e configuração

openSUSE Leap 42.2 instalado e parcialmente configurado

Este é o 2º sistema “não-Debian” instalado, — o primeiro foi o Manjaro KDE 16.10.3 stable, — e ambos surpreenderam pela leveza, estabilidade, e ausência de dificuldades para quem nunca os tinha visto antes. — Nenhum bicho-papão.

Mas o openSUSE Leap 42.2 (stable) vai além:

1) Enfrenta os obstáculos colocados pelo Facebook à navegação em “Páginas”, como quem passeia numa pista de patinação, — embora seja possível que a causa esteja associada à falta de alguma coisa, que ainda impede de assistir vídeos no Chromium (instalado pelo usuário).

2) Apresenta-se “detalhado” ao infinito, — e organizado, — como se não houvesse 1 único bit que não possa ser (graficamente) visto e configurado.

Esse detalhamento se apresenta desde o início da instalação, — com uma profusão de opções que chega a assustar, — porém o grau de transparência, a organização e a lógica (quase intuitiva) permitiram atravessar todas as provas, mesmo sem jamais ter ouvido falar na metade dos itens colocados à escolha.

Apenas, mantenha a calma, — releia com atenção. — Na dúvida, não mexa, — ou leia de novo, e torne a examinar.

O relato está dividido em:

  • Download, gravação e Boot pelo Pendrive
  • Instalação
  • Roteiro resumido
  • Editando o Grub
  • Montagem automática de partições
  • Montagem de outras partições sem /etc/fstab (31 Mar. 2017)
  • Wine, CorelDraw, Dreamweaver, MS Word e Verdana
  • Outras configurações e registros (17 a 27 Jan. 2017)

Download, gravação e Boot pelo Pendrive


Verificação sha256sum da imagem ISO do openSUSE Leap 42.2 (stable), com ajuda do CTRL-F do Kate

A imagem ISO do DVD openSUSE Leap 42.2 (stable) foi baixada por Torrent a partir das indicações da página oficial, assim como a soma de verificação SHA256.

  • Também foi baixada a imagem ISO do CD “openSUSE-Leap-42.2-NET-x86_64”, de apenas 95,0 MiB, mas acabou não sendo utilizada.

Gravando Pendrive com a imagem ISO do openSUSE, mas por comando “dd

Uma vez que o método “Criar um Live USB do jeito mais fácil” exige openSUSE ou Windows, o jeito foi recorrer ao método “Criar um Live USB do jeito mais difícil”:

dd_rescue /path/ISO /dev/sdX

Porém, na falta do “dd_rescue”, foi usado o “dd”, — coisa que não se recomenda, — pois foge por completo da recomendação oficial.

Menu e opções-padrão após o Boot pelo DVD de instalação do openSUSE Leap 42.2 (stable)

Dado o Boot pelo Pendrive, foi disparada a sub-opção “Check Installation Media”, — e o Pendrive foi reprovado.

    Boot from Hard Disk
    Installation
    Upgrade
    More...
        Rescue System
        Boot Linux System
        Check Installation Media
        Memory Test

Pendrive rejeitado na auto-verificação: “This is not a openSUSE medium

Ao reiniciar o computador, não existe pausa nem aviso para retirar o Pendrive, — e o novo Boot (não programado) foi aproveitado para tentar a instalação, — dessa vez, sem testar o “medium”, para não dar ideias.

Foram deixadas as opções-padrão, — e/ou automáticas, — tal como se apresentavam:

F3 - Video mode - Default
F4 - Source - Hard Disk
F5 - Kernel - Default
F6 - Driver - No

Ao iniciar a instalação, as opções feitas foram (2) Installation; e (3) Source: Hard Disk

Após clicar na opção “Installation” do Menu inicial, são oferecidas várias opções, para os mais diversos objetivos, — Settings, Expert, Exit or reboot (usado antes, para reiniciar), Upgrade, Rescue system, Boot installed system, Network setup, — além da escolha de outras fontes (source medium), como DVD / CD-ROM ou Network.

As escolhas feitas foram: — Start installation, — Installation, — Hard Disk.

O Pendrive é tido como “Hard Disk”, — e se você escolher “DVD / CD-ROM”, não vai dar certo.

Instalação


Contrato sujeito a controles do Departamento de Estado etc. e nova chance de escolher Idioma e Teclado

Sem sessão Live, não havia como fazer a instalação com um navegador web aberto, para tirar dúvidas, — o que, de certo modo, evitou muita perda de tempo (considerando a quantidade de opções desconhecidas). — Também por isso, a instalação só foi documentada em fotos de celular.

Ao todo, a instalação levou 1 hora e 20 minutos, — dos quais, 32 minutos só na alteração manual das partições a serem usadas ou não.

Outra etapa de maior duração (33 minutos) foi a da instalação, propriamente dita, — após todas as opções do usuário, —  porém 3 abas permitem alternar entre o “slide-show”, as Notas de lançamento, e o acompanhamento detalhado de tudo que acontece.

1:46 - Abrindo o Instalador.
1:49 - Particionamento sugerido.
-------------------------------------------------------------------- 3 minutos
2:21 - Corrigido o particionamento sugerido.
----------------------------------------------------------------- +32 minutos → (32 + 3 = 35)
2:33 - Confirmar licenca Adobe. — Instalar.
----------------------------------------------------------------- +12 minutos → (12 + 35 = 47)
3:06 - openSUSE-sistema-instalado
----------------------------------------------------------------- +33 minutos → (33 + 47 = 1h 20min)

Roteiro resumido


1:47 - Idioma, Teclado e Contrato de licença abrem o processo de instalação do openSUSE.

Você se compromete a não emprestar seu computador com openSUSE para ninguém do chamado “eixo do mal”.

1:47 - Testando o sistema. — O Instalador testa dispositivos USB, dispositivos FireWire, dispositivos de diskete, controladores de disco rígido, carrega módulos de Kernel para os controladores de disco rígido, testa os discos rígidos, procura por sistemas de arquivos e inicializa o gerenciador de software.

Escolhido “Adicionar repositórios antes da instalação” do openSUSE

1:48 - Opções de instalação. — Foi marcado “Adicionar repositórios antes da instalação”. — Isso parece ter garantido uma instalação atualizada, pois mais tarde, ao carregar o sistema a partir do HDD, não foi necessária nenhuma grande atualização.

Na instalação do Kubuntu, há uma escolha que parece prometer alguma coisa assim, — mas ao carregar pela primeira vez, depois de instalado, invariavelmente detecta dezenas de pacotes desatualizados.

A outra opção, — “Incluir produtos complementares de outra mídia”, — foi deixada desmarcada, pois não havia nenhuma outra mídia a considerar, dentro dos nulos conhecimentos de quem nunca lidou com openSUSE na vida.

Particionamento sugerido pelo instalador do openSUSE, — aqui começa o desconhecido

1:49 - Para quem nunca se aventurou a ser mais do que mero “usuário leigo” do Kubuntu, — nem alcança sequer o feijão-com-arroz no Debian, — o particionamento sugerido pelo instalador do openSUSE parece escrito em grego, com uma penca de “subvolumes” grafados numa festa de arrobas.

Foram necessários vários minutos, — clicando aqui e ali, — até perceber que a saída desse emaranhado é clicar em “Particionador experiente” (parece irônico, para quem está perdido, mas é verdade).

Indicações dos sistemas de arquivos que o openSUSE prefere para as partições “/” e “/home

1:51 - Felizmente, clicando aqui ou ali, — antes de encontrar a saída, — ficou registrada uma imagem das preferências do openSUSE quanto ao formato das partições de sistema (“/”) e “/home”.

Mas tarde, — ao escolher outras partições, — essa foto serviu de referência, para fazer tudo igual.

O caminho para isso parece ter sido right-click na primeira linha da proposta. — Não há registro de clique nos botões “Editar as configurações recomendadas” ou “Criar a configuração da partição…” (embora tenham sido explorados de passagem).

Apresentação básica do “Particionador avançado”, no Instalador do openSUSE

1:51 - Ao clicar no botão “Particionador experiente”, surgiu afinal o caminho para escolher outras partições, não incluídas na proposta original.

No entanto, esse “modo de visão” inicial ainda foi muito ineficiente, levando a grande perda de tempo.

Com exceção da partição de sistema “sda1”, — assinalado por um “F” de formatar e com nítida indicação de sistema de arquivos BtrFS, — é complicado ver o que mais estaria previsto.

A partição “sda6”, por exemplo, — sem nenhuma indicação de uso ou de formatação, com seu inocente sistema de arquivos ext4, — quem poderia imaginar que estivesse marcada para ser “/home”?

Editando “sda1” (KDE Neon) para desativar sua formatação e uso como raiz do openSUSE

Para inspecionar o destino reservado a cada partição, — até descobrir qual partição estava marcada para ser “/home”, — teria de fazer right-click em todas, uma após outra, abrir a página de edição, olhar e, quando finalmente descobrisse, desmarcar. — Trabalho de doido.

Opções de exame do projeto de particionamento. — “Gráfico dos dispositivos” revela surpresas ocultas

2:05 - Depois de vários minutos tateando às cegas, finalmente fiz o que deveria ter feito desde o início, — examinar todos os modos de visão oferecidos na coluna à esquerda.

Gráfico das partições Raiz, Home e Swap afinal escolhidas para instalação do openSUSE

2:05 - Bastou selecionar o modo de exibição “Gráfico dos dispositivos”, por exemplo, para obter uma visão clara de quais partições o Instalador do openSUSE pretendia utilizar como /home e Swap, — desarmar esse esquema, — e organizar outro [2:12].

Particionamento sugerido corrigido para instalação do openSUSE

2:21 - Vários minutos ainda foram investidos no exame de inúmeros detalhes técnicos, — absolutamente incompreensíveis, para quem nunca tinha visto nada semelhante, — até chegar de volta ao “particionamento sugerido”, — corrigido.

2:22 - País e Fuso horário (São Paulo, para o Centro-Sul, DF etc.).

2:23 - Repositórios (sem alterações).

2:23 - Contrato de licença.

2:25 - Seleção do ambiente gráfico (KDE).

2:26 - Nome, Usuário e Senha. — Não há campo para definir o hostname (Linux5).

Configurações da instalação, — gravar inicialização no MBR (sdb), — não na partição de sistema

2:27 - Configurações da instalação. — Aqui foi feita outra correção. — O que constava inicialmente era gravar o código de inicialização na partição de sistema (sdb2). — Alterado para gravar no MBR do segundo HDD (sdb).

Não está claro o motivo por que deveria gravar na partição de sistema do openSUSE (sdb2), — nem se isso faria algum sentido.

  • É possível que isso esteja ligado a alguma proposta de criar uma partição específica de Boot, e que tenha sido descartada, — mas não é possível afirmar.

Tampouco se descarta que tal “opção” fosse efeito colateral de alguma ação desatenta, ao logo do processo, até aqui. — Lembrar que a proposta inicial do Instalador do openSUSE era de instalar o sistema na partição inicial do primeiro disco rígido (sda1).

Quanto à escolha do sdb para gravar a chamada do Grub, o objetivo foi preservar o MBR do sda, — que atualmente leva ao Grub controlado pelo KDE Neon, — e o MBR do sdc, — que atualmente leva ao Grub controlado pelo Manjaro.

Motivo: — Incerteza de que o Grub do Manjaro e/ou do KDE Neon fossem capazes de gerar uma entrada adequada para carregar o openSUSE, — afinal a experiência já tinha mostrado que o Grub do KDE Neon não é capaz de carregar o Manjaro (após cada atualização, é necessário editar manualmente o arquivo /boot/grub/grub.cfg do KDE Neon).

E de fato, mais tarde foi constatado que o Grub gerado pelo Manjaro também não é capaz de carregar o openSUSE, — falta identificar qual detalhe está pegando, e descobrir se é possível uma correção permanente, ou se também exigiria correção manual após cada atualização.

Enfim, a experiência de instalar o Manjaro sem deixar que gravasse uma chamada em algum MBR (sdc) já tinha mostrado o risco de isso acabar em dor-de-cabeça, — pelo menos, para um “leigo”.

2:32 - Hardware detectado (mero exame, para registro).

2:33 - Confirmar licença Adobe.

Finalizada a instalação do openSUSE, — com direito a acompanhar os detalhes, pela segunda aba

Segue-se a instalação no computador, propriamente dita, — acompanhada (e fotografada) pela aba “Detalhes”.

Histórico de pacotes do Gerenciador de software do YaST2

O registro completo desses “detalhes” da instalação foi encontrado, mais tarde, nas primeiras 2.852 linhas do arquivo /var/log/zypp/history, — indicado no Histórico do Gerenciador de pacotes do YaST2.

Registro final da instalação no log do Gerenciador de pacotes do YaST2

3:02 - Último registro da instalação no arquivo /var/log/zypp/history.

3:06 - Concluída a instalação do openSUSE, — mensagem: — “O sistema vai reiniciar agora”.

Editando o Grub


Acrescentando no Grub do openSUSE o parâmetro necessário para carregar o Manjaro

Logo nos primeiros testes, ficou comprovado que nem o Grub do openSUSE conseguia carregar o Manjaro, — nem o Grub do Manjaro conseguia carregar o openSUSE.

No primeiro caso, também ficou comprovado que bastava acrescentar, — no Grub do openSUSE, — o mesmo parâmetro já testado no Grub do KDE Neon, para finalmente conseguir carregar o Manjaro.

Na última linha de cada entrada referente ao Manjaro, — em /boot/grub2/grub.cfg (do openSUSE), — onde se vê:

initrd /boot/intel-ucode.img

Acrescentar o parâmetro que falta:

initrd /boot/intel-ucode.img /boot/initramfs-4.4-x86_64.img

É uma solução precária, imediatista, — a longo prazo, é chato ter de fazer essa correção manual, a cada atualização do Grub, — mas tem a vantagem de já ser conhecida, e permitir que siga em frente, sem perda de tempo, até encontrar melhor solução.

Comparação das entradas “openSUSE” no seu Grub (dir.) e no Grub do Manjaro (esq.)

Em princípio, nada impede que também se encontre a “correção” necessária para que o Grub do Manjaro consiga carregar o openSUSE. — É questão de mais tempo ou menos tempo, conforme a prioridade que se dê a essa busca.

De resto, ambos os Grub conseguem carregar todos os demais sistemas instalados, — Debian, Kubuntu e “derivados”, — sem nenhuma outra correção “manual”.

Grub exibindo apenas uma parte do Menu de inicialização, — de openSUSE até Manjaro

Em termos visuais, — e abstraindo a imagem de fundo, de fácil alteração, — o Grub do openSUSE exibe letras maiores e mais legíveis.

Colapso do retângulo central utilizado pelo Grub, ao confirmar (Enter) uma seleção

A princípio, a explicação parecia estar em uma menor resolução na tela. — De fato, a “área útil” limita-se a um retângulo centralizado, — e ao confirmar uma seleção (Enter), a primeira coisa que acontece é essa área central dar lugar a um retângulo preto.

Com seta para baixo ou “End”, descobre-se o resto do Grub, — com Zesty Zapus e Ready-only Snapshot

É esquisito, mas há outra consequência pior. — O retângulo central não comporta todas as entradas, — 7 sistemas, cada um com suas Opções avançadas = 14 linhas + Read-only Snapshot.

Como não há qualquer indicação de “Segue”, ou “Continua”, isto só foi percebido, ao procurar o Zesty Zapus.

Antigo Grub do KDE Neon, também com (aparente?) ausência do Linux Mint

É possível que esta fosse a causa da (aparente?) ausência do Linux Mint, em um antigo Grub do KDE Neon, — provavelmente corrigida (sem perceber como), ao editá-lo no Grub-customizer. — As características são bastante parecidas.

Alteração do tamanho do retângulo do Menu de inicialização, no tema do Grub

Existem advertências contra o uso do Grub-customizer, — encontrado no repositório da comunidade (não-oficial), — mas pesquisando um pouco pode-se descobrir a solução do problema, editando arquivos de configuração.

A causa acabou sendo encontrado no arquivo /boot/grub2/themes/openSUSE/theme.txt, — e não tinha nada a ver com “baixa resolução”. — As letras são grandes porque a configuração adota fonte DejaVu Sans Bold 14, e faltava espaço porque o Menu de inicialização tinha sua altura limitada.

Menu de inicialização, finalmente completo na tela do Grub

Alterados o início e a altura do retângulo, finalmente o Menu de inicialização foi exibido por inteiro, — sem necessidade de se procurar alguma coisa escondida.

Suposto erro no Grub, — apenas olhe. — Nenhuma consequência, até hoje

Após editar 2 ou 3 arquivos de configuração do Grub (inclusive /etc/default/grub), — mas ainda antes de conseguir alterar a imagem de fundo, — o Menu de inicialização começou a exibir uma mensagem de erro, — “sparse file not allowed”.

Jamais foi pressionada nenhuma tecla “para continuar”, — bastava esperar alguns segundos, para seguir com o carregamento do Linux selecionado, — e após 6 dias ainda não havia percebido nenhum problema real.

Com todas as anotações, fotos e capturas de tela, ameaçava ser trabalhoso e demorado, descobrir qual alteração causou isso, testando item por item.

No entanto, uma simples busca por “sparse file not allowed” (entre aspas) retornou dezenas de tópicos certeiros, desde 2011 (pelo menos).

O “problema” foi causado por uma tentativa de que o Grub “lembrasse” (e selecionasse automaticamente) o último Linux carregado, — possibilidade já conhecida (na teoria), mas experimentada (na prática) apenas no Manjaro, que já vem configurado assim.

Acontece que o Grub não grava em partições de formato btrfs, — caso do openSUSE, — daí, essa mensagem de erro.

E de fato, o Grub do openSUSE nunca chegou a selecionar o último Linux carregado.

Bastou reverter aquela configuração, — tornar a comentá-la com um “#” no início da linha, — e a mensagem de erro desapareceu:

# GRUB_SAVEDEFAULT="true"

Montagem automática de partições


Montagem automática de partições pelas Configurações do sistema (KDE), — inútil no openSUSE

Tal como no Debian, a montagem automática de partições adicionais no início da sessão, pelo KDE, — “Configurações do sistema → Hardware → Armazenamento removível → Dispositivos removíveis”, — também não funciona no openSUSE.

No Debian KDE, recorri (por enquanto) ao Gerenciador de Discos (Disk Manager), que se encarrega da edição do /etc/fstab, através de opções feitas em uma interface gráfica.

O recurso oferecido pelo openSUSE, — bem mais detalhado (e organizado) que o “Disk Manager” do Debian, — chama-se “Particionador”.

Trata-se, na verdade, de uma seção ou módulo do YaST, — Yet another Setup Tool, — o Centro de Controle do openSUSE.

Uma vez aberto, chama-se “Particionador avançado”, — e é ninguém menos que o “Particionador experiente”, já visto durante a instalação.

Recepção quando se pensa em apenas montar automaticamente algumas partições

Exige senha, para começar, e já abre com uma advertência assustadora sobre os perigos de se formatar o que não deve. — De fato, a todo momento pode-se cometer um engano.

Pessoalmente, não gosto dessa mistura de funções inocentes com ações potencialmente desastrosas. — Faz todo sentido, aterrorizar o leigo, para que se afaste dali, — mas, então, como ele resolverá um problema tão banal?

No fundo, tudo se resume em (1) Não formatar; (2) Montar; e (3) Digitar um ponto de montagem

Nas primeiras horas, o “Particionador” foi utilizado para montar apenas as partições de uso mais urgente, — Works, Sites, XTudo e Armazem1.

Ao “editar” uma partição ainda não montada, é necessário marcar “Montar partição”, — com o cuidado de não marcar “Formatar a partição”.

A única “dificuldade” é criar o ponto de montagem, — é preciso “inventar” e digitar um caminho (path), — pois as sugestões automáticas limitam-se a algumas pastas do sistema.

Opções do /etc/fstab

Após algum tempo pesquisando, — para entender um mínimo sobre aquela pletora de opções, — a conclusão foi de que não havia mais nada que valesse a pena mexer.

Exame das opções referentes à montagem da partição “Works”

Resumo das ações que serão aplicadas ao clicar em Concluir

Edição posterior do arquivo /etc/fstab, — a partir do Dolphin em modo Root, — pra corrigir um ponto de montagem

Um erro cometido ao “inventar” e preencher o ponto de montagem da partição Works foi corrigido mais tarde, por edição manual do arquivo /etc/fstab, — aberto a partir do Dolphin em modo Root.

Particionador do YaST2 no modo de exibição Gráfico de montagem

Dias depois, — confirmado que as 4 montagens iniciais funcionavam conforme o esperado, — voltou a ser aberto o Particionador do YaST2 para configurar a montagem automática das partições dos demais Linux, para monitoramento pelo Conky.

Preenchimento manual de um ponto de montagem “inventado” arbitrariamente

Após marcar “Montar”, — com o cuidado de ”Não formatar”, — cada partição escolhida exigiu “inventar” e preencher por digitação um ponto de montagem “arbirtrário”.

Digo, “arbitrário”, no sentido de que nenhum “padrão” foi sugerido pelo sistema.

Resumo das alterações a serem aplicadas pelo Particionador do YaST2

Por decisão pessoal, “arbitrária”, foi seguido o “padrão” /media/flavio/LABEL, criado pelo Kubuntu e seus “derivados”, — “padrão” que se deve, em grande parte, aos caminhos e opções do início do ano passado, — por exemplo, usar o Dolphin (udisks) e/ou as Configurações do sistema (KDE) para montar as partições, aceitar o resultado e aplicá-lo depois em outros sistemas (exceto Manjaro, que segue no padrão /run/media/flavio/LABEL, por enquanto).

Uma consequência desse “padrão” é que alguém logado como “visitante”, a priori, não terá acesso a todos esses pontos de montagem, — mas ainda falta estudar (e conferir) como essas coisas acontecem, na prática.

Particionador do YaST2 edita o arquivo /etc/fstab, — e efetua a montagem no mesmo instante

O Particionador do YaST2 não se limita a editar o arquivo /etc/fstab, — também faz a montagem das partições, na mesma hora.

Montagem das partições com efeito quase imediato sobre o Conky

O resultado da montagem das partições é percebido no Conky, quase que de imediato, — com exceção de algum erro, — ou nos casos em que permaneça algum conflito.

No primeiro dia, uma tentativa de usar ponto de montagem /media/$USER/Works impediu que, — após corrigir, — o novo ponto de montagem /media/flavio/Works entrasse em funcionamento imediato.

A correção só funcionou, de fato, após reiniciar o computador.

Agora, isto se repetiu com a partição-raiz do Linux2, — rótulo da partição /dev/sda3, devido a uma antiga inversão, com origem em 2009. — Também neste caso, a correção só fez efeito após reiniciar o computador.

É possível que, deletando manualmente o ponto de montagem conflitante, a correção pudesse vigorar de imediato, — mas isso não foi verificado.

Montagem de outras partições sem /etc/fstab


Autorização para montagem de partições adicionais por udisks2 sem pedido de autenticação no openSUSE

30 Mar. 2017 - Após um levantamento sobre a montagem de partições adicionais nos diferentes sistemas Linux instalados, chegou a hora de substituir o uso indiscriminado do “/etc/fstab”, — que agora volta a ser reservado para as partições do sistema, — raiz (“/”), “/home” e Swap.

A “receita” específica para uso de udisks2 + polkit-1 no openSUSE foi encontrada na resposta de Shaman Penguin a uma questão “LEAP 42.2 Dolphin Drag and Drop”.

Tratava-se de criar um arquivo “/etc/polkit-1/rules.d/10-udisks2.rules”, com este conteúdo:

// See the polkit(8) man page for more information
// about configuring polkit.
// Allow udisks2 to mount devices without authentication
// for users in the "users" group.
polkit.addRule(function(action, subject) {
    if ((action.id == "org.freedesktop.udisks2.filesystem-mount-system" ||
         action.id == "org.freedesktop.udisks2.filesystem-mount") &&
    subject.isInGroup("users")) {
        return polkit.Result.YES;
    }
});

Usando Krusader como Root, para ver e editar arquivos na pasta “/etc/polkit-1/rules.d/” do openSUSE

Com tantos sistemas instalados “em paralelo” (multiboot), essa operação foi realizada no Kubuntu, — que estava usando usando para examinar a estrutura hierárquica das pastas de sistema do Debian e do openSUSE, — pensando na possibilidade de copiar o “/etc/polkit-1/rules.d/99-udisks2.rules” do Mageia (Linux2), que por sua vez, tinha sido copiado do Antergos.

Para lidar com isso a partir do Kubuntu, foi usado o “Krusader como Root”.

Acontece que as autorizações são “lidas” por ordem alfanumérica dos nomes-de-arquivo, — e dentro desta, primeiro em “/etc/polkit-1/rules.d/”, depois em “/usr/share/polkit-1/rules.d/”, alternadamente.

Daí, a prioridade determinada pela numeração no início dos nomes-de-arquivo, conforme o exemplo do link acima:

  1. /etc/polkit-1/rules.d/10-auth.rules
  2. /usr/share/polkit-1/rules.d/10-auth.rules
  3. /etc/polkit-1/rules.d/15-auth.rules
  4. /usr/share/polkit-1/rules.d/20-auth.rules

Regras opostas, preexistentes, em “/etc/polkit-1/rules.d/90-default-privs.rules

O arquivo “/etc/polkit-1/rules.d/90-default-privs.rules”, — com uma série intrincada de configurações-padrão, que não gostaria de alterar sem entender direito, — seria “lido” antes de um arquivo começando por “99”.

Além disso, o conteúdo do arquivo “99” usado no Antergos e no Mageia não é exatamente igual ao que Shaman Penguin propõe para seu arquivo “10”, — por isso, foi dada preferência a testar este último, antes de qualquer outra coisa. — E funcionou.

Desabilitando com “#” as partições adicionais no “/etc/fstab

Para o teste, foi feito um backup do arquivo “/etc/fstab”, — e desabilitadas todas as linhas referentes às partições “adicionais”.

Montagem automática pelo udisks2, nas Configurações do sistema → Dispositivos removíveis

Em seu lugar, passou a ser usada a montagem automática pelo KDE, que usa udisks2, — agora sem exigir autenticação.

As partições “Linux5” e “Home5”, — do próprio openSUSE, — permanecem desabilitadas, uma vez que já são montadas automaticamente pelo “/etc/fstab”.

No caso da unidade SSD externa, — que geralmente permanece desconectada, mas cujas partições devem ser montadas automaticamente ao ser plugada, — foram habilitadas também as opções da segunda coluna.

Como é incerta a atribuição de “sdd” ou “sde”, — conforme um Pendrive também esteja plugado, — existem 2 entradas para cada partição, na seção “Dispositivos desconectados”.

É de se notar que os pontos de montagem “/media/flavio/”, — antigas criações arbitrárias, feitas através do Particionador do YaST2, — deram lugar a “/run/media/flavio/”.

Adaptando “~/.conkyrc” aos novos pontos de montagem

Em consequência, foi necessário alterar:

  • O arquivo (oculto) de configuração “~/.conkyrc”, para buscar informações das partições nos novos pontos de montagem
  • Os atalhos PrintScreen e Shift-Print, para o gnome-screenshot salvar as capturas de tela pelo novo caminho (path) “/run/media/flavio/000_PrintScreen/
  • As pastas exibidas em várias abas do Dolphin, — que abre automaticamente com o início da sessão, — e “Salvar sessão”, para tudo correr bem com o recurso “Restaurar sessão salva manualmente”

Diferenças no comportamento do Conky, ao tentar exibir informações de uma partição desplugada

Eventualmente, a mudança também afeta o modo como o Conky exibe informações de partições não-montadas, — como as do Armazem2, do Sabayon e do Antergos, — quando a unidade SSD externa não está plugada.

Quando a montagem é feita pelo “/etc/fstab”, o Conky exibe informações que são, na verdade, da partição-raiz, — onde se encontra o link para o ponto de montagem vazio.

Quando a montagem é feita pelo udisks2, o Conky exibe as informações “zeradas”, por falta de dados.

Wine, CorelDraw, Dreamweaver, MS Word e Verdana


Mapa temático de Brasília e do DF, — em camadas, — elaborado por volta de 2005

GoogleEarth e Wine não costumam ser prioridades, ao configurar um novo sistema Linux. — Não são de uso diário, — e já estão funcionais em 2 ou 3 sistemas, instalados em 2 ou 3 HDDs diferentes.

Obter fontes de letra Verdana, — ou algum sucedâneo, como Vermana, Veranda etc., — foi o “motor” que acelerou as experiências com Wine.

Compensar a ausência temporária de fontes Verdana implicaria em duplo desperdício de trabalho, primeiro, para alterar um sem-número de configurações (como chegou a ser tentado no Conky), — e no futuro, refazer todas as configurações outra vez.

Reexportando um dos temas cobertos pelo mapa de Brasília, — o Contorno do Paranoá (EPCT)

Além da “legibilidade na tela”, as fontes Verdana têm outra característica valiosa, — espaçamento mono dos números, ponto, vírgula, espaço em branco e outros caracteres típicos de campos semi-numéricos, — de modo a manter o alinhamento em colunas desse tipo.

A aparente inexistência de pacotes como ttf-mscorefonts-installer (ou fonts-arkpandora, por exemplo), levou a tentar um “atalho” recém-descoberto. — Basta ter os pacotes Verdana em algum lugar dos HDDs, para adicioná-los ao sistema pelo Gerenciador de fontes. — E o antigo CorelDraw traz Verdana, bem como várias outras fontes, utilizadas em inúmeros arquivos, acumulados desde a década de 1990.

Mapa temático exportado pelo CorelDraw, com todos os detalhes das camadas selecionadas

No entanto, o bom resultado da instalação e no teste do CorelDraw, — e em seguida, do Dreamweaver e do MS Word, — sem qualquer falha ou perda de tempo, fez com que tudo isso avançasse rápido.

Dreamweaver conectado e com cache de 10 mil arquivos atualizado

Ficou faltando apenas o teste de conversão de antigos arquivos do MS Word / Ventura Publisher, — que ainda depende de instalar o Wordpad (único que identifica o antigo “á), e de recuperar e substituir o arquivo Normal.dot, com todas as macros acumuladas até cerca de 2001~2003.

Texto “menos antigo”, já em Word / VP para Windows, — há outros, ainda do Word DOS / Xerox VP

Para um acervo que não cresce nem evolui, — e que já foi parcialmente convertido, — não compensa investir em novas alternativas, se já foram feitas macros para converter textos do MS Word alterados pelo Ventura Publisher (desde as versões DOS até as primeiras versões Windows).

Opções para abrir os instaladores de programas do Windows, — com Wine, ou com Q4Wine

O único registro diferente, — em relação à experiência anterior, — é que no openSUSE se ofereceram 2 opções para rodar os instaladores desses antigos aplicativos, — “Abrir com Wine” ou “Abrir com Q4Wine”.

Esta 2ª opção levou a um aparente beco-sem-saída, — exige indicar a localização das “livrarias” para 32bit e 64bit, — enigma que o fraco entendimento de leigo não logrou desvendar nos primeiros minutos.

Fica de molho, — até que encontre alguma vantagem, — uma vez que a velha e boa opção “Abrir com Wine” funcionou à perfeição, tanto para o CorelDraw, quanto para o DW e o MS Word.

Para se manter fiel à tradição, — ao usar pela primeira vez a opção “Abrir com Wine”, — ele detecta a ausência do pacote “Mono” e se oferece para instalá-lo. — Costumo aceitar, e até hoje nunca falhou.

Funcionalidades dos sistemas Linux, — dentro das limitações de um leigo. — Fontes: Verdana, Dingbats

A instalação do CorelDraw, do Dreamweaver e do MS Word deu tão certo, que elevou drasticamente a pontuação do openSUSE como candidato a sistema “principal”, ao lado do Kubuntu 16.04 LTS e do Linux Mint 18 KDE.

Com sua habilidade para enfrentar corrida de obstáculos no Facebook (embora sem vídeos), já vinha sendo usado como “principal”, — aliás, quase único, exceto 2 dias dedicados a um conserto do Manjaro (+ relato), — e começa a fazer sentido movê-lo para o sda, — uma vez que os outros “principais” estão em sdb1 e sdc1.

Em tempo: - A marcação com “x” vermelho no Quadro comparativo não significa que sejam itens impossíveis, — apenas, (ainda) não foram conseguidos. — Os itens em branco ainda não foram tentados a sério, pela percepção de que poderiam exigir muito tempo, sem haver prioridade que justifique.

Efeito da instalação das fontes Verdana sobre o Conky

Enfim, as tais fontes Verdana, — cuja busca provocou esses bons resultados, — foram a última coisa a ser obtida, horas mais tarde.

Primeiro, foram instalados free-ttf-fonts e intlfonts-ttf-fonts, — encontrados com facilidade pela busca no Gerenciador de pacotes do YaST2, — mas sem resultado prático.

Infelizmente, faltou escolher o pacote que de fato resolveria o problema, — fetchmsttfonts, que localiza, baixa e instala as fontes disponibilizadas pela MS para uso geral, — mas isso só foi descoberto depois.

Instalando várias fontes True-Type encontradas no Wine, pelo Gerenciador de fontes

Nesse meio-tempo, foram feitas várias experiências, pelo “método direto”, — usar o Gerenciador de fontes para incorporar fontes TrueType já existentes no computador.

No caso, as fontes TTF existentes na pasta /home/flavio/.wine/drive_c/windows/Fonts/.

Selecionadas várias fontes True-Type, escolhe-se instalar “para uso pessoal” (só do Usuário) ou para todo o sistema (disponível para todos). — Não chegou a demorar 1 minuto. — Houve 1 aviso de erro (fonte já instalada), e a opção foi “Ignorar automaticamente”, para evitar novas interrupções.

Substituição global do comprimento dos gráficos de barra do último bloco do Conky

Depois disso, o ajuste do Conky consistiu basicamente em reduzir o comprimento dos gráficos de barra do último bloco inferior, encurtar o nome “openSUSE” e corrigir alguns espaçamentos tornados desnecessários.

Mais tarde, “enp1s0” foi substituído globalmente por “eth0”, — e finalmente o Conky passou a exibir o tráfego de rede.

Log da instalação do fetchmsttfonts

Por último, foi instalado o fetchmsttfonts, — e eliminadas as fontes duplicadas. — Saiu Verdana local (só do Usuário), ficou Verdana obtida na web (disponível para todo o sistema).

Outras configurações e registros (17 a 27 Jan. 2017)


Efeito do tema Maia transparent sobre o Painel. — Também afeta o Menu, notificações etc.

Este é apenas um um resumo do índice em TXT, — quase 400 linhas, para localizar eventos nas fotos e capturas de tela já renomeadas, — e mesmo estas não incluem todas as configurações.

Algumas coisas, — como substituir o Menu K tradicional pelo Menu em cascata, configurar o KDE Spectacle e suas teclas de atalho, por exemplo, — já se tornaram tão banais, que nem foram registradas.

17 Jan. 2017


3:14 - Sincronizar data e hora automaticamente. - Ok.

3:25 - Instalando Conky (via YaST2). - Ok.

3:48 - Workspace theme - Obter novos temas - Maia transparent. - Ok.

Conversão de arquivos do formato PNG para JPEG, no Konqueror

3:54 - Konqueror - Viewmode filesize. - Ok.
3:56 - Konqueror converte PNG em JPEG. - Ok.
3:57 - Konqueror - falta KFind. - Instalar KFind.
3:59 - Konqueror - CTRL-F - Busca-avancada. - Ok.
4:01 - Konqueror - Falta ISO-mount.
4:04 - Instalar Chromium. - Ok.
4:12 - Wine e Xsane instalados. - Ok.
4:16 - Instalar fuseiso. - Ok.

O Konqueror apresentou 4 das 5 funcionalidades procuradas, — Painel lateral (F9), Busca avançada, Modo de exibição “Tamanho de arquivo”, Conversão de arquivos PNG para JPEG, — e até o momento só não oferece “Montar e abrir imagem ISO”.

Abrir imagem ISO com Ark praticamente elimina a urgência de procurar “iso-mount”

A descoberta de uma opção ainda não explorada até agora, — abrir imagem ISO com Ark, — extingue qualquer urgência de procurar “Montar e abrir imagem ISO”.

Para obter “Busca avançada” no Konqueror, foi necessário instalar KFind (via YaST2).

A instalação do Chromium (v.55) apresentou um conflito com chromium-ffmpegsumo (v.54), — e optei por não instalar este último. — Falta pesquisar a possibilidade de substituir o Chromium pela versão anterior (v.54).

A consequência perceptível é que apenas uma parte dos vídeos são reproduzidas no Chromium, — mas a maioria dá erro.

Porém, o Chromium enfrenta muito bem os obstáculos que o Facebook opõe à navegação em “Páginas”, — e no momento isso é muito mais valioso do que ver vídeos. — A ver, se uma coisa tem relação com a outra.

O Xsane já foi bastante testado, — 48 páginas de várias revistas.

4:25 - Cubo tem duração limitada a 0,5 segundo (difícil capturar tela).

4:50 - pasta-PrintScreen-proprietario
4:54 - chown-pasta-PrintScreen

Embora o conteúdo da partição “XTudo” pertencesse a “flavio”, a gravação estava bloqueada, — talvez, porque a montagem inicial foi feita por clique no Dolphin, — que exige senha (tal como o Debian).

5:02 - KWallet-intrujao
5:02 - KDEwallet-intrujao

Desativar a Carteira do KDE foi uma das primeiras providências, — assim como desativar a Pesquisa de arquivos, — porém ainda houve alguns casos em que a abertura do Chromium solicitou KDEWallet. Depois, isso parou.

7:34 - [Nokia] - Bloqueio de tela, após algum tempo longe do computador. — Desabilitado bloqueio de tela, — e também o bloqueio ao retornar.

Baixar fotos do celular ou da câmera digital, pelo Kamera, — usar a opção em minúsculas

10:58 - baixa-fotos-celular-Nokia-windowsphone

O Kamera (do KDE) vem sendo usado há vários anos, para baixar fotos da câmera digital Sony, — e mais recentemente, também do celular Nokia Lumia (Windows Phone 8), — porém só chamou atenção há cerca de 1 ano, quando essa operação apresentou dificuldades no Linux Mint 17.3 Cinnamon (possivelmente, por desconhecimento do ambiente Cinnamon).

De acordo com as observações deste último ano, é inútil clicar na opção onde “Gerenciador de Arquivos” começa com maiúsculas, — assim como é inútil clicar no item que aparece no painel lateral (esq.) do Dolphin.

Só o que funciona é clicar na opção totalmente em minúsculas, da Notificação, — e que abre uma 2ª janela do Dolphin, no alto da tela. — Em seguida, basta arrastar as fotos para a pasta de destino, no Dolphin de baixo.

Arrastar, soltar, e selecionar “Copiar aqui”, — não “Mover aqui”

Depois de algumas experiências malucas (e desnecessárias) com gPhoto, Gwenview, Qlix etc., — que resultaram na perda de um cartão de memória externa do Nokia Lumia, e a necessidade de reformatar o cartão da câmera digital Sony por meio de um ritual esotérico, — nunca mais arrisquei a opção “Mover”.

Agora, uso sempre a opção “Copiar”, — e depois deleto as fotos no celular e na câmera digital, usando seus próprios recursos.

É possível que os problemas com os cartões de memória se tenham originado ao desconectar os dispositivos depois de concluída a cópia, — porém antes de se concluir a remoção dos originais. — Fato é que, clicando com o botão direito do mouse no dispositivo (painel lateral do Dolphin), não é dada a opção “Desconectar com segurança”. Portanto, na falta de indicações claras, o risco não compensa. — Ao passo que, escolhendo a opção “Copiar aqui”, o Dolphin informa com clareza o momento em que a tarefa termina.

Guardar sempre a última foto baixada, — com o nome original, — facilita muito a vida.

Copiando a fórmula já construída, — deu trabalho, — para renomear as fotos no KRename

11:02 - instala-KRename
11:05 - KRnema-fotos-celular

Para renomear as fotos do celular, — no mesmo padrão das capturas de tela, para se enfileirarem por ordem cronológica, — foi instalado o KRename.

O passo seguinte é colocá-lo como 2ª opção para abrir Pastas, — nas “Associações de arquivos”, — logo abaixo do Dolphin.

Assim, basta um right-click na pasta com as fotos, para abri-la no KRename pelo Menu de contexto.

O ideal seria dispor do pyRenamer, — muito mais simples de usar (embora igualmente rico em recursos), além de “lembrar” padrões salvos antes, — porém ainda não foi encontrado pelo YaST2.

Uma vez que a construção da “fórmula” no KRename deu bastante trabalho, foi guardada em arquivo TXT, para reuso em diferentes sistemas Linux.

18 Jan. 2017


14:58 - Texto selecionado no Chromium “desaparece”, — a seleção é “destacada” em letras brancas sobre fundo branco, — a mesma cor de fundo de zilhões de sites e blogs. — Por coincidência, também é a cor de fundo do editor de texto do Blogger.

Isso também afeta várias outras tarefas, — onde um nome ou título surge “selecionado”, — por exemplo, o título de uma página a ser marcada como Favorito (Bookmark).

Ainda sem solução.

19 Jan. 2017


00:36 - surto-FB-mais-DCM
00:38 - fim-surto-Chromium-fechado-Swap-alto

Foi um caso raro, — no openSUSE, — de sobrecarga de CPU (e Swap).

Embora o Facebook estivesse aberto em 1 aba do Chromium, não se tratava de uma “Página”, — apenas o “Feed de notícias”. — Em outra aba, estava aberta uma página do DCM, lotada de publicidade intrusiva.

01:39 - Spectacle configurado para passar a gravar diretamente em /XTudo/Byteria/openSUSE.

Atualizações automáticas do openSUSE

13:48 - Updates. — Leitura difícil dos nomes dos pacotes em letras miúdas, passando em rápida sucessão, — enquanto a maior parte do retângulo da notificação não é utilizada.

De acordo com o registro da instalação e atualização de pacotes no arquivo /var/log/zypp/history, o que aconteceu nesse momento foi isso:

  • 2017-01-19 13:48:21|command|root@linux-yjpi|'/usr/lib/packagekitd'|
  • 2017-01-19 13:48:24|install|bind-libs|9.9.9P1-43.1|x86_64||download.opensuse.org-oss_1|f9fc8a55f8b06ce0f6475000624a1b02f632672ff54c8b9f21e9eb8c12985490|
  • 2017-01-19 13:48:24|install|bind-utils|9.9.9P1-43.1|x86_64||download.opensuse.org-oss_1|b59f3adc6eabdd9262a79e1e2126fac20957c4121101ca8e7f748dbe71c15cf1|
  • 2017-01-19 13:50:03|command|root@linux-yjpi|'/usr/lib/YaST2/bin/y2base' 'sw_single' 'qt'|

20 Jan. 2017


16:23 - Updates

17:18 - alguns-videos-funcionam (Chromium).
18:03 - outros-videos-nao

21 Jan. 2017


11:38 - Finalmente, obtida montagem automática da partição Linux2 (sda3) ao carregar o openSUSE.

Também pela primeira vez, o openSUSE abre sem pedir senha para montar determinada partição, — que só foi montada manualmente (via Dolphin) uma única vez.

24 Jan. 2017


11:38 - Updates
11:40 - Dolphin ainda com 5 entradas para ocultar

25 Jan. 2017


Produção do índice cronológico de fotos e capturas de tela

10:11 - Grub-customizer-desaconselhado.png
10:11 - Grub-customizer-instabilidade.png
13:27 - Cronologia-Kwrite-modo-edicao-bloco.png

21:35 - Conclusão do levantamento inicial.

26 Jan. 2017


(1) Só o log informa que faltou atualizar o Grub; (2) Comando; (3) Correção das entradas do Manjaro

12:46 - Notificação de atualizações.
12:49 - Concluída atualização de 5 pacotes.

12:55 - Exame do arquivo /var/log/zypp/history indica que ficou faltando atualizar o Grub; — sugere fazer isso manualmente. — Mas, e se eu não fosse curioso de olhar o arquivo de log?

12:56 - Grub atualizado manualmente.
12:57 - Copiando manualmente o “apêndice” necessário para carregar o Manjaro.

1) Registro esse episódio, apenas como uma idiossincrasia curiosa. — Parece improvável que o Grub de fato precisasse ser atualizado, — uma vez que a entrada principal do openSUSE não se altera (mesmo quando há um Kernel novo), — e não há necessidade de acrescentar nova entrada nas Opções avançadas (já que nenhum Kernel se tornou “antigo”).

2) Atualizar manualmente o Grub do openSUSE não exige nenhum esforço sobre-humano, — mas vale notar que o comando é dado por extenso:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Notar que esse é o verdadeiro comando por trás do “update-grub”, — mero “alias”, — utilizado no Debian, no Kubuntu etc. — Veja também Grub2/Setup; ou este tópico sobre o Fedora.

3) O complicador, — neste caso específico, — é que após cada atualização do Grub é necessário inserir manualmente um parâmetro que falta na última linha de cada entrada referente ao Manjaro.

_______________
Relato inicialmente publicado às 13:41 de 17 Jan. 2017, e desenvolvido até 23:25 do dia 27, no openSUSE Leap 42.2 KDE.

— … ≠ • ≠ … —

Não-debians