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

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 4 dias já encontrei vários pequenos desafios, que provavelmente serão superados nos próximos meses.

Estes pequenos desafios se somam 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 cola”

Nas distros que uso há 10 anos (Kubuntu, Mint), o Login automático (no Boot) é definido nas Configurações de sistema (KDE System settings). — Ao “Aplicar” essa opção, pede-se a senha, e tudo está resolvido.

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 lá verifica que está desmarcada outra vez. No openSUSE, só o que de fato funciona é exercer essa opção através do YaST2 (que pede senha antes de abrir). Nos “derivados” do Mandrake / Mandriva, só o que funciona é fazer essa opção através do Centro de Controle (senha antes de abrir).

No Devuan 2 Beta KDE, ao “Aplicar” essa opção, não foi pedida senha, — a opção “não colou”, — 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, 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 disponíveis são os arquivos da pasta /usr/share/xsessions.

O Relogin permaneceu desativado, — prática adotada por precaução, desde a instalação do Slackware, para não cercear a possibilidade de testar eventuais opções.

Referências



KWallet, Synaptic & etc.


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.

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 pelo APT.

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

Migrar ou reinstalar


Seria uma experiência fascinante, migrar do Devuan 1.0 para o 2.0 Beta, — as instruções parecem bem claras e objetivas, — mas não quis me engajar na etapa que viria depois, de 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 “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 seu (pouco) 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


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


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

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, pode levar até 24 horas para que todos sincronizem 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 até para obter 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), mesmo através 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.

Porém essa primeira instalação demorou 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
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

Portanto, 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 hardware estivesse meio cansado; ou com algum “defeito temporário”, quem sabe. — Ou com maior probabilidade, que 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”.

Parte desses tempos 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 o “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, 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 um pouco maior, — 14 minutos, — mesmo sem cometer erro algum.

De fato, um simples “update-grub” costuma ser muito demorado, em algumas distros (como KDE Neon), — e muito mais rápido em outras (como o 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 complementar, — embora montem normalmente as partições BtrFS / XFS. Quem sabe, a demora esteja na tentativa de “entender” o openSUSE?

Utilitários e desastre


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), — devido a pequenas dificuldades aqui e ali.

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.

Partições existentes há 12 meses, após instalar o Devuan MATE em Novembro

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 no particionamento, de Novembro para Dezembro, após substituir o Tumbleweed

Apenas no caso do openSUSE, experimentei os sistemas de arquivo BtrFS e XFS, — nenhum problema em 13 meses, desde Janeiro 2017. — Mas, ao substituir o 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”
  • for n<11 — 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 correto é 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.

Comparação do Devuan 2 “ascii” Beta com os demais sistemas instalados

xx

— … ≠ • ≠ … —

No-systemd



Debian


terça-feira, 9 de janeiro de 2018

Kernel patch Spectre Meltdown

Reorganização dos Kernels até 12 de Janeiro 2018. — Verde: patched. Laranja: aguardando patch

Se você usa outro Kernel que não 4.4 / 4.9 / 4.14, — e sua distro não oferecer suporte para enfrentar as recém descobertas vulnerabilidades Spectre / Meltdown, — você está com falta de sorte.

6 Jan. 2018 - É o que diz Greg Kroah-Hartman, mantenedor dos três Kernels LTS mais recentes; — dos anteriores, apenas o 3.16 tem previsão de vida útil além de 2018:

If you rely on any other kernel tree other than 4.4, 4.9, or 4.14 right now, and you do not have a distribution supporting you, you are out of luck. The lack of patches to resolve the Meltdown problem is so minor compared to the hundreds of other known exploits and bugs that your kernel version currently contains. You need to worry about that more than anything else at this moment, and get your systems up to date first.

Este é o caso do Kernel 4.12 usado no PCLinuxOS, — que já o retirou de seus repositórios. — Não receberá patch.

Por isso, optei por estreitar o número de Kernels, — de preferência, só versões LTS.

Vale frisar a observação de que existem muito mais bugs e brechas com que se preocupar, no momento, do que apenas com Spectre / Meltdown.

