quarta-feira, 4 de abril de 2018

Chromium isn't your default browser

Chromium reclama e pede para ser o navegador-padrão, — todas as vezes que é aberto

A instalação do Konqueror (com mais alguns pacotes) parece ter sido a causa de o Chromium começar a reclamar que não é o navegador-padrão, — e perguntar se deseja torná-lo padrão, — todas as vezes que é aberto.

Você clica em Set as default, — e não adianta. — O Chromium torna a perguntar, todos os dias, a cada nova abertura.

Tentando tornar o Chromium navegador padrão, em suas configurações

Você vai nas configurações do Chromium, — clica e torna a clicar em Make default, — e também não adianta.

Confirmado: — Chromium era o navegador padrão (desde sempre, aliás)

Você verifica em System settings >> Applications >> Default applications, — e também lá o Chromium consta como navegador-padrão. — De fato, assim era… até a véspera.

Tudo isso já aconteceu antes, em outras distros instaladas aqui, — e acho que em algumas ainda acontece, — mas essa foi a primeira vez que a provável causa do problema ficou bem isolada e evidente, com absoluta clareza.

Isso ficou claro, em parte, devido a uma rotina mais rígida, de instalar poucos pacotes de cada vez, — apenas um aplicativo (e suas dependências), — sem misturar com outros aplicativos (e outras dependências), — e nunca misturar com as atualizações regulares.

Segundo o Histórico do Synaptic:

Commit Log for Sat Feb 24 07:18:23 2018
Instalados os seguintes pacotes:
• krusader (2:2.6.0-1)

Commit Log for Sat Feb 24 07:19:27 2018
Instalados os seguintes pacotes:
• kfind (4:17.12.2-0ubuntu1)
konqueror (4:17.12.2-0ubuntu3)
• libkf5konq-data (4:17.12.2-0ubuntu3)
• libkf5konq6 (4:17.12.2-0ubuntu3)

Commit Log for Sat Feb 24 07:52:58 2018
Instalados os seguintes pacotes:
• dolphin4 (4:16.04.3-0ubuntu1)
• libkonq5abi1 (4:16.04.3-0ubuntu1)

E ao ser aberto, — menos de uma hora depois, — o Chromium já começou a reclamar.

• 2018-02-24_08-10-10_Kbb-Chromium-isnt-default-browser

Instalação do Konqueror atribui a ele a prioridade na associação com arquivos *htm*

A causa específica foi localizada em System settings >> Applications >> File associations >> *htm*

Ao que tudo indica, foi a mera instalação do Konqueror que atribuiu a ele a prioridade para abertura de arquivos html, htmlh, xhtml, — uma vez que as primeiras configurações personalizadas não tocaram nessa área, — e outras só foram feitas bem depois do problema, que se manifestou em menos de 1 hora.

17 Abr. 2018 - Mais tarde, o problema foi constatado em uma distro, mesmo antes de instalar o Konqueror. — Em todo caso, a solução foi a mesma.

Reorganização da associação de arquivos HTML a diferentes aplicativos

Usando os botões Mover para cima e Mover para baixo, a prioridade dos diferentes aplicativos foi reorganizada, — de modo a colocar o Chromium no topo, — o que corresponde ao clique simples (ou duplo, conforme sua preferência) sobre qualquer arquivo desses 3 tipos, no Dolphin.

Os demais aplicativos associados ao tipo de arquivo podem ser facilmente utilizados pelo Menu de contexto (right-click), — na ordem aqui definida.

No caso dos arquivos htm ou html, o LibreOffice Writer foi colocado como segunda opção, — por ser uma das alternativas mais usadas para extrair trechos de páginas web que bloqueiam a cópia quando visitadas pelo Chromium, Firefox etc. — Salva-se a página e abre-se o arquivo html pelo editor de textos, que ignora esse bloqueio.

Outro aplicativo utilizado com certa frequência é o Kate, — para verificar detalhes do código de uma página salva anteriormente.

Opções menos utilizadas foram jogadas para baixo, — ou mesmo removidas, como no caso do Notepad (Wine), — para que nunca sejam chamadas por descuido.

Abrir o Konqueror parece exigir que ele seja o aplicativo-padrão para arquivos HTML

Infelizmente, esta solução criou outro problema, — pois abrir o Konqueror depende dele abrir o arquivo Bookmarks (html), como aplicativo-padrão, — e as coisas se complicam.

A ver, nos próximos dias.

• Essa instalação do Kubuntu 18.04 (daily-build) será substituída dentro de algumas horas, — com formatação da /home, para eliminar a “herança” de um PCLinuxOS experimental.

Navegador vs. gerenciador de arquivos


Embora seja um “navegador web”, o Konqueror também é um “gerenciador de arquivos”, — e já foi padrão (se não me engano) no Kurumin ou no Kubuntu, até vários anos atrás, — e esse acúmulo de funções acabou por torná-lo mais complexo do que o desejável.

Optou-se por um aplicativo (simples!) para cada função, — de modo a desempenhá-la da melhor maneira possível, — e a partir de certo momento o Kubuntu passou a vir com o Dolphin.

Na época, essa guinada foi meio chocante. Pessoalmente, — como mero usuário (e muito mais ignorante de Linux do que hoje), — me senti bastante perdido. Foi como se me tivessem tomado um belo brinquedo, em troca de outro, bem mais tosco.

Houve muito choro e ranger de dentes, nos foruns. — Depois, surgiram dicas de como adicionar pacotes e funcionalidades, — por meios, talvez, não tão “amigáveis”, a princípio.

Hoje, eu não saberia viver sem o Dolphin, — tornou-se a base da minha experiência de KDE, — e sua falta é um dos primeiros motivos a me desgostar do Xfce ou do Cinnamon, para dar apenas 2 exemplos de “escritórios” com os quais me  sinto relativamente ambientado, no geral.

Tenho cada vez menos motivos para (ainda) instalar, configurar, abrir e usar o Konqueror, — cada vez mais abandonado, — e cada vez mais “amputado”, à medida em que o KDE 5 vai avançando.

Nunca, porém, como “navegador”, — isso foi uma das primeiras coisas que deixei de fazer, há vários anos. — Talvez, mesmo, desde quando ainda era um aplicativo padrão do Kubuntu.

— … ≠ • ≠ … —

Kubuntu


terça-feira, 3 de abril de 2018

Kubuntu 18.04 Bionic - back to Kernel 4.4

Kubuntu 18.04 Bionic Beaver com Kernel 4.4

Conforme relatado, o Kubuntu 18.04 LTS “development branch” (em desenvolvimento) foi instalado a partir da imagem ISO “daily build” 2018-02-21, com Kernel 4.13, — e no dia 22 já recebeu atualização para o Kernel 4.15, que se mostrou desastroso para o velho hardware de 2008.

Mas, — mesmo com o imediato retorno ao Kernel 4.13, — o Kubuntu 18.04 Bionic Beaver ainda ficou longe do ideal.

  • Sem som (desde a instalação)
  • Chromium reclama que não é o navegador-padrão (Chromium vs. Konqueror)
  • update-apt-xapian roda sem ser chamado e abusa da CPU por intermináveis minutos
  • Teclado continua sem acesso ao 3o. Nível
  • Teclado continua sem ativar NumLock no início da sessão
  • etc.

Alguns desses problemas podem ser herança da /home de um antigo PCLinuxOS experimental, — e já está planejado reinstalar o Bionic Beaver em breve, sem essa herança.

Mas o mais grave era o Chromium não conseguir enfrentar as tais Páginas do Facebook, — sem ficar lento, devagar-quase-travando (com surto de uso de CPU e algum aquecimento).

Nas distros em que isso ocorre, também é comum acontecer quando surge algum vídeo ou GIF animado (mesmo parado) na linha-do-tempo do Twitter ou do Google Plus, — e em mais 2 ou 3 circunstâncias, menos importantes, — mas as Páginas do Facebook são o indicador mais gritante, pois a navegação fica impraticável, até para rolar, ver e visitar os links mais relevantes.

Na falta de conhecimentos técnicos mais profundos, ficou claro que 2 ou 3 providências às vezes ajudam, — pelo menos, no caso específico deste hardware:

  • Mudar o Compositor de OpenGL2.0 para XRender (já faço isso há tempos)
  • Instalar ou substituir alguns pacotes relacionados a Intel-video, drivers etc.
  • Recuar do Kernel 4.9 (ou maior) para 4.4, — quando disponível nos repositórios

Acontece que no, momento, os repositórios do Kubuntu 18.04 Bionic Beaver só oferecem o Kernel 4.15, — e tudo indicava que o 4.13 só aparecia no Synaptic, porque ainda estava instalado aqui.

