Translate

quinta-feira, 6 de junho de 2019

Movendo Kubuntu do SSD para o HDD

Clonagem de partições Linux por cópia & cola no GParted, em sessão Live

Resolvi trocar o Kubuntu LTS pelo Kubuntu “rolling release”, — instalado como Kubuntu 19.04 “Disco Dingo” (development branch) no início de seu desenvolvimento (Novembro 2018); e agora transformado em Kubuntu 19.10 “Eoan Ermine” (development branch). — Se tudo der certo, em Novembro próximo será transformado em Kubuntu 20.04 (development branch).

Portanto, não se trata de pular de um “lançamento” para outro, — mas migrar para cada novo “desenvolvimento”, ao se encerrar o anterior. — Desse modo, não existem saltos semestrais entre versões “fixas”, mas uma sucessão contínua de versões fluidas.

Para fazer essa troca, “bastava” deslocar o Kubuntu 19.10, — do SSD externo para um dos HDDs internos, — em substituição ao antigo Kubuntu 16.04 LTS “Xenial Xerus”, que já estava cada vez menos interessante.

Com isso, abriria uma “vaga” no SSD externo, para novas experiências, no futuro.

Partições do Kubuntu 19.10 (em verde) a serem movidas para o lugar do Kubuntu 16.04 (vermelho)

Esse deslocamento foi facilitado pela estrutura modular do particionamento adotado nos 3 HDDs internos + 1 SSD externo, — agrupado em 12 “módulos” (slots), — cada um com partições Raiz (Root), Home e Swap, numeradas de 1 a 12.

Note que se trata de hardware com Bios, e particionamento MBR, — sem partições de Boot separadas. — Com UEFI e GPT, seria mais complicado.

Tratava-se, portanto, de copiar as partições de um módulo (Slot 11) para as partições de outro módulo (Slot 4):

   Linux11  ->  Linux4
   Home11   ->  Home4
   Swap11   ->  Swap4

Para isso, foi usado o GParted, — em sessão Live, para trabalhar com todas as partições desmontadas:

  • Clique com o botão direito na partição de origem e selecione “Copiar
  • Clique com o botão direito na partição de destino e selecione “Colar

Neste caso específico, usei o DVD do Mageia 7 (Beta2) KDE, de Março deste ano, por ser o mais recente que havia na gaveta.

Redução da partição Swap11, para poder colar na partição Swap4, que era menor

Naturalmente, a partição de origem não pode ser maior do que a partição de destino. — Por isso, a partição “Swap11” (4,25 GiB) teve de ser reduzida, para colar na partição “Swap4” (4 GiB).

Para não perder tempo com um cálculo exato (sujeito a erro e a ter de recomeçar por causa de 1 bit a mais), reduzi logo para 3,7 GiB. — Ao ser “colada”, ela se expandirá para ocupar todo o espaço da partição de destino.

GParted reproduz Label, UUID e amplia Swap para preencher todo o espaço

Pode parecer bobagem, clonar a partição Swap, — principalmente se não contém nada de útil, pois nunca usei Hibernar ou Suspender sessão, — e de fato, o GParted não “copiou” a Swap, mas criou uma nova partição Swap no destino, com o UUID da Swap de origem.

No entanto, é um modo simples e rápido de manter o identificador UUID, — e com isso, a consistência do sistema.

Caso contrário, teria de localizar e editar todos os arquivos de sistema que façam referência ao UUID da “Swap11”, — para substituir pelo UUID da “Swap4”. — Um trabalho sem sentido, e ainda por cima, sujeito a variações de uma distro para outra (ou conforme as configurações):

  • /etc/fstab
  • /etc/default/grub - no caso do openSUSE, Mageia, PCLinuxOS, Manjaro
  • /etc/initramfs-tools/conf.d/resume - no caso do Devuan

Aplicação dos Rótulos (Label) corretos às partições do “Slot 4”

O passo seguinte foi alterar os Rótulos (Label) das partições, em conformidade com sua nova localização no “Slot 4”.

Esses Rótulos são fundamentais para me orientar nesse labirinto de 12 distros e 41 partições, — e também para os aplicativos de todas as distros encontrarem o caminho (path) das demais partições (adiante).