Não compensa se deixar obcecar () pelo mais recente pânico da moda, — que, aliás, veio para ficar, pois repousa em opções adotadas pela indústria décadas atrás, e vai dar muito trabalho nos próximos anos e décadas. — Relaxe um pouco, ou você não terá fôlego para assistir até o final.

Em resumo, as vulnerabilidades estão no hardware e não têm conserto, — pelo menos, até que a indústria desenvolva projetos inteiramente novos, — e os atuais computadores se tornem peças de museu.

O que os desenvolvedores de software podem fazer, é adaptar os sistemas aqui e ali, — coisa que está apenas começando, com algumas providências mais óbvias no momento.

Índice


  • openSUSE
  • Arch Linux
  • PCLinuxOS
  • PCLinuxOS (II) - para experiências
  • Kubuntu 16.04 LTS
  • Mint 18 Sarah
  • KDE Neon User Edition
  • Devuan
  • Mageia
  • spectre-meltdown-checker
  • Chromium / Chrome

openSUSE


Verificação de correções contra Spectre / Meltdown no openSUSE

4 Jan. 2018 - As primeiras correções do openSUSE Leap contra as vulnerabilidades Spectre / Meltdown começaram a ser anunciadas em Current Status: openSUSE and “Spectre” & “Meltdown” vulnerabilities, — com links para SUSE Addresses Meltdown and Spectre VulnerabilitiesSecurity Vulnerability: "Meltdown" and "Spectre" side channel attacks against modern CPUs, — que por sua vez remetem a várias outras páginas.

Na prática, — e descontadas demoras (aqui) em verificar o openSUSE, — foram recebidas sucessivas atualizações, incluindo:

2018-01-04 19:05:40

Os seguintes 3 pacotes serão atualizados:
  conky kernel-firmware ucode-amd

2018-01-06 13:15:17

O seguinte pacote NOVO será instalado:
  kernel-default-4.4.104-39.1
Os seguintes 8 pacotes serão atualizados:
  ImageMagick libMagickCore-6_Q16-1 libMagickWand-6_Q16-1 libzypp ucode-intel zypper zypper-aptitude zypper-log

2018-01-11 15:38:15

O seguinte pacote será atualizado:
  ucode-intel

É de se supor que, — se o hardware tivesse menos de 9¾ anos, — o quadro poderia ser outro.

Do terceiro link (acima):

Verifying if a system is protected :

Following updating the latest kernels, it is possible to check /proc/cpuinfo for  'kaiser' or 'pti'  or 'spec_ctrl' information.

When the output includes:
  'kaiser' or 'pti' flags, then v3 (Meltdown) protection is active.
  'spec_ctrl' flag, then v2/v1 (Spectre) protection is active.

Em retrospecto, encontram-se 2 flags “kaiser”, — processor 0 e processor 1:

Linux5:/home/flavio # cat /proc/cpuinfo | grep kaiser
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm dtherm kaiser
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm dtherm kaiser

Ao passo que a busca por “spec_ctrl” não encontra resultados.

  • Ver “spectre-meltdown-checker” (adiante)

Arch Linux


Adicionar legenda

6 Jan. 2018 - Kernel 4.9.75-1-lts

Sem entender nada do assunto, segui essa dica para conferir:

[flavio@Linux9 ~]$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz
CONFIG_PAGE_TABLE_ISOLATION=y

[flavio@Linux9 ~]$ dmesg | grep iso
[    0.000000] Kernel/User page tables isolation: enabled

  • Ver “spectre-meltdown-checker” (adiante)

12 Jan. 2018 - intel-ucode-20180108-1

13 Jan. 2018 - Kernel 4.9.76-1-lts

PCLinuxOS


Kernel 4.14 no PCLinuxOS de teste (II)

Por motivos diversos, havia aqui 2 instalações do PCLinuxOS, — digamos, PCLinuxOS (I), quase perfeito para as atividades diárias; — e PCLinuxOS (II), destinado a experiências de Localização.

Todas as observações a seguir foram feitas no PCLinuxOS (II).

7 Jan. 2018 - Para quem usa o Kernel 4.12 no PCLinuxOS, o Synaptic não propôs nenhuma atualização de Kernel relativa às vulnerabilidades recém descobertas, — pois a revisão só foi feita nos Kernels 4.4 / 4.9 / 4.14, segundo o anúncio Meltdown/Spectre update no forum oficial:

