Translate

sábado, 23 de outubro de 2021

MX Linux 21 Wildflower KDE - instalação de substituição

Tela do MX Linux 21 Wildflower KDE Plasma com as informações do sistema no KInfocentre
MX Linux 21 Wildflower •

Eu já tinha instalado o MX Linux Beta1 KDE em Agosto, e funcionou muito bem nesses 2 meses, sem absolutamente nenhum problema. — Por isso, nem me dei o trabalho de testar o Beta2 ou o RC1. — Resolvi substituir, agora, para ter, nos próximos 2 anos, uma instalação “padrão”, da versão aprovada e corrigida.

Primeiro, instalei em uma partição provisória — testei para confirmar que estava tudo certo — e só então “movi” para a partição onde estava o Beta1.

Em suma: - Substituir uma instalação existente — mas só depois de testar e aprovar a nova instalação — do mesmo modo como eu já tinha feito ao substituir a instalação do PCLinuxOS.

Índice

  • ISO, download, verificação, K3b
  • Sessão Live
  • Particionamento manual
  • Instalação
  • Teste do MX Linux 21 instalado
  • Teste do MX Linux 21 com a antiga /home
  • Substituição do Beta1 instalado antes
  • Grub, limpeza da /home e teste final
  • Teste do MX Linux 21 realocado

ISO, download, verificação, K3b

Verificação da imagem ISO pela soma sha256

Baixei a imagem ISO do MX Linux 21 KDE pelo link oficial e verifiquei a integridade do arquivo pela soma sha256.

Verificação da imagem ISO pela soma MD5

Verifiquei a integridade da imagem ISO também pela soma MD5 e “queimei” em DVD, para ter sempre à mão, quando precisar.

Sessão Live

Menu de inicialização do Live MX Linux 21

Ao ligar o computador, o Live MX Linux 21 apresenta seu menu de inicialização já com a 2ª linha pré-selecionada: — “Idioma - Teclado - Fuso horário” — e a experiência com o MX Linux 19 e o MX Linux 21 Beta1 já me convenceu de que é melhor configurar logo essas 3 coisas, antes de iniciar a sessão Live.

Opções avançadas do menu de inicialização do Live MX Linux 21

O mesmo se pode dizer das Opções Avançadas, bem destacadas na 3ª linha do Menu de inicialização do Live MX Linux 21 — em especial para quem deseja explorar seus recursos de Persistência — e neste caso, recomendo ler com atenção a documentação sobre o assunto.

Eu até hoje evitei mexer nas complexidades das opções de Persistência. — Me basta a opção básica, que permite preservar, na instalação em HDD / SSD, as configurações, arquivos etc. da sessão Live — e esse é um dos motivos para definir logo minhas opções de Idioma, Teclado e Fuso horário, antes de iniciar a sessão Live.

Portanto, apenas voltei ao Menu inicial, para cuidar disso.

Opções de Idioma, Teclado, Fuso horário ao iniciar o Live MX Linux 21

Feitas minhas escolhas de Idioma, Teclado e Fuso horário, eu estava pronto para iniciar a sessão Live do MX Linux 21 — já pré-configurada do modo como eu queria, para se transmitir à instalação em HDD / SSD.

Configuração do KDE Spectacle para documentar a sessão Live desde o início

O KDE Spectacle não é minha ferramenta preferida para captura de telas — mas configurei logo no primeiro momento, para documentar todos os detalhes da sessão Live, desde o início.

Instalação do Synaptic pelo apt, para facilitar a configuração da sessão Live

Outro passo importante era instalar logo o Synaptic — pelo apt — para facilitar a configuração da sessão Live, que se transmite à instalação em HDD / SSD.

Habilitar montagem de partições pelo usuário

Eu tinha esquecido de preparar um Pendrive com vários arquivos de que eu ia precisar. — Ok, eu já devia ter colocado tudo isso na nuvem. — O MX Tweak é o caminho mais simples e direto para autorizar o uDisks2 a montar partições “removíveis” (que não fazem parte do sistema), sem pedir senha, pois isto criaria pontos de montagem que não pertencem ao usuário.