Ajustes no Conky para omitir a antiga localização do Kubuntu 19.10

Após encerrar a sessão Live, foi carregado o Mageia 7 (instalado), — que controla o Menu de inicialização da máquina, — para atualizar o Grub e reconhecer a substituição do Kubuntu 16.04 pelo Kubuntu 19.10 no “Slot 4”.

Para isso, o SSD externo foi desplugado, — pois neste momento ainda existem nele 3 partições com UUIDs duplicados. — Só serão formatadas após confirmar que o “clone” está funcionando.

Acima - O arquivo de configuração do Conky é um exemplo do uso dos Rótulos (Label) como parte do caminho (path) para as partições. — Nesse momento, foi retirada a legenda “Kubuntu d” da linha referente ao “Slot 11”.

Atualização do Grub sem o SSD: — apenas 9 distros (Mageia + 8)

Sem o SSD externo, o Grub do Mageia reconheceu as 8 distros restantes, — entre elas, o Kubuntu 19.10 em sua nova localização.

Menu de inicialização com o Kubuntu 19.10 em seu novo local

Com o Grub atualizado, já foi possível testar o Kubuntu 19.10 “Eoan Ermine” (development branch) em sua nova localização.

Clone do Kubuntu 19;10 testado e aprovado

Bastou 1 hora de uso mais ou menos intenso, — fazendo atualizações, instalando pacotes, trocando tema e cores escuras por outros mais leves, — para constatar que o Kubuntu “transplantado” estava funcionando conforme o esperado.

Hora de arrumar a bagunça deixada para trás.

Reataurando o tamanho da partição Swap11 original

A partição Swap11 original já havia sido restaurada em seu antigo tamanho (4,25 GiB), ainda na primeira sessão Live.

Formatação das partições originais, para limpeza e mudança de UUID

Em nova sessão Live, o GParted foi usado para formatar as partições originais (Slot 11), — não só para esvaziá-las, como para alterar seus identificadores UUID, — e reaplicar os Rótulos (Label).

Certa vez, há 2 ou 3 anos, cheguei a carregar uma distro com partições duplicadas (mesmos UUIDs), e o resultado foi muito estranho. — Infelizmente, não lembro se as alterações do sistema eram aplicadas em ambas as partições, ou em apenas uma, ao acaso.

Atualização do Grub com o SSD externo plugado

Com isso, o Grub do Mageia já podia ser atualizado, mais uma vez, — agora, com o SSD externo plugado, — para detectar as outras 10 distros remanescentes.

Menu de inicialização com as 11 distros restantes

O Menu de inicialização ainda ficou um pouco vazio, — afinal, resta 1 vaga, — mas voltou a ser possível carregar o Sabayon e o Devuan.

Cópia

Pelo comando sudo blkid foi feita nova documentação dos identificadores UUID em arquivo texto (datado), — para fácil localização por CTRL-F.

Essa documentação, em arquivos TXT sucessivos (datados), após cada formatação, preserva todo histórico de UUIDs já extintos, — o que, em várias ocasiões, ajudou a entender por que alguma distro às vezes era flagrada fazendo referência a algum UUID inexistente.

Correção das partições a serem montadas em System settings >> Removable devices

Faltava desativar a montagem automática das partições Linux4 e Home4 pelo Udisks2 (*), que já não é necessária, — em System settings >> Removable devices; — e habilitar a montagem automática de Linux11 e Home11, cujos novos identificadores UUID já não fazem parte do /etc/fstab.

Hostname “Linux4”

Por último, foram editados os arquivos /etc/hosts e /etc/hostname para substituir “Linux11” por “Linux4”, — o que foi mais do que suficiente, no Kubuntu. — Em outras distros, às vezes a coisa não é tão simples.

Devuan, antes e depois de simplificar o arquivo /etc/fstab

Para minha surpresa, descobri que ainda não tinha simplificado o arquivo /etc/fstab do Devuan, — que continuava usando os identificadores UUID para montar as partições dos HDDs internos, — e usando os Rótulos (Label) apenas para definir os pontos de montagem.

