Translate

segunda-feira, 27 de fevereiro de 2017

Quadro comparativo dos sistemas Linux instalados (2016-2017)

Quadro comparativo dos sistemas Linux mantidos para aprendizado

10 Jun. 2017 - A instalação do Arch Linux KDE, no último final-de-semana, teve o dom de lembrar os objetivos da brincadeira, — reduzir minha dependência de “decisões proprietárias”, — e representou um belo passo à frente.

Pela primeira vez, um sistema totalmente “comunitário” resolveu uma das tarefas mais renitentes, — navegar uma série de “Páginas” do Facebook (entre outras redes), 3 ou 4 vezes por dia, com direito a assistir os vídeos que interessarem, — sem que o velho hardware fique devagar-quase-travando.

27 Jun. 2017 - A alegria não chegou ao final do mês.

Para ficar “perfeito”, ainda falta conseguir rodar o Google Earth (sem placa aceleradora 3D) e rodar no Wine alguns velhos aplicativos, necessários ao aproveitamento do trabalho acumulado em 27 anos de arquivos digitais, — coisa que não era de se tentar logo na primeira semana. — Mas isso não é necessário todos os dias, e justifica carregar outro Linux, quando for o caso. Assim, foi possível trabalhar 7 dias seguidos, quase que apenas no Arch Linux KDE.

Experiências abortadas


Quadro comparativo dos sistemas Linux instalados até o início de Junho

Os bons resultados com Arch Linux tornaram dispensável manter o Manjaro e o Antergos, neste momento. É dispersivo, tentar aprender (e lidar com) coisas demais. — Além disso, o Antergos e o Sabayon tinham parado de funcionar (ambos na noite de 28 Maio, quanta coincidềncia), exigindo tempo e atenção para descobrir as causas. — O Fedora andava meio estagnado, sem muito tempo para pesquisar e torná-lo mais “usável”. — Enfim, uma segunda experiência com Mageia (“instalação clássica”) apresentava poucas vantagens, que justificassem aquela duplicação paralela.

Essas 10 partições (raiz + home) foram formatadas, para eliminar até mesmo as configurações. — Ficam as Capturas de tela, fotos, anotações e alguns arquivos TXT, para exame caso haja motivo.

Restrições ao “modo root”


Atalhos para Krusader em modo root, dentro do próprio Krusader

Não foi sonho, nem alucinação, — capturas de tela garantem que “Krusader - modo Superuser” (root mode) era um item normal no Menu do Kubuntu, do Debian testing, do KDE Neon e do Manjaro, pelo menos:

  • 2016-12-24_11-28-12_Kubuntu_Menu-root-Krusader
  • 2017-01-04_13-56-12_Manjaro_Krusader-root
  • 2017-01-12_18-16-30_Neon_Krusader-root-mode
  • 2017-02-07_19-16-01_Debian testing_Krusader-modo-root

Nos últimos meses, isso desapareceu do Menu do KDE Neon (talvez, ao ser reinstalado), — e do Manjaro (após alguma atualização).

Caminho existente no Linux Mint 18 KDE, desde Agosto 2016

No Linux Mint KDE, nunca vi “Krusader modo-root” no Menu, desde quando foi instalado, há cerca de 1 ano, — mas, dentro do Dolphin, pode-se clicar com o botão direito em uma pasta, e abri-la “como root”, — por enquanto:

  • 2016-08-26_17-09-43_Mint_Dolphin-abrir-pasta-como-root
  • 2016-12-21_12-04-45_Mint_Dolphin-abrir-boot-grub-como-Root

A rigor, não é uma diferença “entre distros”, mas entre as que se atualizam mais depressa, ou mais devagar. As mais “avançadas” recebem boas, — e más — novidades primeiro.

Há uma enxurrada de reclamações e pedidos de ajuda, — bem como 2 explicações principais: — (a) Seria uma “tutela” para evitar que novatos se machuquem, tipo um “cercadinho” para bebês; — ou (b) Foram bloqueados Kate e Dolphin por “kdesu”, como medida temporária, até que seja sanada uma brecha de segurança (previsão: final de 2017).

A explicação (a) causa revolta de uns, em nome da liberdade, — e defesa de outros, em nome de se fazer tudo por comandos, — mas parece ser lenda urbana ou, no mínimo, uma deformação da informação correta. Desde Fev. 2017, uma linha de código diz ao Kate e ao Dolphin que abortem, quando chamados por “kdesu”.

+#ifndef Q_OS_WIN
+    // Check whether we are running as root
+    if (getuid() == 0) {
+        std::cout << "Executing Dolphin as root is not possible." << std::endl;
+        return EXIT_FAILURE;
+    }
+#endif

Um teste com “kdesu”, — feito apenas no Arch Linux, — mostra que não carrega Dolphin, Kate, KWrite. O único que abre é o Krusader.

  • E no entanto, o KDE Neon retirou “Krusader - Superuser” de seu Menu. — Mas há várias outras coisas estranhas acontecendo no KDE Neon, — inclusive, um crash renitente do Konqueror, todas as vezes que é aberto. Pode ser só comigo.

