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