Remanejamento de sistemas Linux ao reparticionar discos

Conky ajustado após remanejar os sistemas Linux instalados e reparticionar os discos rígidos

Nos últimos 7 anos, pouca coisa foi alterada no particionamento inicial dos 2 HDDs de 320 GB, — “sda” e “sdb”, — mas vários “erros” cometidos na época (2009) pediam correção, quando houvesse espaço para o remanejamento dos sistemas Linux instalados, — de preferência, sem que ficassem inoperantes, sequer 1 dia.

Não foi tão simples, — reparticionar 4 HDD / SSD e deixar todos os sistemas novamente 100% funcionais acabou exigindo 48 horas, ao longo de 3 dias (6 a 8 Jan. 2017), — mas nunca faltaram pelo menos 2 ou 3 sistemas em operação (além do Live Knoppix).

O relato é longo, — mesmo suprimindo e resumindo, — porque é a memória do quê (e como) foi feito.

• Objetivos
• Preparação
• Reparticionando o SSD externo (sdd) - I
• Reparticionando o 3º HDD (sdc)
• Reparticionando o SSD externo (sdd) - II
• Teste dos clones: Mint, Kubuntu e Zesty
• Grub e root=UUID conflitante - I
• Reparticionando o 1º HDD (sda)
• Reparticionando o 2º HDD (sdb)
• Arrumando a (nova) casa
• Ajuste do Conky às novas partições
• Grub: - Manjaro vs. KDE Neon
• Datas adulteradas pelo Unison
• Pontos de montagem despadronizados no Debian
• Teste final do Kubuntu, Mint e Zesty
• Movendo a pasta /home para uma partição separada
• Ajuste de “hostname” e “hosts”
• Grub e root=UUID conflitante - II
• Ajustes no Grub do Manjaro

Além disso, é parte de uma reorganização longamente pensada, a partir de vários ensaios, testes e observações, nos últimos meses:

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.)

Objetivos

Motivos de o Kubuntu 16.04 LTS e o Linux Mint 18 KDE serem considerados “principais”

1) Um dos objetivos era colocar em diferentes HDDs o Kubuntu e o Linux Mint, — os 2 sistemas “principais”, por serem os mais estáveis, e nos quais consigo realizar o maior leque de tarefas. — Há vários anos, a ideia é ter a segurança de pelo menos um sistema funcionando, caso o outro “quebre” (hipótese cada vez mais remota, mas…), — mas nada disso faria sentido, se ocorresse alguma falha no HDD “sdb”, onde ambos estavam instalados (com suas /home, onde se acumulam Wine, Corel, cache do Google Earth e todas as configurações de vários anos).

Heranças de 2009 no particionamento de “sda” e “sdb”

2) Outro objetivo era mudar o formato das partições de trabalho “E:\” e “F:\” (herdadas do antigo Windows XP), de Fat32 para ext4. — Após tantos anos, também estava clara a real necessidade de espaço nessas 2 partições (podiam ser redimensionadas com vantagem), assim como a conveniência de criar uma 3ª partição de documentos de uso corrente, para separar outros arquivos, — em “Sites”, “Works” e “XTudo”, por exemplo.

3) Igualmente, mudar o formato da recente partição “Backup2” (no SSD externo), de exFAT para ext4. — Aliás, “backups” de verdade são minoria, tanto ali quanto na recente partição “Backup1” (do 3º HDD interno). O maior volume de arquivos está, na verdade, apenas “armazenado” ali, para não ocupar as partições de trabalho. Por isso, ao longo do processo, essas partições tiveram suas etiquetas (label) mudadas para “Armazem1” e “Armazem2”, — e dentro delas há uma pasta “Backup” (entre outras).

Localização “física” das antigas partições no 2º HDD (sdb)

4) Em outra escala, incomodavam bastante o fato de “sdb” ter apenas 1 partição primária, — e o Linux Mint estar em uma partição lógica, depois das partições de Swap, — com um embaralhamento enorme entre suas numerações e suas verdadeiras localizações “físicas”.

4.1) O HDD “sda” estava mais bem dividido, — com 2 Linux em 2 partições primárias, — mas as partições de Swap também estavam antes das partições de documentos (embora a numeração lógica sugerisse o contrário).

Particionamento anterior, — e início de correção no “sdc”, ao instalar o Manjaro KDE

5) Enfim, não havia mais nenhum sentido nas enormes partições “/home” do Kubuntu (178,9 GiB) e do Linux Mint (74,8 GiB), — que durante anos, foram usadas para backup e “armazenagem” de arquivos estáticos, — enquanto Debian, Neon e Zesty (instalados depois), simplesmente não tinham partição “/home”. Em casos de reinstalação / substituição do Debian testing, do KDE Neon, ou do Kubuntu 17.04 Zesty Zapus, teria sempre de fazer backup das respectivas pastas “/home”, ou perder configurações que custaram tempo e trabalho.

5.1) A recente divisão inicial do SSD externo “sdd”, — com 3 partições primárias para eventual instalação de sistemas Linux, — mostrou-se muito útil, porém 40 GiB era um exagero, —  e a falta de partições “/home”, uma burrice, a longo prazo.

5.2)  Por último, a divisão inicial do 3º HDD interno “sdc”, — com partições para até 6 sistemas Linux, — evitou o mesmo exagero no tamanho, mas manteve o erro de não prever partições “/home”. — Isso começou a ficar claro (e ser corrigido) ao instalar o Manjaro KDE (com expectativa de ser mantido por muitos anos).

Modelo de particionamento que emergiu da experiência prática com os recentes “sdc” e “sdd”

Testadas na prática essas 2 experiências recentes, acabou tomando forma um “modelo” a ser adotado em todos os HDDs internos, bem como no SSD externo (que não permanecerá sempre plugado).

Esse “modelo” não chegou a ser 100% desenhado, — apenas foram feitas simulações em planilha, onde o espaço restante para “dados” ia se ajustando em função de 2 ou 3 Linux por HDD, com partições “/” e “/home” de 20 ou 25 GiB etc.

Não foi considerada nenhuma hipótese de compartilhar partições Swap para economizar espaço, já que a ideia é dispor de um particionamento racional para qualquer eventualidade, por muitos anos, sem necessidade de remendos ou improvisos. — Se no futuro a Memória RAM for aumentada para 8 GiB (mantendo um ou todos os atuais HDDs), será possível fundir algumas dessas partições, ou 2 Linux compartilharem 2 partições, por exemplo, — mas não faltará espaço para casos como o do Debian, que “prefere” ter exclusividade sobre seu Swap.

