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 (só) 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 Vulnerabilities e Security 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

• PCLinuxOS - Kernel patch Spectre Meltdown
• PCLinuxOS - Add Locale, LibreOffice manager & Software Center
• Mageia 6 - Kernel 4.14
• PCLinuxOS - instalação direta (sem sessão Live)
• PCLinuxOS - instalação e configuração
• Rosa Desktop Fresh R10 - live DVD, instalação e configuração
• openSUSE Tumbleweed - instalação e configuração
• Slackware Plasma 5 KDE - instalação e configuração
• Slackware - instalação e aprendizado (interrompido)
• openSUSE - removendo Snapper, PIM, Baloo e Akonadi
• Escolhendo Grub entre vários Linux
• Escolhendo (e aprendendo) Linux conforme as necessidades
• Arch Linux KDE - Instalação e configuração
• Mageia 6 sta2 - Instalação e configuração
• Unity e dependência de decisões proprietárias
• Montagem de partições no Antergos e no Manjaro
• Transição do Manjaro (rolling-release) para 17.0
• Sabayon 16.11 KDE - Instalação e configuração
• Fedora 25 KDE - Instalação e configuração
• Consertando o Manjaro após erro em atualização
• openSUSE Leap 42.2 - Instalação e configuração
• Instalação do Manjaro KDE 16.10.3 stable
• Mageia 5 KDE Live USB
• Fedora 24 alpha KDE em sessão Live USB

PCLinuxOS - Add Locale, LibreOffice manager & Software Center

Software Center tripartite do PCLinuxOS

Um dos “pequenos” desafios do PCLinuxOS é a ausência de pacotes de Localização nas imagens ISO “oficiais”, — as “traduções” dependem das (poucas) comunidades internacionais, cujas ISOs às vezes demoram a ficar prontas, — e no caso do Brasil excluem a versão KDE, devido ao pequeno número de contribuidores com tempo disponível para a tarefa:

• PCLInuxOS BR
• PCLInuxOS CZ
• PCLinuxOS DK
• PCLinuxOS IT
• PCLinuxOS NL
• PCLinuxOS TR
• PCLinuxOS SU

A este desafio, se soma outro: — O gerenciamento de pacotes e atualizações é fatiado em 3 ferramentas separadas:

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 dos os demais pacotes de software, — e sempre considera o LibreOffice “obsoleto”. — Ignore isso!

Ao lidar com esses 3 mecanismos, é fundamental lembrar que o primeiro passo é, — sempre, — atualizar todo o sistema, pelo Synaptic.

Ao tentar usar o LibreOffice manager ou o Localization manager, eles sempre verificam se o sistema está atualizado, — caso contrário, a única opção é abortá-los, até que isto seja feito, — e só então poderão ser usados com sucesso.

Localização

Menu de boot: — F2 sem opções de Idioma, antes de escolher LiveCD ou Install

No Menu de boot do DVD / Pendrive, — usando a ISO original (USA), — a tecla F2 “Language” só oferece “English (US)”, — mas a escolha do Teclado será oferecida a seguir, independente de você escolher sessão “LiveCD” (que permite instalar), ou “Install” (sem sessão Live).

Durante a instalação, — por qualquer um dos dois caminhos, — são instalados apenas os pacotes existentes no DVD / Pendrive.

Como foi usada uma ISO do repositório principal, veio Idioma / Localização en_US.

Iniciando Localization manager, — AddLocale

Depois de instalado, — e atualizado pelo Synaptic, — você deve usar o Localization manager (Menu >> Software Center) para baixar os pacotes do seu Idioma.

Esta ferramenta permite adicionar 1 único Idioma / Localização de cada vez. — Se quiser mais um, deve rodar o Localization manager outra vez, — e assim por diante.

Depois de 3 meses usando o PCLinuxOS, ainda não houve motivo para qualquer tentativa de remover uma Localização, — portanto, ainda não sei se isto é possível.

Está avisado que o Idioma original jamais é removido, — mas para voltar a ele é preciso rodar novamente o Localization manager, — com a opção default.

Fazendo experiências com 2 instalações paralelas do PCLinuxOS, tive a impressão de que valia a pena instalar, primeiro, o LibreOffice com seus pacotes de Idioma, — e só depois, os pacotes de Localização do sistema, como um todo.

• Ver PCLinuxOS “principal” — e “experimental” (adiante).