Redirecionando tecla de atalho PrtScn para o gnome-screenshot

Instalei o gnome-screenshot e reconfigurei a tecla de atalho PrtScn para usá-lo em lugar do Spectacle. — O que me interessava era capturar e salvar rapidamente, com apenas 1 toque; e em alguns casos capturar com retardo de 7 segundos — tudo automático, sem burocracia.

Baixei, instalei e sincronizei o Google Chrome, para acesso rápido aos meus Bookmarks, redes, fóruns etc. — a minha nuvem.

Antes, instalei o Chromium pelo Synaptic, mas agora já não consegui sincronizar — por isso, removi e instalei o Chrome.

Dos HDDs, eu trouxe os arquivos de configuração do Conky e um papel de parede que o deixa mais legível. — Não é tão elegante quanto o Conky do MX Linux, mas me permitiria monitorar em detalhes o que se passa no sistema durante a instalação.

Particionamento manual

Criando uma partição para instalar o MX Linux 21

Em um espaço não-alocado no final do SSD, criei uma partição provisória “Linux14”, para instalar o MX Linux 21. — Desse modo, eu preservaria a instalação do MX 21 Beta1, que ainda estava na partição “Linux12”.

Partição provisória para o MX Linux 21

Criei essa partição provisória “Linux14” um pouco menor (28 GiB) do que as outras (30 GiB) — desse modo, eu poderia copiá-la, no futuro, para “colar” na partição “Linux12”, quando resolver substituir a instalação anterior, do MX Linux 21 Beta1. — Ao “colar”, ela será expandida para ocupar os 30 GiB disponíveis na partição de destino.

Isso ficará mais claro quando chegar essa hora.

Instalação

Etapas iniciais do Instalador do MX Linux 21

O Instalador do MX Linux 21 já adivinhou que eu preferia Teclado ABNT2 — e pré-seleciona a opção de personalizar a escolha das partições — embora o usuário possa mudar essa opção, caso prefira usar um disco inteiro.

Escolha da partição-raiz para instalar o MX Linux 21

Escolhi apenas a partição-raiz onde eu queria instalar o MX Linux 21.

O instalador propôs outro rótulo (Label); e preferi corrigir para “Linux14”. — Aceitei o formato sugerido (ext4) — e os parâmetros “noatime”, “dump”, Pass “1”, para o /etc/fstab.

Deixei para adicionar, no futuro, uma partição /home separada, partição Swap etc.

Opções de instalação do Grub, UEFi etc. no Instalador do MX Linux 21

Fiquei olhando as opções de Grub, UEFI etc. — sem encontrar nada que eu me sentisse seguro de querer mudar — enquanto o Instalador prosseguuia em sua tarefa (até +/-72%), sem perder tempo.

Hostname, domínio, Samba

Precisei corrigir ou preencher o Hostname “Linux12”, pois o Instalador do MX Linux não poderia adivinhar meus planos para o futuro. — Desabilitei o servidor Samba, que não uso. — Fui obrigado a inventar um domínio qualquer, pois o Instalador não aceitou deixar esse campo vazio.

Localização e serviços no Instalador do MX Linux 21

As configurações de Localização estavam corretas — conforme escolhi no Menu de inicialização da sessão Live do MX Linux 21. — Entre os serviços, apenas desabilitei Cups.

Conta Root, Auto Login do usuário e persistência das modificações na Live

Após configurar a conta de usuário, habilitei a conta root, o Login automático do usuário e a persistência das modificações da sessão Live na instalação em SSD.

Para me certificar do significado desta última opção, abri o Help Desktop (PDF) — que resume tudo o que se precisa saber durante a instalação (e muito mais). — Os atalhos para essa Ajuda e para o FAQ (que ocultei na Área de trabalho) continuam em ~/Desktop, e também no Menu.

Concluí a instalação em 24 minutos, de 0:19 a 0:43, com algumas pausas e demoras para pensar, ler o manual etc.

A sessão Live durou cerca de 3 horas, das 21:45 até 0:43, incluindo as configurações, instalação de pacotes, particionamento e backup final de arquivos para um Pendrive, por precaução.