De fato, depois que foi desinstalado (adiante), desapareceu por completo. Não existe mais nos repositórios. Agora, está claro que não adiantava insistir. Nunca mais receberia atualizações.

É óbvio que o computador está com problema de junta, — junta tudo e joga fora, — mas… não é assim que age um usuário Linux (mesmo quando não sabe quase nada de Linux).

Escolha dos pacotes .deb para instalação do Kernel 4.4.116

Embora 99% dos resultados do Google para "Kernel install" se destinem aos que anseiam pelo mais novo Kernel (que ainda não chegou em sua distro), nem por isso deixam de ser úteis para quem queira seguir o caminho inverso, — instalar um Kernel antigo.

Escolhi a postagem Como instalar qualquer versão do Kernel Linux no Ubuntu manualmente, do Diolinux, por ser simples, — nada de compilar, — além de estar em português bem claro.

No link indicado do kernel-ppa/mainline, encontra-se o Kernel 4.4 até a versão v4.4.126, mas pareceu mais prudente usar a v4.4.116, — por mero achômetro, considerando que nos repositórios do Kubuntu 16.04 LTS, do Linux Mint 18 Sarah e do KDE Neon User Edition a revisão mais atual é 4.4.0-116. — Sim, existe aí um zero e um traço a mais. Será que explode?

Os 3 pacotes .deb indicados são, — para arquitetura amd64, — o arquivo "all" e os 2 arquivos "amd64":

  1. linux-headers…all
  2. linux-headers…amd64
  3. linux-image…amd64

A instalação se faz nessa ordem, — alfabética (coincidência ou não): primeiro "headers", depois "image", — daí a orientação do Diolinux de seguir "da esquerda para a direita" ("de cima para baixo", com o Dolphin no modo de visão Detalhado ou Lista).

Antes de prosseguir, — remova drivers proprietários.

Instalação dos pacotes do Kernel pelo QApt (Package Installer)

Ao invés de fazer duplo-clique em cada um (ou clique único, no caso do KDE), sondei com o botão direito do mouse, — e a única opção era Instalar com QApt (Package Installer). — É exatamente esse que o clique também chama.

Ignoro se o clique chamaria o Plasma Discover, caso não o tivesse desinstalado há tempos.

QApt Package Installer — arquivos incluídos no linux-headers_all

O QApt apresenta as informações em 3 abas, — Description, Details, Included files, — e pede a senha ao clicar Install package (confirmação).

O processo todo levou 15 minutos ou pouco mais, — sendo que a demora ocorre na instalação do terceiro arquivo (linux-image).

Esse tempo pode ter sido afetado por um fenômeno estranho: — O Notificador permaneceu ativo (fazendo sabe-se lá o quê) desde o início da sessão, 5 horas antes.

Carregando o Kubuntu Bionic com o Kernel 4.4, para testar

Ao reiniciar o computador, — Grub > Opções avançadas, — foi escolhido o Kernel 4.4, para testar.

Remoção completa do Kernel 4.13 do Kubuntu 18.04 Bionic Beaver (development-branch)

Depois de 1h 30min, ficou comprovado que agora o Chromium consegue enfrentar as Páginas do Facebook, — leve e ágil, — sem qualquer efeito colateral negativo.

Pelo Synaptic, então, foi completamente removido o Kernel 4.13 original, — de modo a ficar apenas o Kernel 4.4.

Conclusão (7 Abr. 2018)


Após vários dias de uso contínuo, o Kubuntu 18.04 com Kernel 4.4 foi “aprovado” para navegar pelo Chromium em Páginas do Facebook, — sem lentidão, sem trava, sem surto de uso de CPU, — ao lado do Kubuntu 16.04, do Linux Mint 18 KDE, do KDE Neon User Edition e do PCLinuxOS KDE.

• Essa instalação do Kubuntu 18.04 (daily-build) será substituída dentro de algumas horas, — com formatação da /home, para eliminar a “herança” de um PCLinuxOS experimental.

Essa constatação abre (ou confirma) um caminho para lidar com o problema, — inclusive em outras distros, não-derivadas do Ubuntu, — de modo a não ficar preso ao Xenial 16.04 LTS, devido ao hardware antigo.

Isso se tornou uma preocupação, desde que todas as versões intermediárias do Kubuntu começaram a apresentar esse problema, no hardware atual, — o que inviabilizaria migrar para o Kubuntu 18.04 LTS Bionic Beaver.

Encontrar uma dica simples, — e um repositório da própria Canonical, — facilitou o teste.

Fazer o mesmo downgrade de Kernel no Mageia, Debian testing, Slackware, Arch, Devuan etc., já são outros 500.

— … ≠ • ≠ … —

Kubuntu


sábado, 24 de fevereiro de 2018

Kubuntu 18.04 LTS (daily-build) - Install, config

Kubuntu 18.04 LTS* Bionic Braver (daily-build), já com Kernel 4.15

• O Kubuntu 18.04 LTS “development branch” (em desenvolvimento) foi instalado a partir da imagem ISO “daily build” 2018-02-21, com Kernel 4.13, — e no dia 22 já recebeu atualização para o Kernel 4.15.

Remoção do Kernel mais recente pelo Synaptic, — rodando Kernel anterior

Infelizmente, o Kernel 4.15 não funcionou tão bem, aqui, — talvez devido ao hardware muito antigo (2008), — fenômeno já observado também em outras distros, como PCLinuxOS (ao passar do Kernel 4.12 para 4.14).

Em resumo, a navegação no Google Plus, — que costuma ser leve e rápida, — ficou “pesada”, cheia de “meia-trava” (trava, demora). Também se tornou sofrível a navegação no Facebook, — e quando aparece um vídeo (parado!) no Feed, as coisas travam mais ainda.

O Kernel 4.15 foi então removido do Bionic Beaver, pelo processo corriqueiro: — Boot > Grub > Opções avançadas > Kernel anterior, — e remoção do mais recente pelo Synaptic.

Caso o Grub seja controlado por outra distro (dualboot), é necessário carregá-la em seguida, para atualizar o Grub.

Com isso, o funcionamento voltou ao “normal”, — embora não tão “perfeito” como o do Kubuntu 16.04 Xenial (Kernel 4.4), por exemplo, — mas não há outras opções de Kernel nos repositórios do Bionic Beaver.

Desativando w83627ehf em /etc/modules

• O driver w83627ehf configurado pelo comando “sudo sensors-detect” passou a provocar mensagens de erro “Failed to start Load Kernel Modules” durante o Boot. — A configuração foi desabilitada e as mensagens cessaram, — sem qualquer prejuízo aparente para o Sensors nem para o Conky.

• Após 5 dias, o som permanece mudo, — problema que não se registrava mais, nesse hardware, há vários anos.

Crash do LibreOffice ao exportar PDF

• LibreOffice fecha abruptamente ao tentar “Exportar como PDF”.

Foram tentados caminhos alternativos pela “impressora PDF”, — inclusive instalar mais alguns pacotes, — sem resultado algum, embora não provoquem crash.

Por causa disso, no dia 28 este relato passou a ser desenvolvido no Slackware.

Montagem automática de partições adicionais pelo KDE System settings > Removable devices

• Nos primeiros dias, a montagem automática de partições adicionais, — pelas Configurações do sistema (KDE System settings > Removable devices), — simplesmente não funcionou.

Este problema já vinha ocorrendo nas demais distros que chegaram ao KDE 5.12, — KDE Neon, PCLinuxOS, Arch Linux, — e nas quais ainda persistiu por mais algumas semanas.

Porém no Kubuntu 18.04 este problema acabou no dia 25. — De repente, as partições adicionais passaram a ser montadas automaticamente, no início da sessão.

A conferir, quais pacotes foram instalados ou atualizados, e quais configurações alteradas, durante a sessão anterior ao inesperado conserto.

03:51 - Início de sessão sem funcionamento do Automount. — Instalados vários novos pacotes. — Também houve 2 atualizações às 4:52 (inclusive udev) e às 16:40 (ver Histórico de pacotes, adiante). — Restart após 17:51 (uptime 14h).

• 17:57 - Início de sessão (Boot meio demorado). — Surpresa: Automount funcionou para algumas partições (que já estavam marcadas há tempos).

• 18:02 - Marcadas as demais partições para KDE Automount. Restart.

• 18:06 - Início de sessão com Automount de todas as partições adicionais.

Nas demais distros com KDE 5.12, o problema se resolveu “espontaneamente”, num período de 3 a 5 semanas mais tarde, — e o exame dos pacotes atualizados ou instalado em cada uma dessas 4 distros talvez permita distinguir qual deles aparece justo na véspera de todos os casos:

5 Março - o Arch voltou a montar partições adicionais no início da sessão, automaticamente.

13 Março - o PCLinuxOS voltou a montar partições adicionais automaticamente.

18 Março - o KDE Neon voltou a montar partições adicionais automaticamente.

Configurações residuais do Packagekit, Plasma Discover e Unattended-upgrades

• Foram desabilitadas notificações e atualizações automáticas, — pela remoção dos pacotes Unattended-upgrades, PackageKit, — e por tabela, do Plasma Discover.

Permanecem suas configurações residuais, — o que facilita reverter à situação anterior, caso sejam reinstalados.

Opções de atualização no Muon Package Manager

Dias depois, foi desmarcada — no Muon Package Manager — a opção de atualizar as informações dos repositórios, 1 vez ao dia (automaticamente), coisa que costumava ocorrer logo no início da sessão.

Infelizmente, não foram registradas as configurações iniciais do Muon, — logo após a instalação do Kubuntu Bionic Beaver, — pois talvez bastasse desabilitar ali as unattended-upgrades.

Reload diário automático afeta a RAM inicial e bloqueia “sudo apt update”

A rotina é registrar o tempo de Boot e o uso de memória RAM no início da sessão, — em seguida, conferir atualizações (manualmente) pelo sudo apt update / apt list --upgradable, — e por fim, aplicá-las pelo Synaptic, — para tomar conhecimento do que se passa.

Duas ou três vezes por semana, são carregadas e atualizadas as distros que não tenham sido usadas no trabalho diário.

Heranças (/home)


Primeira sessão do Kubuntu 18.04 instalado, — com a /home de outra distro

A instalação do Kubuntu 18.04 LTS foi feita com aproveitamento da pasta /home/flavio utilizada antes pela “duplicata” (experimental) do PCLinuxOS, — com os mesmos identificadores UID=1000, GID=1000, porém várias diferenças na estrutura de arquivos (ocultos) de configurações de usuário.

Outras 2 experiências poderão ser tentadas:

(a) Instalar com uma /home vazia; e

(b) Instalar com um clone da /home do Kubuntu Xenial, — para tirar várias dúvidas.

Ao carregar pela primeira vez, portanto, o Kubuntu 18.04 se apresentou com o Wallpaper antigo; — atalhos PrtScn chamando gnome-screenshot (ainda não instalado) e mandando salvar em pastas /media/LABEL (em vez de /media/flavio/LABEL); — e Painel com vários espaços vazios onde deveriam estar o Menu, Centro de Controle (Drakconf, do PCLinuxOS), Chrome etc.

Daí, porque o gnome-screenshot foi instalado logo nos primeiros 2 minutos, — era mais simples do que reverter os atalhos para o KDE Spectacle, — e os caminhos (path) da salvação alterados para o padrão de pontos de montagem do Kubuntu.

O primeiro passo foi verificar todas as configurações, — corrigir o necessário (página inicial do Dolphin, p.ex.), — e documentar o que já estava conforme desejado:

2018-02-22

10:35 - NL - Boot verbose Kubuntu BB
10:38 - Kubuntu BB Panel PCLOS
10:39 - Kubuntu BB Dolphin mount path
10:39 - Dolphin start page
10:40 - apt install gnome screenshot
10:43 - System settings shortcut PrtScn
10:45 - System settings Keyboard
10:47 - System settings Compositor
10:47 - System settings Preferred Language
10:47 - Localizatio Numeric Currency Time Formats
10:47 - System settings Spell checker dictionaries
10:47 - System settings Time Zone
10:48 - System settings KWallet
10:48 - System settings User
10:49 - KDE System settings Automount
10:49 - System settings File search
10:50 - System settings Search Bar
10:51 - System settings Background services - Applications Menu
10:51 - System settings Login Logout
10:52 - System settings Desktop effects
10:52 - System settings Screen Corners Edges
10:52 - System settings Screen Locking
10:52 - System settings Fonts
10:53 - System settings Font Management
10:58 - less var log dpkg Pacotes existentes
11:10 - edit Panel add widget Menu
11:12 - Kate memoria
11:13 - Menu SEM Recentes Frequentes
11:14 - Conkyrc MountPoint Path
11:19 - Conky
11:20 - apt install lmsensors
11:22 - Menu icon Kubuntu
11:25 - Synaptic atualizaveis
11:25 - Synaptic Locales All Recomenda
11:26 - Synaptic Reload
11:27 - Synaptic updates
11:38 - Synaptic Gimp
11:40 - Synaptic sources
11:41 - Synaptic Configs
11:42 - Synaptic ttf mscorefonts
11:45 - killall conky
11:45 - re Conky Verdana
11:49 - Save session
11:50 - Menu Wine Dreamweaver
11:51 - Restart
11:53 - Boot verbose Kubuntu
11:54 - Startup unmounted geral
11:56 - Gimp QApt Lang Support incomplete
11:57 - Gimp Wallpaper
12:03 - Conkyrc colors
12:05 - Drakconf no Painel
12:11 - Automount disable all
12:17 - Synaptic ScreenRuler
12:22 - Synaptic PackageKit Remove Discover
12:25 - Synaptic Unattended upgrades Remove
12:36 - Wallpaper crop KInfocenter
12:40 - Chromium
12:51 - Keyboard
14:48 - CPU Facebook Page slow
14:48 - Facebook group Ok
14:55 - Conkyrc Colors
15:04 - Nokia USB cable connect
15:06 - Download photos
15:07 - KInfocenter
15:09 - Synaptic pyRenamer
15:12 - sensors detect
15:14 - QApt Batch Lang
15:17 - KDE Automount - check again
15:18 - Restart
15:23 - Startup manually mount
15:26 - Open Directory with pyRenamer

Teste construtivista (“na real”)


Quadro dos sistemas Linux, logo após a instalação do Kubuntu Bionic Beaver

Instalar o Kubuntu 18.04 LTS* Bionic Beaver daily-build foi um modo de não perder tempo com teste Live do Beta, nem teste Live do Beta2, nem teste Live do lançamento, — e muito menos, colocar em risco um Kubuntu 16.04 LTS* confiável e produtivo. — O novo Kubuntu foi instalado “ao lado” dele (dualboot).

Na prática, a instalação substitui vários testes, — mais trabalhosos do que compensadores, devido à curta duração (além de não serem “a mesma coisa”), — por um investimento mais consistente, ao longo de 2 meses:

Alpha 1           - Jan.,  4
Alpha 2           - Feb.,  1
daily-build.......  Feb., 21
Beta 1            - Mar.,  8
Final Beta        - Apr.,  5
Release Candidate - Apr., 19
Release           - Apr., 26

Quadro dos sistemas Linux instalados, 4 dias depois (26 Fev. 2018)

O objetivo é começar a enfrentar desde já os eventuais problemas do próximo Kubuntu 18.04 LTS*, — até deixá-lo 100% produtivo.

No mínimo, isso evita incertezas, — sempre presentes numa transição como essa, — e torna mais fácil a curva de aprendizado, readaptações, desafios.

E, na pior das hipóteses, fica preservado o velho e bom Kubuntu 16.04 LTS*.

* LTS = Long Term Service (Suporte de Longo Prazo). - São versões do Ubuntu / Kubuntu com 3 ou 5 anos de atualizações de segurança, — enquanto os lançamentos intermediários têm vida útil bem mais curta, de apenas 9 meses (3 trimestres), o que não chega a compensar o investimento em instalação, ajustes, aprendizado, pesquisa e solução de problemas. — Daí o pouco tempo dedicado ao Kubuntu 16.10 Yakkety Yak (Live, Install crash); ao Kubuntu 17.04 Zesty Zapus (Install, Clone / Move, Fix); e ao Kubuntu 17.10 Artful Aardvak (Live).

Slots modulares


Particionamento dos HDDs internos / SSD externo e seu uso por distros Linux

Isso foi possibilitado pelo particionamento dos HDDs e SDD em “slots” modulares compostos de 3 partições, cada (Raiz, /home, Swap), numerados de Linux1 a Linux12. — O Kubuntu 18.04 entra no slot Linux11, substituindo uma duplicata (experimental) do PCLinuxOS.

A rigor, as mudanças, problemas e desafios, nem são mais surpresas, — boa parte dessas novidades já se vêm manifestando no KDE Neon, no Debian testing, no Arch Linux, no PCLinuxOS.

