quarta-feira, 15 de março de 2017

Montagem de partições no Antergos e no Manjaro

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

A montagem automática das partições “adicionais”, — aquelas que não fazem parte do “sistema”, — foi um dos fatores a retardar o relato da instalação e configuração do Antergos, em 3 Mar. 2017.

Com todas as capturas de tela centralizadas na partição “XTudo”, — pois não faria sentido deixá-las dispersas nas partições dos 11 sistemas instalados em paralelo, — a boa ordem dos trabalhos pressupõe que essa partição “XTudo” esteja montada desde o momento em que cada sistema é carregado, para registrar o tempo decorrido (uptime), o uso inicial da Memória RAM, e vários outros indicadores exibidos no Conky.

Desde o início de cada sessão, o Dolphin também já deve estar aberto, — com várias abas, em várias pastas, conforme os trabalhos em andamento, em cada época. — Essas “flutuações” do ambiente de produção são atualizadas pelo recurso “Desligar / Sessão → Salvar sessão”, aliado à opção de “Restaurar a sessão salva manualmente”.

Este relato se compõe dos seguintes resumos, — com links para mais detalhes de cada caso:

  • Manjaro
  • Udisks2
  • Polkit-1
  • Antecedentes
  • Linux Mint 17.3 Cinnamon
  • Debian 8 / 9
  • openSUSE
  • Fedora
  • Sabayon

Manjaro


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

Curiosamente, essa montagem automática não tinha apresentado problema algum no Manjaro (1º Jan. 2017), — também baseado no Arch Linux. — 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.

Nesse aspecto, o Manjaro se comportou exatamente como o Kubuntu, o KDE Neon e o Linux Mint KDE, entre outros, — nos quais, basta isso, para obter a montagem automática.

Udisks2


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

Por trás dessa configuração, “trabalha” o daemon udisks2, — o mesmo utilizado pelo Dolphin, por exemplo, para montar uma partição “sob demanda” (quando você clica nela, no Dolphin).

Por isso, o caminho (path) para a montagem da partição é igual nos 2 casos, — e pode ser alterado por algumas regras em “/etc/udev/rules.d/”:

/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

Acontece que, no Antergos, ao clicar no Dolphin para montar uma partição exibida na barra lateral, ele solicita a senha de Root, — coisa que não acontece durante o carregamento do sistema, — e o resultado é como um carregamento “incompleto”, pendente de ação manual (senha de Root), antes que o ambiente se possa considerar realmente pronto.

Em resumo, a mera configuração de montagem automática não funcionou no Antergos.

Por comodismo, talvez o próximo passo fosse tentar o arquivo “/etc/fstab”, — mas não encontrei nos repositórios nenhum aplicativo similar ao “Discos” (gnome-disk-manager), nem ao “Gerenciador de discos” do Debian. — Ou, se encontrei, não consegui perceber, ou ter certeza. Em Arch, sou estranho em terra estranha.

Sem entender absolutamente nada desse emaranhado de sutilezas que é a estrutura de um Linux, — e por isso, dando apenas 1 passo de cada vez, para sentir o terreno, — comecei por testar uma alteração de “política”, que já havia resolvido um problema semelhante no Fedora.

Em resumo, tratava-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; } });

Sequência repetida a posteriori, para conferir como foi criado o arquivo “99-udisks2.rules

Na falta de um recurso tipo “Dolphin como Root”, foi seguida a sequência:

su
cd /etc/polkit-1/rules.d
kate
[copy & paste]
save as
99-udisks2.rules

Um pouco mais à vontade com comandos em tela preta, seria mais simples apenas copiar esse arquivo do Fedora.

Antecedentes


Sistemas Linux experimentados nos primeiros 8 anos

Instalar e usar um sistema Linux “facilitado” para iniciantes, — como o (K)Ubuntu, — exige muito pouco aprendizado.