Por enquanto, isso deixou de ser problema grave, enquanto se possa chamar “kdesu krusader”, — ou abri-lo como Usuário, e dentro dele ir ao menu “Ferramentas → Krusader em modo root”. — Isso é mais demorado, além de deixar 2 Krusader abertos, mas no curto prazo é uma alternativa. Para encurtar caminho, também se pode criar esse atalho na Barra de ferramentas.

Painel lateral do Konqueror


Ultimamente, também começou a desaparecer o painel lateral (F9) do Konqueror, — que existia no Kubuntu, no Mint, no Debian e no KDE Neon.

No KDE Neon, o desaparecimento foi notado após a atualização de 19 Dez. 2016, — que removeu “dolphin4”, entre outras coisas.

Depois, todos aqueles pacotes foram reinstalados. — Não houve conflito, — mas tampouco trouxe de volta o painel lateral.

No Mageia, Manjaro, Antergos, Sabayon, — e agora, no Arch, — o Konqueror já veio sem painel lateral (F9).

Atalhos no Gwenview


Após uma atualização massiva de KDE-apps (17.04.2-1) no Arch Linux, em 8 Junho, o atalho personalizado “Esc” deixou de funcionar, para sair do Gwenview. O atalho continua aplicado, — foi reaplicado etc., — mas não funciona mais.

Dois dias depois, uma atualização massiva de KDE-apps (17.04.1 para 17.04.2) produziu o mesmo problema no KDE Neon.

Índice


  • 10 Jun. 2017
  • Experiências abortadas
  • Restrições ao “modo root”
  • Painel lateral do Konqueror
  • Atalhos no Gwenview
  • 14 Mai. 2017
  • Linux Mint
  • Manjaro
  • Mageia 6 sta2
  • Grub, grubs
  • Por causa de umas questões paralelas
  • Março ~ Maio 2017
  • 13 Mar. 2017
  • 24 Fev. 2017
  • “Derivados” do Debian
  • Sistemas e tarefas
  • Escolha dos “não-debian”
  • Agosto 2016 ~ Fevereiro 2017
  • Posfácio
  • Não-debians [Menu]


14 Mai. 2017


Quadro comparativo dos sistemas Linux instalados, no final da tarde de 14 Mai. 2017
Quadro comparativo dos sistemas Linux instalados, no final da tarde de 14 Mai. 2017

Trabalhando dias seguidos no Linux Mint 18 KDE, um aviso na noite de 13 Mai. 2017 apresentou um festival de pacotes para atualizar, — 106, além de 11 novos, — e o resultado foi a passagem do KDE Plasma 5.8.5 para 5.8.6, e do KDE Frameworks 5.28 para 5.33.

Nada de tão espetacular, se você já tinha outros sistemas com essas (e até outras) versões mais “novas”, — ótimo antídoto contra ansiedade por novidades. — Você vê que novidades não são o prêmio-grande da loteria, o mundo continua girando, e versões “antigas” atendem muito bem suas necessidades.

Você mata a curiosidade, — e ainda aprende alguma coisa sobre outras distribuições Linux, — sem botar em risco sua “trabalhabilidade”.

Nesta semana, — pois não houve verificação diária, — Fedora, Manjaro e Sabayon também passaram do KDE Plasma 5.9.4 para 5.9.5.

Como o acompanhamento se tornou trabalhoso, deixam de ser registradas “correções” de Kernel, para simplificar.

Linux Mint


Atualizador “mintUpdate”, com a seleção mais adequada à integridade do Linux Mint
Atualizador “mintUpdate”, com a seleção mais adequada à integridade do Linux Mint

Após alguns transtornos na migração do Linux Mint 18 para 18.1, — que evidenciaram o quanto ele é fundamental para meu trabalho, — acabei reinstalando o Linux Mint 18 KDE e, desde então, o Synaptic foi abandonado, em favor do mintUpdate, que oferece a seleção mais adequada à manutenção da integridade do sistema, nas atualizações do dia-a-dia.

Não que o Synaptic pareça ter “culpa” por aqueles transtornos, — o upgrade foi feito pelo mintUpdate, — mas gato escaldado evita água fria.

Há tempos o Synaptic oferece 35 atualizações, que até hoje o mintUpdate não recomendou

O Synaptic continua em uso para instalação de novos pacotes (por ser mais prático), — e também para copiar e documentar o Histórico das atualizações feitas pelo mintUpdate, — porém há tempos ele oferece 35 atualizações que, até hoje, o mintUpdate não parece recomendar. Melhor deixar quieto, a menos que estude muito tudo aquilo.

Portanto, sigo ignorando essas 35 atualizações indicadas pelo Synaptic, — e o Linux Mint 18 KDE (reinstalado) segue funcional. — Um dia, isso terá de ser enfrentado (ou nunca), mas no momento não há motivo para caçar trabalho; muito menos, pressa em caçar confusão.

Manjaro