Naturalmente, já não existem os UUIDs do antigo Kubuntu 16.04 LTS “Xenial Xerus”, — por isso, as partições “Linux4” e “Home4” não foram montadas, — e na falta de informações, o Conky repetiu as da partição-raiz do próprio Devuan.

Uma vez que, no Devuan, (apenas) as partições do SSD externo (USB) são montadas automaticamente pelo Udisks2 (*), seus UUIDs não precisavam estar no /etc/fstab. — Caso contrário, a linha 11 mostraria informações do novo “Slot 4”, e não partições vazias.
_______
(*) No Debian e no Devuan, as partições do SSD externo são automaticamente montadas, sem necessidade de incluí-las no Udisks2 pelo KDE System settings, — nem no /etc/fstab, — ao passo que no Kubuntu, Mint KDE e KDE Neon, é necessário habilitar sua montagem no KDE System settings. — Ver casos de outras distros e no Cinnamon.

Simplificação do arquivo /etc/fstab do Devuan

Para resolver de vez o assunto, bastou aplicar o modelo simplificado, — que adotei há tempos no /etc/fstab do Slackware, e depois, também no Debian.

Em resumo, ele usa os Rótulos (Label), tanto para identificar as partições, quanto para definir os pontos de montagem.

Uma vantagem dessa abordagem é que o Boot do Debian não trava nem entra em pânico, a cada vez que uma partição é formatada e desaparece seu antigo UUID. — Nesses casos, era preciso logar no tty e editar o arquivo /etc/fstab pelo vi ou pelo nano, para prosseguir. — Não lembro se já houve caso de o Debian não carregar porque esqueci de aplicar Rótulo (Label) após formatar alguma partição. Além disso, os instaladores de algumas distros preservam os Rótulos ao formatar, a menos que você esvazie o campo ou preencha com outro Rótulo.

Distribuição final das distros nas partições existentes, com 1 vaga no SSD externo

O resultado disso tudo é que o Kubuntu 19.10 “Eoan Ermine” (development branch) tomou lugar entre as distros “permanentes”, — deixando 1 vaga para novas experiências, no SSD externo, — que, por princípio, pode ser facilmente desplugado.

Comparativo das distros instaladas, na situação de 25 de Maio

Embora o Kubuntu 16.04 LTS “Xenial Xerux” fosse uma das mais produtivas, — com o maior número de aplicativos instalados e funcionando, — vinha ficando cada vez menos atrativa, pela falta de vários avanços do KDE mais recente, aos quais me acostumei nas outras distros.

Além disso, o suporte ao Kubuntu 16.04 LTS terminou em Abril, — durou apenas 3 anos, embora o do Ubuntu 16.04 vá até 2021.

Comparativo das distros instaladas, na situação de 5 de Junho

Para todos os efeitos práticos, o KDE Neon (Bionic) e o Mint 18 KDE (Xenial) substituem com vantagem o Kubuntu 16.04, — e já faz algum tempo que transferi para o Mint o controle dos Backups.

No site do Linux Mint, consta que o Mint 18 KDE terá suporte até 2021. — Não tenho certeza absoluta, pois é possível haver sutis confusões de significado das palavras, — mas ainda não vi afirmação categórica em contrário.

WTF


Um colega pergunta por que, com mil diabos, alguém iria mover uma distro de um SSD, que é muito mais rápido, para HDD “mecânico”, muito mais lerdo? — Bom, isso pode ser verdade na teoria, mas na prática é preciso levar em conta vários fatores individuais, tais como os modelos de HDD e SSD, os modelos de conectores disponíveis na Placa-Mãe, — e também o caso específico de cada usuário.

E afinal, tudo que ficou registrado aqui também se aplica em sentido contrário, — do HDD para o SSD.

Pessoalmente, já fiz várias remoções de ida-e-volta (HDD-SSD-HDD), — quando recebi o SSD de 1 TB, — e novamente ao adquirir um HDD de 1 TB, que veio se somar aos 2 HDDs de 320 GB.

Naquela ocasião, tratava-se de reorganizar o particionamento, — até chegar ao atual sistema de “módulos”, — sem perder as distros que estavam instaladas e funcionando muito bem:


xxx

— … ≠ • ≠ … —

Ferramentas &tc.



Kubuntu

Nenhum comentário:

Postar um comentário