The following kernels have been updated to close vulnerabilities associated with the Meltdown / Spectre exploits. All previous kernels are considered insecure / unsecure.

kernel-4.4.110-pclos1-1-1pclos2018.x86_64.rpm
kernel-4.9.75-pclos1-1-1pclos2018.x86_64.rpm
kernel-4.14.12-pclos1-1-1pclos2018.x86_64.rpm


Please install one of the updated kernels and nvidia drivers if applicable as soon as they show up in the regular software repositories.

kernel installation instructions: https://pclinuxoshelp.com/index.php/Kernel

« Last Edit: Today at 12:16:22 AM by Tex »

As instruções de instalação indicadas (acima) afirmam que nenhum “update” de Kernel jamais é incluído no processo regular de atualizações do PCLinuxOS:

It is important to note that the kernel is never updated as part of the the normal apt / Synaptic update process. This is because updating implies removal of the previous version. This would be bad news if the new kernel is not suitable for YOUR hardware! Instead, new kernels are added to the system (much like installing a new application). The new kernel becomes the default for the next boot but the previous version is kept in case of problems.

Chrome com uso intenso de CPU e falhas de (renderização?) no PCLinuxOS com Kernel 4.14 patched

8 Jan. 2018 - Portanto, instalei o Kernel 4.14, — mas o resultado foi infeliz.

Commit Log for Mon Jan  8 13:46:54 2018

Installed the following packages:

kernel-4.14.12-pclos1 (1-1pclos2018)
kernel-devel-4.14.12-pclos1 (1-1pclos2018)

Entre os problemas verificados:

• Lentidão do Chrome no GooglePlus e no Facebook (entre outros)
• Falhas de (renderização?), por exemplo, ao acessar os Favoritos
• Perda total do acesso ao 3º nível do Teclado

Bastou reiniciar o computador, — entrar nas “Opções avançadas” do Menu de inicialização e escolher o Kernel original, 4.12, — para o Chrome voltar ao “normal”.

Em vista disso, o novo Kernel 4.14 com correções contra Spectre / Meltdown foi completamente removido.

Commit Log for Mon Jan  8 21:59:04 2018

Completely removed the following packages:

kernel-4.14.12-pclos1
kernel-devel-4.14.12-pclos1

Agora, falta conseguir que o 3º nível do Teclado volte a funcionar.

PCLinuxOS de teste (II) funcionando bem com Kernel 4.9.75 "corrigido"

9 Jan. 2018 - Uma vez que o Kernel 4.12 não recebeu correções contra as falhas de segurança Spectre / Meltdown, — e cedo ou tarde essas correções terão de ser aplicados em todas as distros, — instalei os Kernels 4.4 e 4.9, para teste e observação:

Commit Log for Tue Jan  9 12:04:44 2018

Installed the following packages:

kernel-4.4.110-pclos1 (1-1pclos2018)
kernel-4.9.75-pclos1 (1-1pclos2018)
kernel-devel-4.4.110-pclos1 (1-1pclos2018)
kernel-devel-4.9.75-pclos1 (1-1pclos2018)

Tanto o Kernel 4.9 quanto o 4.4 funcionaram “normalmente”, — vale dizer, tão bem quanto o 4.12 “original” da distro instalada pela imagem ISO “oficial” pclinuxos64-kde5-2017.11.

Em seguida, foi completamente removido o Kernel 4.12, — classificado como “obsoleto”:

Completely removed the following packages:

kernel-4.12.14-pclos1
kernel-devel-4.12.14-pclos1

Depois disso, ele desaparece do Synaptic. — Já tinha sido retirado dos repositórios PCLinuxOS, — e só continuava “visível” enquanto ainda existia “localmente”.

11 Jan. 2018 - Novas revisões de Kernel, — que também funcionaram sem problema algum:

Commit Log for Thu Jan 11 12:13:28 2018

Installed the following packages:

kernel-4.4.111-pclos1 (1-1pclos2018)
kernel-4.9.76-pclos1 (1-1pclos2018)
kernel-devel-4.4.111-pclos1 (1-1pclos2018)
kernel-devel-4.9.76-pclos1 (1-1pclos2018)

