Byteria: Reparticionamento dos discos rígidos

Debian clonado pelo GParted para concluir a reorganização do particionamento dos HDDs

Ao deletar o Windows XP instalado numa antiga partição sda1 de 40 GiB (29 Mai. 2016), já existia uma partição estendida sda2, — contendo 2 partições lógicas “E:\” e “F:\”, que na época precisavam ser mantidas. — Por isso, ao criar 2 partições ext4 de 20 GiB no lugar do antigo Windows, elas foram automaticamente classificadas como sda1 e sda3.

Em boa hora, essa “pequena correção” foi deixada de fora do remanejamento de sistemas Linux e reparticionamento dos discos rígidos (10 Jan. 2017), — façanha que, mesmo sem isso, deu muito mais trabalho do que gostaria de tentar nos próximos 10 anos. — Mas desse modo, a nova sequência ficou invertida: sda1, sda3, sda2.

• Ver “Reparticionando o 1º HDD (sda)”, em Remanejamento de sistemas Linux ao reparticionar discos (10 Jan. 2017).

A solução do problema ficou em segundo plano (matutando nos intervalos), até chegar a hora, — agora, para poder instalar um 9º sistema, após o Manjaro, o openSUSE e o Fedora. — Além disso, precisava carregar o Knoppix para conferir mais alguns itens do Quadro comparativo de sistemas Linux.

O roteiro imaginado era simples, — embora sujeito a dúvidas sobre alguns resultados:

Carregar o Knoppix (Pendrive 16 GB), para usar o GParted com total liberdade.
Copiar (clonar) o Debian instalado em sda3 para a unidade SSD externa.
Deletar sda3 e sda2, — fora de ordem.
Recriar 2 partições, — na expectativa de que se tornariam sda2 e sda3, — na ordem certa.
Copiar (clonar) o Debian de volta para a nova sda3.
Fazer os ajustes necessários para o Debian e demais sistemas não estranharem nada.
Atualizar o Grub, para minimizar qualquer possibilidade de estranhamento.

Em Janeiro, para não complicar, apenas a /home do Kubuntu 17.04 foi movida para uma partição separada, — como teste-piloto, — mas as do KDE Neon e do Debian ficaram para ser movidas após esta última correção no particionamento geral.

• Ver “Movendo a pasta /home para uma partição separada”, em Remanejamento de sistemas Linux ao reparticionar discos (10 Jan. 2017).

Quadro comparativo das funcionalidades obtidas com diferentes sistemas Linux, até o momento

Agora, foi decidido não testar o clone intermediário do Debian (no SSD externo), antes de deletar a partição sda3 original, — uma vez que o excesso de cautela apenas complicou o remanejamento de sistemas Linux e reparticionamento dos discos rígidos (10 Jan. 2017), aparentemente sem necessidade.

Para essa decisão de agora, contribuiu o fato de o Debian testing (não Stretch) estar longe de ser muito útil no dia-a-dia. — Indispensáveis, de fato, são o Kubuntu 16.04 LTS e o Linux Mint 18 KDE, — reforçados pelo bom desempenho do KDE Neon, e agora também pelo bom desempenho do openSUSE, nas atividades mais requeridas.

Também é verdade que, já por 2 ou 3 vezes, o Debian testing (não Stretch) ficou temporariamente fora de combate, — mas tem sido interessante conseguir recuperá-lo, — daí, o gosto de mantê-lo, com todo seu histórico, para continuar brincando e aprendendo.

Trocando 6 por ½ dúzia

Clonando a partição original do Debian (sda3) para o SSD externo pelo GParted, no Knoppix

Mover o Debian da segunda partição (antes chamada sda3), para a terceira partição (agora chamada sda3), tem certo sabor de “trocar seis por meia-dúzia”, — mas a divergência com “Linux2” e com toda a lógica do particionamento já provocou 1 ou 2 erros, — felizmente, sem consequências graves.