Removendo pacote com dependências problemáticas, que obstruía atualizações do Manjaro

Mais uma vez, o Manjaro consolidou a sensação de generosidade em problemas, — bem como em localização rápida de soluções, — gerando um aprendizado agradável.

Ao ser carregado, já trata de procurar atualizações, automaticamente, — é fácil perceber que isso está ocorrendo, e basta aguardar 1 ou 2 minutos. — Logo apresentou um festival de 380 pacotes.

Nas primeiras tentativas, usando a opção de deflagrar o processo a partir da notificação no Painel, não havia resposta.

Apenas abrindo o Octopi e mandando instalar as 380 atualizações pela barra inferior de sua janela, resultava em um diálogo, informando erro e perguntando se “deseja executar essa transação em um Terminal”.

Tentando pelo Terminal, informava não ser possível satisfazer às dependências de 1 pacote.

A busca pela expressão, — “Manjaro, falha ao preparar a transação (não foi possível satisfazer as dependências)”, — localizou ocorrências absolutamente iguais, em vários fóruns, logo no topo dos resultados, — e as respostas sugerem que isso costuma ser causado por desatualização do repositório tentado.

Encontram-se sugestões de editar o “/etc/pacman.d/mirrorlist”, — caso o primeiro repositório esteja com status “desatualizado”, — movendo outro repositório para o topo da lista.

Até pensei em tentar, mas (felizmente!) não encontrei modo de editar o arquivo com Kate ou KWrite, usando “sudo”, nem “su”, — e tampouco encontrei Dolphin / Krusader “as root” no Menu.

Faltava um desses 3 gerenciadores de arquivos, — e tentei instalar, na expectativa de que automaticamente gerasse uma entrada de “as root” em Menu → Sistema (já vi isso acontecer, em algumas distros), — mas o Octopi se declarou em greve, até que o problema fosse resolvido.

De qualquer modo, editar o arquivo de configuração dos Repositórios não seria um bom caminho, e analisando as imagens, acabou ficando claro que o australiano “manjaro.uberglobalmirror”, — que estava no topo do arquivo “/etc/pacman.d/mirrorlist”, — constava como “atualizado”, no Manjaro repository - Status of mirrors.

Portanto, substituí-lo por outro qualquer, escolhido “no olho”, não ia resolver nada, — e como existem dezenas de espelhos para escolher, o usuário que tente esse caminho arrisca perder horas e horas, copiando e colando, um após outro, até ficar maluco, — ou cometer algum erro, e piorar mais ainda a situação.

Felizmente, numa das 3 postagens sobre o Manjaro aqui no Byteria, estava registrado o caminho correto para “editar” o arquivo “/etc/pacman.d/mirrorlist”. — Trata-se de verificar o status de todos os repositórios, em busca dos mais rápidos no momento, com exclusão dos desatualizados:

sudo pacman-mirrors -g

Isso não resolveu o problema, — mas eliminou uma hipótese, poupando carradas de tentativas inúteis num caminho errado.

Por via das dúvidas, foi limpado o cache, — também não resolveu, mas tampouco podia fazer mal. — No mínimo, evita a ocupação crescente da partição de sistema com 1,2 GiB de pacotes baixados e já instalados.

A próxima sugestão tentada, — remover o pacote encrencado, — foi a que resolveu o problema.

Por algum motivo, — erro de digitação?, — o comando não deu resultado:

pacman -R gstreamer0.10-good-plugins

Foi tentado, então, removê-lo pelo próprio Octopi, — que gentilmente interrompeu sua greve e fez este imenso favor.

Depois disso, o Octopi consentiu em fazer a atualização, — não de 180 pacotes, mas de 187, — e todos foram felizes para sempre.

Ou, nem tanto, — havia outras 12 ou 13 atualizações do AUR, que nunca entendi como mandar instalar. — Com a remoção desse pacote + 1 dependência, caíram para 10 ou 11 atualizações.

Tentá-las, parece equivalente a tentar a perdição, — pisca um aviso em vermelho, de “Pacote sem suporte - Potencialmente perigoso!”, — e por enquanto, a opção é digitar “A” para abortar a operação. Pelo menos, até fazer alguma ideia do quê se trata, para quê serve etc.

Ainda que um “aprendizado” miúdo como esse não pareça levar a grandes coisas, é um modo tranquilo, — sem tomar tempo, — de aplainar um bicho-papão do imaginário sobre pacotes Arch etc.

Quando o causo começou a tomar tempo demais, — das 22:10 às 22: 50, — foi deixado de lado, até concluir as atualizações dos demais sistemas. Não sendo indispensável ao trabalho, o Manjaro poderia esperar essa atualização, se necessário, até outro final-de-semana. Bastava um asterisco no Quadro comparativo, e uma anotação no caderno, com a faixa horária das Capturas de tela, — de “2017-05-13_22-10-04_Ma.jpg” até “2017-05-13_22-49-57_Ma.jpg”.