Última forma da planilha, — após o remanejamento dos sistemas Linux e reparticionamento dos HDDs

A simulação em planilha prosseguiu durante o processo, — o tamanho da partição “Sites” acabou sendo definido na hora, assim como alguns Swap de 4,08 e 4,25 GiB (por não ter certeza sobre eventuais espaços a mais, que o GParted pudesse exigir). — Aliás, a conversão de “GiB” em “MiB” (para preencher no GParted) foi feita na hora, em calculadora, pois a planilha não acompanhou o ritmo das decisões e das operações realizadas. No entanto, seria prático criar essa coluna na planilha, para conversão automática dos tamanhos em “MiB”.

Esse desconhecimento prévio sobre várias coisas levou a perder tempo com algumas operações desnecessárias, — e também com várias tentativas falhadas.

Por outros motivos, — não tirar a atenção do “quê” e “como” iria fazer (não deslocar o foco do real para sua representação abstrata), — não foi elaborado nenhum “planejamento”, nem traçado qualquer “fluxograma” da sequência de operações para implementá-lo.

Preparação

Backup das partições Fat32 “E:\” e “F:\”, preparando para deletá-las

6 Jan. 2017, a/p 17:09 - Carregados e atualizados o Zesty Zapus, o Debian testing, o KDE Neon, o Kubuntu LTS e o Linux Mint (que passou do KDE 5.8.4 para 5.8.5, com atualização de 101 pacotes).

21:24+ - Esvaziadas as partições “/home” do Kubuntu LTS e do Linux Mint. — Suas pastas “Downloads” foram transferidas e fundidas numa só, em “Backup1” (Armazem1), — e deletadas as pastas “/.thumbnails” (1,9 GiB no caso do Kubuntu). Portanto, ficaram apenas os arquivos ocultos, contendo vários anos de configurações (inclusive toda memória do Google Earth), além do Wine (CorelDraw, Dreamweaver, MS Word).

Retirado de “E:\” tudo que não fosse espelho atual dos sites. — Todos os backups recentes foram transferidos para junto dos backups mais antigos, em “Backup1” (Armazem1).

22:37 - Carregado o Live Knoppix (Pendrive 16GB com arquivo de persistência), para iniciar de fato os remanejamentos e reparticionamentos.

Situação anterior do SSD externo (sdd), — apenas um Zesty já sem uso, e dados (espelho) na partição exFAT

22:40 - Live Knoppix (Pen16) passa a gravar Prints em sua própria Home, para desmontar todas as partições “adicionais” (não-pertencentes a ele), — inclusive “F:\”.

22:43 - Sincronização automática das horas (isso nunca persiste), para situar os Prints corretamente na sequência cronológica.

Reparticionando o SSD externo (sdd) - I

GParted desaconselha tentar mover partição “para a esquerda”

22:53 - Redimensionar as 3 partições primárias do SSD externo (sdd1, sdd2, sdd3), — de 40 GiB para 25 GiB, — tentando deslocar a 2ª e a 3ª “para a esquerda”, para ocuparem o espaço liberado.

Isso não funcionou, — o GParted tinha avisado que não valia a pena tentar.

Como estavam vazias, — exceto um antigo Zesty (já transferido), — não valiam o esforço, e foram deletadas.

Deletando todas as partições do SSD externo (sdd)

23:03 - Deletadas todas as partições de SSD externo (sdd), uma vez que apenas “Backup2” tinha conteúdo, — e ao mudar seu formato de exFAT para ext4, não teria como mantê-lo.

Como era um espelho de “Backup1”, — que seria mantido, — bastaria espelhar novamente, mais tarde.

As outras partições estavam sem uso no momento (o antigo Zesty já tinha sido clonado para “sdc”). Portanto, era mais prático apagar tudo e re-particionar, do que ficar movendo / redimensionando etc.

Deixado sdd vazio, — para reorganizar sdc, que depois lhe serviria de modelo.

Reparticionando o 3º HDD (sdc)

Clonagem do Linux Mint pelo GParted. — Grow file system to fill the partition

23:10 - Redimensionada sdc1 (25 para 16,2 GiB), para receber clone do Linux Mint.

• Totalmente desnecessário. — Após copiar / colar, o GParted expande o clone para ocupar o espaço excedente.

Além disso, foi perdido bastante tempo tentando copiar Mint para uma partição de tamanho exatamente igual, — sem sucesso. — Aumentar alguns MiB na partição de destino, foi o que resolveu.

• Depois disso, nunca mais houve problema em copiar uma partição para outra, de tamanho exatamente igual.

23:42 - Clonado Linux Mint 18 KDE, de sdb6 para sdc1, — localização definitiva. — O objetivo era tê-lo em um HDD separado do Kubuntu 16.04 LTS (sdb1).

Como foi deixado um pequeno espaço a mais no final da partição de destino, o GParted fez um “grow file system to fill the partition”. — Ou seja, não precisava ter reduzido a partição de destino de 25 para 16,2 GiB.

23:45 - Redimensionada a partição sdc1 para voltar a 25 GiB. — Esta já seria a localização definitiva do Linux Mint.

Mint, Manjaro e Zesty Zapus em sdc1, sdc2, sdc3. — Deletando partições Swap para reorganizar o final

23:56 - Clonado Zesty Zapus de sdc7 para sdc3, — também localização definitiva.

Deletando 6 partições Swap. — Havia mais 5,99 GiB sem uso, após as partições Swap, — e como não vale a pena tentar deslocar partições “para a direita / para a esquerda”, o mais prático era deletar todas 6, e depois recriar apenas 3, “grudadas” no final do disco.

Redimensionando “Backup1” e recriando 3 partições Swap, sem deixar espaço no final

7 Jan. 2017, à 0:12 - Ampliando "Backup1" de 751 para 769 GiB, — para depois recriar 3 partições Swap, sem deixar espaço vazio no final.

Reparticionando o SSD externo (sdd) - II

SSD externo, — com 2 partições provisórias para Home1 e Home2

0:49 - Particionando SSD externo, — com 2 grandes partições provisórias para receber Home1 (do Kubuntu LTS) e Home2 (do Mint), — a serem reduzidas a seguir.

Clonagem das partições “/home” do Linux Mint e do Kubuntu LTS

1:03 - Copiadas Home1 e Home2 para SSD externo, — onde poderiam ser redimensionadas para 25 GiB, sem afetar os originais (até as cópias serem testadas).