De outro ângulo, “trocar seis por meia-dúzia” era justamente o que convinha: — Exigiria o mínimo de alterações manuais nos links e caminhos (path) entranhados no próprio Debian, no Grub e nos demais sistemas.

Copiando de volta o Debian para sda3, — agora, de fato a terceira partição do disco rígido

Desse modo, bastaria substituir o antigo rótulo (label) Linux2 por um novo rótulo Linux3, — para que o maior número de “coisas” continuassem funcionando, sem necessidade de inúmeros ajustes manuais por toda parte.

Alterando o rótulo (label) do Debian, — que agora está, de fato, na terceira partição do HDD

A outra opção, — trazer o Debian de volta para a segunda partição (que agora é sda2), — exigiria fazer manualmente inúmeras correções, em vários pontos, de vários sistemas.

Enfim, ao não testar o clone intermediário (provisório) no SSD externo, não foi necessária nenhuma alteração no identificador UUID, — que foi, e voltou, o mesmo. — Ao final da movimentação, bastou desconectar o SSD externo, para não confundir as coisas, ao carregar o Debian realocado.

Uma vez testado e aprovado o Debian em sua nova partição, — clone exato da antiga, — bastará formatar a partição intermediária (provisória), no SSD externo. Assim, não haverá UUID repetido para causar confusão, caso esqueça o SSD conectado.

Preparando o teste do Debian

Arquivo /etc/hosts do Debian ainda continha (apenas) Linux3

Carregado openSUSE para preparar o teste, foi constatado que o /etc/hosts do Debian, — ainda com data de Setembro, portanto antes do re-particionamento geral, — continha (apenas) “Linux3”.

Este era seu “nome” desde quando foi deletado o Windows XP, para instalar o Debian e o KDE Neon (29 Mai. 2016), — e deveria ter sido alterado após o remanejamento de sistemas Linux e reparticionamento dos discos rígidos (10 Jan. 2017).

A mudança nunca foi feita porque, no Debian, o sudo nunca reclamou, — e afinal, já era previsto que o Debian talvez voltasse a ser Linux3.

Editando /etc/hostname

Já o arquivo /etc/hostname tinha sido alterado em 12 Jan., — e agora foi editado de novo, para voltar a Linux3.

Atualização do Grub, para testar o Debian em sua nova localização física

Por fim, foi atualizado o Grub, para dar chance a qualquer eventual ajuste que pudesse faltar.

É muito possível que isto fosse totalmente desnecessário, — afinal, o Grub já apontava para sda3 e para o mesmo UUID. — No entanto, como não sei “tudo”, não custava nada investir um minuto na precaução.

Teste do Debian

Debian carregado pela primeira vez, após a clonagem para nova partição

Reiniciado o computador, o Debian carregou dentro do tempo usual dos últimos meses, — e sem nenhum problema perceptível.

Uso do su para rodar o comando apt update, — e mais tarde, o sudo

O comando apt update (via su) apontou 124 pacotes a serem atualizados, — e ao aplicar, em seguida, o Synaptic incluiu mais 1 novo, a ser instalado.

Mais tarde, foi testado também o sudo apt update, — para conferir as boas relações entre /etc/hosts e /etc/hostname.

Às 23:17, foi concluído o relato dessa etapa inicial, — com 11 imagens editadas no Gimp, — e encerrada a primeira sessão do “novo” Debian, após 9h 29min de bastante atividade, sem problemas visíveis.

Ao todo, foram dispendidas menos de 2 horas na realocação do Debian, — incluindo algumas verificações do Konqueror e do Chromium, no Knoppix, para completar o Quadro comparativo dos sistemas Linux:

11:43 a 13:22 - Knoppix
13:31 a 13:45 - openSUSE
13:48 a 23:17 - Debian “novo”

Ajustes nos demais sistemas

Situação ao carregar o Zesty Zapus, — a montagem automática passou de Linux2 para Linux3 (sda3)

