sábado, 15 de setembro de 2018

Fedora 28 KDE - install, config

Fedora 28 KDE instalado

Esta é minha 2ª instalação do Fedora, — ver Fedora 25 KDE (31 Jan. 2017), — e 6 horas depois, não carregava mais.

Depois de várias tentativas sem sucesso, já tinha desistido do Fedora 28 e me preparava para testar outra distro, — OsGeoLive chegou a ser baixada e gravada em DVD, — a ser precedida de um teste de badblocks destrutivo.

Fedora 28 acabou salva por uma tentativa final, no último instante, — voltou a carregar, — e ganhou sobrevida, para continuar tentando, a duras penas.

No entanto, continuou apresentando problemas em série, por mais alguns dias. — Este relato teve um início precipitado, para registrar o essencial, “antes que acabe”. — Dias depois, foi encontrada a causa dos problemas, e Fedora 28 se tornou uma distro civilizada.

Índice


  • Sessão Live
  • Instalação: Anaconda
  • Histórico de pacotes
  • Datação

Sessão Live


Verificação da imagem Fedora-KDE-Live-x86_64-28-1.1.iso por sha256sum

Foi escolhida a imagem Fedora-KDE-Live-x86_64-28-1.1.iso, — feita a verificação, — e gravada em DVD pelo K3b, para guardar.

No Menu de Boot, simplesmente escolhi o primeiro item, — “Start Fedora-KDE-Live 28”, — pois os demais não tinham interesse naquele momento.

Pelo KSysguard, fica claro que o Fedora KDE Live montou todas as partições Swap que encontrou, — comportamento inconveniente, a priori.

Por hábito, o ambiente foi preparado para várias atividades paralelas à instalação, — como abertura do Konqueror, para eventual pesquisa na web. — No caso do Facebook, ele abriu várias vezes como Mobile (m.facebook.com).

Papel de parede original do Fedora KDE Live 28, antes de reiniciar a sessão Plasma KDE

Pretendia digitar anotações de todo o processo no Kate (na verdade, KWrite), — com direito a data & hora exatas, via F7, — por isso, foi configurado Teclado ABNT2 (pt_BR) com acesso ao 3º Nível.

Ao reiniciar a sessão KDE (Logout / Login), — ideia boba, pois as configurações do Teclado não precisam disso para fazer efeito, — o papel de parede do Fedora 28 Live foi substituído pelo do KDE, — e caiu a conexão web.

Bastou Desconectar / Conectar pelo ícone da área de Notificações do Painel, para restabelecer o acesso à Rede.

Uso intenso de CPU ao iniciar o instalador Anaconda, no Live Fedora 28 KDE

Teria sido inútil configurar a área de trabalho na sessão Live, para instalação. — Ao clicar no ícone Install to Hard Drive, o instalador Anaconda ocupa toda a tela, — exceto o Painel.

Exame de hardware retarda a escolha do Idioma a ser usado pelo Anaconda, — e que afeta o Relógio

Há uso intenso de CPU, — desde o clique inicial, até vários minutos depois de escolher o Idioma a ser usado durante a instalação. — Suponho que se trata do exame do hardware, que neste caso abrange nada menos que 41 partições em 3 HDDs + 1 SSD externo.

Apesar disso, foi útil configurar o Menu (Cascade), KWrite, Konsole, Spectacle, além do Relógio. — Mas o fuso horário escolhido no início (UTC-0300) sofreu alteração pelo Anaconda. — Após escolher o Idioma a ser usado durante a instalação (pt_BR), Anaconda tornou a subtrair 3 horas (UTC-0600), sem atentar para o fuso escolhido (Time Zone); e apesar da sincronização NTP (que já veio ativada).

Após fechar o Konqueror, não foi mais possível reabri-lo (2 tentativas), — mas foi possível abrir 2 janelas do Konsole: uma para monitorar as atividades pelo Top; outra para tentar monitorar a Temperatura pelo Lm-Sensors (em vão: não existe isso na imagem ISO). — O KSysguard e o KWrite já estavam abertos antes do Anaconda.