Para isso, desabilitei a opção de reiniciar automaticamente ao fechar o Instalador. — E, sim, os arquivos da sessão Live foram mantidos na instalação em SSD — mas não custava me precaver.

Teste do MX Linux 21 instalado

Grub do MX Linux 21

O Grub do MX Linux 21 ficou bonito — embora pequeno para 12 distros (é relativamente fácil ampliar esse “retângulo” central) — mas não gerou entradas para o openSUSE Tumbleweed, instalado em partição BtrFS.

Isso é comum, com a maioria das distros que já instalei — mas não é um problema, pois prefiro usar o Grub do próprio openSUSE — e tenho o Grub do Mageia como reserva, para alguma emergência.

Acima - A nova instalação do MX Linux 21, dona do Grub, assume o topo de seu Menu de inicialização. — A instalação anterior (21 Beta1) permanece entre as outras, pela ordem alfa-numérica das partições — sda10, sda11, sda12, sda13, sda3, sda4... (openSUSE em sda2 não aparece).

Reaplicação do papel de parede e disparo do Conky

A persistência não manteve a aplicação do papel de parede — um problema menor — mas ele estava lá, e bastou reaplicar.

O Conky não iniciou automaticamente — o que é normal, pois não configurei isso — mas bastou disparar um comando no Konsole, pois os arquivos de configuração estavam lá.

Também foram preservadas as capturas de tela, as anotações em TXT, o pacote .deb do Chrome — de modo que não precisei do backup no Pendrive.

O Chrome disse que meu perfil estava em uso em outro computador — um caso de excesso de persistência, digamos assim. — Bastou desbloquear, e restaurar a sessão anterior do Chrome.

As demais configurações da sessão Live foram mantidas com sucesso.

Adicionando a antiga /home e a partição Swap à nova instalação do MX Linux 21

Não senti necessidade de continuar testando a nova instalação — nem de perder tempo com muitas outras configurações, que nem cheguei a fazer na sessão Live, pois logo iria obter todas elas, e muitas mais, pela /home da instalação anterior. — Até ali, configurei apenas o suficiente para documentar a instalação e os resultados, com algum conforto.

Bastaram 25 minutos, de 0:56 a 1:21, para me dar por satisfeito com a instalação.

Acima - Copiei para o /etc/fstab as 2 linhas referentes à partição Swap e à partição /home da instalação anterior (MX 21 Beta1) — e reiniciei a máquina.

Teste do MX Linux 21 com a antiga /home

Início do MX Linux 21 KDE com a /home da instalação anterior

A sessão do MX Linux 21 KDE com a /home da instalação anterior já carregou com alto índice de sucesso — a julgar pela minha experiência recente com casos assim.

Um aviso “xmessage” dizia que “Could not start ksmserver” — mas bastou clicar em “Okay” para fechar, e não aparecer mais nas inicializações seguintes.. — Esse aviso aparece, vez por outra, aleatoriamente, em várias distros, inclusive algumas que não têm ksmserver instalado, e depois não se repete mais durante muito tempo.

As partições-raiz das outras distros foram automaticamente montadas — mas não as partições Home1 a Home11. — Isso já me aconteceu várias vezes, ao incorporar uma /home pré-existente, ou ao “mover” essas partições de um HDD para outro, e sei como resolver (em geral com pouco esforço).

As 2 instâncias do Conky iniciaram automaticamente porque na /home da instalação anterior elas já estavam no Autostart. — No Conky2, ficou logo evidente que faltava instalar aha e html2text (para exibir os dados do htop); e o Screenfetch.

No lado esquerdo do Painel, entre os Lançadores (Launchers) do Dolphin e do Kate, faltava remover o ícone (não-exibido) do Chromium e substituir pelo do Chrome.

No lado direito do Painel, junto Relógio, ficou claro que faltava instalar o pacote qml-module-qtquick-xmllistmodel — necessário para exibir o widget Weather (Clima).

“Esquecer” partições “desconectadas”