Isso, porque as observações indicaram:

a) Ao instalar o LibreOffice + Idioma (ou só seu Idioma) por último, isso desabilitou o acesso ao 3º Nível do Teclado (Keyboard 3rd Level), — que tinha sido ativado, antes, pela Localização do sistema.

b) Ao passo que instalando primeiro o LibreOffice + Idioma, — e só depois a Localização do sistema, — o 3º Nível do Teclado entrou em funcionamento, normalmente, e se manteve.

No primeiro caso, foram feitas várias tentativas, — inclusive reinstalar a Localização do sistema, — e o problema acabou sendo corrigido (se a memória não me engana).

De qualquer modo, o problema acabaria por acontecer, — pois, cedo ou tarde, você terá de atualizar o LibreOffice (3 upgrades em 3 meses), — e cada atualização implica remoção total da versão anterior, para instalar a nova versão.

E aí, terá de instalar, de novo, seus pacotes de Idioma (a menos que prefira en_US).

Acesso ao Terceiro Nível do Teclado, pelos arquivos de configuração do PCLinuxOS

A solução definitiva só foi encontrada em meados de 2019, — pela edição do arquivo:

/etc/X11/xorg.conf.d/00-keyboard.conf

com o acréscimo do parâmetro lv3:lwin_switch para definir o acesso ao 3º nível do Teclado:

# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "br"
        Option "XkbModel" "pc101"
        Option "XkbOptions" "lv3:lwin_switch,compose:rwin"
EndSection

Eu já tinha descoberto esta solução, ao corrigir uma instalação mal-feita do Slackware, em Agosto de 2017, — mas só 2 anos depois me ocorreu usá-la no PCLinuxOS, — e deu certo.

Nesse meio-tempo, fiz outras alterações, — como reverter a interface KDE para o Inglês, em todas as distros, — de modo que as Capturas de tela sejam entendidas, ao pedir ou receber ajuda em fóruns internacionais.

LibreOffice

Consta que o próprio LibreOffice avisa quando existe uma atualização, — porém costumo moldar suas janelas em tamanhos e formatos que não mostram o “canto superior direito”, — e talvez por isso não lembro de jamais ter visto nenhum desses avisos.

Ao instalar o PCLinuxOS pela ISO, veio o LibreOffice 5.4.3, — evidentemente, sem pacotes de Idioma pt_BR.

19 Dez. 2018 - Por burrice, fiz a remoção completa do LibreOffice original, pelo Synaptic, — onde o LibreOffice sempre aparece como obsoleto (embora jamais aponte qualquer versão mais nova). — Devido a isso, acabei tendo de reinstalar o LibreOffice, — e veio a versão 5.4.4.

31 Jan. 2018 - Por puro acaso, num grupo sobre PCLinuxOS no Facebook, deparei com a informação de que já estava disponível o LibreOffice 6.0.0, — e tomei a iniciativa de fazer a substituição do 5.4.4, obsoleto.

15 Fev. 2018 - Feita atualização do LibreOffice para 6.0.1, — mas não há qualquer registro do porquê. — Nenhum print de um “aviso”, pelo menos.

25 Mar. 2018 - Feita atualização do LibreOffice para 6.0.2, — outra vez, sem nenhum registro de ter recebido qualquer aviso.

O motivo dessa iniciativa é que já estava há um bom tempo sem acesso ao 3º Nível do Teclado, — pretendia reinstalar os pacotes de Idioma / Localização do sistema, para tentar solucionar o problema, — e resolvi, primeiro, verificar eventuais atualizações do LibreOffice. — Na verdade, a nova versão estava disponível havia um mês.

O tópico LibreOffice Manager (lomanager) - (Read 284.326 times), de 2009, by Pinoc, no Forum oficial do PCLinuxOS, permite verificar as datas em que foram anunciadas essas versões, — além de conter instruções precisas sobre como lidar com o assunto:

9 Nov. 2017 - LibreOffice 5.4.3.

13 Dez. 2017 - LibreOffice 5.4.4.

28 Jan. 2018 - LibreOffice 6.0.0.

9 Fev. 2018 - LibreOffice 6.0.1.

24 Fev. 2018 - LibreOffice 6.0.2.

Nenhuma ansiedade por versões novas. — Isso é apenas um registro da minha experiência real.

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

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