Instalação: Anaconda


Etapas iniciais do instalador Anaconda no Fedora 28 KDE

Não existe uma ordem definida para as 4 primeiras etapas da instalação pelo Anaconda, — Teclado (adivinhou); Hora & Data (adivinhou); Nome do Host & Rede; Destino da instalação, — mas este último foi deixado para o final, por ser uma etapa crítica.

Particionamento dos HDDs + SSD externo para instalação de 12 distros Linux em dualboot

Diante do particionamento cuidadosamente organizado para permitir a convivência de 12 distros Linux em “slots” lado-a-lado, — sem interferência mútua, — não faria sentido permitir que o instalador Anaconda se esbaldasse e fizesse a festa, como bem entendesse.

Seleção do SSD externo e da opção de Particionamento “Personalizado”, no instalador Anaconda

Portanto, o caminho era selecionar um único disco, — o SSD externo, — e Particionamento “Personalizado”.

Nesse aspecto, é tranquilizador o aviso de que: — “Os discos não selecionados aqui não serão tocados”.

Essa garantia trouxe tranquilidade, mais adiante, — ao perceber que não tinha visto nenhum campo para selecionar a localização do Bootloader. — Era fundamental que o Anaconda não gravasse a trilha inicial (MBR) do primeiro disco (sda), de onde é chamado o Menu de inicialização da máquina, sob controle do Mageia.

Substituição de “LVM” por “Partição padrão”, no instalador Anaconda

Chegando ao Particionamento “personalizado” (manual) do SSD externo, o Anaconda agrupa as partições pertencentes a cada sistema instalado, — “Debian GNU-Linux 9” (MX Linux), “LMDE 3”, “Linux desconhecido” (Devuan 2), — e em “Desconhecido” uma partição de backup (Armazem1), que não pertence a nenhuma distro.

Esse agrupamento de partições, — segundo o sistema a que pertencem, — veio bem a calhar, para o sistema de “slots” adotado nessa máquina. Não faria sentido usar a partição-raiz de uma distro, a partição-home de outra, e a partição-swap de uma terceira distro.

Neste caso, seriam usadas as partições do MX Linux (Debian GNU-Linux 9), — que não tinha sido bem instalado e configurado. — O Plasma KDE implantado sofria várias interferências de resíduos de configuração do IceWM-Roxy original.

A primeira providência foi substituir a opção LVM, — “Logical Volume Manager”, preferida pelo projeto Fedora, — por partições “padrão” (tradicionais). Pretendia instalar o Fedora 28 em partições comuns, independente de quais partições seriam escolhidas.

Essa opção pessoal se mantém desde a instalação do Fedora 25, — quando pesquisei o assunto. — A meu ver, partições LVM não trariam nenhuma vantagem para um usuário comum, analfabeto em TI, com uma máquina antiga, 2 HDDs velhos e lentos (2008); 1 SSD externo USB2 bastante usado (2011); e apenas 1 HDD mais recente (2016).

Distribuição das 3 distros Linux mais produtivas, em 3 HDDs diferentes

No momento, o risco está “distribuído”, — das 3 distros que domino melhor, KDE Neon está em um HDD; Kubuntu em outro; Linux Mint em um terceiro, — de modo que qualquer falha em 1 dos 3 HDDs ainda deixa 2 distros habilitadas para todas as atividades.

Já o SSD externo tem sido usado para as mais variadas experiências, — Antergos, Sabayon, Devuan, antiX, MX Linux, LMDE 3; e agora, Fedora 28 KDE. — Nenhum motivo para misturar as coisas.

Até hoje, não houve necessidade de “redimensionar rapidamente”, — nem vagarosamente, — qualquer partição, de nenhum sistema. Os tamanhos foram definidos uma única vez, com base na experiência de 9 anos com várias distros Linux; e provavelmente só serão redefinidos ao montar outro hardware, com discos maiores, para atender as exigências previsíveis dos próximos 5 ou 10 anos.

