Translate

quarta-feira, 15 de março de 2017

Montagem automática de partições adicionais em distros Linux

Antergos uptime 1min2 0seg, com 25 partições adicionais montadas automaticamente

A montagem automática das partições “adicionais”, — que não fazem parte de cada “sistema”, — pode ser feita de várias maneiras:

1) No Plasma KDE (meu ambiente preferido), primeiro tento pelo System settings, — mas isso só funciona, se a distro não exigir senha.

2) Nos casos em que isso não é suficiente, crio um arquivo de configuração que autoriza a montagem de partições adicionais sem pedir senha.

3) Só em último caso, recorro ao arquivo /etc/fstab.

Índice


  • Manjaro
  • Antergos
  • Udisks2
  • Polkit-1
  • openSUSE
  • Fedora
  • Sabayon
  • Mageia
  • Debian
  • Arch Linux
  • Observações

Manjaro


Montagem automática de partições “adicionais” pelas Configurações de sistema do Manjaro KDE

A montagem automática não apresentou problema algum no Manjaro (1º Jan. 2017), — a primeira distro “não-debian” que experimentei, a partir desse ano. — Bastou marcar as partições “adicionais” nas Configurações do sistema (KDE), e desde então, elas são automaticamente montadas no início de cada sessão:

System settings → Removable storage >> Removable devices

Nesse aspecto, o Manjaro se comportou exatamente como as distribuições que já conhecia, — o Kubuntu, o KDE Neon e o Linux Mint KDE, — nos quais, basta isso, para obter a montagem automática.

Antergos


Uso do daemon udisks2 na montagem automática de partições “adicionais”

Embora baseado no Arch, — tal como o Manjaro, — o Antergos apresentou outro comportamento, e exigiu destrinchar algumas coisas nas entranhas do Linux.

Udisks2


Por trás dessa configuração feita pelo KDE, “trabalha” o daemon udisks2, — o mesmo utilizado pelo Dolphin, por exemplo, para montar uma partição “sob demanda” (ao clicar no painel lateral).

Por isso, o caminho (path) para o “ponto de montagem” das partições é igual nos 2 casos, — e pode ser alterado por algumas regras em:

/etc/udev/rules.d/99-udisks2.rules

# UDISKS_FILESYSTEM_SHARED
# ==1: mount filesystem to a shared directory (/media/VolumeName)
# ==0: mount filesystem to a private directory (/run/media/$USER/VolumeName)
# See udisks(8)
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{UDISKS_FILESYSTEM_SHARED}="1"

Polkit


Criação do arquivo “/etc/polkit-1/rules.d/99-udisks2.rules” no Antergos

No Antergos, ao clicar em uma partição na barra lateral do Dolphin, é solicitada senha de Root, — o que não é natural, ao logar como usuário, — e a sessão fica pendente de ação manual, antes que o ambiente esteja realmente pronto para o trabalho.

Ao procurar ajuda, em casos assim, é muito comum receber a sugestão de editar o arquivo “/etc/fstab”, — e acrescentar nele 1 linha para cada partição “adicional” que você queira montar automaticamente no início da sessão.

Embora não goste dessa alternativa, já recorri a ela, — de preferência, usando o “Discos” (gnome-disk-manager), ou o “Gerenciador de discos” do Debian, como “interfaces gráficas”. — Você efetua “escolhas”, e eles geram as linhas necessárias no “/etc/fstab”, sem errinhos bobos de digitação.

Mas não encontrei esses aplicativos no Menu do Antergos, nem nos seus repositórios, — e acabei por testar uma alteração de “política”.

Em resumo, trata-se de criar o arquivo “/etc/polkit-1/rules.d/99-udisks2.rules”, e colar nele o conteúdo sugerido, — para habilitar a montagem de partições sem a exigência da senha de Root:

// 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; } });

Feito isso, a montagem automática de todas as minhas partições “adicionais” passou a ser feita, sem necessidade de 20 ou 25 linhas adicionais no arquivo “/etc/fstab”.

openSUSE


Particionador do YaST2 também serve como “editor” do arquivo “/etc/fstab

No openSUSE (17 Jan. 2017) não adiantou recorrer às Configurações do sistema (System settings) para obter a montagem automática de partições “adicionais”.

Embora não conhecesse o openSUSE, foi relativamente fácil encontrar uma solução provisória, — graças às pesquisas anteriores para lidar com essa questão no Mint 17.3 Cinnamon (Jan. 2016) e no Debian (Jun. 2016).

De início, o “Particionador” do YaST2 foi usado com o mesmo objetivo do “Discos” e do “Gerenciador de discos”, — editar o arquivo “/etc/fstab”, mediante opções em uma interface gráfica, — porém de um modo bem mais eficiente e detalhado, com riqueza de parâmetros.

