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

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 particionamento dos discos rígidos

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.


quinta-feira, 2 de fevereiro de 2017

Fedora 25 KDE - Instalação e configuração

Fedora 25 KDE

Dúvida sobre particionamento, — aliada à falta de sessão Live, para pesquisar na web, — fizeram interromper a instalação, e só retomar 1 hora mais tarde.

Instalador e tutoriais empurram o usuário para a criação de uma partição /boot separada, — além de considerarem ponto pacífico que o usuário deseja usar LVM. — Por isso, a primeira instalação acabou abortada, até apurar direito essa estória.

O Installation Guide para o Fedora 25 contém pelo menos 4 páginas diretamente relacionadas a essas 2 questões:

5.4.8. Installation Destination
5.4.10. Manual Partitioning
5.4.10.6. Recommended Partitioning Scheme
5.4.10.7. Advice on Partitions

Porém, lendo e relendo essas 4 páginas, — e abstraindo vários tópicos misturados, além de links cruzados para questões paralelas, sem relação direta com a dúvida, — fica um sabor de omissão e de esquiva. Não se encontra uma única afirmação positiva da necessidade (ou não) de uma partição /boot separada, — muito menos, um porquê.

Igualmente, fala de LVM como se todos já soubessem tudo a respeito, e não desejassem outra coisa na vida. — Porém, chama atenção a reiterada ressalva de que a pasta /boot não pode estar em um volume lógico (ou sub-volume) LVM.

Isto acende uma hipótese que explicaria o porquê da partição /boot separada. — Em vários momentos, as ressalvas abrangem o par, — “não pode estar em um volume LVM, nem em um subvolume BtrFS”.

Isso lembra a preferência do openSUSE por BtrFS, — com seus 19 sub-volumes, inclusive 2 sub-volumes para subpastas em /boot/grub2/, — mas não para a pasta /boot, propriamente dita (com o initramfs e o vmlinux), que propunha colocar em uma partição “tradicional”, separada.

Afirmações positivas e claras, mesmo, só fui encontrar no artigo “Disk partitioning in Fedora”, de Bruce Byfield, — um texto não-engajado no LVM, nem no particionamento tradicional, — e muito menos, a favor ou contra as opções do Fedora.

Livre da “obrigação” de ensinar “tudo”, — portanto, sem indigestão de assuntos paralelos, — o artigo dá o resumo da ópera, em especial nos tópicos necessários para fazer as opções imediatas e retomar uma simples instalação do Fedora 25 KDE:

  • Fedora suporta tanto o particionamento “tradicional”, quanto gerenciamento de volumes lógicos (LVM). Qual você deveria usar, é assunto de guerra santa, mas o Fedora adota LVM como padrão, “provavelmente” porque permite partições remotas, tornando-o atrativo para servidores e redes.
  • LVM oferece a vantagem de redimensionamento rápido. Partições tradicionais tomam mais tempo para alterar, mas são mais robustas, — se uma partição tradicional se corrompe, outras não são necessariamente afetadas, — enquanto o colapso de uma partição LVM pode levar ao colapso geral.
  • Raiz (“/”) e Swap são as 2 únicas partições indispensáveis. — Se você não criar nenhuma outra, todas as pastas do sistema serão alojadas na Raiz.
  • Você tem a opção de criar partições separadas para outras pastas do sistema, — o que pode protegê-lo em caso de ataques.

Era o que precisava saber, para prosseguir com a instalação, — sem fazer primeiro um PhD, — e deixar o estudo para a fase do relato, já com o Fedora 25 KDE funcionando, para observar e testar algumas dicas.

Montagem automática de partições


Montagem automática de partições pelas Configurações do sistema (KDE)

Montar automaticamente um punhado de partições adicionais, — este foi o maior desafio encontrado após a instalação do Fedora, — e retardou as configurações por mais 1 dia.

Por “partições adicionais”, refiro-me às que não fazem parte do sistema, — partições de outros sistemas, outras partições de documentos etc., — mas que precisam estar montadas desde o início da sessão, para o Conky exibir o espaço ocupado.

No Kubuntu, no Linux Mint KDE e no KDE Neon, basta marcar as partições desejadas em:

Menu → [Sistema, ou Configurações] → Configurações do sistema → Hardware → Armazenamento removível → Dispositivos removíveis
Mas isso é apenas uma interface gráfica, que traduz as opções do usuário em comandos e parâmetros, gravados em arquivo-texto, — como tudo, do Linux, — em algum lugar da “árvore” de arquivos e pastas, na partição de sistema (raiz).

Por trás dessa interface gráfica, o que existe são comandos udisks, — os mesmos usados pelo Dolphin, — de modo que o caminho (path) de montagem é padronizado, — /media/$USER/, em alguns sistemas; ou /run/media/$USER, em outros (regra modificável em /etc/udev/rules.d/99-udisks2.rules).

No Debian KDE, isso não funciona, — provavelmente, pelo mesmo motivo que não funcionou no Fedora, — mas seu Gerenciador de discos (Disk Manager) mostrou-se uma ótima interface gráfica para resolver a questão, inclusive com montagem instantânea, — muito melhor do que o Discos (gnome-disk-utility), — e com isso, não foi necessário aprender mais.

Gerenciador de partições do KDE edita pontos de montagem, grava em /etc/fstab, — e não consegue montá-los