Tampouco, nunca foi necessário “adicionar” nenhum “volume” ou partição, — nem local, nem muito menos “remoto”, — a qualquer um dos sistemas instalados.

Implantar LVM em uma máquina de uso puramente doméstico, — e cada vez mais superada, pelos parâmetros atuais, — só faria sentido para um estudante, ou aspirante a profissional, como parte de sua formação e aperfeiçoamento.

Pessoalmente, considerei uma experiência relativamente proveitosa, — ao instalar o openSUSE Leap em partição BtrFS, com /home XFS, em Janeiro de 2017. — Aprendi apenas o bastante para admirar a beleza dessa maravilha, que após mais de 1½ ano e 2 upgrades ainda não apresentou problemas. Até hoje, funciona com admirável suavidade e solidez. Numa outra experiência (Tumbleweed), sim, tive um pequeno desastre, que me ensinou a evitar outros, dali por diante. Como um macaco esperto, até aprendi 1 ou 2 truques para sair daquele aperto. Mas o grande aprendizado é que aquilo tem um custo, — com frequência, a máquina fica semi-inútil durante vários minutos, ao carregar o openSUSE Leap pela primeira vez, de manhã, enquanto se realizam tarefas agendadas de manutenção etc. E não tenho motivos para deixá-la ligada a noite inteira, pois aqueles minutos não valem o consumo de tantas horas de energia. Em suma, tenho uma segurança extra, — que o Linux Mint oferece a qualquer usuário “médio” ou iniciante, sem complicações, pela simples inclusão do Timeshift.

Seleção da partição-raiz do Fedora, no instalador Anaconda

Ao selecionar uma partição para o sistema, o instalador Anaconda indica o sistema de arquivos (ext4) e o rótulo (Label) pré-existentes. — Bastou preencher o ponto de montagem “/” e marcar para formatação. — Ao formatar, os rótulos (Label) são mantidos ou re-aplicados, o que é muito prático.

Transferência das partições da antiga distro Linux para a nova instalação do Fedora 28

O mesmo aconteceu com as partições Home e Swap, — exceto que esta última dispensa indicar ponto de montagem.

À medida em que as partições são escolhidas, “movem-se” do grupo da distro anterior para o grupo “Novo Fedora 28 instalação”.

Resumo das mudanças a serem feitas nas partições

É apresentado então um sumário das partições que serão destruídas — e sua nova destinação, — para “Aceitar mudanças”, ou voltar atrás e corrigir alguma coisa.

Criação de usuário — opção de torná-lo Adminsitrador — e configurações avançadas, no Anaconda

Depois disso, surgem mais 2 etapas, — senha de Root — e Criação de usuário, com a opção de torná-lo Administrador.

Nas configurações avançadas de Usuário, é possível escolher outro nome para sua pasta pessoal; — alterar seu identificador (UID) ou o de seu grupo (GID); — ou incluí-lo em mais alguns grupos.

Como todas as distros precisam ler e gravar nas mesmas partições de dados, foi tranquilizador ver que o Fedora adota por padrão UID e GID=1000, — o mesmo nível das demais distros instaladas (exceto PCLinuxOS, que usa 500 por padrão, e teve de ser compatibilizado).

Ao final de cada etapa, clicar “Pronto”, no canto superior esquerdo da tela, 1 ou 2 vezes.

Instalação do Fedora 28 completada

Feito isso, a parte automática da instalação (slide show) se realizou em cerca de 29 minutos, — das 11:42 às 12:11, — ou das 8:42 às 9:11, segundo o Relógio alterado pelo Anaconda.

Histórico de pacotes


Estado do Fedora 28 KDE recém-instalado, — antes de receber 962 atualizações

Uma lacuna na experiência anterior (Fedora 25), foi me limitar a dar Ok às atualizações apresentadas na área de notificações do Painel, — e a usar o dnfdragora para instalar ou remover pacotes.

Ao contrário do Synaptic, esses 2 “facilitadores” do Fedora não oferecem pesquisa no histórico, — nem permitem selecionar e copiar a lista dos pacotes envolvidos, para documentar as operações em um TXT de consulta rápida:

pacotes_historico_Arch.txt
pacotes_historico_Debian-ex8-Testing.txt
pacotes_historico_Devuan2-KDE.txt
pacotes_historico_Fedora-28.txt
pacotes_historico_KDE-Neon.txt
pacotes_historico_Kubuntu-16-04.txt
pacotes_historico_Leap.txt
pacotes_historico_LMDE3b.txt
pacotes_historico_Mageia-6.txt
pacotes_historico_Mint-17-18.txt
pacotes_historico_PCLinuxOS.txt

É muito mais simples e prático consultar ou fazer buscas nesses arquivos TXT, — pertencentes ao usuário-padrão (UID=1000), e centralizados em uma pasta acessível a qualquer distro, — do que em logs de sistema espalhados por várias pastas e subpastas de 12 distros diferentes.

Por falta de um TXT como esses, não é mais possível saber exatamente o que foi instalado ou removido do Fedora 25, por exemplo. — Queria fazer melhor, agora, com o Fedora 28.

Ao carregar pela primeira vez o Fedora 28 KDE recém-instalado, já se apresentaram 962 pacotes disponíveis para atualização, — na verdade, 942 atualizáveis + 20 para instalar, como ficou claro logo a seguir.

Pacotes efetivamente instalados com o Fedora 28 KDE

Antes de instalar essa avalanche de atualizações, procurei documentar o estado inicial do Fedora 28, com todos os pacotes instalados e suas versões:

sudo rpm -qa > ~/rpm-qa-all-installed.txt

O arquivo obtido tem 1.746 linhas, — número presumível dos pacotes instalados pelo Anaconda, — e, de acordo com o Gerenciador de Partições do KDE, estavam ocupados 5,62 GiB da partição do sistema.

Um segundo comando gerou outra lista, — agora, em ordem alfabética, — para referência rápida a qualquer momento em que precise conferir alguma coisa:

sort rpm-qa-all-installed.txt > rpm-qa-all-installed-SORT.txt

Copiando em TXT o registro das atualizações instaladas no Fedora 28 KDE

Só depois disso, foram aplicadas as atualizações, — por comando, para copiar a lista em um TXT.

Naturalmente, esse TXT já começa enorme, e logo se tornará descomunal. — O do Debian testing, por exemplo (iniciado em 1º Out. 2016), já está com 26.715 linhas, — mas isso não é problema para um CTRL-F dentro dele, no Kate.

Busca por pacotes específicos no histórico de todas as distros instaladas

Tampouco é problema para um CTRL-F por conteúdo, no Dolphin, — em uma pasta com os TXTs de todas as distros.

O TXT também inclui os pacotes manualmente instalados, — dentro da ordem cronológica dos acontecimentos, — e sempre utilizando F7 > date [Enter], no Kate, para documentar o dia e a hora aproximada do registro (cópia no TXT).

Horas exatas são dadas pelo histórico do Bash, — datado desde o primeiro dia:

1 2018-09-17_10-23-39 echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
2 2018-09-13_14-27-21 source ~/.bash_profile

[flavio@linux10 ~]$ history | grep install

27  2018-09-13_15-35-54 sudo dnf install rpm-build cabextract ttmkfdir
32  2018-09-13_16-16-57 sudo dnf install lm_sensors.x86_64
37  2018-09-13_16-49-53 sudo dnf install redhat-lsb.x86_64
39  2018-09-13_17-10-44 sudo dnf install chromium.x86_64
42  2018-09-13_17-16-42 sudo dnf install libreoffice.x86_64
45  2018-09-13_17-23-12 sudo dnf install gimp.x86_64
48  2018-09-15_09-48-20 sudo dnf install gnome-screenshot.x86_64
64  2018-09-15_14-08-27 sudo dnf install pyrenamer.noarch
65  2018-09-15_14-11-30 sudo dnf install krename.x86_64

Remoção do PackageKit pelo dnfdragora — sem direito a seleção e cópia da lista