As principais alterações a serem feitas nos outros 7 sistemas instalados consistiam em:

a) Montar automaticamente a partição Linux3 (sda3), — ao invés de Linux2 (sda3).

Em quase todos os casos, — exceto openSUSE, — a montagem automática é definida em:

Menu → [Favoritos] → Configurações do sistema → Hardware → Armazenamento removível → Dispositivos removíveis

Em todos esses casos (exceto openSUSE), a mudança aconteceu espontaneamente, pois tudo leva a crer que o comando udisks guiava-se por “sda3”, — que acompanhou o Debian na nova partição, — e usava o antigo rótulo (label) “Linux2” apenas para definir o ponto de montagem.

b) Definir a montagem automática da partição Home3, — ao invés da Home2, como antes.

Edição das configurações do Conky, no Kubuntu Zesty Zapus

c) Ajustar o arquivo /home/.conkyrc de cada um dos demais Linux, para o Conky monitorar o uso das novas partições do Debian, — Linux3 e Home3.

Ao carregar os demais sistemas (exceto openSUSE), o Conky apresentava os seguintes dados, na linha referente às partições do Debian:

a2 Debian 0B [______] 44,0MiB [______]

Era o resultado dessa antiga linha de código, no arquivo /home/.conkyrc de cada Linux:

a2 Debian ${alignr}${fs_used /media/flavio/Linux2} ${alignr}${fs_bar 6,45 /media/flavio/Linux2} ${alignr}${fs_used /media/flavio/Home2} ${alignr}${fs_bar 6,45 /media/flavio/Home2}

O índice “a2” era apenas um texto, indicando sua localização no 1º HDD (sda), e sua “numeração” como 2º Linux, — um lembrete, para facilitar a vida no dia-a-dia.

Depois dos ajustes, a linha de código ficou assim:

a3 Debian ${alignr}${fs_used /media/flavio/Linux3} ${alignr}${fs_bar 6,45 /media/flavio/Linux3} ${alignr}${fs_used /media/flavio/Home3} ${alignr}${fs_bar 6,45 /media/flavio/Home3}

E o Conky passou a apresentar os seguintes dados, — até ocorrer a montagem automática da partição Home3, no início da sessão seguinte, — ou até fazer a montagem manual pelo comando mount -a:

a3 Debian 8,56GiB [______] 0B [______]

Linha do /home/.conkyrc copiada de um sistema para outro, — com adaptações de pontos de montagem

A linha corrigida no Conky do Zesty Zapus foi então copiada para o Conky dos demais sistemas, — com algumas adaptações, pois os pontos de montagem (ainda) não estão padronizados:

/media/flavio/
/run/media/flavio/
/run/media/

Alteração das partições a serem montadas, pelo Particionador avançado do YaST2

Apenas no openSUSE, — onde a montagem automática do KDE não funciona, — o procedimento teve de ser diferente.

Arquivo /etc/fstab gerado pelo Particionador avançado do YaST2

O “Particionador avançado” do YaST2 foi utilizado para alterar as partições a serem montadas no início de cada sessão, — e ele grava as alterações no arquivo /etc/fstab.

Só que, neste caso, não é necessário esperar o próximo boot, — nem usar mount -a para antecipar o efeito. — O YaST2 se encarrega de fazer a montagem, no mesmo instante.

No próprio Debian, não foi necessário alterar mais nada, — pois dentro de cada sistema, o Conky refere-se a “/” e “/home”. — Se esta última não estiver numa partição separada, a taxa de ocupação é a mesma da partição do sistema.

Ao todo, foram dispendidas menos de 2 horas para fazer os ajustes nos 7 sistemas, — sem interromper outras atividades:

23:21 a 23:45 - Zesty Zapus
23:55 a 00:02 - KDE Neon User Edition
00:08 a 00:15 - Kubuntu 16.04 LTS
00:25 a 00:30 - Linux Mint 18.1 KDE
00:34 a 00:44 - Manjaro KDE
00:54 a 01:06 - openSUSE
01:17 a 01:28 - Fedora

Movendo a /home do KDE Neon para outra partição

Usando o Debian para mover a pasta /home do KDE Neon (Linux1) para a partição Home1

Com o Debian finalmente em seu local definitivo, chegou a hora de mover sua /home, — e também a do KDE Neon, — para partições separadas:

Linux1/home → Home1, — no caso do KDE Neon

Linux3/home → Home3, — no caso do Debian

O procedimento consiste, basicamente, em 3 passos:

1) Mover o conteúdo da pasta /home, — subpastas user1, user2, user3 etc., — para a partição onde deverá ficar

2) Atribuir a propriedade de cada subpasta ao respectivo usuário, — no caso, só havia 1 subpasta “flavio”, pois nunca foi criada outra conta no Debian, nem no KDE Neon

3) Editar o arquivo /etc/fstab para montar a nova partição como /home, — de modo que a pasta original torna-se um link para a partição “home” separada

Naturalmente, a /home que será movida não pode estar em uso. — Para isso, recomenda-se:

login as root DIRECTLY at the server or boot from a rescue medium like KNOPPIX, this will not work over ssh (because then the /home directory is in use).

A primeira alternativa, — que não testei, — talvez possa ser obtida por Sair → Encerrar sessão, e na tela de Login usar CTRL-Alt-F1 para abrir um Terminal tty (tela preta) e logar como Root. Depois, basta saber tudo (ou ter tudo anotado em papel), e sair digitando e disparando os comandos, até concluir a tarefa.

Convenhamos que, com 8 sistemas instalados em paralelo (não em VM), isso pode ser feito de modo bem mais cômodo, — usar o Debian para mover a /home do KDE Neon, — e usar o KDE Neon para mover a /home do Debian, por exemplo.

• Ver “Movendo a pasta /home para uma partição separada”, em Remanejamento de sistemas Linux ao reparticionar discos (10 Jan. 2017).

Dentro do Debian, a /home do KDE Neon foi então movida com o comando simplificado:

su
mv -f flavio /media/flavio/Home1/

Usar su torna $USER=root, — e a propriedade de pasta do usuário comum foi atribuída a ele

Em seguida, — posicionado na partição Home1, — viria o passo de atribuir a propriedade da pasta ao usuário.

Este é um passo recomendado em todos os tutoriais examinados, e é seguido apenas por desencargo de consciência, — uma vez que a pasta já pertence ao (único) usuário “comum”.

Porém, neste caso específico, a tentativa foi feita de um modo errado, — e aconteceu exatamente o contrário do previsto:

su
~~chown -R $USER:$USER flavio~~

Ao usar su, o $USER em atividade passou a ser o root. — Mais tarde, ao examinar a pasta “flavio” no Dolphin, ficou claro que sua propriedade se havia transferido para root.

Tentando novamente o comando chown -R $USER:$USER, — agora, usando sudo

Após 2 tentativas frustradas de carregar o KDE Neon com sua nova partição Home1, este passo voltou a ser aplicado, — agora, do modo correto, — após verificar que a propriedade da pasta do usuário havia passado para o root.

Então, foi usado sudo, — que permite ao usuário comum rodar o comando como root, mas sem se tornar root. — Portanto, ao atribuir a propriedade da pasta a $USER, agora está realmente atribuindo ao usuário comum.

sudo chown -R $USER:$USER flavio

Depois disso, finalmente o KDE Neon carregou com sucesso, — sem qualquer problema ou demora, — e continua muito bem, após 3 dias de trabalho regular.

Copiando a linha da partição Home1 no arquivo /etc/fstab do Debian

Nesse meio tempo, já havia realizado o terceiro passo, — incluir a partição Home2 no /etc/fstab do KDE Neon, — com ponto de montagem /home.