30 Mar. 2017 - Encontrei tempo para pesquisar e testar uma solução definitiva da montagem automática de partições adicionais no openSUSE, — usando udisks / polkit, — e finalmente eliminado o uso do “/etc/fstab” para esta finalidade.

Dessa vez a receita teve de ser um pouco diferente, — criar um arquivo “/etc/polkit-1/rules.d/10-udisks2.rules”, — pois um arquivo começando por “99” seria lido após outro já existente, iniciado por “90”, e cujo conteúdo preferi não alterar, sem estudar primeiro.

Fedora


Fedora não carregava mais, após a edição do arquivo “/etc/fstab

O Fedora (31 Jan. 2017) rompeu o dualismo “udisks2” vs. “/etc/fstab”, — nenhum dos dois funcionou, — e finalmente exigiu pesquisar além deles, até descobrir a existência uma “terceira via”.

Descartado o recurso puro e simples ao “udisks2”, a primeira tentativa foi usar o “Gerenciador de partições do KDE” (KDE Partition Manager), — porém ele não consegue montar as partições, por não existirem os pontos de montagem. — Ao que parece, ele não os cria.

Outra tentativa foi instalar e usar o “Discos” (gnome-disk-utility), — encontrado nos repositórios, — para resolver a montagem automática de partições “adicionais”.

Nos 2 casos, a edição efetuada por eles no arquivo “/etc/fstab” deixou o Fedora “incarregável”, — entra em “Emergency mode”, pedindo senha Root para manutenção.

O melhor que se pode fazer, nessa hora, é des-editar o “/etc/fstab”, usando o “vi” ou o “nano”, para “comentar” todas as linhas causadoras do desastre.

  • Em resumo, colocar “#” no início de todas as linhas encarregadas de montar as partições “adicionais”, — para que o Fedora volte a carregar normalmente. — Voltamos, então, ao ponto de partida.

Ou, talvez, criar os pontos de montagem indicados no “/etc/fstab”, — mas, como não sabia se isto resolveria o problema, — o caminho mais simples foi disparar um “reboot” e ir para outro sistema, pesquisar mais.

Encontrei a solução “polkit-1”, e o Fedora carregou normalmente, — com as partições e pontos de montagem indicados no “/etc/fstab”.

1º Fev. 2017 - Encontrei a solução definitiva, com alteração ou criação do arquivo “/etc/polkit-1/rules.d/90-udisks2.rules”, — e finalmente dispensada a alteração do “/etc/fstab” (totalmente “limpado” em 7 Fev., após conferir que tudo estava Ok).

Considerando meu total desconhecimento de Fedora, a solução definitiva em cerca de 24 horas foi super-rápida.

Sabayon


Copiando “99-udisks2.rules” do Antergos para o Sabayon, no Krusader (modo Root)

A montagem automática de 4 partições “adicionais” foi habilitada nas Configurações do sistema (System settings) do Sabayon (4 Mar. 2017), — porém não funcionou.

17 Mar. 2017 - Para testar o procedimento mais simples, foi copiado o arquivo “/etc/polkit-1/rules.d/99-udisks2.rules” do Antergos para o Sabayon, — usando o Krusader (modo Root).

Feito isso, bastou carregar o Sabayon para confirmar o bom resultado, — dispensando usar 20 ou 25 linhas no “/etc/fstab”.

Mageia


Montagem automática de todas as partições habilitadas pelo udisks2, ao carregar o Mageia 6 sta2

A princípio, a mera configuração de montagem automática pelo “System settings → Removable devices” também não produziu qualquer efeito no Mageia 5 (14 Fev. 2017).

Por isso, utilizei o “Centro de Controle Mageia” para definir as partições “adicionais” a serem montadas, — um modo de usar interface gráfica para “escrever” no “/etc/fstab”, sem cometer erros bobos de digitação.

Cópia do arquivo “/etc/polkit-1/rules.d/99-udisks2.rules” do Sabayon para o Mageia

Ao substituí-lo pelo Mageia 6 sta2 (20 Mar. 2017), fiz o teste de simplesmente copiar o arquivo “/etc/polkit-1/rules.d/99-udisks2.rules” do Sabayon, — usando o “Krusader as Root”, — e bastou reincializar o computador para os comandos udisks2 definidos pelo pelo “System settings → Removable devices” fazerem efeito (21 Mar.).

Debian


Documentando a montagem automática de partições adicionais nas distribuições Linux instaladas

8 Mai. 2017 - O Debian ficou sendo a exceção: — Nunca consegui que funcionasse a “autorização” para montagem sem senha. — Claro, a causa da “dificuldade” pode não estar no Debian, mas entre a cadeira e o teclado.

Já fiz algumas experiências no Debian, mas a estrutura da pasta “/etc/polkit-1” é um pouco mais complicada.— Convém estudar com calma, para não sair mexendo à toa:

localauthority
10-vendor.d
20-org.d
30-site.d
50-local.d
90-mandatory.d
localauthority.conf.d
50-localauthority.conf
51-debian-sudo.conf
nullbackend.conf.d
50-nullbackend.conf

Infelizmente, as buscas no Google também não retornaram qualquer solução dentro do “padrão” desejado, — e continuei usando o /etc/fstab para a montagem das partições extras, — através do aplicativo “Discos”, que facilita a tarefa, por meio de opções na interface gráfica.

Arch Linux


Testando no Arch Linux a mesma solução udisks2 aprovada no Antergos

3 Jun. 2017 - Testei a mesma solução usada no Antergos, — criar um arquivo “/etc/polkit-1/rules.d/99-udisks2.rules”, com o mesmo conteúdo, — e resolveu de imediato.

O Arch Linux foi instalado por volta das 14h; — o arquivo de configuração foi criado às 21:47, usando o Dolphin em modo root do openSUSE; — e às 21:50 o Arch Linux já carregou com todas as partições adicionais montadas.

Observações


Remoção do Fedora, Manjaro, Antergos, Sabayon, após instalar o Arch Linux

Instalar, configurar e aprender a lidar com 6 distribuições Linux que até então não tinha visto nem de longe, — Mageia, openSUSE, Fedora, Manjaro, Antergos e Sabayon, — era coisa para fazer com um pouco mais de calma e vagar.

De preferência, 1 de cada vez, para não encavalar centenas de capturas de tela, arquivos em TXT, anotações em caderno etc., — com inevitável demora no posterior levantamento, filtragem e organização de inúmeros pequenos relatos, — até o ponto em que detalhes começam a ser esquecidos e, depois de certo tempo, resta uma tremenda barafunda para desemaranhar.

8 Jun. 2017 - Os ótimos resultados obtidos no Arch Linux KDE tornaram dispensável manter o Manjaro e o Antergos, — que, após um bom tempo, continuavam sem atender às necessidades de trabalho.

Além disso, o Antergos e o Sabayon deixaram de funcionar no dia 28 de Maio, — por motivos que não chegaram a ser investigados, — e o Fedora também não oferecia perspectivas de se tornar muito útil para as principais tarefas do dia-a-dia.

Para simplificar a vida, estes 4 sistemas foram deletados, — assim como um 2º Mageia, — com as respectivas partições “/home”.

As 10 partições formatadas mantêm os mesmos rótulos, — Linux6, Linux8, Linux10… Linux12, Home6… Home12, — e continuam configuradas para montagem automática nos 7 sistemas restantes.