Minha primeira tentativa para regularizar a montagem automática de partições “removíveis” (as que não fazem parte do sistema) foi entrar em KDE System Settings >> Removable storage >> Removable Devices — desmarcar a opção “Montar automaticamente todas as mídias removíveis no Login”, para ter acesso às opções individuais de cada partição — selecionar todos os itens em “Dispositivos desconectados” e mandar “esquecê-los”.

Esta providência não é suficiente para restabelecer a montagem automática das demais partições “removíveis” — mas em algumas distros é indispensável.

Montagem manual das partições, para “ensinar” o sistema

O passo seguinte foi montar manualmente — pelo Dolphin — todas as partições que não estavam sendo montadas automaticamente pelo uDisks2, no início da sessão KDE Plasma.

Depois disso, a montagem passou a funcionar automaticamente, a cada inicialização.

Acima - Àquela altura, eu já tinha instalado os pacotes necessários, e o Conky2 já exibia os números fornecidos pelo htop — bem como as versões do Qt e do Plasma, fornecidas pelo Screenfetch.

Com isso, considerei testada e aprovada a inclusão da antiga /home na nova instalação do MX Linux 21 KDE.

Recolocando em ordem as opções de boot UEFI

Hora de recolocar o Grub do openSUSE no topo das opções de boot do UEFI.

Substituição do Beta1 instalado antes

“Movendo” a nova instalação do MX Linux 21 para o lugar da anterior

Pelo GParted, “copiei” a partição com a nova instalação do MX Linux 21 e “colei” na partição onde estava a instalação anterior (Beta1), para substituí-la.

aaaa

No detalhe à esquerda: - A partição de 28 GiB é expandida para ocupar todo o espaço da partição de destino (30 GiB).

No detalhe à direita: - Mudei o Rótulo (Label) da partição-cópia para “Linux12” — e alterei o identificador UUID da partição “Linux14” original, para distingui-la de sua cópia.

Grub, limpeza da /home e teste final

zzz

Atualização do Grub, para detectar a nova instalação do MX Linux 21 KDE na partição “Linux12”.

O Conky registrou que a instalação ocupava 7,82 GiB da partição.

Copiando e deletando o conteúdo de /home/UserFolder

O conteúdo da pasta /home/UserFolder já não é necessário — e ficou inacessível pelo MX Linux 21, pois clicar na pasta /home agora leva à partição Home12. — Copiei para uma partição de dados, e em seguida deletei pelo Midnight Commander em modo root.

Com isso, a ocupação da partição-raiz Linux12 diminuiu de 7,82 GiB para 7,49 GiB. — Não se pode dizer que foi uma redução fantástica — mas aquilo não era útil, nem acessível.

aaaa

De volta ao MX Linux 21 KDE, tudo continuava funcionando sem qualquer problema.

Deletei a partição provisória “Linux14”, que já não era necessária.

aaaa

Desabilitei a detecção de outras distros (os_prober) em /etc/default/grub — e a atualização do Grub, que demorava 1 min 20s por comando no Terminal, passou a ser feita em 17 segundos.

Acima - No detalhe à esquerda, “GRUB_DISABLE_OS_PROBER=false”. — À direita, a configuração alterada para “GRUB_DISABLE_OS_PROBER=true”.

Eu tenho 2 motivos para desabilitar os_prober na maioria das distros que uso em dualboot.

Primeiro, porque o Grub de cada distro “lê” o Grub das outras 11 para extrair as informações de cada uma delas — e quanto maiores os arquivos /boot/grub/grub.cfg, mais essa operação demora, usa CPU, aquece etc. — Isso é muito mais notável, quando a instalação ou remoção de Kernel se faz por um aplicativo GUI  (Instaladores, gerenciadores de pacotes), que demandam ainda mais recursos e, com frequência, repetem até 3 vezes essa operação.

Segundo, porque o Grub do openSUSE só precisa que o Grub das outras 10 distros indique os parâmetros de cada uma delas — e o Grub de emergência (Mageia), também. — Portanto, “seja breve”.

Não entendo nem 1% das entranhas do Grub. — Me parece um tanto “antigo” — mas ainda é o que oferece mais recursos.

Subtítulo

\\\\

[imagem]

xxx

__________________________
Publicado inicialmente em 23 Outubro 2021