 |
| 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
— … ≠ • ≠ … —
PC desktop UEFI / GPT
- Transição para hardware UEFI-GPT
- Arch Linux - install, config
- Debian testing - install, config
- Linux Mint 20 (beta) "Ulyana" + Plasma KDE
- Upgrade para o Fedora 32
- Void + KDE
- MX Linux 19.2 KDE Beta 2
- KDE Neon upgrade 20.04 Focal Fossa
- Slackware by Alien BOB
- Slackware 15 alpha1
- Manjaro - instalação e configuração
- PCLinuxOS KDE Darkstar - instalação de substituição
- MX Linux 21 Wildflower KDE - instalação de substituição
- Redcore Linux - instalação e configuração