Terminado o giro pelos outros 10 Linux, o problema voltou a ser examinado, e acabou resolvido, — de “2017-05-14_00-05-50_Ma.jpg” até “2017-05-14_00-44-11_Ma.jpg”.

Em algum momento, — antes? agora?, — voltou a funcionar a opção do Octopi de “executar em um Terminal”, que andava fora de combate, havia várias semanas.

Mageia 6 sta2


Primeira fase de uma atualização em 2 etapas, no Mageia

Mageia apresentou, de início, apenas 1 atualização, — urpmi, — e imaginei que, a partir dele, talvez decorressem outras atualizações. — Mera suposição de leigo, em vista de 2 ou 3 casos semelhantes.

E, de fato, tão logo concluiu essa primeira etapa, foram propostos outros 76 pacotes para atualização, — porém isso não levou a qualquer alteração perceptível do sistema, em relação ao status do dia 8.

Só no dia seguinte (14), houve uma atualização “normal”, — em “etapa única”, com 22 pacotes sugeridos, inclusive Kernel.

Também no dia seguinte (14), o Resumo semanal do Mageia Blog chamou atenção para as menções de “RC” e “pronto”, nas listas de discussão, indicando que o lançamento do Mageia 6 está próximo.

Grub, grubs


Correção manual do Grub do openSUSE, com Kwrite

Aproveitando o embalo do Sábado à noite, foi conectada a unidade SSD, carregados os outros 10 sistemas Linux, e atualizados, um após outro, até cerca de 0:48 do Domingo. — Em seguida, foi atualizado o Grub (controlado pelo openSUSE), para detectar um ou outro Kernel novo e gerar o novo Menu de inicialização.

O comando é utilizado “por extenso”, — não vem de fábrica nenhum script tipo “update-grub”:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Usar o Grub do openSUSE, — chamado a partir da trilha inicial (trilha MBR) do sdc, — é uma necessidade, enquanto não entender por que só o openSUSE consegue gerar uma entrada de Menu de inicialização capaz de carregá-lo.

Ou, até aprender como corrigir o Grub gerado pelos demais Linux, para que consiga carregar o openSUSE.

Até o momento, o Grub gerado pelo openSUSE exige 2 correções manuais, para conseguir carregar o Manjaro, e o KDE Neon reinstalado.

No caso do Manjaro, o Grub gerado pelo openSUSE precisa da seguinte correção manual, — desde sempre:

Nas linhas onde aparece:

ucode.img

Substituição nas entradas com o Kernel atual:

ucode.img /boot/initramfs-4.9-x86_64.img

Ou, nas entradas com o Kernel anterior:

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

No caso do KDE Neon User Edition, — instalado em 31 Mai. 2016, — o Grub gerado pelo openSUSE costumava funcionar perfeitamente, até o dia em que aquela instalação foi deletada por distração, há algumas semanas. Foi necessário, então, reinstalar o KDE Neon.

Porém, as atuais imagens ISO do KDE Neon parecem não se entender direito com meu computador, — embora ele não inclua nenhum hardware lançado há menos de 3 ou 4 anos, — e não consegui encontrar nenhuma ISO mais antiga para baixar (sim, tinha usado Pendrive; não gravei DVD, nem guardei a ISO antiga em HDD).

Por conta disso, agora o Grub gerado pelo openSUSE precisa ser manualmente corrigido, para carregar o KDE Neon.

Todas as ocorrências de:

root=UUID=XXXXXXX ro quiet splash $vt_handoff

Precisam ser globalmente substituídas por:

root=UUID=XXXXXXX ro nomodeset $vt_handoff

Obs.: - Inicialmente, a substituição era outra, — também funcionava (acho), — mas experimentei a opção acima, por algum motivo, e não me preocupei mais com isso:

root=UUID=XXXXXXX ro quiet splash nomodeset

A inclusão do UUID na substituição global evita afetar as entradas de outras distribuições Linux, que também incluem “ro quiet splash $vt_handoff”.

Tudo isso é mais fácil e rápido de fazer, do que de explicar, — mas não deixa de ser chato. — Um motivo a mais, para percorrer o circuito de atualização dos 11 Linux apenas 1 vez por semana, se tanto. Mais por curiosidade, do que por necessidade, — apenas 2 ou 3 são usados no dia-a-dia.

Pela manhã foram carregados os 11 sistemas, um após outro, — para documentar pelo KInfocenter as novas versões do Plasma, Frameworks, Qt e Kernel, — sem verificar o Quadro das “funcionalidades”.

Portanto, o Quadro comparativo é apenas aproximado, — não há como capturar 11 “realidades”, uma após outra, sem que alguma delas se altere durante o processo. — Tente levar 11 crianças ao Zoo.

Por causa de umas questões paralelas


Cabe deixar claro que não sou expert em coisa alguma, no Linux, — mero usuário, hesitante até em pretender ser “médio” fora do Kubuntu / Linux Mint / KDE Neon, — e, de fato, após 10 anos batendo cabeça, é só em 2 desses 3 que consigo fazer todo o trabalho.