Kernel 4.14.13 no PCLinuxOS

Com elas, também se ofereceu nova revisão do Kernel 4.14.13, — que também não funcionou muito bem no hardware local:

Commit Log for Thu Jan 11 14:04:43 2018

Installed the following packages:

kernel-4.14.13-pclos1 (1-1pclos2018)
kernel-devel-4.14.13-pclos1 (1-1pclos2018)

12 Jan. 2018 - Após alguns dias de teste, mais uma vez o Kernel 4.14 foi completamente removido — e com o Kernel 4.9.76 se restabeleceu a normalidade no PCLinuxOS (II).

Commit Log for Fri Jan 12 17:55:56 2018

Completely removed the following packages:

kernel-4.14.13-pclos1
kernel-devel-4.14.13-pclos1

PCLinuxOS (II) - para experiências


O segundo PCLinuxOS tinha sido reinstalado exatamente para isso, — fazer experiências, — em especial, com diferentes maneiras de instalar (ou não) partes da Localização, que é fatiada por segmentos, e gerenciada à parte dos aplicativos em geral.

13 Dez. 2017 - (1ª instalação - SSD externo) - Apagada pela 2ª.

15 Dez. 2017 - (2ª instalação - SSD externo) - Experiências. Apagada pela 4ª.

19 Dez. 2017 - (3ª instalação - HDD interno) - Ferramenta de trabalho.

30 Dez. 2017 - (4ª instalação - SSD externo) - Experiências de Localização.

Por via das dúvidas, as experiências com diferentes Kernels também estão confinadas a esse PCLOS “secundário” — até que pareça seguro aplicar alguma delas ao “principal”.

Kubuntu 16.04 LTS


Kubuntu atualizado para o Kernel 4.4.0-108

4 Jan. 2018 - Dustin Kirkland lamenta, — em Ubuntu Updates for the Meltdown / Spectre Vulnerabilities, — que se tenha rompido, na véspera, uma espécie de pacto de cavalheiros, que previa a divulgação do problema só no dia 9, quando toda a indústria já teria prontas as primeiras soluções.

Canonical manteve para o dia 9 a previsão de patches para os Kernels 3.2 / 3.13 / 4.4 / 4.13, — o que deixaria de fora, num primeiro momento, os demais Kernels 4.8 / 4.10 / 4.11 (todos não-LTS) existentes nos repositórios do Ubuntu e de inúmeras distros “baseadas” nele.

9 Jan. 2018 - Kernel do Kubuntu 16.04 LTS atualizado para 4.4.0-108.

Boot normal, funcionamento sem qualquer perda. — O teste de fogo é navegar em “Páginas” do Facebook (não Feed, Perfis, Grupos), — coisa impraticável em algumas distros instaladas no meu hardware (3º Trim. 2008).

Kernel 4.4.0-109 menos de 24 horas depois, no Kubuntu

Ao redor do mundo, foram registrados problemas em alguns hardwares, — e, em menos de 24 horas, chegou nova atualização do Kernel, — para 4.4.0-109.

As alternativas ao Kernel 4.4 no Kubuntu 16.04 LTS

As alternativas ao Kernel 4.4 no Kubuntu 16.04 LTS não são muito felizes, neste momento: — 4.8 / 4.10 / 4.11 / 4.13, — todos não-LTS (ainda que venham a ser apelidados “LTS”, no âmbito de alguma distro), e fora do esforço principal de correções (patches).

Embora Canonical e outros possam investir em patches para eles, o universo de teste será sempre menor que o dos esforços “oficiais” (com abrangência para todas as distros).

Nunca tinha encontrado motivos para trocar o Kernel 4.4 do Kubuntu 16.04 LTS por qualquer uma das demais opções oferecidas nos repositórios oficiais, — e agora, menos ainda.

No dia 12, intel-microcode 3.20180108.0~ubuntu16.04.2.

12 Jan. 2018 - Disponibilizada a página Meltdown and Spectre Status Update, para acompanhamento regular.

Mint 18 Sarah KDE


mintUpdate não inclui automaticamente atualizações do Kernel (nível 5)

Alguns problemas no início de 2017 me levaram a fazer downgrade do Linux Mint 18 Sarah para o Kernel 4.4.0-21, — e nele ficou estacionado até ontem, já que o mintUpdate não instala atualizações de Kernel por default.