O que estes 2 fazem, é gerar e gravar entradas no arquivo /etc/fstab, — e tentei fazer isso no Fedora, seja pelo Discos (instalado só para isso), seja pelo Gerenciador de partições do KDE (KDE Partition Manager).

Em princípio, não gosto do Discos, por misturar ações inocentes (montar partições, editar pontos de montagem) com ações potencialmente desastrosas (deletar partição, formatar), — mas acaba sendo melhor do que editar manualmente o arquivo /etc/fstab. — Se você edita à mão e não dá certo, você perde horas imaginando mil erros dos mais variados tipos, ao passo que uma interface gráfica exclui erros de digitação, de atenção e de imaginação criadora, pois segue padrões pré-estabelecidos.

Porém, o Gerenciador de partições do KDE não conseguiu montar, — por não existir o ponto de montagem definido nele mesmo (digitados manualmente, mas segundo padrões já vistos em vários sistemas). — Será que faltava reiniciar, para fazer efeito?

Fedora não carrega, porque udisks não tem permissão para montar partições adicionais do /etc/fstab

Nos 2 casos, ao reiniciar o computador, o resultado é que o Fedora simplesmente já não carregava.

You are in emergency mode. After logging in, type “journalctl -xb” to view system logs, “systemctl reboot” to reboot, “systemctl default” or “^D” to try again to boot into default mode.
Forneça a senha de root para manutenção
(ou pressione Ctrl-D para continuar):

Examinar os logs do sistema não trouxe qualquer inspiração, — pelo menos, até a linha nº 1.863, — e ainda faltava seguir inúmeros conselhos exibidos nessas 1.863 linhas, de examinar outras 1.001 coisas, talvez igualmente intermináveis (e remetendo a outras 999 coisas).

No emergency mode do Fedora, poderia usar vi /etc/fstab para desabilitar a entrada e seguir com o boot

Digitando um simples “reboot”, foi possível carregar outro sistema (openSUSE), para desabilitar a entrada do /etc/fstab que causava o problema, e continuar pesquisando, — até descobrir que o obstáculo estava em um emaranhado de “regras” ou “políticas”, — diferentes das que vigoram no Debian, por exemplo.

Até onde é dado a um leigo perceber, parece que criar ponto de montagem exige poderes de nível 1.300-e-alguma-coisa, mas udisks só alcança 1.100-e-lá-vai-pedrada, — ou será o contrário? — Por isso, o que no Debian acontece com naturalidade, no Fedora exige autorização por escrito (digamos assim).

É muito possível que essa burocracia reforçada, para montar partições adicionais no Fedora, derive de sua conformação ao uso de volumes e sub-volumes LVM.

Em tempo - Na verdade, não era necessário reinicializar o computador, para testar o /etc/fstab, — bastava um comando simples. — Nada como problemas, para aprender mais.

“… até descobrir”, é um modo de dizer, — nem tudo que reluz é ouro. — Por mais que parecesse fazer sentido, só um teste poderia confirmar ou descartar.

Me limitei a criar o arquivo “/etc/polkit-1/rules.d/90-udisks2.rules”, — sugerido no 4º link (abaixo), — copiar da página, e colar nele o conteúdo:

// Allow udisks2 to mount devices without authentication
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.udisks2.filesystem-mount-system" || action.id == "org.freedesktop.udisks2.filesystem-mount" || action.id == "org.freedesktop.udisks2.filesystem-mount-system-internal") { return polkit.Result.YES; } });

Depois de 24 horas, montagem automática de partições no Fedora solucionada em 10 minutos

Desse momento em diante, todas as partições marcadas nas Configurações do sistema passaram a ser montadas automaticamente, no início da sessão, — e nunca mais foi pedida senha, nem de Root, nem de Usuário Administrador.

Só então, foi possível avançar com várias outras configurações, — mais ou menos paradas desde a véspera, por exigirem montagem frequente de partições adicionais para examinar outros sistemas Linux, consultar anotações etc.

Depois de pesquisar desde a véspera, a solução foi aplicada em 10 minutos, — tempo gasto para conferir links relacionados. — Depois que se encontra a palavra-chave, tudo parece óbvio.

Pistas - Chegaram a ser consultadas apenas algumas páginas. — Demorado, foi chegar a elas (entre centenas de outras), pesquisando “Fedora automount mountpoint” etc., — até descobrir que a palavra-chave era “polkit”:

  1. Mount NTFS partition on-demand without password?
  2. Fedora KDE: Automount NTFS Partition at Login
  3. Bug 1318473 - Can't add parttitions to fstab
  4. montar partição local on demand como usuário regular
  5. pklocalauthority

No mato sem Grub


xx

Wallpaper


Goiás “Velho”, em foto de Adelano Lázaro

Foto de Goiás “Velho”, por Adelano Lázaro.

O nivelamento foi feito pelo prumo dos elementos verticais, com ScreenRuler “sempre no topo”

A edição no Gimp limitou-se a um rotacionamento de -1,30º, para acertar o nivelamento; e em seguida, corte das bordas inclinadas.

O nivelamento foi feito pelo prumo dos elementos verticais, com ajuda do ScreenRuler “sempre no topo”, para não ser ocultado pelo Gimp durante o trabalho.

— … ≠ • ≠ … —

Não-debians