É comum passar dias, semanas, sem precisar do CorelDraw, Dreamweaver ou MS Word, — para reutilizar trabalho acumulado na forma de arquivos digitais desde 1990, — mas, pela Lei de Murphy, é quando você está impossibilitado que a necessidade aparece.

Portanto, não vamos louvar demais o KDE Neon, — ficam Kubuntu LTS e Linux Mint 18 KDE.

No entanto, já instalei e usei o GoogleEarth no KDE Neon por quase 1 ano, antes de detonar o sistema (por simples distração), e nada sugere que não consiga reinstalar esse recurso, — principal substituto do AutoCAD, que em anos recente vinha sendo usado apenas para gerar mapas. — A falta de urgência em fazer isso mostra o quão tranquilizante é ter mais de 2 sistemas em paralelo (dualboot).

Bastou um upgrade (18 → 18.1) para deixar o Linux Mint com a língua de fora, durante alguns meses.

E bastou uma distração, para deletar um KDE Neon que, durante quase 1 ano, se mostrou estável e produtivo, — coisa que 3 imagens ISO e 2 reinstalações ainda não lograram alcançar outra vez.

Portanto, 1 sistema 100% funcional é pouco, 2 é bom, 3 já começa a dar trabalho, — mas, pela Lei de Murphy, quem tem 2 tem 1, quem tem 1 pode ficar sem nenhum. — Vale a pena ter 3, e não custa nada experimentar 5 ou 11, em busca de novas alternativas. De preferência, bem diferentes entre si, e todas afastadas das atuais.

Notar que todos os atuais “2 ou 3” dependem, direta ou indiretamente, da previsibilidade do tio Mark Shuttleworth, — vale dizer, não dá para repousar em serviço, — em especial, se você é apenas um “usuário médio”, e ainda por cima, sem capital para contratar assessoria urgente, de uma hora para outra. Sem aviso prévio.

Muito mais frequente, é ter de acessar o Facebook no Chromium, — não que o Firefox seja “pior” ou “melhor”; apenas, preciso manter os Bookmarks sincronizados e disponíveis nos vários sistemas, sem complicações de exportar / importar entre 2 browsers diferentes (sim, faço isso, às vezes).

Nesse aspecto, parece promissor que o Mageia e o openSUSE se mostrem capazes de enfrentar o recurso “Páginas” do Facebook (não me refiro ao Feed, Grupos ou Perfis), sem sucumbir à lentidão ou congelamento, — mas desanimador que isso venha associado à incapacidade de assistir vídeos. — Não é tão indispensável assistir vídeos, mas convenhamos que viver na precariedade não é o sonho de consumo de ninguém.

É curioso que o Debian (testing ou Jessie, tanto faz), o Manjaro e o Zesty Zapus se comportem de modo diametralmente oposto, — neles consigo assistir vídeos (inclusive no Feed, Grupos e Perfis do Facebook), mas sucumbem diante da sobrecarga representada pela simples navegação em “Páginas” do Facebook (mesmo sem tentar ver qualquer vídeo). — Isso talvez tenha fácil explicação, mas procurá-la não é tão urgente, enquanto puder dispor de 2 sistemas 100% funcionais, e um terceiro habilitado para 90% dos usos necessários.

Enfim, vale notar que inúmeras outras tarefas de uso diário, — Xsane, OCRFeeder / gImageReader, Gimp, Okular, Kamera, Kate / KWrite, LibreOffice, Chromium (para tudo mais), WhatsChrome, K3b, ScreenRuler / KRuler, pyRenamer / KRename, conversão PNG → JPEG, Dolphin / Krusader / Konqueror, busca avançada etc., — funcionam 100% bem, em todos os 11 sistemas instalados até agora, de modo que ao carregar o Antergos ou o Sabayon (os mais recentes e menos familiarizados) não é necessário sair correndo. Apenas, (ainda) são incômodos para trabalhar por longos períodos.

Março ~ Maio 2017


Quadro comparativo dos sistemas Linux instalados, em 8 Mai. 2017

xx

Quadro comparativo dos sistemas Linux instalados, em 25 Abr. 2017

xxx

Quadro comparativo dos sistemas Linux instalados, em 17 Abr. 2017

xxx

Quadro comparativo dos sistemas Linux instalados, em 31 Mar. 2017

xxx

13 Mar. 2017


Quadro comparativo dos sistemas Linux instalados, no final da tarde de 13 Mar. 2017

Com a instalação do Antergos e do Sabayon, carregar e atualizar, sucessivamente, os 11 sistemas deixou de ser tarefa para 40 ou 50 minutos.

No dia 13 Mar. 2017, por exemplo, alguns fatores contribuíram para que essa tarefa se prolongasse por mais de 4 horas, — das 13:50 até cerca das 18:00.

Ao final de tão longo período, é muito possível que o primeiro sistema a ser atualizado já tivesse novas atualizações disponíveis.

O Antergos só foi atualizado às 16:45, — o que pode ter contribuído para ser o único a apresentar Frameworks 5.32 nesse dia.