Esta é uma decisão deixada para o usuário, — e Clement Lefebvre costumava recomendar que, “se está funcionando, não conserte”. — Até hoje, esse conselho nunca falhou (pelo menos, no Linux Mint).

9 Jan. 2018 - Nas primeiras horas do dia 10, constatei que já estava disponível o Kernel 4.4.0-108-113, — e pela primeira vez resolvi fazer essa atualização no mintUpdate.

Reiniciado o computador com a nova revisão de Kernel, o Linux Mint 18 Sarah carregou sem qualquer problema. — Nenhuma perda de leveza ou agilidade, nem mesmo nas “Páginas” do Facebook (não Feed, Perfis, Grupos).

Leque de opções de Kernel no Linux Mint 18 Sarah

As demais alternativas de Kernel são as mesmas do Kubuntu 16.04 LTS: — 4.8 / 4.10 / 4.11 / 4.13.

Ainda no dia 9, Linux Mint publicou uma nota de segurança sobre Spectre / Meltdown, indicando revisões de Kernel com as primeiras correções:

  • 3.13 series (Linux Mint 17 LTS): patched in 3.13.0-139
  • 3.16 series (LMDE): patched in 3.16.51-3+deb8u1
  • 4.4 series (Linux Mint 17 HWE and Linux Mint 18 LTS): patched in 4.4.0-108
  • 4.13 series (Linux Mint 18 HWE): patched in 4.13.0-25

Kernel 4.4.0-109 disponível menos de 24 horas depois

Menos de 24 horas depois, já estava disponível o patch 4.4.0-109.

12 Jan. 2018 - intel-microcode 3.20180108.0~ubuntu16.04.2

A nota do Linux Mint também indicou, com bastante clareza, algumas providências a serem adotadas no Chromium / Chrome, — ver adiante.

KDE Neon


Opções de Kernel no KDE Neon

As alternativas de Kernel no KDE Neon são os mesmos 353 pacotes vistos no Kubuntu 16.04 LTS: — 4.4 / 4.8 / 4.10 / 4.11 / 4.13. — No momento, estava em uso o 4.10.0-42.

Instalação do patch 4.4.0-108 pelo Synaptic

9 Jan. 2018 - Foi instalado o Kernel 4.4.0-108, — feito Reboot para carregá-lo, — e a seguir, removido o 4.10.0, que no momento não apresentava perspectivas.

Nenhum problema de boot, com essa revisão do Kernel 4.4, — e funcionamento impecável, sem qualquer perda.

Segundo patch do Kernel 4.4.0 em 24 horas

No dia 10, já estava disponível novo patch, — Kernel 4.4.0-109.

11 Jan. 2018 - intel-microcode 3.20180108.0~ubuntu16.04.2

Devuan


Patch do Kernel 3.16 no Devuan

12 Jan. 2018 - O comando apt-update finalmente apresentou atualização de Kernel, — com mais duas opções, — e foi aplicada a atualização-padrão pelo Synaptic.

Mageia


Kernel e microcode patch contra Spectre / Meltdown no Mageia, dia 14

14 Jan. 2018 - Com atraso, vi o anúncio Updated kernel packages fix security vulnerabilities, feito na véspera, e carreguei o Mageia para instalar as atualizações:

Os seguintes 8 programas serão instalados:

- cpupower-4.14.13-1.mga6.x86_64
- dracut-044-11.1.mga6.x86_64
- kernel-desktop-4.14.13-1.mga6-1-1.mga6.x86_64
- kernel-desktop-latest-4.14.13-1.mga6.x86_64
- ldetect-lst-0.3.7.5-1.mga6.x86_64
- microcode-0.20180108-1.mga6.nonfree.noarch
- vboxadditions-kernel-4.14.13-desktop-1.mga6-5.2.2-7.mga6.x86_64
- vboxadditions-kernel-desktop-latest-5.2.2-7.mga6.x86_64

* Ainda não incluído no quadro comparativo (a seguir).

spectre-meltdown-checker


Relatividade dos patches de Kernel já disponibilizados, — segundo o spectre-meltdown-checker