Encolhendo os clones das partições “/home” do Kubuntu LTS e do Linux Mint

1:21 - Encolhidos para 24,4 GiB os clones das antigas partições Home1 e Home2.

1:22 - Atribuídas novas Label e novos UUID (random) para Home1 e Home2 encolhidas.

1:41 - Home1 encolhida copiada para sdd5 (localização provisória); e Home2 encolhida copiada para sdc5 (localização definitiva).

Registro dos identificadores UUID às 2:09, — e os passos seguintes

2:03 - “sudo blkid” para registrar os identificadores UUID de todas as partições, e anotar os próximos passos.

Eliminando partições provisórias e terminando o particionamento do SSD externo (sdd)

2:14 - Label “Backup1” alterada para “Armazem1”, no 3º HDD (sdc).

No SSD externo (sdd), — Deletar as cópias provisórias de Home1 e Home2.  — Criar partição “Armazem2”. — Criar 3 partições Swap, — exatamente como no 3º HDD (sdc).

2:23 - Atribuindo novos identificadores UUID (random) a sdc1 e sdc3 (Mint novo + Home definitiva).

Novo registro dos identificadores UUID, — para conferir os passos necessários dali em diante

2:41 - Novo exame dos identificadores UUID e dos passos seguintes. — Ao selecionar um UUID, o Kate destaca as repetições.

/dev/sda1: 

/dev/sda3: 

/dev/sda5:  - E - formatar ext4  **

/dev/sda6:  - F - formatar ext4  **

/dev/sda7:  - Swap - *** DEL 1st

/dev/sda8:  - Swap - *** DEL 1st

/dev/sda9:  - Swap - *** DEL 1st

/dev/sda10: - Swap - *** DEL 1st

**   Deletar depois de testar novos Mint, Kubuntu
*** Deletar Swaps, que estão no início da partição estendida

/dev/sdb1:  - Kubuntu atual - ** Preservar

/dev/sdb5:  - Home1 atual   - ** Preservar

/dev/sdb6:  - Mint atual    - ** Preservar

/dev/sdb7:  - Home2 atual   - ** Preservar

/dev/sdb8:  - Swap - *** DEL 1st

/dev/sdb9:  - Swap - *** DEL 1st

/dev/sdb10: - Swap - *** DEL 1st

/dev/sdb11: - Swap - *** DEL 1st

**   Deletar depois de testar novas Home1, Home2
*** Deletar Swaps, que estão no início da partição estendida

/dev/sdc1:  - Mint (novo) - re UUID

/dev/sdc2:  - Manjaro

/dev/sdc3:  - Zesty (novo) - re UUID

/dev/sdc5:  - Home2 - Mint (nova)

/dev/sdc6: 

/dev/sdc7:  - (Zesty atual)

/dev/sdc8: 

/dev/sdc9: 

/dev/sdc10:

/dev/sdc11:

/dev/sdd1:  - Kubuntu (novo)

/dev/sdd2: 

/dev/sdd3: 

/dev/sdd5:  - Home1 (Kubuntu) - nova

/dev/sdd6: 

/dev/sdd7: 

/dev/sdd8:  - deletar (Home2)

/dev/sdd9:  - deletar (Home1)

O excesso de cautela deveu-se à intenção de testar os clones do Linux Mint + /home definitivos (sdc) e Kubuntu LTS + /home provisórios (sdd), — antes de deletar as instalações originais (sdb), — e só prosseguir depois disso.

Para que os clones pudessem ser testados, era necessário que não tivessem identificadores UUID repetidos.

Não fosse pela cautela, bastaria manter os identificadores UUID de origem, — e sempre deletar os originais e/ou as cópias intermediárias. — Outra alternativa era apenas guardar backups comprimidos (supondo-os imunes a erro), que não interfeririam em nada.

Nessa fase, foram utilizadas várias Label improvisadas, apenas para ter pé da situação.

Teste dos clones: Mint, Kubuntu e Zesty

Editando /etc/fstab do Mint no Manjaro, — antes de disparar “sudo update-grub”

2:49 - Manjaro KDE (sem Swap), para preparar os testes dos clones do Kubuntu e Linux Mint, com as respectivas Home1 e Home2 encolhidas, e novos Swap. — Prints salvos em sua própria Home (pois “F:\” estava para ser deletado em breve).

3:01 - Conky do Manjaro ajustado para exibir as novas Home11 (sdc5) e Home21 (sdd5), Armazem1 e Armazem2 (ex-Backup1, Backup2)

3:14 - Editando /etc/fstab do Linux11 (novo Mint em sdc1) — UUID da nova Home11 e novo Swap.

3:27 - Editando /etc/fstab do novo Zesty (sdd3) — novo UUID Swap.

“sudo update-grub” no Manjaro, para detectar os clones do Linux Mint e do Zesty Zapus

3:30 - “sudo update-grub” no Manjaro, para detectar os clones do Mint e Zesty em seus novos locais definitivos (desplugado o SSD externo, onde só havia cópias provisórias).

Edição do etc/fstab do Manjaro, para atualizar o identificador UUID da nova partição Swap

3:44 - Knoppix (Pen16), de novo. — Editando /etc/fstab do Manjaro, para incluir seu novo Swap (sdc10)

Clonando o Kubuntu LTS de sdb1 para sdd1

3:57 - Copiando Kubuntu de sdb1 para sdd1. — Excesso de precaução, já que o Kubuntu original seria mantido.

A ideia era apenas usar um Kubuntu provisório para testar a cópia provisória de sua /home reduzida para 25 GiB.

Edição do etc/fstab do clone do Kubuntu, com novos identificadores UUID

4:12 - Editando /etc/fstab do novo Kubuntu (provisório) em sdd1

4:19 - Manjaro, enfim com Swap (4,25 GiB), ok.

4:26 - sudo update-grub no Manjaro, para incluir também o novo Kubuntu (provisório).

Grub do Manjaro, com os originais e os clones do Kubuntu LTS, Linux Mint e Zesty Zapus

4:29 - Foto do Grub do Manjaro, — destaque (verde): novo Linux Mint em sdc1

4:29 - Carregado o Mint (supostamente) novo, — nervoso, ágil e rápido, quase instantâneo.

Dolphin entrega o ouro: — O “novo” Linux Mint estava rodando na partição antiga

4:46 - Dolphin na Raiz do Mint: — É a partição antiga! (sdb6: apenas 7,5 GiB livres).

4:48 - Editando /etc/fstab do Mint “novo”, — UUID de sdc1, sdc5 (Home), sdc9 (Swap).