A chamada “instabilidade”, — na verdade: fluidez, mudança constante, — há muito tempo também já deixou de ser um bicho-de-sete-cabeças.

  • O KDE Neon foi instalado ainda no início de seu desenvolvimento, e trabalhou muito bem, durante 9 meses (até ser destruído por acidente).
  • O Mint 18 KDE foi instalado ainda na fase Beta, e também trabalhou muito bem durante meses (até o upgrade para 18.1).
  • O Mageia 6 foi instalado ainda na fase sta2 (estabilização, anterior ao RC), e continua firme após 11 meses.
  • O Debian foi convertido em Testing há 1 ano e 4 meses, — muito antes do lançamento do Stretch. — Já virou Buster / Sid (nunca será estabilizado), e até hoje deu menos problemas do que algumas instalações anteriores do Jessie.
  • O Arch Linux é uma distro “rolling release”.
  • O openSUSE Tumbleweed também é “rolling release” e se mostrou muito sólido. — Só foi substituído porque enjoei de tantas atualizações, — e era redundante mantê-lo lado a lado com o openSUSE Leap. Bastava um. Optei pelo mais “calmo”, que desde o começo funcionou melhor e deu muito menos problemas. Além disso, já tinha investido muito mais nele.

Instalação


KSysguard e Watch Sensors para monitorar a instalação do Kubuntu 18.04 Bionic Beaver

A instalação do Kubuntu 18.04 LTS Bionic Beaver (development-branch) não apresentou novidades em relação às instalações anteriores do Kubuntu 17.04, do 16.04 LTS, do 14.04 LTS, ou do 12.04 LTS, — o Ubiquity segue as mesmas etapas, com as mesmas opções.

As únicas diferenças registradas, ao longo desses anos, decorreram de

  • passagem da conexão de 1 megas para 10 megas (1,28 MiB/s), antes de 2016;
  • aumento no número de partições (+HDD interno, +SSD externo) e de distros instaladas;
  • uso de CD / DVD ou USB

Em 2016, foi usado Pendrive (USB), — porém agora optei por DVD (para guardar), e isso deve exigir mais tempo ao copiar arquivos localmente.

O acréscimo de +1 HDD, +1 SSD, — com inúmeras partições e várias distros em "dualboot", — exige mais tempo a verificar espaços livres e a detectar outros sistemas na instalação do Grub; — além de mais trabalho manual para que cada nova distro não use as partições Swap das demais.

09:27 - Installer - English
09:27 - Installer - Portuguese
09:27 - Keyboard Layout
09:28 - Download updates / Third party software (Yes, yes)
09:28 - Unmount /dev/sdb?
09:29 - Dolphin - Unmount sdb
09:29 - Unmount /dev/sdb? (Yes) - Detecting partitions and free spaces (8 minutes)
09:33 - Active wired connection (verify)
09:34 - sudo apt install lm-sensors
09:36 - watch sensors (Konsole + KSysguard)
09:37 - Manual Partitioning
09:39 - Grub - MBR /dev/sdd
09:40 - Root partition - Format
09:41 - Home partition
09:42 - Swap partition
09:42 - Disable other Swap partitions
09:45 - Disable other Swap partitions (3 minutes)
09:45 - Root, Home, Swap partitions
09:46 - Write partitions to Disk? (Partitioning: 9 minutes)
09:46 - Localization (Time Zone)
09:47 - Copying files... 17%
09:52 - Copying files... 74% - PrintScreen fail (smartphone photo)
09:52 - PrintScreen Ok (5 minutes)
09:53 - User Name, Password, Auto-Login
09:54 - Slideshow — Grub from 9:59 to 10:09
10:14 - Slideshow (20 minutes)
10:14 - Install - Finish

Portanto, o tempo total foi de 47 minutos, — dos quais:

  • 08 minutos detectando partições existentes e espaços livres
  • 09 minutos no Particionamento manual, — dos quais:
  • 03 minutos des-selecionando 11 partições Swap (das demais distros)
  • 05 minutos copiando arquivos
  • 20 minutos na instalação propriamente (Slideshow), — dos quais:
  • 10 minutos verificando outros sistemas e atualizando Grub
  • 42 minutos nessas 4 etapas
  • 05 minutos em todas as demais etapas — de fato, há muito pouco a decidir e fazer

Com uma conexão rápida e apenas 1 HDD vazio, deve ser rapidíssimo.

Vale registrar que em algumas distros, como o Mageia, a atualização do Grub é 4 vezes mais rápida. — Leva apenas 2 minutos, — contra 8 minutos (ou mais) no Kubuntu 18.04, no KDE Neon e outras.

A grande diferença em relação à instalação do Kubuntu 16.04 LTS em 34 minutos pode ser atribuída a:

  • 41 partições em 4 HDDs / SSD a examinar, — e poucas em 2 HDDs naquela época
  • 11 partições Swap a desabilitar, — e nenhuma naquela época
  • Pendrive naquela época vs. DVD agora

Na “Preparação”, os 8 minutos de detecção de partições e espaços livres ficam marcados por intensa atividade de CPU, — e nenhuma atividade de rede, — desde a ordem de tentar desmontar sdb8 (previamente desmontado no Dolphin) até a apresentação das partições existentes e da proposta de como dar um jeito de arrumar espaço.

Esses 8 minutos foram aproveitados para conferir no Painel se havia conexão ativa (sim), — instalar rapidamente o lm-sensors, — e rodar watch sensors numa janelinha do Konsole, de modo a monitorar o aquecimento e outros indicadores.

A ver, por que a instalação do Kubuntu 17.04 Zesty Zapus levou apenas 21 minutos.

Histórico de pacotes


ISO: bionic-desktop-amd64.iso - de 2018-02-21

Instalação concluída em: 2018-02-22 às 10:14

Primeira sessão: 2018-02-22 às 10:38 - Wallpaper e Painel do PCLinuxOS (herança /home)

apt install


23  2018-02-22_10:40:03 sudo apt install gnome-screenshot
30  2018-02-22_11:16:35 sudo apt install conky-all
33  2018-02-22_11:20:21 sudo apt install lm-sensors                                                   
36  2018-02-22_11:23:27 sudo apt install synaptic

Synaptic


Thu Feb 22 11:28:31 2018 - Updates - KDE 5.12.1 para 5.12.2

Thu Feb 22 11:36:57 2018 - Install - Chromium

Thu Feb 22 11:38:27 2018 - Install - Gimp

Thu Feb 22 11:42:21 2018 - Install - ttf-mscorefonts-installer

Thu Feb 22 12:17:22 2018 - Install - ScreenRuler

Thu Feb 22 12:23:56 2018 - Remove - Packagekit, Plasma-Discover

Thu Feb 22 12:25:21 2018 - Remove - Unattended-Upgrades

Thu Feb 22 15:08:11 2018 - Install - KRename

Thu Feb 22 15:08:55 2018 - Install - pyRenamer

Notify > Script > QApt Batch Installer (Lang Pack incomplete)
2018-02-22 15:52:35 install gimp-help-common:all <none> 2.8.2-0.1
2018-02-22 15:52:36 install gimp-help-pt:all <none> 2.8.2-0.1

Thu Feb 22 16:21:07 2018 - Updates - Kernel 4.15.0-10 (4.15.0-10.11)

Sat Feb 24 07:14:24 2018 - Updates - Apps (4:17.08.3-0ubuntu2) to 4:17.12.2-0ubuntu1

Sat Feb 24 07:18:23 2018 - Install - Konqueror, KFind

Sat Feb 24 07:52:58 2018 - Install - Dolphin4

Sat Feb 24 07:59:42 2018 - Remove - Akregator

Sat Feb 24 09:34:02 2018 - Remove - Kernel 4.15.0-10

Sun Feb 25 04:52:55 2018 - Updates - udev (235-3ubuntu3) to 237-3ubuntu3 (...)

Sun Feb 25 04:57:08 2018 - Install - fuse2fs

Sun Feb 25 05:10:15 2018 - Install - fuseiso

Sun Feb 25 05:13:11 2018 - Install - fuseiso9660

Sun Feb 25 05:21:00 2018 - Install - kde-service-menu-fuseiso

Sun Feb 25 05:30:08 2018 - Install - libkonqsidebarplugin4a

Sun Feb 25 05:34:32 2018 - Install - konq-plugins

Sun Feb 25 05:41:34 2018 - Install - k4dirstat

Sun Feb 25 06:09:23 2018 - Install - kdiff3

Sun Feb 25 06:12:36 2018 - Install - ffmpeg

Sun Feb 25 16:40:25 2018 - Updates - ippusbxd, printers

Sun Feb 25 17:15:27 2018 - Install - bzip2-doc, p7zip-rar, unar

Sun Feb 25 18:21:58 2018 - Install - printer-driver-cups-pdf

Sun Feb 25 18:55:17 2018 - Install - hunspell, libreoffice-lightproof-pt-br