Até agora, o alcance desses patches de Kernel, intel microcode etc. é bastante relativo, — de acordo com o spectre-meltdown checker.

Arch Linux e demais distros, — por enquanto, só uma proteção relativa contra Spectre / Meltdown

Por enquanto, atenuaram apenas os riscos do Meltdown “Variant 3”.

De acordo com o spectre-meltdown-checker, apenas openSUSE atenuou riscos de 2 variantes

Exceção, — entre as distros instaladas aqui, — é apenas o openSUSE Leap, que já mostra alguma proteção também contra Spectre “Variant 1”.

Nenhum demonstra proteção contra Spectre “Variant 2”, até o momento.

Kernel patch do Devuan não passou no spectre-meltdown-checker

Como leigo total, não posso avaliar a eficácia do spectre-meltdown-checker, — versão do dia 13, atualizada 5 horas antes de iniciar esse exame, — e me preocupa ver que o Devuan, mesmo após receber o Kernel “patched”, é considerado vulnerável em todos os quesitos.

* Para facilitar, o spectre-meltdown-checker foi baixado apenas ma vez, descompactado, e a pasta resultante .spectre-meltdown-checker/ foi copiada para a /home/$USER das demais distros.

Chromium / Chrome


chrome://flags/#enable-site-per-process

A nota de segurança do Linux Mint também abordou questões relativas a NVIDIA, Intel Microcode, Opera, Firefox e Chromium / Chrome.

Um link remete a Actions required to mitigate Speculative Side-Channel Attack techniques, — de onde outro link remete a Site Isolation, — e assim por diante.

A Flag “Strict site isolation” é experimental, — eleva o uso de Memória RAM, — por isso, estou testando em algumas distros; e voltando atrás em outras.

Além disso, Chromium / Chrome foi atualizado em algumas distros, e não em outras, — mas seu funcionamento foi afetado em todas, — independente da aplicação ou não da Flag “Strict site isolation”.

Um efeito mais evidente é um super-espaçamento dos widgets do Byteria, — o que também pode provir de mudanças no próprio Blogger / Blogspot, — e ocorreu em todas as distros.

Em algumas distros, a simples navegação no Google Plus torna-se lenta após algum tempo, — e ocorrem pequenas falhas de (renderização?) ao exibir links da Barra de Favoritos. — Isso foi registrado no Mageia (antes de receber path de Kernel) e no Debian, por exemplo, mesmo sem aplicação da Flag “Strict site isolation”.

Em outras distros, — mesmo com a Flag aplicada, — esses problemas não ocorreram.

— … ≠ • ≠ … —

Não-debians


segunda-feira, 8 de janeiro de 2018

PCLinuxOS - Add Locale, LibreOffice manager & Software Center

Software Center tripartite do PCLinuxOS

Um “pequeno” desafio do PCLinuxOS é a ausência de pacotes de Localização nas imagens ISO “oficiais”, — a instalação automática de “traduções” depende das (poucas) comunidades internacionais, cujas ISOs às vezes demoram a ficar prontas.

Para a maioria dos usuários, acostumados com as distros mais populares, — inclusive Mageia e Rosa, igualmente derivadas do Mandrake / Mandriva, — a segmentação do gerenciamento de pacotes e atualizações em 3 ferramentas acrescenta uma estranheza adicional àquele “pequeno” desafio:

LibreOffice manager - Centraliza as opções de instalar, reinstalar, atualizar, remover o LibreOffice, — bem como adicionar “Localização” (1 de cada vez), — só para ele.

Localization manager - Permite acrescentar 1 “Local” de cada vez, — para o sistema como um todo (exceto LibreOffice), — e ainda não tenho certeza se permite “remover” depois.

Synaptic package manager - Centraliza a instalação e atualização de todos os demais pacotes de software, — e sempre considera o LibreOffice “obsoleto”.

O que há de estranho nesse fatiamento, — é também o que há de liberdade, — ou de incentivo a explorar essa liberdade, que o excesso de moleza ia jogando no esquecimento.

PCLinuxOS em inglês, — com ortografia e formatos do Brasil