Após 20:10, voltei a carregar o KDE Neon, para concluir outras tarefas, e não apresentou novidades. — Mas no dia seguinte, logo cedo, acusou 167 pacotes atualizáveis, e também avançou para Frameworks 5.32.

Naturalmente, não dá para repetir a brincadeira todos os dias, — senão, é o feijão quem vai ficar desatualizado.

24 Fev. 2017


Quadro comparativo dos sistemas Linux instalados, com algumas diferenças de funcionalidade
Quadro comparativo dos sistemas Linux instalados, com algumas diferenças de funcionalidade

Com a instalação do Manjaro, openSUSE, Fedora e Mageia, — estranhos ao universo Debian / Ubuntu, já familiar, — acabou-se a moleza.

Ainda há espaços (no SSD externo) para instalar mais 3 sistemas, — e foram feitos preparativos para começar pelo TrueOS (antigo PC-BSD), — mas a brincadeira dá sinais de saturação.

Mageia 5, — instalação ainda não relatada

Os relatos da instalação e configuração do Manjaro e do openSUSE estão bastante incompletos, — qualquer avanço exige tempo para organizar centenas de prints, anotações, além de bastante leitura e aprendizado, para ser útil, — enquanto o do Fedora ainda se resume a 3 ou 4 tópicos isolados, e o do Mageia (5) 6 sta2 nem começou.

Além disso, as rotinas adotadas para usar, atualizar e registrar regularmente a experiência com os vários sistemas, agora consomem tempo excessivo, — sem falar no “processamento” posterior das observações, para consolidar o conhecimento adquirido.

“Derivados” do Debian


Enquanto isso, os “derivados” do Debian acumulam algumas questões a serem resolvidas.

Desde 5 Fev. 2017, o desenvolvimento do Debian 9 Stretch foi “congelado”, a caminho de se tornar o novo Debian “stable”, daqui a algumas semanas. No entanto, a atual instalação foi orientada para repositórios “testing”, — não “Stretch”, — na expectativa de que continue a evoluir. Mas o que significa isso, na prática, é o que cabe agora observar, para aprender. E cedo ou tarde, algumas opções terão de ser feitas. Ficar no “stable” ou seguir em frente? Talvez já tenha avançado demais, e a essa altura voltar a “stable” implique em algum downgrade. Qual a vantagem disso?

O KDE Neon User Edition, — instalado quase que no nascedouro, quando nada era claro para um leigo, — lançou sua versão LTS, em 9 Dez. 2016, fixado no KDE 5.8. Talvez coubesse uma escolha, naquele dia, — entre ficar no LTS, ou seguir em frente, — mas, agora, a instalação já está no KDE 5.9.2. Seria necessário reinstalar, pois não parece fácil fazer o downgrade (se é que é possível). No entanto, para todos os efeitos práticos, o KDE “rolling-release” tem se mostrado sólido o bastante, para liquidar qualquer “medo de mudanças”. De fato, até hoje se mantém muito mais “produtivo” do que o Zesty Zapus, por exemplo. Nenhum motivo real para reinstalar / retroceder à versão LTS.

O Kubuntu 17.04 Zesty Zapus, — instalado lá no início de seu desenvolvimento, — já lançou versões Alpha 1 e 2 (Janeiro), e Beta 1 (Fevereiro). E agora? Manter e aproveitar a onda de debates nos fóruns, ou pular para o início do 17.10? A ideia inicial era acompanhar a evolução do Kubuntu, para não topar despreparado eventuais surpresas do futuro 18.04 LTS. No entanto, o mais lógico talvez seja eliminá-lo, — e usar seu espaço para o TrueOS (ex-PC-BSD), — afinal, o Debian testing e o KDE Neon (entre outros) são mais do que suficientes para acompanhar a maior parte das surpresas que possam vir nos próximos Kubuntu.

Por fim, o Linux Mint, — único em que consigo realizar todas as tarefas necessárias (além do Kubuntu), — sofreu sequelas no upgrade do 18 “Sarah” para 18.1 “Serena”. Continua fazendo tudo, porém com uso excessivo de CPU (e algum aquecimento). É preciso descobrir a causa e a solução ou, em último caso, reinstalar. Mas reinstalar, com ou sem formatação da partição-raiz? O problema poderia estar em alguma configuração na “/home”, e qualquer reinstalação seria perda de tempo? Formatar a “/home”, e perder vários anos de configurações acumuladas? Reinstalar versão 18 “Sarah” ou 18.1 “Serena”? Nessa hora, até o Linux Mint 17.3 KDE, — testado de passagem, em sessão Live USB, — faz um aceno saudosista, só para complicar as ideias.

  • 28 Jan. 2017 - Upgrade, — e início do problema.
  • 1º Mar. 2017 - Foi reinstalado o Linux Mint 18.1 “Serena” KDE, — sem formatar a partição-raiz, — e o problema continuou.
  • 8 Mar. 2017 - O problema pareceu se resolver sozinho, após uma atualização “com erro” (vai entender), — pero, no mucho! — Alguma sequela ainda se manifestava.
  • 29 Abr. 2017 - Reinstalado Linux Mint 18 “Sarah” KDE, — com formatação da partição-raiz (não da /home). — Algum problema continuou, mas acabou cedendo perante algumas manipulações. Às vezes, algum problema ainda reaparece, mas não tem atrapalhado.