Mon Feb 26 17:59:25 2018 - Updates - ...

Tue Feb 27 08:11:22 2018 - Updates - ...

Tue Feb 27 11:16:34 2018 - Install - mc

Wallpaper


Goiás (velho) e a Serra Dourada ao amanhecer

Goiás (velho) e a Serra Dourada, by Josue Marinho, ao amanhecer (6:41), 3 Abr. 2016.

Não foi encontrado Gimp na sessão Live DVD, durante a qual foi usada a imagem original.

Depois de instalado no HDD, o Gimp foi usado para aplicar alguns ajustes: Colors > Auto > White balance, Stretch contrast, Stretch HSV e (talvez) Color enhance.

Esses 4 ajustes automáticos são tentados nessa ordem, recuando em qualquer um deles que faça mais do que apenas “limpar” algum excesso de infra-vermelho, ultravioleta (como faria um bom filtro físico ou de software na câmera); ou alguma “perda” por lentes de menor qualidade relativa. Mas a decisão é subjetiva, claro.

Enfim, a imagem foi cortada (Crop) para eliminar a faixa inferior com a data e a hora; Exportada (Ctrl-E); e aplicada à Área de trabalho no formato Scaled and Cropped para evitar distorção (corte do excedente nas laterais).

Configuração final do Conky no arquivo (oculto) ~/.conkyrc

Para que a primeira linha do Conky ficasse legível contra o fundo quase branco, foi utilizada uma cor diferente nessa linha (fechando o atributo no final):

${color cornsilk2}${font verdana:size=24}Kubuntu 18.04${font}${color}

Mais tarde substituído por um tom um pouco mais “dourado”:

${color palegoldenrod}${font verdana:size=24}Kubuntu 18.04${font}${color}

Para destaque do restante, contra inúmeras cores no fundo:

# Default colors and also border colors
default_color mintcream
default_shade_color cornsilk4

A escolha de mintcream dá um tom levemente azulado que ajuda a distinguir as letras e gráficos contra diferentes cores de fundo. Neste caso, o sombreamento preto (ou default) parece afinar as letras, dificultando a leitura; — ao passo que qualquer tom mais claro do que cornsilk4 parece inchar demais as letras, deixando-as meio borradas (apesar do maior destaque).

Mesmo cornsilk4 ainda deixava as letras borradas (apesar do maior destaque) e mais tarde foi substituído por gray20:

default_shade_color gray20

Obs.: Os scripts do Conky ainda não foram convertidos para a sintaxe da versão 1.10.

— … ≠ • ≠ … —

Kubuntu


sexta-feira, 16 de fevereiro de 2018

Devuan 2.0 “ascii” Beta KDE

Devuan 2.0 “ascii” Beta instalado e atualizado

• O Devuan 2.0.0 “ascii” Beta foi lançado em 14 Fev. 2018, — no 3º aniversário do Devuan 1.0 “jessie” Pre-Alpha, lançado em 2015, — e menos de 9 meses após a edição 1.0.0 final.

Representa, portanto, uma “aceleração”, após um desenvolvimento inicial bem mais difícil e demorado.

Índice


  • KDE (Testing)
  • SDDM e Auto-Login
  • KWallet
  • Synaptic
  • Kernel & updates
  • Montagem de partições adicionais
  • Funcional
  • Migrar ou reinstalar
  • ISO, sha256sum, K3b
  • Velocidades e demoras
  • Instalação (I e II)
  • Particionamento
  • Pacotes
  • Grub
  • Utilitários e desastre
  • Particionamento
  • Debian installer
  • Wallpaper

KDE (Testing)


KDE Plasma, Cinnamon e LXQt “testing” no Devuan 2.0 “ascii” Beta

Abstraindo questões mais “técnicas”, o que me interessou de imediato foi a possibilidade de instalar o Devuan com KDE Plasma 5, — pois não consegui me adaptar ao Xfce (default) nem ao MATE, — o que, para mim, limitou muito a possibilidade de seu uso no trabalho diário.

Essa implementação do KDE Plasma 5 no Devuan 2 “ascii” Beta ainda está em fase de testes, — assim como as do Cinnamon e do LXQt, — e nesses 11 dias já encontrei vários pequenos desafios, que com certeza tendem a ser corrigidos nos próximos meses.

Esses pequenos desafios se vêm somar a vários outros, do Debian, — que em 10 anos ainda não aprendi a solucionar, — mas alguma coisa no Devuan 2.0 “ascii” Beta trouxe de volta a vontade de insistir mais. Talvez alguma leve fragrância de “without-systemd” (fora do meus limitados conhecimentos); ou mais provavelmente, a novidade do brinquedo.

SDDM e Auto-Login


Seleção do gerenciador de sessão SDDM ao instalar o Devuan 2.0 “ascii” Beta

Um desses pequenos desafios foi conseguir Login automático, — com o gerenciador de sessão (display manager) SDDM, — que venho usando em todas as distros instaladas.

Login automático pelas Configurações do sistema “não pega”

Nas distros que uso há 10 anos (Kubuntu, Mint), o Login automático (no Boot) pode ser habilitado durante a instalação, — ou mais tarde, nas Configurações de sistema (KDE System settings). — Ao “Aplicar” essa opção, é solicitada senha, e já está valendo.

Em outras distros (openSUSE, Mageia, PCLinuxOS), — o KDE System settings não pede senha ao “Aplicar” essa opção, e a mudança “não pega”. Você sai das Configurações de sistema, e ao voltar verifica que está desmarcada outra vez. — No openSUSE, o que de fato funciona é exercer essa opção através do YaST2 (que pede senha antes de abrir). — Nos “derivados” do Mandrake / Mandriva, o que de fato funciona é fazer essa opção através do Centro de Controle (senha antes de abrir); exceto no Rosa, que incorporou o CC como uma seção do System settings.

No Devuan 2 Beta KDE, ao “Aplicar” essa opção, não foi pedida senha, — a opção “não pegou”, — e como nele não existe nada similar ao YaST2 ou ao CC, restava examinar os arquivos de sistema.

Arquivo de configuração gerado pelo comando “sddm --example-config > /etc/sddm.conf”

A definição do auto-Login (com Usuário-padrão e sessão-padrão) deveria estar em um arquivo /etc/sddm.conf, — mas ele não existia, — e reinstalar o SDDM pelo Synaptic não acrescentou nada.

Esse arquivo de configuração foi criado, então, — como Root, — pelo comando:

   19  2018-02-17_14:00:30 sddm --example-config > /etc/sddm.conf

Edição do /etc/sddm.conf pelo mcedit em modo Root

A edição do /etc/sddm.conf foi feita pelo editor interno do Midnight-Commander (mcedit) em modo Root e se limitou ao acréscimo de 2 parâmetros: Sessão e Usuário para Auto-Login:

   [Autologin]
   # Whether sddm should automatically log back into sessions when they exit
   Relogin=false
   
   # Name of session file for autologin session
   Session=plasma.desktop
   
   # Username for autologin session
   User=flavio

No primeiro caso, não adianta tentar os nomes de fantasia “Plasma” ou “Default Xsession” mostrados pelo System settings, — os parâmetros válidos são os arquivos existentes na pasta /usr/share/xsessions.

Mantive desativado o Relogin, — padrão adotado por precaução, desde a instalação do Slackware, — para não cercear a possibilidade de testar eventuais opções.

Referências



KWallet


Aviso ininteligível ao tentar desativar o KWallet nas Configurações do sistema

No caso do KWallet, sim, as Configurações do sistema “percebem” (acho) a necessidade da senha de Administrador, — mas o aviso que apresenta (colapsado) não pode ser redimensionado, portanto não pode sequer ser lido. — Beco sem saída.

Felizmente, só é chamado (2 vezes) ao abrir o Chromium. — Segue a vida, por enquanto.

Synaptic


Solução provisória — abrir Synaptic por comando

Mais uma vez, o Plasma Discover se mostrou inviável, — bastou abrir para disparar um surto de abuso de CPU, — e o Synaptic foi sumariamente instalado por comando “apt install”.

Não adianta chamá-lo pelo Menu, — ele faz que vai, mas não abre. — Como não é problema capaz de atrapalhar o trabalho, a alternativa provisória é chamá-lo pelo Konsole.

Kernel & updates


Status de proteção similar ao das demais distros Linux instaladas

Desde o primeiro Boot, o Devuan 2 Beta já exibiu no Painel uma notificação de atualizações, — na verdade, apenas uma atualização: do Kernel 4.9.0-4 para 4.9.0.5 (ou de 4.9+80+deb9u2 para 4.9+80+deb9u3), — com instalação simultânea de 2 pacotes “firmware-linux-free” e “irqbalance”.