Desse modo, basta comentar (“#”) as linhas do Conky referentes a essas partições vazias, para deixarem de ser exibidas, — e ficam bem à mão, no caso de outras distros serem instaladas nelas.

— … ≠ • ≠ … —

Não-debians


quinta-feira, 9 de março de 2017

Transição do Manjaro (rolling-release) para 17.0

Manjaro antes e depois do upgrade

Na maior tranquilidade, — sem fanfarra e sem foguete, — quase ia passando desapercebida a transição do Manjaro 16.10.3 para 17.0.1, no dia 6 Mar. 2017.

Ou do release “16.10.1”, conforme o “/var/log/pacman.log”:

[2017-03-06 12:59] [ALPM] upgraded manjaro-release (16.10-1 -> 17.0-1)

Uma “atualização” comum, corriqueira, dessas que se fazem todos os dias, — sem necessidade de avisos, advertências, nem cuidados especiais.

Só no outro dia, — quando o lançamento da nova versão foi noticiado no Distrowatch, — me dei conta de que o Grub* agora indicava “Manjaro 17”, e que no Conky a identificação “Fringilla” foi substituída por “Gellivara”.

* Para simplificar, em momentos mais calmos são carregados e atualizados os vários sistemas Linux, sucessivamente, e por fim é atualizado o Menu de inicialização (Grub), para dar acesso às eventuais mudanças de Kernel. O Manjaro só voltou a ser carregado 2 dias depois mas, embora o Kernel permanecesse o mesmo, o Menu de inicialização refletiu a mudança do título para “Manjaro 17”.

Para um histórico mais abrangente:


Novidades


Notificação de “83 atualizações disponíveis”, no Manjaro. Ação oferecida: “Atualizar sistema”
Notificação de “83 atualizações disponíveis”, no Manjaro. Ação oferecida: “Atualizar sistema”

Em se tratando de uma distribuição rolling-release, talvez não fosse mesmo de esperar música de banda, bandeirolas e foguetório.

E é possível que o upgrade tenha menos a ver com impactos imediatos, — pelo menos, para quem vinha atualizando regularmente o sistema, — e mais com o que virá daqui por diante.

De mais visível, seu KDE evoluiu de 5.9.2 para 5.9.3, — embora várias outras novidades tenham sido anunciadas:

  • We updated the stock kernel to linux49 4.9 LTS
  • We updated the Xorg-Stack to v1.19 series
  • We updated KDE to its latest components: Plasma 5.9.3, Apps 16.12.3, Framework 5.31.0
  • We enhanced and improved our Manjaro Tools & Profiles
  • MHWD we adopted a more efficient way to handle libglx binaries
  • Some of our themes got updated and new got designed

Kernel, à parte


Gerenciamento de Kernel, no Menu K → Configurações → Manjaro settings manager → Kernel

Na prática, nem o Kernel mudou, — pois isso é gerenciado à parte, conforme a opção de cada usuário.

E o fato de o Kernel 4.9 LTS não oferecer “Registro de alterações”, — nem qualquer indicação de “Recomendado”, — não anima um iniciante a mexer com isso, por enquanto. Para que?

Outras novidades anunciadas, também merecem um desconto, — Framework 5.31.0, por exemplo, já estava instalado desde muito antes. — O que de fato mudou, conforme o pacman.log, foi:

[2017-03-06 12:59] [ALPM] upgraded kio (5.31.0-1 -> 5.31.0-2)

Cabe verificar outros pequenos detalhes como esse, — ou apenas ser feliz.

Mensagens de erro


Mensagens de erro no início da atualização

O que de fato chamou atenção, — e talvez a tenha desviado da novidade, — foi uma sucessão de mensagens de erro, acusando falta de resposta do Mirror brasileiro linorg.usp.br (se é que entendi o que se passou), no caso de inúmeros pacotes.

Porém, foi constatado que o Chromium navegava normalmente. — Além disso, muitos outros pacotes foram baixados sem mensagem de erro, — e no final o Octopi emitiu mensagem de “sucesso”, mudando a notificação do Painel, de vermelho para amarelo (só atualizações do AUR).

Para todos os efeitos, portanto, as atualizações se completaram com sucesso.

Com todas as demoras de resposta (ou falta de) por parte do linorg.usp.br, o processo durou 22 minutos, — das 12:37 às 12:59.

Uma recente atualização, de tamanho mais ou menos semelhante (87 pacotes), em 22 Fev. 2017, durou 15 minutos, — das 22:26 às 22:41.

Outra atualização, numericamente bem maior (203 pacotes), em 2 Fev. 2017, durou 13 minutos, — das 11:52 às 12:05.

Prioridade dos Mirrors


Arquivo /etc/pacman.d/mirrorlist, gerado conforme o menor tempo de resposta

Terminada a novela do Mirror, — e sem muita segurança de que a atualização se tivesse completado de modo 100% católico, — procurei um meio de escolher outro Mirror. Mas, não é assim que as coisas funcionam.

O comando “sudo pacman-mirrors -g” sonda todos os Mirrors do mundo, — para o Brasil, só está configurado o da USP, — e atualiza a lista, por ordem crescente do tempo de resposta.

Arquivo “/etc/pacman.d/mirrors/Brasil”:

[Brasil]
Server = http://linorg.usp.br/manjaro/$branch/$repo/$arch

Arquivo “/etc/pacman.d/mirrorlist”:

## Manjaro Linux repository mirrorlist
## Generated on 09 March 2017 16:22
##
## Use pacman-mirrors to modify
##

## Country       : Brasil
## Response time : 0.198
## Last sync     : 18:43h
Server = http://linorg.usp.br/manjaro/stable/$repo/$arch

## Country       : United_States
## Response time : 0.443
## Last sync     : 18:45h
Server = http://mirror.dacentec.com/manjaro/stable/$repo/$arch

## Country       : Ecuador
## Response time : 0.450
## Last sync     : 18:43h
Server = http://mirror.cedia.org.ec/manjaro/stable/$repo/$arch

## Country       : Netherlands
## Response time : 0.482
## Last sync     : 18:44h
Server = http://ftp.nluug.nl/pub/os/Linux/distr/manjaro/stable/$repo/$arch

... (etc.)

xx

— … ≠ • ≠ … —

Não-debians


domingo, 5 de março de 2017

Sabayon (Gentoo) - Instalação e configuração

Sabayon (Gentoo) após “atualização 2 disponíveis”, — que levou 2h 30min, talvez por inexperiência

As principais observações sobre o Sabayon 16.11 KDE (amd64), — no que difere dos demais sistemas Linux já instalados, — referem-se ao gerenciamento de pacotes e atualizações.

Vale notar que esta é uma experiência sem estudo prévio sobre Gentoo ou Sabayon, — trata-se de “aprender fazendo”, — onde mais vale o gosto de “ver” e “brincar”, do que qualquer (suposta) “obrigação”.

  • Essa “brincadeira” (absoluta “falta de pressa”) é possível porque o Kubuntu 16.04 LTS e o Linux Mint 18.1 KDE garantem o “ambiente de produção” para todas as tarefas necessárias. Além deles, o KDE Neon User Edition e o openSuSE também atendem às tarefas mais frequentes no dia-a-dia. — Portanto, basta reiniciar o computador, escolher o sistema da hora, — e mais tarde, voltar ao Sabayon para seguir brincando.

Ainda falta a montagem automática das partições “adicionais”, — e depois, adaptar o “~/.conkyrc” para exibi-las, — uma vez que, no Sabayon, não basta marcá-las em “K Menu → Configurações do sistema → Hardware → Armazenamento removível → Dispositivos removíveis”.

É provável que essa montagem automática se resolva pelo arquivo “/etc/fstab” (como no Debian e no openSuSE), e / ou pela configuração de alguma “política” (“polkit”, como no Fedora)
.

••• Ver “Montagem automática de partições adicionais” - (adiante).

É claro que houve alguma pesquisa e leitura, — em especial nesses 3 pontos fundamentais:

  • Sua escolha, — porque Sabayon pareceu a melhor opção para a experiência inicial de um leigo, na área do Gentoo.
  • Alguma leitura básica sobre sistema Portage de gerenciamento e instalação de pacotes (Gentoo), e mais especificamente Entropy, equo etc. [Viva o Linux, Sabayon]
  • Confirmar que, — nessa primeira aproximação, — poderia deixar de lado coisas como LVM, BtrFS, XFS etc., além de dispensar qualquer (suposta) necessidade de partição “/boot” separada. — A instalação foi feita unicamente com partições “/” (raiz) e “/home”, — ambas “tradicionais”, em sistema de arquivos ext4, — além de 1 partição Swap.

ISO e Live DVD (I e II)


Mensagem de erro quilométrica, perto do final da 1ª tentativa de instalação do Sabayon

A imagem ISO do Sabayon 16.11 KDE (amd64) foi baixada e verificada por md5sum em 3 Mar. 2017.

Por distração, um primeiro DVD acabou sendo gravado pelo K3b na velocidade 16x (4 Mar. 2017).

Por isso, no Menu de Boot, foi usada a opção “Check disk for defects”, que terminou com uma mensagem positiva, — “All fine, baby, the Live System is healthy”, — apesar de outras mensagens de “No iSCSI initiator found” e de “Sorry, but keyboard mapping br is invalid”.

Depois da verificação, ele reiniciou e foi carregada a sessão Live DVD, — que tratei de configurar ao máximo, além de abrir o navegar no Chrome para tirar algumas dúvidas, antes de iniciar a instalação, — mas nessa 1ª tentativa o processo não se completou.

A fase de instalação, propriamente dita (slide-show), começou às 17:07, e às 17:31 já estava nas “tarefas de configuração de pós-instalação”, — mas às 17:33 apresentou mensagem de erro, com 3 opções (Report bug, Debug, Quit), e foi encerrado.

Durante todo esse tempo, o KSysguard não registrou atividade de rede, — download, — embora o Chrome estivesse conectado e navegando normalmente, — antes, durante e depois da tentativa de instalação.

Para minimizar os riscos de novo erro, foi gravado um segundo DVD em velocidade 4x. — A nova sessão Live DVD foi carregada sem as opções de Idioma e Teclado PT-BR, — e configurada só no mínimo indispensável para as capturas de tela (Atalho “PrtScn”).

Nesta 2ª tentativa, o Instalador foi deixado em full-screen, — evitando abrir o Chrome ou alternar com o Dolphin, — que foi aberto apenas para montar o Pendrive e confirmar a gravação da primeira captura de tela.

A fase de instalação, propriamente (slide-show), começou às 23:00 e foi deixada sozinha, — sem supervisão, sem prints, sem qualquer outra atividade humana. — De acordo com o arquivo “/var/log/anaconda/anaconda.log”, terminou às 23:29, com mensagem de sucesso.

Instalação (II)


Início da 2ª tentativa de instalação do Sabayon, — com o Relógio do Painel “estacionado”, havia 3 minutos

A 2ª tentativa de instalação do Sabayou começou por volta das 22:46, — embora o Relógio do Painel tivesse parado em “22:43” (que continuou exibindo até o final). — No entanto, as capturas de tela (bem como os logs) registram as horas corretas, compatíveis com as das fotos de celular.

O instalador Anaconda, — já conhecido da instalação do Fedora, — é menos “sequencial” do que os instaladores do Debian, do Ubuntu (Ubiquity) ou do Manjaro (Calamares).

Os primeiros passos foram escolher o Idioma e o layout do Teclado (PT-BR), assim como o Fuso horário (Américas / São Paulo).

Opções iniciais da instalação do Sabayon

A conexão (Rede) já tinha sido detectada e ativada automaticamente, desde o carregamento da sessão Live DVD, — mas poderia alterar o nome do Host para “Linux11”, por exemplo.

Neste ponto, restava definir o destino da instalação, — discos, partições etc., — para habilitar o botão “Iniciar a instalação”.

Escolha do dispositivo, — e da opção “Eu irei configurar o particionamento

Tendo previamente confirmado que poderia usar um esquema de particionamento simples e trivial, foi escolhido o dispositivo SSD externo, — e marcada a opção “Eu irei configurar o particionamento”.

Seleção manual de partições pre-existentes, para a instalação do Sabayon

Na 1ª tentativa, me guiei pelas partições do Antergos (Unknown Linux), — somando +1 na numeração de cada partição, — de sdd1 para sdd2 (“/”), de sdd5 para sdd6 (“/home”), de sdd9 para sdd10 (Swap).

Mas poderia ter feito de cabeça, uma vez que as primeiras 3 partições são para sistemas, a 4ª é a partição estendida, as 3 seguintes são para Home, em seguida uma partição de dados (Armazem), e as 3 últimas para Swap, — tudo na devida ordem numérica.

Porém, na 2ª tentativa bastava selecionar as 3 partições da tentativa anterior, — e preencher com os mesmos pontos de montagem. — Cada uma das partições configuradas vai sendo transferida de “Sabayon” (embaixo, à esquerda) para “Novo Sabayon” (no alto).

Resumo do particionamento, — ao clicar em “Finalizado”

Ao clicar em “Finalizado” (no alto, à esquerda), se apresenta o resumo das ações de particionamento que foram definidas pelo usuário. — Se estiver tudo certo, clique em “Aceitar mudanças”.

Voltamos então à tela “Resumo da instalação”, — agora, com o “Destino” definido, — e com o botão “Iniciar a instalação” habilitado, para prosseguir.

Opções avançadas, — em Criar usuário

Então, requisita-se a definição da Senha Root, — e se oferece a oportunidade de Criar usuário, — com as opções de torná-lo Administrador, requerer (ou não) senha para usar a conta de usuário, e mais algumas Opções avançadas.

Início da instalação do Sabayon no computador, — com slide-show

Por fim, a mesma tela, — que requisitou definir Senha Root e ofereceu a oportunidade de Criar usuário, — é aproveitada para o slide-show durante a instalação do Sabayon no computador.

Ao contrário de outros instaladores e “distros”, — por exemplo, Debian, — aqui não será necessária mais nenhuma ação do usuário.

Você pode até ir dormir, — mas a demora não chegou a 30 minutos.

Configurações do sistema (KDE)


Montagem automática de partições (KDE), — sem efeito, até o momento (••• ver adiante)

A primeira sessão do Sabayon instalado começou à 0:05 de 5 Mar. 2017, — seguindo o roteiro comum de configurações personalizadas:

  • Configurar Dolphin. — Montar partição “XTudo”
  • Papel de parede
  • Configurar Spectacle. — Inverter atalhos PrintScreen / Shift-Print
  • Na inicialização, restaurar sessão salva manualmente. — Salvar sessão
  • Ativar NumLock ao iniciar o KDE Plasma. — Tecla de acesso ao terceiro nível
  • Montagem automática de partições adicionais
  • Desativar a Carteira do KDE (KWallet)
  • Login automático. — Entrar novamente após sair (“Encerrar sessão”)
  • Temas da área de trabalho → obter → Maia transparent
  • Decorações da janela → obter → Transparent oxygen
  • Bloqueio de tela — Não bloquear após X minutos. — Não bloquear ao reativar
  • Efeitos da área de trabalho → Cubo
  • Pesquisa de arquivos — desativar
  • Compositor — (Automaticamente escolhido: OpenGL 2.0; Método de escala: Preciso)
  • Efeitos da área de trabalho — Desativadas animações ao Minimizar / Maximizar etc.

A montagem da partição “XTudo”, — onde costumam ficar fotos, capturas de tela, modelos do Conky e todo material mais usado nessas experiências, — pediu senha Root, por isso, foi deixada para depois.

Não havia pressa. Todo esse material tem cópia no 2º backup, — na partição “Armazem2”, do SSD externo, — que não precisa de senha para montar. Por algum motivo, basta clicar nela, pelo Dolphin.

O capítulo de montagem automática de partições “adicionais”, nas Configurações do sistema (KDE), não faz efeito algum, — tal como não faz efeito no Debian e mais algumas “distros”. — Provavelmente, será necessário incluí-las no arquivo “/etc/fstab”, e / ou alterar alguma “política” (tipo “polkit”). Nada muito urgente.

••• Ver “Montagem automática de partições adicionais” (adiante).

As Configurações do sistema (KDE), parece que simplesmente não incluem o Kwallet, — um popup torra a paciência, 2 vezes, a cada vez que se abre o Chrome / Chromium. — Também não é tão urgente.

Também não adiante desmarcar o pedido de senha para logar automaticamente na conta do Usuário, — isso terá de ser resolvido em outro lugar. — Sem urgência.

Enfim, a brincadeira do Cubo foi descartada, — devido a algumas “tremidas nervosas” da tela, nas primeiras horas. — Em vez de sobrecarregar, a opção foi desativar mais alguns “Efeitos” bobos, como as animações de Maximizar e Minimizar janelas. Esse tem sido um cuidado corriqueiro, uma vez que não existe placa aceleradora de vídeo (3D), mas apenas o recurso onboard de 2008, para o qual estão alocados 256 MB da Memória RAM. Após quase 24 horas de uso constante, as coisas parecem bastante tranquilas.

Pacotes e atualizações


Sistema “atualizado”, desde o primeiro momento, — e sem novidades após 1 hora, 2 horas

Chamou atenção o fato de, ao carregar pela primeira vez, logo após a instalação, o Magneto Entropy se apressou em notificar que, — “Seu Sabayon está atualizado. Tudo parece estar Ok. Não há atualizações a fazer. Legal!”.

A versão instalada era “16.11” (29 Out. 2016), — que até hoje (6 Mar. 2017) é a opção-padrão na página de download para desktop, — embora já existam imagens ISO mensais “17.03” (28 Fev.), e imagens diárias com a data de hoje (6 Mar.).

As indicações do Centro de Informações do KDE (KInfocenter) também pareciam defasadas, em comparação com o pouco que havia lido, e com o que diz sua página oficial: — “Sabayon is a beginner-friendly Gentoo-based open-source Linux distribution. We aim to deliver the best "out of the box" user experience by providing the latest open source technologies in an elegant format. In Sabayon everything should just work. We offer a bleeding edge operating system that is both stable and reliable”.

Porém, o mais urgente era instalar o Gimp (que não veio junto), — e substituir o Google Chrome (que veio) pelo legítimo Chromium, para ver se eliminava alguns defeitos iniciais.

No entanto, a (pouquíssima) leitura não deu nem para o começo. Digitando “pacote” ou “Software” no Menu, não se acha nada. Digitando “Package”, aparece apenas um link “Sabayon packages”, — que leva à página “Sabayon Entropy Store”. — Não era bem isso que o iniciante procurava.

Sem saber o “nome de batismo” do gerenciador “Rigo”, — ou as palavras-chave “Application Browser”, — poderia passar por ele vezes seguidas, sem “ver” que ele existia.

Comando “equo update” finalmente encontrou novidades, — e revelou a existência do Rigo

De volta a uma das (pouquíssimas) leituras anteriores, tratei de ouvir um palpite “da boca do cavalo”, como se diz, — e ele mandou apostar em “su” + “equo update”.

Desse modo, — após 2 horas, — finalmente, apareceram “2 atualizações disponíveis”, — e fiquei sabendo da existência do Rigo, com um botão de brinde para abri-lo sem necessidade de voltar ao Menu K.

Por “2 atualizações disponíveis”, — coisa de aparência boba, — leia-se, “1 upgrade completo”.

O processo se estendeu por 2h 25min, — até 4:31, — com dúzias de informações e perguntas muito boas, porém absolutamente incompreensíveis para um iniciante que faltou a 99,7% das aulas.

Ou talvez seja mais exato dizer que o upgrade geral terminou às 4:12, — e daí por diante devia ter ignorado o resto?

Rigo “trabalhando muito”, após quase 2 horas, — “Instalando versão 17.03

Depois de quase 2 horas vendo o desfile no “Mostre para mim” do Rigo, — cuja barra de título exibia “Estou trabalhando muito”, — às 3:59 ficou claro que o Sabayon 16.11 estava se transformando em 17.03.

Na verdade, não é possível dizer se fiquei mesmo assistindo esse desfile. Há uma lacuna de 1h25min nas capturas de tela, entre 2:29 e 3:56. Poderia ter havido alguma falha do KDE Spectacle ou da tecla PrtScn, porém é muito provável que tenha ido tirar um cochilo. Afinal, não sabia o que estava fazendo na frente do computador, — e desconfiava que ele saberia cumprir o seu dever, sem ninguém para atrapalhar. Terá feito perguntas? Respondeu sozinho?

Logo adiante, às 4:08, — instalando o Kernel “Linux Sabayon 4.8.17-0”, — reclamou que não conseguiu montar uma penca de partições, mas só pediu a senha depois. Após fornecer a senha, tornou a reclamar que não conseguiu montar a mesma penca de partições, às 4:09.

Atualização completa, — e inúmeros itens para “revisão manual”

A partir das 4:12, a atualização se declarou concluída.

Porém, começaram as perguntas realmente embaraçosas, — bem como vários cliques em “Atualizar” aqui e ali, — e que voltavam a ser exibidos para clicar de novo, várias vezes.

Havia até um trecho, — totalmente em branco (cinza), sem nenhuma pergunta ou informação, — e as opções de “Ok, obrigado!” e “Mostre para mim”. Talvez fosse uma mensagem secreta, com tinta invisível.

Tudo, ao mesmo tempo, — e muitas vezes, sem possibilidade de efeito imediato, — apenas entrar na fila (qeue).

Complicado, por exemplo, dizer que “há 53 bibliotecas preservadas”, — com a opção “Atualizar”, que não faz sentido em nenhuma língua do mundo. — Se foram “preservadas”, é porque não fazem mal. E afinal, tudo já foi “atualizado”. Significaria “remover”?

Enfim, uma gorda fila de aplicativos que “não serão mais atualizados” foi apresentada para “revisão manual”. — Até olhei os primeiros, sem entender nada daquela algaravia. — A decisão acabou sendo a de remover tudo aquilo, — lamentando ficar sem Konqueror e Okular (difícil crer que tenham encerrado suas carreiras). Mas foi uma alegria, quando chegou a hora de eliminar Akonadi, KDE-PIM e várias outras coisas.

Final da “revisão manual”, após a atualização (ou upgrade) do Sabayon

Às 4:31 (relógio exibindo “4:21”), restava apenas o Akonadi para “revisar manualmente”, — declarando no texto (no alto) que você pode “mantê-los ou desinstalá-los”, mas oferecendo (embaixo) “Reinstalar” ou “Remover”, — e as últimas 5 bibliotecas “preservadas”, com aquela opção esquisita de “atualizar”.

A ambiguidade, — afinal, é “manter” ou “reinstalar”?, — aliada à persistência de “avisos” cobrando providência, — pelo menos foi eliminada.

A expectativa é que, — feita a limpeza até o último grão de poeira, — seja possível instalar (sem ambiguidade) o Konqueror e o Okular, — um de cada vez, — e ver se explode, pega fogo, ou assobia.

Mas o mais urgente, ali mesmo, era instalar Gimp, Conky, Xsane, — além de remover o Google Chrome, e instalar o Chromium, — coisas realizadas com sucesso até 4:48 (com o relógio ainda exibindo “4:21”).

Epílogos


Instalação do Konqueror no Sabayon, pelo Rigo Application Browser

6 Mar. 2017 - Concluído o relato (acima), foram reinstalados o Konqueror e o Okular, sem maiores protestos por parte do Sabayon.

Apresentação de dependências adicionais, durante a instalação do Konqueror pelo Rigo, no Sabayon

Ao longo do processo, o Rigo apresenta eventuais dependências, — que podem ser aceitas em bloco, ou examinadas individualmente.

Alteração do hostname, — de “sabayon.local” para “Linux11”

O “nome da máquina” foi corrigido, — de “sabayon.local” para “Linux11”, — pela simples edição do arquivo “/etc/hostname”.

Em outros sistemas, foi necessário editar também “/etc/hosts”, para incluir o novo hostname, — porém no Sabayon o arquivo estava vazio, — e assim foi deixado.

Ao carregar novamente, a mudança fez efeito, e não houve reclamações.

Como não existe rede por aqui, — é um computador isolado, e sem acesso externo, — a utilidade dessa modificação é apenas cosmética, — exibir “Linux11” no Conky e no Konsole.

••• Montagem automática de partições adicionais


Copiando “/etc/polkit-1/rules.d/99-udisks2.rules” do Antergos para o Sabayon, no Krusader (modo Root)

17 Mar. 2017 - Ao resumir a montagem automática de partições “adicionais” nos diferentes Linux instalados, foi retomada esta configuração específica do Sabayon, — aproveitando para testar uma ideia: — Simplesmente copiar e colar o arquivo “/etc/polkit-1/rules.d/99-udisks2.rules” de outro sistema para o Sabayon.

Isso foi feito “de fora”, — no Kubuntu, usando o Krusader em modo Root, para agilizar. — E o Sabayon finalmente carregou com 4 partições “adicionais” montadas automaticamente.

São as partições “Armazem1”, “XTudo”, “Works” e “Sites”, que tinham sido habilitadas nas Configurações do sistema (System settings) desde o dia da instalação do Sabayon, — sem resultado.

Confirmado que agora a configuração funciona, foi habilitada a montagem automática das demais partições.

Crash do Kwin


Crash do Kwin

O Sabayon foi removido após um crash do Kwin em 29 Mai 2017.

A experiência ficou adiada, — até nova instalação do Sabayon no final de 2018, — agora, sem usar o Rigo. — Só comandos Entropy, para começar.
_________
Relato produzido e publicado de 5 a 6 Mar. 2017, e complementado de 6 a 8 Mar. 2017, no Sabayon.
••• “Montagem automática de partições adicionais” acrescentado em 17 Mar. 2017.

— … ≠ • ≠ … —

Não-debians