O Knoppix é um caso a parte, — curiosidade que vem desde os tempos do Kurumin, e que até meados de 2016 nunca tinha conseguido carregar. — Não é uma “distro”, no sentido comum da palavra. Não se destina a ser “instalado”, muito menos receber atualizações. É concebido para rodar como “Live CD / DVD”, ou “Live USB”, — e neste caso, a “instalação” no Pendrive permite configurar um arquivo ou partição de “persistência”, para não perder arquivos e configurações, de uma sessão para outra. — Uma vez compreendido isso (“na pele”), tornou-se minha ferramenta preferida para manutenção, particionamentos etc. (embora também tenha alguns Live CDs do GParted Live, Boot Repair Disk, Memtest86).

Sistemas e tarefas


Sistemas instalados em paralelo, desde 2007

A escolha desses sistemas vem do histórico pessoal, — começando pelo Kurumin, em fins de 2007, e Kubuntu a partir de 2009, — assim como as tarefas exigidas (tabuladas só as que apresentam alguma dificuldade em um ou outro sistema).

O “paralelismo”, — sistemas lado-a-lado (dual-boot / multi-boot), ao invés de máquinas virtuais, — também vem do histórico pessoal, pois no início era relativamente frequente “escangalhar” um sistema, por falta de conhecimentos. Ter um “estepe” era prudente, em casos de emergência.

Esse espaço reservado para um “segundo Linux” foi aproveitado para experimentar alternativas, — em especial, Debian (quase sempre KDE) e Linux Mint (Xfce, Cinnamon), — embora também tenha experimentado Ubuntu, Xubuntu, Big Linux e outros, que não duraram nem deixaram lembrança. [Obs.: o quadro acima foi simplificado. Na verdade, chegou a haver 3 sistemas instalados lado-a-lado, no início de 2009].

Por falta de conhecimentos e consequente dificuldade com as “diferenças”, só houve comparação mais sistemática a partir de 2015, quando no “segundo” espaço foi instalado o mesmo Kubuntu “principal”, — com a diferença de um ser 32bit, e o outro 64bit, — o que permitiu configurá-lo “exatamente igual”, até o último detalhe. Pela primeira vez, as configurações deixaram de ser um tanto vagas, coisas feitas 1 vez a cada 2 anos e logo esquecidas (apesar das anotações dispersas no “caderno de informática), para se tornarem alguma coisa efetivamente “mapeada”.

Depois disso, foi possível sistematizar também as diferenças entre o Kubuntu 14.04 e o Linux Mint Cinnamon 17.3, na primeira metade de 2016, — e abandonar definitivamente qualquer veleidade de usar outro ambiente, que não KDE.

A adoção do KDE também vem do histórico pessoal, — certa preferência, desde a década de 1990, por abundância de Memória RAM, que torna o computador mais “duradouro”, sem o custo de uma CPU de última geração e/ou upgrades frequentes. — O atual foi montado com 4 GB RAM, já vai para 8 anos (2009), e até hoje é mais do que satisfatório. Nenhum problema com KDE, nem qualquer necessidade de usar ambientes mais “leves”.

É possível que, se continuasse acompanhando a evolução do Windows, esta máquina já estivesse pondo a língua de fora, — e o uso exclusivo de Linux esteja prolongando seu valor de uso, — mas realmente não posso afirmar.

Em todo caso, fica evidente meu total desconhecimento de qualquer sistema que não fosse “derivado” do Debian, até o final de 2016.

Escolha dos “não-debian”


Sistemas Linux escolhidos entre os mais procurados no Distrowatch
Sistemas Linux escolhidos entre os mais procurados no Distrowatch

A ideia era selecionar sistemas de diferentes “troncos principais”, — mesmo que “derivados”, — para experimentar estruturas, o mais diferentes possível, umas das outras. O importante é que fossem razoavelmente afeitos ao usuário “comum”, — e de preferência, com bom número de usuários.

Mas logo ficou claro que esse conceito de “tronco” não faz muito sentido, — a menos que se estude o assunto com profundidade, abrangência, detalhamento e “tecnicalidade”, — coisas que fogem ao propósito de uma simples “aproximação inicial”, para começar a “ver como é”.

Slackware (30º no Distrowatch) pareceu pouco propício à brincadeira, — e nenhum “derivado” se mostrou atraente, — por isso ficou para o futuro.

OpenSUSE () faz parte de outro “tronco”, — apesar de certa relação, muito longínqua, com Slackware, lá nas origens de seu ancestral SuSE, há uns 20 anos.