O começo mais simples era copiar a linha referente à partição Home1 no arquivo /etc/fstab do Debian.

UUID=bf458c71-8224-4457-8faa-b4a16240fc66 /media/Home1 ext4 defaults 0 0

Arquivo /etc/fstab do KDE Neon, para montagem da partição /home separada

Em seguida, bastou colar essa linha no arquivo /etc/fstab do KDE Neon, — e fazer as adaptações necessárias.

# Home movida em 7 Fev. 2017
UUID=bf458c71-8224-4457-8faa-b4a16240fc66 /home ext4 defaults 0 2

KDE Neon carregado com a nova partição /home

Após corrigir a propriedade da pasta do usuário (passo anterior), finalmente o KDE Neon carregou, — já com o Conky indicando menor uso da partição raiz, e o uso da nova partição /home.

Movendo a /home do Debian para outra partição

Movendo a pasta do usuário do Debian para a partição Home3

Mover a pasta do usuário do Debian para a nova partição /home.

Atribuindo (ou confirmando) a propriedade da pasta do usuário Debian

Atribuir a propriedade da pasta ao usuário Debian, por desencargo de consciência.

Arquivo /etc/fstab do Debian com a linha referente à partição /home

Acrescentar a partição /home no arquivo /etc/fstab do Debian.

# Nova Home3
UUID=9ecacf62-bfbf-4a15-8ab2-fbd46cadd7d6 /home ext4 defaults,noatime 0 2

A inovação ficou por conta do parâmetro noatime, — que desabilita o registro da hora em que cada arquivo foi acessado (lido) pela última vez, — mas não o registro da última vez em que foi gravado.

Debian carregado, já com a /home em uma partição separada

Dessa vez, não houve qualquer percalço, e alguns minutos depois o Debian foi carregado com a /home em partição separada, — sem qualquer problema perceptível nos 3 dias seguintes.

Instalando CorelDraw e Word no KDE Neon

Exportando camadas selecionadas de um antigo mapa construído em CorelDraw

Com a /home do KDE Neon finalmente em sua partição definitiva, prosseguiram as experiências com o Wine, — instalar antigas versões do CorelDraw e do MS Word.

Não havia nenhuma fonte instalada na pasta /home/flavio/.wine/drive_c/windows/Fonts/ , — e o CorelDraw traz grande quantidade de fontes, que podem ser instaladas opcionalmente. — Ao todo, foram instaladas 100 fontes.

Mapa exportado em formato JPEG, com as camadas selecionadas

No primeiro teste, foi possível abrir um antigo mapa em camadas, selecionar algumas delas, e exportar o mapa em formato JPEG.

Antigo documento do MS-DOS Word, com acentuação codificada pelo Ventura Publisher

O Word também funcionou, — pelo menos para abrir um arquivo da década de 1990.

Agora falta substituir o arquivo normal.dot, por uma cópia contendo inúmeras macros personalizadas para converter a acentuação codificada pelo antigo Xerox Ventura Publisher.

Instalando CorelDraw e Word no Debian

Exportando camadas selecionadas de um mapa CorelDraw em formato JPEG, no Debian

No Debian, finalmente foi instalado o CorelDraw, e testada com sucesso a exportação de um mapa em formato JPEG, — porém a instalação do antigo MS Word falhou nos instantes finais (com direito a crash do LibreOffice Calc, que estava aberto). — A tentar novamente, mais tarde.

Na falta do menu de contexto “Abrir com wine”, comando “wine instalar.exe”

Ao contrário dos demais sistemas, no Debian o menu de contexto (right click) sobre o instalador, no Dolphin, não oferece “Abrir com Wine”. — A solução foi abrir um terminal no Dolphin (F4), posicionado no CD do instalador, e digitar comandos como “wine instalador.exe”.

Restaurando data e hora dos arquivos