Essa estranha segmentação dos gerenciadores deu a ideia de manter todos os aplicativos em inglês, — não só seus Menus, como também seu conteúdo, para me familiarizar com os nomes originais dos itens, seções, opções etc. do KDE System settings, Control Center, entre outros, — sem abrir mão do corretor ortográfico nem dos formatos brasileiros de data, hora, moeda, números, sistema de medidas.

Agora que está feito, não tenho dúvidas de que tudo isto seja possível em qualquer outra distro Linux, — talvez até com maior facilidade, — mas até o mês passado não fazia a menor ideia de “por onde começar”.

Provavelmente, nem teria tido essa ideia, — como não tive nos 10 anos anteriores.

PCLinuxOS “principal” — e “experimental”


“Usabilidade” obtida com diferentes distros Linux instaladas, em Janeiro 2018

Foram feitas 2 experiências diferentes, — em 2 instalações paralelas do PCLinuxOS (dualboot), citadas como “principal” e “experimental”.

O motivo disso, é que a instalação “principal” estava muito boa, — uma das poucas distros instaladas que conseguem enfrentar a navegação em “Páginas” do Facebook, sem travar nem superaquecer, — e não queria colocá-la em risco.

Aliás, logo no começo, já houve efeitos indesejáveis, — perda de funcionalidades do Teclado ABNT2 no Kate / Kwrite, — e cheguei a pensar que havia estragado a instalação “principal” (Linux6, HDD interno).

Instalações do PCLinuxOS


Esse, o motivo de substituir a 2ª instalação (SSD externo), que ainda existia, por uma 4ª instalação, — para começar essas “experiências” do zero, e testar mais algumas variações.

13 Dez. 2017 - (1ª instalação - SSD externo) - Apagada pela 2ª.

15 Dez. 2017 - (2ª instalação - SSD externo) - Experiências. Apagada pela 4ª.

19 Dez. 2017 - (3ª instalação - HDD interno) - Ferramenta de trabalho.

30 Dez. 2017 - (4ª instalação - SSD externo) - Experiências de Localização.

xxxxxx

— … ≠ • ≠ … —

Não-debians


sábado, 6 de janeiro de 2018

Mageia - Kernel 4.14

Mageia 6 com Kernel 4.14

O Kernel 4.14 não é propriamente uma novidade, — já o tinha, aqui, no Debian testing; e até as vésperas do Natal ainda o tinha no openSUSE Tumbleweed (desinstalado no dia 19), — mas foi uma surpresa no caso do Mageia 6, que não é “rolling-release”.

Atualizações apresentadas pelo mgaapplet

Estava finalizando a ronda, — após ver se alguma distro já se havia habilitado a solucionar o mais recente problema descoberto da Intel, — e o Mageia é sempre o último, já que controla o Grub e deve incorporar eventuais revisões de Kernel dos demais.

Revisão de Kernel do Arch dispensa atualização do Grub

Arch Linux tinha recebido uma revisão, — do linux-lts-4.9.74-1 para linux-lts-4.9.75-1, — mas isso não exige atualização do Grub, pois sua entrada se limita a referir “linux-lts”, sem especificar versão.

Apenas a revisão de Kernel do openSUSE Leap, minutos antes, exigia atualização no Grub do Mageia.

Não parece que o novo Kernel do Mageia diga respeito ao problema recém descoberto da Intel, — mas a linguagem do mgaapplet não é muito clara para um leigo:

kernel-desktop-4.14.10-1.mga6 - Linux Kernel for desktop use with x86_64​                                                                                                                      
The kernel package contains the Linux kernel (vmlinuz), the core of your Mageia operating system. The kernel handles the basic functions of the operating system: memory allocation, process allocation, device input and output, etc. This kernel is compiled for desktop use, single or multiple x86_64 processor(s) / core(s), using HZ_1000, voluntary preempt, CFS cpu scheduler and cfq i/o scheduler.

This kernel relies on in-kernel smp alternatives to switch between up & smp mode depending on detected hardware. To force the kernel to boot in single processor mode, use the "nosmp" boot parameter.

O que mudou?

* Sáb Dez 30 2017 tmb <tmb> 4.14.10-1.mga6
        + Revision: 1187428
        - update to 4.14.10
        - update conflicts on nvidia-current
        - ALSA: hda - Fix missing COEF init for ALC225/295/299
        - cpufreq: schedutil: Use idle_calls counter of the remote CPU
        - tracing: Remove extra zeroing out of the ring buffer page
        - tracing: Fix possible double free on failure of allocating trace buffer
        - tracing: Fix crash when it fails to alloc ring buffer