Também pretendia incluir no TXT os pacotes removidos, mas, — no caso do PackageKit e do Akonadi, — acabei abrindo exceção, para evitar o risco de eliminar algum pacote importante, no meio de um grande número de dependências.

Histórico de pacotes do dnfdragora não oferece busca nem permite seleção e cópia das listas

Aliás, foi assim que percebi a impossibilidade de copiar a lista do dnfdragora, — pois nem lembrava mais desse detalhe.

Uma primeira tentativa de recuperar essas listas a partir dos logs do sistema não deu resultado:

$ sudo cp /var/log/dnf.rpm.log-20180916 var-log-dnf-rpm-log-2018-09-16.txt
$ sudo cp /var/log/dnf.rpm.log var-log-dnf-rpm-log.txt
$ cat var-log-dnf-rpm-log-2018-09-16.txt | grep Cleanup > var-rpm-Cleanup.txt
$ cat var-log-dnf-rpm-log.txt | grep Cleanup >> var-rpm-Cleanup.txt

Com variações dos 2 últimos comandos, foram gerados extratos dos logs com os pacotes atualizados, instalados e removidos:

var-rpm-Cleanup.txt
var-rpm-Installed.txt
var-rpm-Upgraded.txt

Isso facilita as consultas, — mas não há registro dessas remoções feitas pelo dnfdragora. — Os logs incluem tudo o que ocorreu até esse momento, e tudo o que ocorreu depois.

É possível ter havido perda de dados, devido à série de problemas enfrentados desde a atualização inicial, — pois também se perderam sucessivas configurações (memória) do Gimp, Chromium etc., — e no bash_history falta pelo menos 1 comando.

Redução do uso inicial de Memória RAM após a remoção parcial do Akonadi (73+ pacotes) e PackageKit

Com a remoção do PackageKit, — que frequentemente “contamina” a medição do uso inicial de Memória RAM, — e de 73+ pacotes ligados ao Akonadi, o consumo mínimo do Fedora 28 KDE caiu de cerca de 830 MiB para cerca de 495 MiB.

Datação


O exame da instalação, configuração e solução de problemas foi feito, basicamente, a partir de:

  • Fotos de celular
  • Capturas de tela
  • Histórico de comandos
  • Extratos de logs do sistema
  • Anotações em Caderno e em Notas.txt

As Capturas de tela, inicialmente pelo KDE Spectacle; depois pelo gnome-screenshot, já foram geradas no formato:

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

Para compatibilizar, as fotos de celular foram renomeadas pelo pyRenamer, — como poderiam ter sido pelo KRename, já que o Fedora oferece ambos, — no mesmo formato padrão.

No pyRenamer >> Imagens, — admitindo que as Fotos foram baixadas sem perda dos dados Exif:

{imageyear}-{imagemonth}-{imageday}_{imagehour}-{imageminute}-{imagesecond}_NL.jpg

No KRename, — admitindo que os arquivos foram gravados praticamente no mesmo instante das Fotos, — e baixados sem alteração de data e hora:

[creationdate;yyyy-MM-dd_HH-mm-ss]_NL[$16-[length]]

Com isso, basta reunir as Fotos e Capturas em uma pasta, para obter a sequência cronológica.

A datação do histórico dos comandos foi estabelecida logo na primeira hora:

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

Anotações em Notas.txt usam o recurso F7 >> date [Enter] — que agiliza a digitação, — embora isto sirva apenas como referência aproximada, delimitando o que foi feito antes desse momento, ou o que será tentado a partir de então.

Ainda menos exatas são as anotações à mão, em caderno, — que precisam ser conferidas com outros elementos, a posteriori, — mas neste caso foram muito necessárias, devido a abundância de erros (extremamente repetitivos), durante vários dias, para evitar um excesso de Fotos e Capturas.

Mesmo assim, foram enfileiradas nada menos que 818 Fotos e Capturas de tela do Fedora 28 instalado, — afora 159 da instalação.

— … ≠ • ≠ … —

Não-debians


Nenhum comentário:

Postar um comentário