4:51 - Recarregando o Mint “novo”. — Ok, Swap novo (4,25 GiB), — mas ainda carregado a partir da Raiz antiga (sdb6).

Na verdade, ao editar /etc/fstab (que já havia corrigido antes), de fato estava corrigindo o do antigo Linux Mint. — Por isso, ao recarregar, finalmente assumiu a nova /home e o novo Swap, — mas, sempre carregando a partir da instalação antiga (sdb6).

Porém, nada disso estava claro, naquele momento, — muito menos, os motivos disso.

5:36 - Kubuntu (novo), segundo o Grub, — porém na Raiz antiga e com a Home antiga.

5:58 - Copiado e colado o conjunto de UUID do /etc/fstab da nova partição para o /etc/fstab da partição antiga.

6:02 - Depois disso, Kubuntu LTS também passou a carregar com a nova Home, — mas ainda a partir da Raiz antiga.

Essa edição (não-planejada) do /etc/fstab do Kubuntu original, — a ser mantido, — introduziu um grau extra de confusão, em um cenário onde identificadores UUID já dançavam e se embaralhavam em todas as direções, numa sopa de letras e números.

6:05 - Estava ficando claro que era hora de dormir.

Grub e root=UUID conflitante - I

Identicador UUID correto da partição sdd1, — localização correta do clone do Kubuntu LTS

12:09 - O exame do arquivo “/boot/grub/grub.cfg” do Manjaro mostrou que cada entrada referente ao clone do Kubuntu 16.04 LTS (sdd1) apontava 2 identificadores UUID conflitantes:

menuentry 'Ubuntu 16.04.1 LTS (16.04) (em /dev/sdd1)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-7359b864-23bd-4820-9342-5ecb08ee1d04' {
savedefault
insmod part_msdos
insmod ext2
set root='hd3,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
 search --no-floppy --fs-uuid --set=root --hint-bios=hd3,msdos1 --hint-efi=hd3,msdos1 --hint-baremetal=ahci3,msdos1  7359b864-23bd-4820-9342-5ecb08ee1d04
else
 search --no-floppy --fs-uuid --set=root 7359b864-23bd-4820-9342-5ecb08ee1d04
fi
linux /boot/vmlinuz-4.4.0-57-generic root=UUID=89f3c9f7-17e6-4926-8347-19698765896a ro quiet splash $vt_handoff
initrd /boot/initrd.img-4.4.0-57-generic

Identificador UUID incorreto no parâmetro “root”, — localização do Kubuntu LTS original (sdb1)

Portanto, depois de apontar 3 vezes o identificador UUID da partição-clone (sdd1), — o parâmetro root=UUID (linha vmlinuz) terminava indicando o UUID da partição original (sdb1).

Kubuntu LTS finalmente carregado a partir da partição correta (sdd1)

Bastou corrigir este último UUID no arquivo “/boot/grub/grub.cfg” do Manjaro, — e o clone do Kubuntu 16.04 LTS finalmente passou a carregar a partir de sua partição provisória (sdd1).

O mesmo problema foi encontrado nas entradas dos clones do Linux Mint e do Zesty Zapus, — e bastou corrigi-las, para eles finalmente também serem carregados a partir de suas partições definitivas (sdc1 e sdc3).

Editar manualmente o arquivo “/boot/grub/grub.cfg”, — gerado pelo comando “sudo update-grub” (ou por alguma atualização do próprio Grub), — está longe de ser uma solução satisfatória, a médio prazo.

No entanto, esta “solução” imediatista permitiu testar a integridade dos clones do Linux Mint, do Kubuntu LTS e do Zesty Zapus, — bem como das 2 partições /home encolhidas, — de modo a seguir em frente com o particionamento, apagando as partições originais e/ou suas cópias intermediárias (provisórias).

• Ver “Grub e root=UUID conflitante - II” (no final)

Restabelecido o antigo “Backup2”, — agora em formato ext4

15:59 - luckyBackup de Armazem1 (ex-Backup1) para seu espelho Armazem2 (agora em formato ext4) — concluído em 2 horas 29 minutos.

16:30 - Zesty rodando a partir da nova partição, — Ok.

Reparticionando o 1º HDD (sda)

Particionamento anterior do 1º HDD (sda)

17:23 - Deletando todas as partições lógicas do 2º HDD (sda), — preservando apenas as partições primárias sda1 (KDE Neon) e sda3 (Debian).

Portanto, foram deletadas “E:\”, “F:\”, as partições Swap, e a própria partição estendida onde estavam.

Três partições primárias de 25 GiB e nova partição estendida, no 1º HDD (sda)

17:54 - Depois de várias manobras, as 2 partições primárias de 20 GiB já estavam ampliadas para 25 GiB. — Foi criada mais uma partição primária de 25 GiB.

Infelizmente, a segunda partição continuou sendo “sda3”, — “herança” antiga, — e a terceira ficou sendo “sda2”.

Para evitar isso, teria de copiar o Debian para o SSD externo, deletar “sda3”, criar novamente “sda2” e “sda3”, e trazer de volta o Debian, — coisas que preferi evitar, para não gerar a necessidade de testar mais um clone intermediário e mais um clone definitivo. (Claro, tudo seria bem mais simples e rápido sem tantas cautelas).

Por fim, foi criada a partição estendida.

Novo particionamento do 1º HDD (sda)

18:05 - Na partição estendida, foram criadas mais 3 partições ext4, — para abrigar as partições /home de seus 3 Linux, — além de 2 partições de dados “Works” e “Sites”, e 3 partições Swap.

Finalmente, foi “resetado” o padrão de numeração nas etiquetas (label), — Linux1, Linux2, Linux3.

Reparticionando o 2º HDD (sdb)

Deletando quase tudo no 2º HDD (sdb), exceto Kubuntu 16.04 LTS em sdb1

18:14 - Deletar tudo no 2º HDD (sdb), — exceto Kubuntu LTS, na primeira partição primária sdb1.

Uma vez que o Linux Mint já tinha sido transferido para o início de 3º HDD (sdc1), o Kubuntu LTS poderia ser mantido onde estava, — no início do 2º HDD (sdb1), — e apenas ampliar sua partição para 25 GiB.

Particionando o 2º HDD (sdb), após deletar tudo, exceto Kubuntu em sdb1

18:32 - Disco sdb re-particionado, — de modo idêntico ao sda, — com as etiquetas (label) numeradas no novo padrão (Linux4, Linux5, Linux6).

A única diferença é que, — ao invés de 2 partições de dados, — foi criada apenas uma, “XTudo”.

18:37 - Alteradas as etiquetas (label) das partições em sdc, no novo padrão de numeração, — Linux7, Linux8, Linux9.

18:43 - Alteradas as etiquetas (label) das partições em sdd para o novo padrão de numeração, — Linux10, Linux11, Linux12.

Copiando de volta a /home (já encolhida) do Kubuntu 16.04 LTS

18:48 - Copiando de volta a /home (encolhida) do Kubuntu LTS, — de sdd5 para sdb5.

“sudo blkid” para registro atualizado dos identificadores UUID das partições

19:03 - Comando sudo blkid para registro dos identificadores UUID (6ª atualização).

20:33 - Editando /etc/fstab do KDE Neon, — identificador UUID da nova partição Swap.

21:01 - Verificados e editados os demais arquivos /etc/fstab que precisavam de correção. — Mais tarde, foi verificado que ainda ficaram erros (ou foram introduzidos neste ponto?).

21:15 - Shutdown Knoppix. — Desplugar o SSD externo (que ainda contém clones provisórios) e o Pendrive.

Arrumando a (nova) casa

Atribuindo a propriedade das partições de dados ao usuário

Em nenhum momento, — mesmo nas fases mais críticas do processo, — faltou um sistema Linux funcional (positivo operante), com ambiente gráfico (KDE) personalizado, e todos os aplicativos necessários.

Na pior das hipóteses, o Knoppix em Live USB (Pendrive 16GB com arquivo de persistência) era uma garantia de sistema operacional completo, personalizado e lotado de ferramentas (embora evitando abrir o Chromium, para não deixar lento o GParted), — mas o Manjaro também atravessou incólume todos os abalos (Swap foi sua única partição afetada), o que permitiu manter a comunicação e dar andamento ao trabalho regular.

O KDE Neon, — mantido na primeira partição do 1º HDD (sda1), e ainda sem partição /home, — também não foi afetado (exceto pelo Swap). Apenas, não foi usado, por puro esquecimento. Nesse momento, Manjaro é o “brinquedo novo”, que ofusca os outros.

No entanto, a falta da partição de dados “F:\” já estava dando urticária. — Era urgente recuperar os documentos do Backup para as novas partições de dados.

21:31 - Foi verificado que as novas partições Sites, Works e XTudo pertenciam ao Root.

21:33 - “sudo chown -R flavio (Sites, Works, XTudo)”, — para atribuir ao usuário a “propriedade” dessas novas partições de dados.

Fazer isso no Terminal do Dolphin, — “dentro” de /run/media/flavio/, — simplifica o comando, e permite focar no que se está fazendo.

O Dolphin já definiu o caminho (path), — desde quando fez o primeiro “mount”, — e já cuidou do “cd” para chegar aonde estão os pontos de montagem.

Atualização do Grub (Manjaro, MBR em sdc) após o remanejamento dos sistemas Linux

21:36 - “sudo update-grub”, — para poder testar os “novos” sistemas Linux e respectivas /home, — agora em suas localizações definitivas.

Tamanho dos arquivos a serem recuperados para as novas partições de dados

O primeiro passo para “povoar” as novas partições Works e XTudo foi separar, — dentro do próprio Backup, — as pastas da antiga partição “F:\” que iriam para cada uma delas.

Para isso, a antiga pasta “Armazem1/Backup/F/” foi renomeada “Armazem1/Backup/XTudo/”.

Em seguida, foi criada uma pasta “Armazem1/Backup/Works/”, — e arrastadas para ela as pastas diretamente relacionadas ao trabalho nos sites.

A pasta “Armazem1/Backup/E/” foi apenas renomeada como “Armazem1/Backup/Sites/”.

21:54 - Exame visual do tamanho das pastas, — em “Armazem1/Backup”, — a serem restauradas nas novas partições Works, XTudo e Sites (Konqueror, Modo de exibição radial).

Separação, — no Backup, — dos arquivos a serem recuperados para as novas partições de dados

21:57 - Separação, — no Backup, — dos arquivos da antiga partição “F:\” a serem restaurados nas novas partições Works e XTudo.

Ajuste do Conky às novas partições

Reorganização da seção de uso das partições no Conky

22:44 - Encerrando Manjaro, com Conky “novo”.

Uma vez que agora todas as partições de sistema (“/”) e todas as partições “/home” têm tamanho padronizado de 25 GiB, era desnecessário repetir essa informação em 9 linhas, — pior ainda, criar mais 3 linhas, para monitorar o uso das novas “/home” do Debian, do KDE Neon e do Zesty Zapus.

Aliás, era chato procurar informações sobre o uso de uma Home no bloco de cima (dados), — e sobre a Raiz do respectivo Linux em outra linha, no bloco de baixo (sistemas).

A melhor solução era agrupar as partições Raiz e Home de cada Linux em uma só linha, — e indicar sua localização (sda, sdb, sdc) apenas pela última letra, seguida da numeração adotada nas etiquetas (label), — a1, a2, b4, c7, c8, c9.

Essa identificação + localização dos diferentes sistemas ajuda muito, no dia-a-dia, ao procurar as partições de determinado Linux para editar seu “/etc/fstab” ou “/home/.conkyrc”, por exemplo.

Feito isso, bastou reduzir o comprimento dos gráficos de barra para 45 pixels, — operação quase instantânea, por busca e troca global (“CTRL-R” no Kate, Kwrite), — em um TXT separado (para não afetar os demais gráficos de barra do arquivo “/home/.conkyrc”).

Esse arquivo TXT separado foi utilizado, depois, para adaptar e copiar esse bloco para o Conky dos demais sistemas.

No Debian, onde os caminhos (path) estão mais curtos, esse bloco de texto do Conky ficou assim, mais tarde:

Sites    ${alignr}${fs_used /media/Sites} / ${fs_size /media/Sites}  ${alignr}${fs_bar 6,50 /media/Sites}
Works    ${alignr}${fs_used /media/Works} / ${fs_size /media/Works}  ${alignr}${fs_bar 6,50 /media/Works}
XTudo    ${alignr}${fs_used /media/XTudo} / ${fs_size /media/XTudo}  ${alignr}${fs_bar 6,50 /media/XTudo}
Armazem1 ${alignr}${fs_used /media/Armazem1} / ${fs_size /media/Armazem1}  ${alignr}${fs_bar 6,50 /media/Armazem1}
Armazem2 ${alignr}${fs_used /media/Armazem2} / ${fs_size /media/Armazem2}  ${alignr}${fs_bar 6,50 /media/Armazem2}
$hr
a1 Neon    ${alignr}${fs_used /media/Linux1} ${alignr}${fs_bar 6,45 /media/Linux1}  ${alignr}${fs_used /media/Home1} ${alignr}${fs_bar 6,45 /media/Home1}
a2 Debian  ${alignr}${fs_used /} ${alignr}${fs_bar 6,45 /}  ${alignr}${fs_used /home} ${alignr}${fs_bar 6,45 /home}
b4 Kubuntu ${alignr}${fs_used /media/Linux4} ${alignr}${fs_bar 6,45 /media/Linux4}  ${alignr}${fs_used /media/Home4} ${alignr}${fs_bar 6,45 /media/Home4}
c7 Mint    ${alignr}${fs_used /media/Linux7} ${alignr}${fs_bar 6,45 /media/Linux7}  ${alignr}${fs_used /media/Home7} ${alignr}${fs_bar 6,45 /media/Home7}
c8 Manjaro ${alignr}${fs_used /media/Linux8} ${alignr}${fs_bar 6,45 /media/Linux8}  ${alignr}${fs_used /media/Home8} ${alignr}${fs_bar 6,45 /media/Home8}
c9 Zesty   ${alignr}${fs_used /media/Linux9} ${alignr}${fs_bar 6,45 /media/Linux9}   ${alignr}${fs_used /media/Home9} ${alignr}${fs_bar 6,45 /media/Home9}

Observe que, — em cada sistema, — sua própria Raiz foi referida simplesmente como “/”, e sua Home apenas como “/home”.

Adaptação do arquivo oculto “/home/.conkyrc” do KDE Neon, com o bloco trazido do Manjaro

23:02 - KDE Neon carregado, — Ok.

23:14 - Copiado bloco com as alterações feitas no “/home/.conkyrc” do Manjaro, — substituindo “/run/media/flavio/” por apenas “/media/flavio/”, no caminho das partições (path).

Grub: - Manjaro vs. KDE Neon

Usando o Grub-customizer no KDE Neon para fazer alguns testes comparativos com o Grub do Manjaro

8 Jan. 2017, à 0:29 - Usando Grub-customizer no KDE Neon para atualizar e configurar seu Grub, e gravar a chamada no MBR do 1º HDD (sda).

Até então, estava usando o Grub gerado pelo Manjaro, — com chamada no MBR do 3º HDD (sdc).

A partir daí, testes foram feitos, ora com a BIOS procurando o Boot no 1º HDD (sda), ora procurando o Boot no 3º HDD (sdc), — para comparar alguns resultados (com / sem correção manual).

No final, a opção acabou permanecendo com o Grub do Manjaro, — o único (entre os 6 Linux instalados) que gera entradas corretas para carregá-lo.

Usando o Grub dos outros Linux, precisaria fazer uma correção manual das entradas referentes ao Manjaro, — após cada “sudo update-grub”.

Última linha referente ao Manjaro, no Grub gerado pelo Mint, — /boot/grub/grub.cfg:

initrd /boot/intel-ucode.img

Diferente do Grub gerado pelo Manjaro, cuja última linha contém um parâmetro adicional:

initrd /boot/intel-ucode.img /boot/initramfs-4.4-x86_64.img

Sem esse último parâmetro, o Manjaro não carrega.

Datas adulteradas pelo Unison

Sincronização pelo Unison para recuperar do Backup as pastas destinadas à partição XTudo

8 Jan. 2017, à 9:34 ~ 9:43 - Criando perfil Unison (Profile Creation) para povoar XTudo.

9:51 - Sincronização concluída.

Infelizmente, o Unison trouxe todos os arquivos com data-hora desse intervalo (9:43 ~ 9:51), — o que cria vários inconvenientes.

Por ser problema de pouca urgência, ficou para correção nos próximos dias.

10:11 - Unison - povoar Works.

10:33 - Povoaamento da partição Sites.

10:53 - Bios Setup — Procurar Boot (MBR) no 1º HDD (sda), — Grub do KDE Neon / Grub-customizer.

Pontos de montagem despadronizados no Debian

Dolphin → clicar → montar. — Senha

11:06 - Debian carregado e funcionando. — Sem Print por falta de “F:\” (antigo atalho de teclado).

Dolphin pede senha para montar XTudo, — há tempos nem lembrava disso.

Usando Gerenciador de Disco (Disk Manager) para editar /etc/fstab, no Debian

11:29 - Gerenciador de Disco (escreve /etc/fstab), para definir quais partições montar no início de cada sessão, — uma vez que no Debian a montagem automática pelo KDE não faz efeito.

Pontos de montagem despadronizados, — conforme o modo como foram criados

A partição XTudo, — montada pelo Dolphin (mediante senha), — foi para “/media/flavio/”, enquanto as demais ficaram em “/media/”.

Edição dos pontos de montagem (/etc/fstab) pelo Gerenciador de Disco, no Debian testing

Na meia-hora seguinte, foram padronizados os pontos de montagem.

O caminho encontrado foi o Gerenciador de Disco (Disk Manager), — Selecionar a partição e clicar com o botão direito, — Editar ponto de montagem, — eliminar “flavio/”.

Deletado o ponto de montagem dissonante, — até que todos sejam movidos para essa pasta

Mais tarde, — quando já existia o novo ponto de montagem “/media/XTudo”, — foi deletado o antigo ponto “/media/flavio/XTudo”, usando o comando “rmdir” no Terminal (F4) do Dolphin.

Por comodidade imediata, ficou valendo (provisoriamente) o caminho mais curto.

Mas a longo prazo, parece mais conveniente manter o mesmo caminho (path) usado pelos demais “derivados Debian”, — “/media/flavio/”. — Isso evitará muito trabalho, ao copiar caminhos (path), entre os diferentes sistemas.

Já é suficiente ter de lembrar que no Manjaro os caminhos (path) são “/run/media/flavio”, — sem necessidade de lembrar que no Debian está valendo um terceiro padrão.

Teste final do Kubuntu, Mint e Zesty

Habilitando a exibição das entradas do Kubuntu LTS no Grub-customizer

Àquela essa altura, estavam testados e funcionando apenas o KDE Neon, o Debian testing e o Manjaro.

Devido aos sucessivos remanejamentos e manipulações, havia perdido o pé, por completo, quanto ao Kubuntu LTS, ao Linux Mint, e suas /home, — nas localizações definitivas.

Atribuindo novo UUID (random) à partição /home do Kubuntu LTS, no GParted

14:17 - A nova /home do Kubuntu LTS (sdb5) ainda estava com o mesmo identificador UUID da cópia intermediária (sdd5), — por isso, foi atribuído novo UUID (random).

14:25 - Editando /etc/fstab Kubuntu para corrigir identificadores UUID da partição Raiz (“/”) e da /home.

14:37 - No Grub-customizer (KDE Neon), — reabilitada a exibição das entradas referentes ao Kubuntu em sdb1.

Conferindo parâmetro root=UUID no Grub-customizer

14:39 - Grub-customizer - confere UUID Kubuntu sdb1 - ok, 3 iguais

14:47 - Kubuntu (sdb1) finalmente carrega (foto).

16:27 - “sudo kwrite grub.cfg” - Editado vmlinuz root=UUID do Linux Mint

16:37 - Linux Mint carregado - ajustando atalho PrintScreen para salvar em XTudo.

16:56 - Começa pesquisa web por "vmlinuz root=UUID update".

17:32 - “sudo kate grub.cfg” - Zesty em sdc3 - substitui  8 identificadores UUID errados nas linhas vmlinuz root=UUID.

17:40 - Zesty Zapus carregado - ajustando atalho PrintScreen para gravar em XTudo.

18:48 - Debian testing carregado, — Ok.

18:59 - KDE Neon carregado, — Ok.

19:02 - Linux Mint carregado, — Ok.

19:05 - Kubuntu LTS carregado, — Ok.

21:23 - Manjaro KDE carregado, — Ok.

8 Jan. 2017 - Portanto, cerca de 48 horas depois de iniciar o remanejamento de sistemas e reparticionamento geral, — com todas as complicações decorrentes de um excesso de cautela, — os 6 Linux pré-existentes estavam novamente 100% funcionais.

Movendo a pasta /home para uma partição separada

Copiando o caminho (path) usado no Linux Mint para a partição destinada à /home do Zesty Zapus

10 Jan. 2017 - O Kubuntu 17.04 Zesty Zapus (development branch) foi escolhido para o teste-piloto de como transferir sua pasta /home da partição de sistema para uma partição separada, — sdc7 (label “Home9”).

Depois de testado na prática, — e documentados todos os passos, — o mesmo poderia ser feito com o KDE Neon e o Debian testing.

14:33 - No Linux Mint, foi copiado o caminho (path) local da partição sdc9 (label “Home9”), que passaria a ser a /home do Zesty Zapus.

Movendo a pasta /home da partição de sistema (raiz) para uma partição separada

14:43 - Com o Dolphin posicionado em /Linux9/home/, esse caminho (path) foi então colado para construir o seguinte comando, — que falhou:

sudo mv -f /flavio /media/flavio/Home9/

O erro estava em colocar a barra no início de “/flavio”. — Bastou repetir o comando sem ela, para funcionar:

sudo mv -f flavio /media/flavio/Home9/

Inserindo a nova partição /home no arquivo /etc/fstab do Zesty Zapus

14:52 - Em seguida, era necessário inserir as informações e parâmetros dessa nova partição /home no arquivo /etc/fstab do Zesty Zapus, para que seja montada e utilizada, na próxima vez que ele for carregado.

Sem isso, ele apenas encontraria a pasta /home (vazia) em sua partição de sistema, — carregaria desconfigurado, — criaria nova pasta de usuário e começaria a povoá-la novamente.

Atribuindo a propriedade da nova /home ao usuário

As dicas sobre transferência da /home para uma partição separada também incluem um comando para atribuir a propriedade da pasta chamada [USER] para o usuário:

sudo chown -R $USER:$USER [USER]

Não parecia haver nenhuma necessidade disso, — a pasta “Home9/flavio” manteve todas as suas características originais, — proprietário “flavio”, permissões “drwxr-xr-x”.

14:55 - No entanto, o comando não causaria mal algum, — e poderia posar para uma foto.

Kubuntu 17.04 Zesty Zapus (development branch) com a /home em partição separada

15:01 - Ao carregar, o Kubuntu 17.04 Zesty Zapus (development branch) se apresentou com todas as configurações anteriores, — além da nova /home, com 22,4 GiB livres.

Ajuste de “hostname” e “hosts”

Alteração do /etc/hostname pede compatibilização do /etc/hosts

12 Jan. 2017 - Durante muito tempo, os diferentes “hostname” foram:

Linux1 - Kubuntu
Linux2 - Mint
Linux3 - Debian
Linux4 - KDE Neon

Com a nova numeração nas etiquetas (label) das partições, “hostname” deveriam passar a ser:

Linux1 - KDE Neon
Linux2 - Debian
Linux4 - Kubuntu 16.04 LTS
Linux7 - Linux Mint
Linux8 - Manjaro
Linux9 - Kubuntu 17.04 Zesty Zapus

Bastou 1 minuto para encontrar na web a dica de editar o arquivo “/etc/hostname”, — e na mesma hora o prompt do Konsole passa a exibir o novo “hostname”.

Porém, o “sudo” passou a apresentar mensagem de erro, — “sudo: unable to resolve host Linux1” (KDE Neon), ou — “sudo: não foi possível resolver máquina Linux7” (Mint), — embora continuasse funcionando normalmente (ao que parece).

Com mais alguns minutos de pesquisa, ficou claro que faltava fazer o mesmo no arquivo “/etc/hosts”, — onde constava o antigo “hostname” de cada Linux.

Grub e root=UUID conflitante - II

Reinstalando o Kernel do Linux Mint pelo Synaptic

Editar manualmente o arquivo “/boot/grub/grub.cfg”, — para corrigir os identificadores UUID discrepante na última linha, — não era uma solução satisfatória, a médio prazo:

linux /boot/vmlinuz-X.X.X-XX-generic root=UUID=XXXXX

• Ver “Grub e root=UUID conflitante - I” (acima)

Uma vez que o UUID errado se referia sempre à partição original, — onde cada Linux tinha sido instalado, — era de se imaginar que se havia incorporado ao recompilar o vmlinuz, ou outra parte do Kernel.

Se essa hipótese fosse correta, o problema tenderia a desaparecer, à medida em que o Kernel de cada Linux recebesse correções de segurança, — ou nova versão de Kernel.

Foram pesquisadas possíveis caminhos para acelerar o processo, — por exemplo, “sudo update-initramfs -u” (sem efeito para o problema), — mas não foi encontrado nada tão simples, capaz de refazer o vmlinuz com o UUID atual de cada partição de sistema.

Restava reinstalar o último Kernel de algum Linux, — e se resolvesse, fazer o mesmo com os demais.

Por sorte, dentro de apenas 3 dias, — ainda pesquisando vários tópicos que pareciam acenar com alguma alternativa, — o Kubuntu LTS, o KDE Neon e o Debian testing receberam atualizações de Kernel, na manhã de 11 Jan. 2017.

Bastou examinar o arquivo /boot/grub/grub.cfg do KDE Neon, — atualizado por último, — para confirmar que as linhas do vmlinuz dele, do Kubuntu LTS e do Debian agora estavam com UUID correto.

Apenas o Linux Mint e o Zesty Zapus continuavam com UUID antigo na linha do vmlinuz.

No dia 12, finalmente foi feita a experiência de reinstalar o último Kernel, no Zesty Zapus, — e depois no Linux Mint, que talvez continue sem atualização de Kernel por muito tempo.

No Zesty Zapus, foram reinstalados todos os pacotes da última atualização de Kernel (18 Dez. 2016):

Commit Log for Thu Jan 12 18:50:29 2017

Reinstalados os seguintes pacotes: [resolveu vmlinuz / root=UUID no Grub]

linux-generic (4.9.0.11.15)
linux-headers-4.9.0-11 (4.9.0-11.12)
linux-headers-4.9.0-11-generic (4.9.0-11.12)
linux-headers-generic (4.9.0.11.15)
linux-image-4.9.0-11-generic (4.9.0-11.12)
linux-image-extra-4.9.0-11-generic (4.9.0-11.12)
linux-image-generic (4.9.0.11.15)
linux-libc-dev (4.9.0-11.12)

No Linux Mint, primeiro foi experimentado reinstalar apenas “linux-headers”, — sem resultado, — e depois foram reinstalados também os pacotes “linux-image” e “linux-kernel-generic”:

Commit Log for Thu Jan 12 19:01:28 2017

Reinstalados os seguintes pacotes: - [não resolveu vmlinuz / root=UUID no Grub]

linux-headers-4.4.0-21 (4.4.0-21.37)
linux-headers-4.4.0-21-generic (4.4.0-21.37)

Commit Log for Thu Jan 12 19:22:45 2017

Reinstalados os seguintes pacotes: [agora resolveu vmlinuz / root=UUID no Grub]

linux-headers-4.4.0-21 (4.4.0-21.37)
linux-headers-4.4.0-21-generic (4.4.0-21.37)
linux-image-4.4.0-21-generic (4.4.0-21.37)
linux-image-extra-4.4.0-21-generic (4.4.0-21.37)
linux-kernel-generic (4.4.0-21)

Ajustes no Grub do Manjaro

Ajustes no arquivo /etc/default/grub do Manjaro

GRUB_TIMEOUT=10, — (em vez de 5). — Estava carregando rápido demais.

Origem do estranho identificador UUID, tido pelo Manjaro como dispositivo de hibernação

resume=UUID=, — (substituído antigo Swap do final do SSD externo pelo Swap do Manjaro). — Era o último dos inúmeros Swap que o Manjaro montou, automaticamente, ao ser instalado no computador. — Foi desabilitado no /etc/fstab (e já nem existe mais), mas continuava sendo buscado, por ainda estar na configuração do Grub.

Cores de letra “light-gray” e “green” substituídas por “white” e “yellow” no Grub do Manjaro

GRUB_COLOR_NORMAL="white/black", — (em vez de "light-gray/black").

GRUB_COLOR_HIGHLIGHT="yellow/black", — (em vez de "green/black").

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.)