Até o início de 2016, — embora usando Linux desde 2007, — havia aprendido o mínimo. Acessar e gravar nas partições “E:\” e “F:\” do Windows era tudo quanto bastava, — não importando se o Dolphin as apresentava como “Volume de 178 GB”, pois eram poucas; dava para identificar. As partições nem tinham rótulos (label), e ignoro como eram os pontos de montagem.

O fato daquelas partições usarem sistema de arquivos Fat32, — sem manhas de “proprietário” ou “permissões”, — pode ter facilitado seu uso simplificado, dispensando maior estudo.

A mera instalação / configuração de 1 novo Kubuntu LTS a cada 2 anos tampouco estimulava maior aprofundamento, — bastava recuperar as funcionalidades habituais (ou substituir alguma que desaparecia). — Manter o velho Windows também facilitava a acomodação.

Encontrava pouco tempo para dedicar ao “segundo” Linux, — não lembro, sequer, como fiz para obter (se é que obtive) a montagem automática de partições “adicionais” em antigas instalações do Debian e do Linux Mint. — Claro, existem cadernos com anotações, mas além de não oferecerem “CTRL-F”, só registram algumas soluções que pareciam mais valiosas. O que foi fácil ou não foi conseguido, não ficou anotado. E o que demorava a ser conseguido, só era anotado quando boa parte do histórico já estava esquecido.

Apenas a partir de Mar. 2015, com a instalação de um segundo Kubuntu, — “igual” ao primeiro, exceto por ser 32-bit, ao invés de 64-bit, — as configurações começaram a ser sistematizadas, com registros mais completos e detalhados.

A bem dizer, 99% do pouco que sei foi aprendido nesses últimos 12 ou 14 meses, “brincando” de instalar 2, depois 4, e agora 11 sistemas “em paralelo” (multiboot), — com o propósito firme de substituir todas as tarefas ainda dependentes do Windows, — e procurando registrar com detalhes, aqui no Byteria, em postagens um pouco mais estruturadas.

Portanto, os “antecedentes” (abaixo) são meras observações, — com algumas “receitas” práticas, que podem não ser as mais indicadas. — Mero registro, acompanhando um aprendizado ainda bastante precário.

Estudar a estrutura completa do Linux, — caminho para de fato conhecê-lo, — ainda é coisa para o futuro.

Mint Cinnamon


Comandos adotados para montagem automática de partições no antigo Linux Mint 17.3, no início de 2016

Acostumado unicamente ao KDE (Kubuntu), a montagem automática de partições “adicionais” foi particularmente espinhosa no Linux Mint 17.3 Cinnamon (Jan./Fev. 2016), — cujo “Discos” (gnome-disk-utility) escrevia o “/etc/fstab” para usar um recurso do x-gvfs-show ainda incompatível com o resto do sistema (util-linux 2.20).

Disposto a evitar o “/etc/fstab”, — e em especial, evitar escrevê-lo “manualmente”, — a solução adotada acabou sendo a inserção de comandos udisks em “Menu → Preferências → Aplicativos de sessão (gnome-session-properties) → Adicionar → Comando personalizado”:

udisksctl mount --block-device /dev/disk/by-uuid/<uuid>

Debian


Edição do arquivo “/etc/fstab” pelo Gerenciador de discos.(Disk Manager 1.1.1)

O registro detalhado da pesquisa para a montagem automática de partições “adicionais” no Linux Mint 17.3 Cinnamon facilitou bastante a escolha da solução adotada no Debian testing “Stretch”, poucos meses depois, em Jun. 2016.

Embora resistisse ao uso do arquivo “/etc/fstab”, o Gerenciador de discos.(Disk Manager 1.1.1) se mostrou tão eficiente e prático para editá-lo, que a pesquisa parou ali mesmo, — sem chegar à “polkit”, por exemplo, que por isso, nem sei como funciona (ou se funciona) no Debian.

Em resumo, o Gerenciador de discos permite, facilmente, habilitar a montagem automática de partições escolhidas, — além de editar o caminho (path) ou ponto de montagem, e mais alguns parâmetros básicos.