Uma vez feito isso, não houve dificuldade em fazer o mesmo nas demais distros Linux, — coisa que nunca tinha pensado antes.

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

Synaptic

xx

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) - Definitiva (em uso).

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

xxxxxx

— … ≠ • ≠ … —

Não-debians

• Manjaro - live, install, config (II)
• PCLinuxOS - Kernel patch Spectre Meltdown
• PCLinuxOS - Add Locale, LibreOffice manager & Software Center
• Mageia 6 - Kernel 4.14
• PCLinuxOS - instalação direta (sem sessão Live)
• PCLinuxOS - instalação e configuração
• Rosa Desktop Fresh R10 - live DVD, instalação e configuração
• openSUSE Tumbleweed - instalação e configuração
• Slackware Plasma 5 KDE - instalação e configuração
• Slackware - instalação e aprendizado (interrompido)
• openSUSE - removendo Snapper, PIM, Baloo e Akonadi
• Escolhendo Grub entre vários Linux
• Escolhendo (e aprendendo) Linux conforme as necessidades
• Arch Linux KDE - Instalação e configuração
• Mageia 6 sta2 - Instalação e configuração
• Unity e dependência de decisões proprietárias
• Montagem de partições no Antergos e no Manjaro
• Transição do Manjaro (rolling-release) para 17.0
• Sabayon 16.11 KDE - Instalação e configuração
• Fedora 25 KDE - Instalação e configuração
• Consertando o Manjaro após erro em atualização
• openSUSE Leap 42.2 - Instalação e configuração
• Instalação do Manjaro KDE 16.10.3 stable
• Mageia 5 KDE Live USB
• Fedora 24 alpha KDE em sessão Live USB

Mageia - Kernel 4.14

Mageia 6 com Kernel 4.14

O Kernel 4.14 não é propriamente uma novidade, — eu já o tinha, aqui, no Debian testing; e até as vésperas do Natal também 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

Eu estava finalizando a ronda, — após ver se alguma distro já se havia habilitado a solucionar o mais recente problema descoberto da Intel, — e sempre deixo o Mageia por ú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, — removi 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.

Desdobramentos posteriores

Só a partir de 2018-07-26 passou a ser usado o comando urpmi --auto-update, em vez do mgaapplet

Embora instalado no primeiro trimestre de 2017, só a partir de Novembro daquele ano comecei a anotar as atualizações do Mageia no arquivo “pacotes_historico-mgaapplet_Mageia.txt”.

Segundo esses registros, desde então foram feitas as seguintes atualizações, remoções e reinstalações de Kernel:

2018-01-06 - Instalado kernel-desktop-4.14.10-1

2018-01-06 - Removido kernel-desktop-4.9.50-1 — (versão mais antiga do 4.9)

2018-01-14 - Instalado kernel-desktop-4.14.13-1

2018-02-11 - Instalado kernel-desktop-4.14.18-1 / Removido kernel-desktop-4.14.10-1

2018-02-15 - Removido kernel-desktop-4.9.56-1 — (última versão ainda instalada)

2018-02-26 - Instalado kernel-desktop-4.14.20-1 / Removido kernel-desktop-4.14.13-1

2018-03-24 - Instalado kernel-desktop-4.14.25-1 / Removido kernel-desktop-4.14.18-1

2018-04-01 - Instalado kernel-desktop-4.14.30-3 / Removido kernel-desktop-4.14.20-1

Esta instalação se diferenciou por incluir 5 pacotes, — ao invés de apenas 2. — Daí por diante, serão sempre 5 pacotes:

- kernel-desktop-4.14.30-3.mga6-1-1.mga6.x86_64

- kernel-desktop-devel-4.14.30-3.mga6-1-1.mga6.x86_64

- kernel-desktop-devel-latest-4.14.30-3.mga6.x86_64

- kernel-desktop-latest-4.14.30-3.mga6.x86_64

- kernel-userspace-headers-4.14.30-3.mga6.x86_64

2018-05-21 - Instalado kernel-desktop-4.14.40-1 / Removido kernel-desktop-4.14.25-1

2018-05-31 - Instalado kernel-desktop-4.14.44-2 / Removido kernel-desktop-4.14.30-3

No mês seguinte, foi reinstalado o Kernel 4.9, — e removidos os 4.14:

2018-06-16 - Instalado kernel-desktop-4.9.56-1

2018-06-16 - Removido kernel-desktop-4.14.40-1