Opções avançadas do Mageia ao reiniciar o computador — 3 Kernels

Como é sempre bom manter o Kernel anterior, — para o caso de o novo apresentar algum problema, — ao reiniciar o computador o Grub já acumulava 3 itens nas Opções avançadas do Mageia.

Remoção do 3º Kernel mais antigo

Para não acumular Kernels demais, — afinal, ocupam espaço em disco, — foi removido o 3º mais antigo, que a essa altura não era mais necessário.

Correção “manual” das entradas do Grub para o Arch e o Slackware

Após esta segunda atualização automática do Grub do Mageia, — escolhido como padrão para carregar as demais distros instaladas, — faltava corrigir “manualmente” as entradas relativas ao Arch Linux e ao Slackware.

Nas entradas referentes ao Arch Linux, substituir

initrd /boot/intel-ucode.img

por

initrd /boot/intel-ucode.img /boot/initramfs-linux-lts.img

Nas entradas referentes ao Slackware, substituir

linux /boot/vmlinuz-generic-4.9.37 root=/dev/sdc2

por

linux /boot/vmlinuz-huge-4.9.37 root=/dev/sdc2

O editor interno do Midnight-Commander (mcedit) “lembra” tão bem as 2 substituições globais a serem feitas, que o processo todo não leva mais de 1 minuto, — é salvar (F2), sair (F10), encerrar o “sudo mc” (F10) e fechar o Konsole; — e poderia criar um atalho no Menu K para já abrir o mcedit no arquivo /boot/grub2/grub.cfg, embora seja sempre bom conferir sua data e hora, antes de fazer substituições globais às cegas.

Mas, com certeza, deve haver um modo de “automatizar” essas correções, — alguma coisa bem simples e óbvia (depois que tiver aprendido), entre os arquivos da pasta /etc/grub.d/, — que no caso do openSUSE são:

00_header
00_tuned
10_linux
20_linux_xen
20_memtest86+
30_os-prober
40_custom
41_custom
80_suse_btrfs_snapshot
90_persistent
95_textmode
README

e no caso do Mageia:

00_header
01_users
06_grub-customizer_menu_color_helper
10_linux
20_linux_xen
20_ppc_terminfo
30_os-prober
40_custom
41_custom
backup
README

Atualização automática do Grub e manutenção BtrFS ao iniciar o openSUSE após 0:00h

Por precaução, mais tarde voltei para atualizar o Grub do openSUSE Leap e fazer as mesmas correções “manuais”. — Em caso de desastre no Grub “principal”, basta apertar DEL ao reiniciar a máquina, entrar na BIOS Setup, e alterar o dispositivo de Boot, de sda para sdb.

Da primeira parte, — atualizar seu Grub, — o openSUSE se encarregou. Como já passava da 0:00h, tratou de atualizá-lo e de fazer a manutenção do BtrFS, automaticamente, logo nos primeiros 5 minutos da nova sessão.

Correções “manuais” no Grub do openSUSE Leap

A essa altura, o mcedit do openSUSE também já sabe, de-cór-e-salteado, o que deve fazer.

Menu de inicialização do PCLinuxOS, — só falta detectar o openSUSE

Um terceiro Grub, — do PCLinuxOS (MBR de sdc), — também já se mostrou capaz de carregar quase todas as demais distros instaladas. Só falta detectar o openSUSE.

Quadro comparativo das distros Linux instaladas em 6 Jan. 2017

Os propósitos dessa brincadeira toda são, basicamente:

1) Dispor de 2+ alternativas, — além do Kubuntu 16.04 LTS, do KDE Neon e do Linux Mint 18 KDE, conhecidos de longa data (e com os quais evito brincar), — para todas as tarefas necessárias. Até o momento, openSUSE Leap e PCLinuxOS têm se mostrado os mais úteis.

2) Explorar, com calma, o mundo fora da “dependência” da Canonical. — Aliás, reduzir dependências de qualquer tipo.

— … ≠ • ≠ … —

Não-debians