Desde então (15 a 26 Fev. 2018) não houve mais nenhuma atualização, — o que não chega a espantar, pois o Devuan 1.0 Xfce também sempre teve poucas atualizações, bastante espaçadas.

O apt / Synaptic do Devuan 1.0 Xfce registrou apenas 36 atualizações (1+ pacotes, cada), ao longo de 7 meses completos, de 13 Jul. 2017 até 15 Fev. 2018, — o que dá uma média de 5 pequenas atualizações por mês.

Diferenças entre as instruções de upgrade e os repos do Devuan 2 Beta recém-instalado

Fica para estudo o porquê de vir com apenas 2 repositórios, — em desacordo com as instruções de upgrade:

deb http://deb.devuan.org/merged/ ascii main
deb http://deb.devuan.org/merged/ ascii-security main non-free


Montagem de partições adicionais


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

O Devuan KDE apresentou comportamento semelhante ao do Debian KDE em 2 quesitos, no que se refere à montagem de partições adicionais, — ou seja, aquelas que não são do sistema (“/”), nem /home, nem Swap deles mesmos:

  • Não basta clicar nelas, pelo Dolphin, para montá-las pelo udisks2
  • Não adianta marcá-las para montagem automática (início de sessão) pelas Configurações do sistema (KDE System settings > Removable devices), que também usam udisks2

Essa dificuldade ainda não foi objeto de investigação e pesquisa no Devuan. — Isso fica para os próximos meses, — uma vez que 2 anos ainda não foram suficientes para resolvê-la no Debian, e é muito possível que a solução acabe por ser comum a ambos.

Uso do Disk Manager para configurar a montagem automática de partições adicionais no Devuan KDE

No Debian, o problema vem sendo provisoriamente contornado pelo Disk Manager (Root), — que faz a montagem instantânea, permite editar os pontos de montagem (path), e grava essas configurações no /etc/fstab, tornando-as permanentes.

Arquivo /etc/fstab com as partições adicionadas pelo Disk Manager

Em resumo: — O Disk Manager dispensa editar o /etc/fstab “na unha”, e assim se evitam possíveis erros de digitação ou de sutilezas técnicas na escolha dos parâmetros.

Esta solução provisória, — usando identificador UUID das partições, — tem 2 inconvenientes:

  • O Debian não completa o Boot, caso qualquer uma das partições tenha sido formatada, com alteração do identificador UUID, — nem há como chegar ao Disk Manager, sem carregar o Debian. — Quando isso acontece, “basta” logar como Root no tty onde aparece a mensagem de erro, e desabilitar no /etc/fstab as linhas que contêm UUID inválidos. Depois disso, o Debian carrega, e basta usar o Disk Manager para gerar outra linha, com UUID correto. Felizmente, formatar partições dos HDDs internos é coisa que só acontece de vez em quando, ao substituir uma distro por outra.
  • É impraticável incluir no /etc/fstab a montagem de partições do SSD externo, — que não fica plugado o tempo todo.

Uma alternativa seria trocar a identificação por UUID pela identificação por “/dev/sXY”, ou por Label, — mas o SSD externo pode oscilar entre /dev/sdd e /dev/sde, — e às vezes acontece de uma partição ficar sem Label, por distração, ao ser formatada.

Diferentes autorizações para montagem de partições em HDDs e SSD / USB

Porém no Devuan, por puro acaso, ficou evidente que a montagem pelas Configurações do sistema (udisks2) funciona, sim, para as partições do SSD externo.

Uma pista: - Em etc/group, o Usuário está em plugdev, mas não em disk:

plugdev: Allows members to mount (only with the options nodev and nosuid, for security reasons) and umount removable devices through pmount.

disk: Raw access to disks. Mostly equivalent to root access.

Mudar isso (sem estudar metade de todo o Linux) é como usar canhão para abrir uma porta. Existem modos menos estúpidos. — Enfim, no Debian KDE, pede-se a senha, a montagem é feita (enquanto durar a sessão), mas o Usuário não fica autorizado a destruir nada. — No Devuan 2.0 Beta KDE, talvez falte pedir a senha (como nos itens observados acima).

Foi adotado, então, uma configuração mista: — Por /etc/fstab para os HDDs internos, — e por udisks2 para as partições do SSD externo.

Falta conferir se isso funcionará também no Debian KDE.

Pontos de montagem observados no Devuan 2.0 Beta KDE

O resultado desse conjunto de decisões, — e de várias outras, ao longo dos últimos anos, — pode ser examinado na pasta /media.

Os pontos de montagem (path) das partições adicionais do SSD externo foram deixados no padrão /media/$USER/Label, usado pelo udisks2.

Em outras distros, esse padrão é configurado no arquivo /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"

Acontece que esse arquivo não existe no Devuan 2.0 Beta KDE instalado aqui, — nem no Debian KDE, — e pequenas diferenças como essa desaconselham sair copiando “soluções” de outras distros, sem estudar primeiro (ou pelo menos, fazer alguns testes controlados e observar os resultados).

Já o Disk Manager “preferiu” usar o padrão /media/Label, — que também prefiro, por ser mais simples, — mas isso pode ser alterado manualmente, caso a caso; e é provável que também possa ser configurado globalmente.

Vale notar que os pontos de montagem das partições Home e Raiz das demais distros pertencem ao Administrador (Root), — o que faz todo sentido, — mas dentro das pastas [Home]/flavio o usuário “flavio” pode gravar à vontade.

Não é que todas considerem esse nome simpático, — hipótese não de todo impossível, claro, — mas em todas essas distros o Usuário tem o mesmo identificador UID=1000; por isso todos os respectivos arquivos pertencem ao UID=1000; e qualquer usuário UID=1000 é recebido como se fosse o próprio (ainda que usasse outro nome).

Porém, não arrisco afirmar que seja “natural”, o fato de os pontos de montagem (path) de todas as partições de dados, — Armazem1, Armazem2, Sites, Works, XTudo, — pertencerem ao usuário “flavio” (aliás, ao usuário UID=1000).

É possível que isso não tenha caído do céu, — devido a um hipotético padrão seguido por todas as distros Linux. — Apenas, não lembro exatamente quais providências foram tomadas para garantir que fosse assim (nem posso afirmar que tais providências de fato fizeram diferença).

Enfim, em algumas distros instaladas esses pontos de montagem são pastas permanentes, — embora vazias, quando olhadas “de fora” (a partir de outra distro ou sessão Live), mas com data da última vez em que foram usados, — enquanto em outras distros eles só são criados ao iniciar uma sessão.

Funcional


Quadro comparativo das distribuições Linux instaladas

Se o objetivo desse registro é preservar a memória dos desafios, — e das soluções (quando encontradas), — isso não significa que só existam problemas.

Pelo contrário! — Considero definitivamente incorporado ao conjunto de distros para uso regular.

No todo, o Devuan 2 Beta KDE está bastante funcional, — se sai muito bem na comparação com as demais distros instaladas. — Trabalho nele dias inteiros, sem incômodos nem frustrações, apesar do pouco tempo dedicado à pesquisa e aos ajustes, sempre necessários quando um leigo começa a trabalhar com algo que ainda não conhece.

  • Fácil encontrar e instalar novos pacotes pelo Synaptic
  • Chromium, Gimp, LibreOffice etc. sem qualquer falha
  • Baixar fotos do celular (via cabo USB)
  • Renomear fotos em massa pelo pyRenamer
  • Konqueror já se instalou com as funcionalidades esperadas
  • Conversão PNG / JPEG
  • Abrir ISO com Ark
  • Modo de exibição “tamanho de arquivos”
  • Barra lateral (F9)
  • KFind
  • Montagem automática de partições “removíveis” (SSD)
  • E o melhor de tudo: — Nenhum crash percebido em 11 dias

Migrar ou reinstalar


Seria uma experiência fascinante, migrar do Devuan 1.0 para o 2.0 Beta, — as instruções parecem bem objetivas e claras, — mas não quis me engajar na etapa que viria depois, ou seja, instalar KDE e remover por completo o Xfce.

Aliás, se tivesse feito isso, agora estaria atribuindo as falhas do “KDE (Testing)” a algum erro na migração, ou a uma hipotética interferência do Xfce removido, ou a uma má implementação manual do KDE Plasma.

Por isso, decidi reinstalar, — começar com uma partição de sistema totalmente “limpa”.

Também pensei em deletar a /home do usuário Xfce (guardando uma cópia), — para criar outra inteiramente nova, — mas acabei esquecendo.