Red Hat (47º) acabou “representado” em excesso, — pelo Fedora () e pelo Mageia (17º). — Talvez substitua um (ou ambos). Sem maiores conhecimentos, uma possibilidade parece ser o CentOS (11º). Ou, o próximo Mageia 6.

Antergos instalado. Não enfrenta bem o recurso “Páginas” do Facebook

Arch Linux (12º) pareceu pouco afeito a um usuário “comum”, — Manjaro () foi a escolha para começar. — Outra possibilidade é o Antergos (10º), cujo Live DVD infelizmente não carregou na primeira tentativa.

  • 3 Mar. 2017 - Live DVD Antergos carregou normalmente na 2ª e na 3ª vez, — com algumas diferenças, como se não apenas o Wallpaper fosse randômico. — A instalação de pacotes oferece “excesso de opções” (AUR), e foi adiada após as primeiras experiências, até aprender quais opções (dos mesmos pacotes) são mais recomendáveis.
  • 3 Jun. 2017 - Afinal, acabou sendo tão fácil instalar o Arch Linux, — por meio de 2 instaladores “gráficos”, — que fiz isso 2 vezes em 1 semana. E se mostrou tão bom, que o Manjaro e o Antergos puderam ser eliminados, para não complicar, no momento.

Sabayon instalado. Vem com Google Chrome (horrível). Não consegue enfrentar “Páginas” do Facebook

Gentoo (44º) também não pareceu muito adequado, por enquanto. — Talvez, o Sabayon (55º).

  • 4 Mar. 2017 - Instalado o Sabayon.
  • 6 Jun. 2017 - Eliminado o Sabayon.

Para lá das fronteiras do BSD, até o momento, o TrueOS (29º) parece o mais razoável para uma primeira aproximação.

Para quem não entende nada de nada, isso tudo já parece programa suficiente para mais 1 ano.

Muita coisa, entre os primeiros 50 colocados no Distrowatch, — lembrando que é um ranking de visitas, mero “interesse em saber mais”, — ainda não foi examinada, ou foi olhada apenas por alto.

Zorin e Deepin foram descartados por serem “derivados” do Debian e/ou do Ubuntu.

Elementary OS e Solus Budgie chegaram a ser testados em sessões Live CD / DVD, — em parte, para conhecer seus ambientes, — e descartados, por falta de interesse pessoal fora do KDE.

Agosto 2016 ~ Fevereiro 2017


Quadro comparativo dos sistemas Linux instalados, em 6 Fev. 2017

Registros sobreviventes dos primeiros Quadros comparativos, desde Agosto 2016.

Quadro comparativo dos sistemas Linux instalados, em 26 Jan. 2017

xx

Quadro comparativo dos sistemas Linux instalados, em 6 Jan. 2017

xx

Quadro comparativo dos sistemas Linux instalados, em 21 Dez. 2016

xx

Quadro comparativo dos sistemas Linux instalados, em 26 Ago. 2016

Posfácio


Esta postagem foi publicada em 27 Fev. 2017, com as informações do penúltimo “capítulo”, — e desde então foram acrescentadas atualizações, — bem como um resumo dos poucos registros anteriores (faltou preservar sucessivas versões da planilha).

Esses registros servem, principalmente, para:

  • Não esquecer o que já foi “descoberto”, — já ocorreu, 2 ou 3 vezes, de procurar solução para um problema, e o Google indicar uma página daqui mesmo, que nem lembrava mais;
  • Servir de “índice” para facilitar a busca de anotações no “Caderno de informática” (sim, ele continua muito útil), — bem como, localizar Capturas de tela (daí, os dias e horas).

Índice


  • 10 Jun. 2017
  • Experiências abortadas
  • Restrições ao “modo root”
  • Painel lateral do Konqueror
  • Atalhos no Gwenview
  • 14 Mai. 2017
  • Linux Mint
  • Manjaro
  • Mageia 6 sta2
  • Grub, grubs
  • Por causa de umas questões paralelas
  • Março ~ Maio 2017
  • 13 Mar. 2017
  • 24 Fev. 2017
  • “Derivados” do Debian
  • Sistemas e tarefas
  • Escolha dos “não-debian”
  • Agosto 2016 ~ Fevereiro 2017
  • Posfácio
  • Não-debians [Menu]

— … ≠ • ≠ … —

Não-debians


segunda-feira, 6 de fevereiro de 2017

Reparticionamento dos discos rígidos - Epílogo

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:

  1. Carregar o Knoppix (Pendrive 16 GB), para usar o GParted com total liberdade.
  2. Copiar (clonar) o Debian instalado em sda3 para a unidade SSD externa.
  3. Deletar sda3 e sda2, — fora de ordem.
  4. Recriar 2 partições, — na expectativa de que se tornariam sda2 e sda3, — na ordem certa.
  5. Copiar (clonar) o Debian de volta para a nova sda3.
  6. Fazer os ajustes necessários para o Debian e demais sistemas não estranharem nada.
  7. 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
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


xx

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



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

— … ≠ • ≠ … —

Ferramentas &tc.