Quadro comparativo dos sistemas instalados

Quadro comparativo dos sistemas instalados, com ao final deste relato

Nesse meio tempo, o KDE Neon avançou para o KDE Plasma 5.9.1, o Zesty Zapus avançou para Frameworks 5.30.0, — e o Linux Mint segue meio encrencado desde o upgrade para 18.1, embora não o bastante para tirá-lo da situação de “sistema principal”, ao lado do Kubuntu 16.04 LTS.

Com a instalação dessas antigas versões do CorelDraw e do Word, aumentou o utilidade do KDE Neon, — que enfrenta bem a navegação em “Páginas” do Facebook, além de rodar o Google Earth sem placa aceleradora 3D.

Para os usos mais requisitados no dia-a-dia, — parâmetro bastante pessoal, — openSUSE continua em segundo lugar, lado a lado com o KDE Neon.

Conclusão do reparticionamento

Situação final do reparticionamento

Com isso, termina o reparticionamento dos HDDs antigos e recentes, — com espaços para até 9 sistemas operacionais (ou 12, contando o SSD externo), todos com partições separadas para /home e Swap exclusivo, — afora as partições para dados de uso comum (Sites, Works, XTudo, Armazem1, Armazem2).

Como parte do processo, não ficou mais nenhum sistema com pasta /home na partição-raiz, — e qualquer um deles pode ser reinstalado ou substituído, sem perda de configurações, Wine, CorelDraw, dados do Google Earth etc.

Uma vez que o antigo particionamento (bem menos planejado) funcionou de meados de 2009 até Jan. 2017, — exigindo apenas 2 ajustes pontuais, em 2011 e 2016, — é de se esperar que este dure pelo menos mais alguns anos, já que a modularidade facilita a substituição de 1 ou vários sistemas.

Em caso de substituir os HDDs mais antigos, o mesmo modelo pode ser aplicado em novos discos de maior capacidade, — e os sistemas podem migrar para eles, com o mínimo de trabalho. — Nem a numeração precisa mudar.

O tamanho padronizado das partições de sistema e de “home” já se provou extremamente prático para a realocação de qualquer Linux, — mesmo com “etapa intermediária” (clone provisório no SSD externo), — sem a necessidade de redimensionar nada, nem desfazer nada depois.

A grande ameaça à durabilidade desse particionamento geral está na tecnologia, — uma vez que se baseia em BIOS, MBR, ext4.

Pode ser necessário alterá-lo, quando se tornar necessária Memória RAM superior aos atuais 4 GB, — pois a placa-mãe só aceita DDR2, que já não se encontra no mercado, e ainda ignoro tudo sobre BIOS, Legacy etc. nas placas atuais. — Porém, mesmo neste caso, pode sobreviver (ao menos, em parte), na medida em que o computador atual seja mantido (talvez em rede), com os HDDs mais antigos, ao lado de outro mais novo.

Ou em caso de defeito físico, — uma vez que até agora a CPU e a Memória RAM parecem longe de se tornar insuficientes para os usos requeridos.

Sequência da reorganização

Origem - Antigo particionamento (2009 a 2017)

Antes - Ensaio de particionamento em SSD externo (25 Out. 2016)

Antes - Ensaio de backup total (30 Nov. 2016)

Migração - Clonagem de partição de sistema (21 Dez. 2016)

Depois - Backup total e limpeza das partições (25 Dez. 2016)

Depois - Remanejamento de sistemas Linux ao reparticionar discos (10 Jan. 2017)

Epílogo - Remanejamento do Debian de sda3 para sda3 (6 Fev.)

___________
Relato inicialmente produzido no Debian testing, em 6 Fev. 2017; e complementado no Debian e no KDE Neon até 10 Fev. 2017.

— … ≠ • ≠ … —

Byteria

Translate

segunda-feira, 6 de fevereiro de 2017

Reparticionamento dos discos rígidos - Epílogo