_________
• Remanejamentos e reparticionamento feitos de 6 a 8 Jan. 2017, — usando principalmente Knoppix em Live USB (Pendrive 16GB com arquivo de persistência), — mas também o Kubuntu 16.04 LTS, o Manjaro KDE, — e o KDE Neon, no terceiro dia, quando o Kubuntu LTS e o Linux Mint estiveram fora de combate, por falhas localizadas entre a cadeira e o teclado.
• Levantamento inicial de fotos, capturas de tela e anotações concluído em 9 Jan. 2017.
• Relato produzido de 10 a 15 Jan. 2017, no Manjaro KDE.

— … ≠ • ≠ … —

Ferramentas &tc.

• Remanejamento de sistemas Linux ao reparticionar discos
• Backup total e limpeza das partições de trabalho
• Migrando sistemas Linux para disco rígido de 1 Terabyte
• Ensaio de avaliação com luckyBackup e Unison
• Particionamento de Drive SSD para vários Linux
• Tesde de memória com o Memtest86
• De volta ao Gnome-screenshot
• Konqueror como gerenciador de arquivos
• Substituição da fonte de energia do computador
• Facebook sobrecarrega visitar e compartilhar “Páginas”
• Corrigindo pontos de montagem no Linux Mint 18 KDE
• Política de Kernel do Linux Mint vs. Kubuntu, KDE Neon & Debian
• KDE “light” eliminando o PIM
• Conky - configuração em andamento
• Google Earth sem placa 3D no Xenial
• Linux ficou sem Administrador. Que fazer?
• Particionamento de disco para vários Linux
• Padronizando PrintScreen no Linux (com Shutter) e no Windows
• Montagem automática de partições adicionais (Cinnamon e Gnome)
• Boot com “Live USB” (Pendrive) do Linux Mint Cinnamon
• Repositórios de software Linux e gerenciador de pacotes Synaptic
• Monitorando a temperatura da CPU no Linux e Windows
• Conversão em massa de TIFF em JPEG
• Meu Wi-Fi parou de funcionar. E agora?
• Cópia de artigos da mídia para citação
• Lua, Júpiter e Vênus em ISO 1600
• Como se livrar do SPAM da Claro que te interrompe de 30 em 30 segundos
• Quantas pessoas cabem na Avenida Paulista?
• A batalha da Comunicação no Facebook
• O Aeroporto de Cláudio documentado no Google Earth
• O apagão do Facebook não será noticiado
• Blog, microblog e redes sociais
• Adeus ao Orkut
• Bookmark para encontrar um post “favorito” no Facebook
• Sincronização do Google Chrome
• Fotos em alta resolução no Facebook
• Sincronizando pastas de documentos entre Linux e Windows
• Dual-boot, Linux, Windows e Grub-customizer
• Listas, Grupos, Fóruns, Comunidades
• Mandar fotos por email para Grupos do Facebook
• Limitando emails de notificação do Facebook
• Conexão 3G pelo “chaveirinho” da TIM