Um parâmetro inicialmente adotado para a montagem da partição “F:\” (Fat32), — verificar o sistema de arquivos a cada 30 sessões, — acabou resultando numa demora de mais de 1 minuto, no carregamento de todas as sessões do Debian, caso tivesse passado pelo Linux Mint 17.3 Cinnamon.

O mais provável é que o Linux Mint 17.3 guardasse alguma configuração (manual) heterodoxa, feita para compatibilizar com o “relógio de sistema” do antigo Windows XP (eliminado desde Abril), — e isso deixava na partição uma “data de acesso” situada no futuro (do ponto de vista do Debian).

Infelizmente, esse Gerenciador de discos não tem sido encontrado nos repositórios de outras distros. — Não veio com o Debian testing “Stretch” (Jun. 2016), pois foi instalado depois. — Também não veio com o Debian 8.6 (30 Set. 2016), pois o Histórico do Synaptic indica que só foi instalado em 4 Out. 2016. — Continua nos repositórios do Debian testing / Debian 9, porém o desenvolvedor não tem planos de nova versão, e solicita contato de quem queira assumir a tarefa.

openSUSE


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

Tal como no Debian, também no openSUSE (17 Jan. 2017) não adiantou recorrer ao “Menu K → Configurações do sistema → Hardware → Armazenamento removível → Dispositivos removíveis” para obter a montagem adicional de partições “adicionais”.

Embora jamais tivesse visto de longe um SuSE ou openSUSE, encontrar a solução foi relativamente fácil e rápido, — graças às recentes pesquisas para lidar com essa questão no Mint 17.3 Cinnamon (Jan. 2016) e no Debian (Jun. 2016), sistematizadas em registros detalhados.

Em resumo, o “Particionador” do YaST2 supre o mesmo papel 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.

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 simples recurso 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”, por exemplo.

Ou, criar os pontos de montagem indicados nele, — mas, como ainda não sabia nada disso, o caminho mais simples foi disparar um “reboot” e ir para outro sistema, pesquisar mais.

Encontrada a solução “polkit-1”, finalmente o Fedora carregou normalmente, — com as partições e pontos de montagem indicados no “/etc/fstab”. — Depois disso, (aindanão foi feita nova tentativa com “udisks2”, para ver se agora ele também funcionaria (dispensar a edição do “/etc/fstab).

Sabayon


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

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

Para testar o procedimento mais simples, foi agora copiado o arquivo “/etc/polkit-1/rules.d/99-udisks2.rules” do Antergos para o Sabayon, — usando o Krusader (modo Root), — e bastou carregá-lo para confirmar o resultado.

Mageia


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

A mera configuração de montagem automática pelo “Menu K → System settings → Removable devices” também não produziu qualquer efeito no Mageia 5, — e para agilizar, foi utilizado 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, depois espremer os olhos e os miolos numa sopa de letrinhas.

Agora, ao substituí-lo pelo Mageia 6 sta2, foi feito o teste de simplesmente copiar o arquivo “/etc/polkit-1/rules.d/99-udisks2.rules” do Antergos, — usando o “Krusader as Root”, — e finalmente os comandos udisks2 definidos pelo pelo “Menu K → System settings → Removable devices” puderam fazer efeito ao iniciar a sessão.

Conclusão


Parece muito provável que a autorização contida em um arquivo “/etc/polkit-1/rules.d/99-udisks2.rules” possa dispensar o uso do “/etc/fstab” também no Debian, no Fedora e no openSUSE, bastando então escolher as partições “adicionais” pelo “Menu K → System settings → Removable devices”.

A experiência ainda não foi feita no Dabian, porque a estrutura da pasta “/etc/polkit-1” é um pouco mais complicada, — e 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

Também no Fedora e no openSUSE, vale a pena escolher um momento de calma para colocar toda atenção, ao fazer a experiência de trocar o “/etc/fstab” pelos comandos udisks2 das Configurações do sistema + polkit.

— … ≠ • ≠ … —

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

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