2018-06-16 - Removido kernel-desktop-4.14.44-2

Daí por diante, todas as atualizações do mgaapplet / rpmdrake sempre voltavam a oferecer Kernel 4.14, — e após algum tempo enjoei de sempre desmarcá-las manualmente, — mas ao reinstalar, nunca mais foi detectado pelo Grub.

2018-07-04 - Instalado kernel-desktop-devel-4.14.50-2

# date && update-grub && date
Qua Jul  4 13:49:01 -03 2018
Generating grub configuration file ...
Tema encontrado: /boot/grub2/themes/openSUSE/theme.txt
Imagem Linux encontrada: /boot/vmlinuz-4.9.56-desktop-1.mga6
Imagem initrd encontrada: /boot/initrd-4.9.56-desktop-1.mga6.img
Imagem Linux encontrada: /boot/vmlinuz-desktop
Imagem initrd encontrada: /boot/initrd-desktop.img
Encontrado KDE neon User Edition 5.13 (16.04) em /dev/sda1
Encontrado Debian GNU/Linux buster/sid em /dev/sda3
Encontrado Ubuntu 16.04.4 LTS (16.04) em /dev/sdb1
Encontrado openSUSE Leap 15.0 em /dev/sdb2
Encontrado PCLinuxOS em /dev/sdb3
Encontrado Linux Mint 18 Sarah (18) em /dev/sdc1
Encontrado Slackware 14.2 x86_64 (post 14.2 -current) em /dev/sdc2
Encontrado Arch Linux em /dev/sdc3
Encontrado MX 17 Horizon (17) em /dev/sdd1
Encontrado Linux Mint 19 Tara (19) em /dev/sdd2
Encontrado Devuan GNU/Linux ascii em /dev/sdd3
concluído
Qua Jul  4 13:50:02 -03 2018

Desde então, houve mais 5 atualizações do Kernel 4.14, — nunca detectado pelo Grub, — e nenhuma atualização do Kernel 4.9, que é o que de fato está em uso:

2018-07-26 - Instalado kernel-desktop-devel-4.14.56-1

2018-08-13 - Instalado kernel-desktop-devel-4.14.62-> 1

2018-08-20 - Instalado kernel-desktop-devel-4.14.65-> 1
2018-09-15 - Instalado kernel-desktop-devel-4.14.69-> 1
2018-09-24 - Instalado kernel-desktop-devel-4.14.70-> 1

Obs.: - A mudança de nomenclatura deve-se à substituição do notificador e interface gráfica mgaapplet por comandos urpmi --auto-update, a partir de 2018-07-26.

Parece provável que o Kernel 4.9 tenha sido excluído do projeto. De qualquer modo, deve-se considerar essa instalação “sequelada” pelas manipulações que sofreu nas mãos do ignorante aqui.

Devido à minha inabilidade, — e à falta de investir muito mais tempo em pesquisa e aprendizado, — nunca consegui algumas coisas básicas, como assistir vídeo no Chromium, por exemplo.

O Mageia permanece, por teimosia, — ainda espero investir mais nele, — mas seu uso principal é controlar o Grub do computador.

— … ≠ • ≠ … —

Não-debians

• Mageia 6 - Kernel 4.14
• PCLinuxOS - instalação direta (sem sessão Live)
• PCLinuxOS - instalação e configuração
• Rosa Desktop Fresh R10 - live DVD, instalação e configuração
• openSUSE Tumbleweed - instalação e configuração
• Slackware Plasma 5 KDE - instalação e configuração
• Slackware - instalação e aprendizado (interrompido)
• openSUSE - removendo Snapper, PIM, Baloo e Akonadi
• Escolhendo Grub entre vários Linux
• Escolhendo (e aprendendo) Linux conforme as necessidades
• Arch Linux KDE - Instalação e configuração
• Mageia 6 sta2 - Instalação e configuração
• Montagem de partições no Antergos e no Manjaro
• Transição do Manjaro (rolling-release) para 17.0
• Sabayon 16.11 KDE - Instalação e configuração
• Fedora 25 KDE - Instalação e configuração
• Consertando o Manjaro após erro em atualização
• openSUSE Leap 42.2 - Instalação e configuração
• Instalação do Manjaro KDE 16.10.3 stable
• Mageia 5 KDE Live USB
• Fedora 24 alpha KDE em sessão Live USB