Na prática, porém, todas as pastas visíveis da antiga /home foram “zeradas” (não sobrou nem Wallpaper), — mas sobreviveram inúmeras pastas e arquivos ocultos, — de modo que o bash “lembra” todos os comandos usados no Devuan 1.0 Xfce (manteve até a datação, que segue ativa); o Conky já carregou com a configuração anterior (bastou fazer alguns ajustes); e assim por diante.

Numa segunda instalação, dias depois, as pastas da /home mantiveram todo seu conteúdo, — Wallpapers e ícones, por exemplo, — assim como as configurações (arquivos ocultos) do KDE Plasma e dos aplicativos. Já carregou com quase tudo configurado, bastando reinstalar o Chromium, gnome-screenshot etc., para continuar trabalhando como na véspera.

ISO, sha256sum, K3b


Verificação sha256sum da imagem ISO do Devuan 2 “ascii” Beta

A experiência recente de instalar e configurar o Devuan 1.0 Xfce e MATE mostrou que as imagens ISO “Desktop-Live”, — com Refracta Installer, — só são adequadas quando se opta pelo Xfce (default), além de exigirem que as configurações sejam feitas antes de iniciar a instalação (aliás, desde antes de iniciar a sessão Live).

Por outro lado, as imagens “Installer-ISO” tamanho CD (3 CDs) ou DVD não são recomendadas para Desktop. — Por isso, foi usada a ISO “Net-Installer” (netinst), de menos de 300 MiB, — que exige download de grande número de pacotes durante a instalação.

Velocidades e demoras


14 Fev. 2018 - Dessa vez, não consegui encontrar o Torrent, — e nas primeiras tentativas a velocidade de download do Repositório (principal?) prometia demorar muito. — Como os Mirrors se distribuem ao redor do planeta, podia levar até 24 horas para que todos sincronizassem as novidades.

Esse é um fator a levar em conta, ao avaliar a usabilidade de distros menos populares. — O Rosa Desktop Fresh, por exemplo, com frequência demora para obter até os índices dos repositórios. — No caso do Devuan, tenho esperança de que mais instituições acabem aderindo, de modo a aumentar o número de Mirrors no Brasil.

Problemas locais de conexão também acontecem, — mas ao longo do tempo ficaram claras algumas diferenças de uma distro para outra, — inclusive devido ao hábito de carregar e atualizar todas, uma após outra, num período de poucas horas, 2 ou 3 vezes por semana.

15 Fev. 2018 - Felizmente, no dia 15 encontrei Mirrors atualizados, — escolhi um da Holanda, — com velocidade suficiente para cobrir a conexão local de “10 megas” (1,3 MiB/s), apesar da distância.

Feita a verificação “sha256sum”, a imagem foi gravada em CD, — a instalação transcorreu sem falhas, — e após reiniciar, o Devuan 2.0 “ascii” Beta KDE funcionou maravilhosamente.

Instalação (I e II)


A primeira instalação levou 1h 50min, — com 3 etapas mais demoradas respondendo por 1h 19min do total:

16:03 - Menu do Net-Installer
16:10 - Particionamento manual - começo
16:21 - Particionamento manual - fim (11 minutos)
16:24 - Escolher Mirror próximo de você ─ br.deb.devuan.org
16:25 - Repositório especificado “não suporta sua arquitetura”!
16:26 - Escolher outro Mirror — deb.devuan.org
16:29 - Popularity contest? — Package usage survey - Yes
16:30 - KDE (check) - Devuan DE, Print server, Utilitários do sistema padrão (uncheck)
16:31 - Obtendo 1.549 pacotes - (47 minutos)
17:18 - LightDM ou SDDM
17:27 - Instalação do Grub - começa (9 minutos) - clique errado
17:36 - Instalação do Grub - recomeça (12 minutos)
17:48 - Configurando ajustes de Relógio
17:53 - Instalação concluída - remover mídia

17 Fev. 2018 - Dois dias depois, uma nova instalação foi muito mais rápida, — 59 minutos, — com aquelas 3 etapas respondendo por 31 minutos do total:

9:16 - Menu - Graphical Install
9:18 - Lang
9:18 - Locale
9:18 - Keyboard
9:19 - Hostname
9:20 - rede
9:20 - Root passwd
9:20 - User
9:21 - Clock
9:21 - Clock Brasilia
9:22 - Manual partitioning
9:23 - Disable 11 Swap
9:25 - Root partition
9:27 - Format 2 partitions (5 minutos)
9:27 - Install basic system
9:30 - Another CD / DVD? No
9:30 - Mirror: Brasil
9:31 - Mirror br.deb
9:31 - proxy
9:31 - Mirror br.deb OOPS
9:32 - Mirror Brasil
9:32 - 3rd Mirror Brasil
9:32 - Proxy?
9:32 - Config APT
9:34 - Popularity contest? Yes
9:34 - Tasksel original
9:35 - Tasksel custom - (KDE + standard system utilities)
9:35 - install 1584 packages
9:47 - install 1584 packages - end (12 minutos)
9:47 - SDDM
9:56 - Grub (14 minutos)
10:01 - Grub MBR Yes
10:01 - Grub to sdd
10:07 - Grub
10:10 - ajusta Relogio
10:13 - ajusta Relogio
10:14 - System Clock: UTC
10:15 - Install finished

Com toda certeza, a velocidade de download dos pacotes foi muito maior, — o exame das etapas percorridas permitiu eliminar erros e hesitações, — e a soma de todos os demais passos caiu de 31 para 28 minutos.

Particionamento - Um “particionamento manual” que não passa da escolha de 3 partições já existentes, — e formatar 2 delas, — não é tarefa para se gastarem 11 minutos.

O tempo de 5 minutos, na segunda instalação, é mais razoável.

Como a tarefa não envolve download, a diferença faz pensar que no primeiro dia o operador estivesse muito destreinado, após 2 meses sem instalar Devuan. — De fato, houve várias pequenas perdas de tempo, por não lembrar certas idiossincrasias do “Debian installer”.

O restante desse tempo se deveu à necessidade de o particionador detectar 40 partições, espalhadas em 3 HDDs internos (2 deles bem antigos) e 1 SSD externo também não muito novo (USB2).

Manualmente, também foi preciso desmarcar 11 partições Swap, — dezenas de cliques, idas e vindas, — pois o padrão do “Debian Installer” é selecionar todas, sem perguntar nada; e só no final apresentar um “resumo” com pencas de mudanças a serem gravadas em disco. Aí, é preciso voltar atrás e desmontar a bomba.

Cabe ao usuário saber que isso acontece e vai dar problema, — no mínimo, terá de corrigir o arquivo /etc/fstab das outras 11 distros, pois essa “formatação” muda o UUID de todas as partições Swap. — Além disso, precisará descobrir onde fica registrado o “resume-device” de cada distro (bastante diferenciadas entre si), e corrigir cada UUID também nesses arquivos de sistema. Com sorte, não precisará atualizar initramfs, nem initrd, ou coisa pior (em alguns casos, “basta” reinstalar o Kernel para incorporar o novo UUID). Enfim, atualizar o(s) Grub(s), caso isso não ocorra ao longo do processo.

Acredite, — vale a pena lembrar que o “Debian Installer” tem essa mania, — e investir alguns minutos, agora, para evitar um trabalhão, depois.

Pacotes - Uma baixa taxa de download é a hipótese mais óbvia para a demora de 47 minutos em baixar e instalar 1.549 pacotes, na primeira instalação, — contra 1.584 pacotes em apenas 12 minutos, na segunda.

Grub - A necessidade de examinar outras 11 distros, espalhadas em 40 partições, pode ser a causa do longo tempo gasto na etapa de instalação do Grub (12 minutos), — e para piorar, tinha clicado em algum botão errado, na primeira tentativa (9 minutos). — Foi necessário recomeçar essa etapa.

No entanto, na segunda instalação esse tempo foi até maior, — 14 minutos, — mesmo sem cometer erro algum.

De fato, um simples “update-grub” costuma ser muito demorado, em algumas distros (mais de 10 minutos no KDE Neon), — e muito mais rápido em outras (2 minutos no Mageia 6).

Em algumas distros (como KDE Neon, PCLinuxOS, e também Devuan 2.0), o Grub não detecta ou não gera entradas do openSUSE, — provavelmente por falta de algum pacote ou arquivo complementar de configuração (embora montem normalmente as partições BtrFS / XFS). — O Grub do Mageia é o único que consegue carregar o openSUSE.

Utilitários e desastre


Primeira instalação, — sem os “Utilitários de sistema padrão”

Naturalmente, instalar com sucesso, logo de primeira, — e funcionar maravilhosamente, em seguida, — era bom demais, para durar. Tinha de arranjar um desastre qualquer!

Logo comecei a alimentar uma dúvida, — se não teria cometido um erro, ao des-selecionar os “Utilitários de sistema padrão” (standard system utilities). — Quem sabe, não era a falta deles que causava pequenas dificuldades aqui e ali?

Final feliz: — Instalar de novo

Tentei corrigir isso pelo Tasksel, — descobri que essa opção não estava disponível, — e como não podia deixar de ser, fiz alguma coisa muito errada.

Ao perceber o erro, já estava removendo todo o KDE, — e nem o apt / dpkg / tasksel voltaram a funcionar. — Aliás, após fechar o Konsole, ele também não abria de novo. Tinha ido embora.

Fim da primeira instalação, — o jeito foi instalar pela segunda vez.

Em tempo - Incluir essa opção na instalação seguinte não alterou em nada aqueles pequenos desafios. Nada a ver com nenhum deles.

A dúvida sobre esse conjunto de utilidades já tinha me ocorrido em instalações anteriores, — mas com a ISO “netinst” não há como pesquisar na hora, e depois sempre esquecia.

Dessa vez, não deu mais para esquecer, e acabei encontrando a resposta em “What's the consequences if I don't install the “standard system utilities” of Debian?”, — que aproveita para remeter à página do Tasksel:

This task is available only during the installation, it contains the following packages:

# tasksel --task-packages standard
~pstandard
~prequired
~pimportant

Particionamento


Nenhum mistério no “particionamento manual”

Embora escolha sempre a opção de “Particionamento manual”, — que outras distros chamam de “Expert” ou de “Avançado”, — não realizo nenhuma operação cabalística, nem qualquer salto triplo mortal.

Particionamento concluído há 12 meses, — feito para durar bastante tempo

As mesmas 41 partições existem há exatos 12 meses, — e me limito a escolher 3 delas, para “/” (raiz), /home e Swap.

  • A partição “/” (“sistema”, “raiz”, ou “root”) é sempre formatada, — para eliminar qualquer traço de sistemas anteriores.
  • Sempre que possível, evito formatar a /home, para não ter de refazer as configurações pessoais, — que ficam na Pasta do Usuário (/flavio). — Se criar um novo Usuário (digamos, “Visitante”), é claro que terá as configurações-padrão, inicialmente.
  • A partição Swap só é formatada quando a distro exige.

Afora isso, as pastas /home não são usadas para documentos de trabalho, — apenas Wine e seus aplicativos (ex-Windows), Wallpapers, alguns ícones etc., — de modo que não exigem backup de última hora, caso uma delas precise ser formatada.

Portanto, ao escolher “particionamento manual”, não me refiro a nenhuma “reorganização” dos espaços, — que foi feita “para durar”, independente das distros a serem instaladas, — facilitando a substituição de qualquer distro, sem afetar as demais:


Mudanças superficiais em 1 ano, — agora com Devuan 2 Beta e Kubuntu Bionic daily-build

Apenas no caso do openSUSE, experimentei os sistemas de arquivo BtrFS e XFS, — nenhum problema em 13 meses, desde Janeiro 2017. — Mas, ao substituir um Tumbleweed pelo PCLinuxOS, suas partições foram re-formatadas, de volta para ext4.

Graças à idade do hardware (10+ anos), ainda não precisei quebrar a cabeça com GPT, UEFI, — nem com “travas” inventadas para manter o “consumidor” algemado a um sistema pré-instalado “de fábrica”. — Também não há qualquer “selo” ou “garantia” travando o hardware: o gabinete vive aberto, “pegando poeira”; e se a ventoinha fizer barulho, nada o abafa.

Descartadas as primeiras 5 opções — e desativar 11 das 12 partições Swap

Por isso, não havia nada a fazer com as primeiras 5 opções dentro do “Particionamento manual”.

Era o caso de rolar a tela, para desativar 11 das 12 partições Swap que o “Debian Installer” selecionou automaticamente, — ao longos dos 3 primeiros HDDs (sda, sdb, sdc).

O trabalho começou a 1/3 da rolagem vertical — onde estavam as primeiras 6 partições Swap a desativar

Desativar 1 partição Swap selecionada pelo Debian Installer é coisa rápida, — embora exija vários duplo-cliques. — Portanto, “bastava” fazer 11 “coisas rápidas”, mediante dezenas de cliques duplos.

Repita comigo — de 1 a 11:

  • Duplo-clique em 1 partição Swap para configurar
  • Duplo-clique em “Usar como Swap”, para alterar isso
  • Duplo-clique em “Não usar”
  • Duplo clique em “Finalizar a configuração da partição”
  • n=n+1
  • Da Capo

Adicionar legenda

Enfim, o mais importante: — Selecionar as partições a serem configuradas como “/” e “/home”.

  • Duplo-clique em cada uma das duas, para configurar
  • Duplo-clique em “Usar como”, — caso não estivesse indicado ext4
  • Duplo-clique em “Ponto de montagem”, — escolher “/” ou “/home
  • Duplo-clique em “Formatar”, — no caso da “/
  • Duplo-clique em “Rótulo”, — “Linux12”, no caso da “/
  • Duplo-clique em “Finalizar a configuração da partição”

Esse rótulo é importante, na medida em que todas as distros instaladas usam pontos de montagem tipo “/media/Linux12” — ou “/media/flavio/Linux12” — ou “/run/media/Linux12” — e qualquer desvio desse padrão exigiria vários ajustes nas outras 11 distros.

É verdade que existe “formatação” e “formatação”, — depende dos padrões adotados por cada aplicativo, distro ou instalador.

Algumas vezes, por exemplo, “formatar” implica em mudar até o identificador UUID da partição, — e isso afeta outras distros, nas quais você use /etc/fstab para a montagem de partições adicionais. — Daí minha preferência pelo udisks2, sempre que possível, pois me parece que usa informações automaticamente atualizadas.

Outras vezes, “formatar” não afeta, sequer, o Rótulo da partição, — mas na dúvida, prefiro me garantir.

Partições usadas: sdd3, sdd7, sdd11 (SSD externo)

O mais importante, portanto, — partições a serem configuradas como “/” e “/home”, — estava no final da rolagem, por se tratar do “sdd” (SSD externo).

As letras “F” indicam “formatar” — e “K” indica o contrário (keep, preservar). — Nenhuma indicação quanto ao Rótulo. Na dúvida, é melhor dar mais um duplo-clique e conferir.

Feito tudo isso, não adianta clicar em “Continuar”, — pois vai receber um aviso de que não escolheu partição nenhuma!, — e ao “Voltar”, ainda arrisca a ter de recomeçar do zero… Detectar 40 partições, escolher “Particionamento manual”, e fazer tudo isso de novo.

Na verdade, o passo mais garantido é duplo-clique em “Finalizar o particionamento e escrever as mudanças no disco” (o processo avança sem necessidade do “Continuar”).

Depois disso, ainda se apresenta um resumo das operações que serão realizadas. — Se não estiver tudo dentro do planejado, clique em “Voltar” e corrija.

Debian installer


Pela tecla “Voltar”, às vezes chega-se ao Roteiro completo, — incluindo opções fora do roteiro típico

Não tenho expertise bastante para avaliar se os desenvolvedores do Devuan fizeram algumas adaptações no Debian Installer, — e quais, — ou se, após usá-lo inúmeras vezes, nos últimos 10 anos, meus miolos se degeneraram a tal ponto que não lembre o suficiente, sequer, para repetir o êxito obtido em Novembro, ao instalar o Devuan 1.0 MATE.

E no entanto, todo o hardware, bem como o número de partições, são os mesmos, há mais de um ano. — Nenhum motivo para que as telas da etapa de particionamento, por exemplo, sejam, hoje, diferentes das de 3 meses atrás.

Talvez esteja na hora de procurar o maior número de tutoriais sobre o Debian Installer, que puder encontrar, e ler com muita atenção, — pode haver vários detalhes que nunca percebi, ou entendi errado.

Por princípio, é mais seguro um clique-duplo em qualquer opção, — do que apenas selecioná-la e clicar em “Continuar”, — pois foi encontrado pelo menos um caso em que isso não deu certo.

Para isso, no entanto, é indispensável sempre rolar até o final de cada tela, — e examinar todas as opções existentes, com muita atenção, — pois é comum que a última delas seja requisito para poder prosseguir, sem que se percam as opções já feitas na parte superior da tela.

Wallpaper


O Recife visto de Olinda

O Recife visto de Olinda, em Vista do Sítio Histórico de Olinda, by Passarinho / Pref. Olinda.

Wikimedia: Categories: Igreja e Mosteiro de São Bento in Olinda | Views of Brazil

— … ≠ • ≠ … —

No-systemd



Debian