terça-feira, 12 de janeiro de 2021

Adicionando HDD a 11 distros Linux em dualboot

Terceiro HDD 3½’’, no “piso” da grade para dispositivos 5¼’’

• Plugar mais um Hard Disk Drive (HDD) em um PC Desktop é coisa banal, e por si só, não mereceria uma postagem de blog.

No entanto, é um registro que estava faltando (para lembrar), da rotina básica de manutenção de múltiplas distros em dualboot.

HDD adicional

Hard disk drive (HDD) adicional, no UEFI Bios Setup

Este PC Desktop foi planejado em suas linhas gerais, — mas a concretização se condicionou ao percurso (e às eventuais disponibilidades imediatas) de 3 ou 4 lojas razoáveis, para reunir as peças e concluir a montagem, nos limites de 1 dia. — Ao escolher o gabinete (entre poucas opções), me pareceu que oferecia alojamento interno (slots) para até 5 HDDs de 3½’’.

Isso era importante, pois eu tinha 3 HDDs antigos (em perfeitas condições), que eu pretendia aproveitar. — Só ao chegar em casa, percebi que 3 daqueles espaços 3½’’ estavam previamente inutilizados, pela péssima disposição (vertical!) destinada ao SSD interno. — Por isso, acabei instalando apenas 2 HDDs.

Só agora, um ano depois, percebi que o “piso” do módulo para dispositivos 5¼’’ oferecia umas rebarbas para fixar mais um dispositivo de 3½’’. — Mal pude me conter, até desligar toda a energia e aparafusar lá meu 3º HDD.

Hard disk drive (HDD) adicionado

Por sorte, acertei logo o 5º slot Sata:

Local Storage:                total:    2.84 TiB          used: 838.23 GiB   (28.8%)

     ID-1: /dev/sda   SSD  Sata3  Kingston  SA400S37480G        447.13 GiB   480 GB
     ID-2: /dev/sdb   HDD  Sata3  Seagate   ST1000DM003-1SB102  931.51 GiB   1   TB
     ID-3: /dev/sdc   HDD  Sata2  Maxtor    STM3320613AS        298.09 GiB   320 GB
     ID-4: /dev/sdd   HDD  Sata2  Samsung   HD322HJ             298.09 GiB   320 GB
     ID-5: /dev/sde   SSD  USB2   Samsung   S2 Portable         931.51 GiB   1   TB

Optical-1: /dev/sr0   DRW  Sata3  ASUS      DRW-24F1MT

Partição adicional

Substituição de partição por outra maior

Meu objetivo era criar nele uma uma partição de bom tamanho, para substituir a acanhada partição de 65 GiB (Storage) que eu vinha usando desde Janeiro 2020 para toda atividade diária, — e que já estava se tornando insuficiente.

Em resumo, eu precisava:

  • Na primeira distro: — Criar uma partição de bom tamanho (“Warehouse”)
    • Mover para ela o conteúdo de “Storage”

  • Em todas as distros: - Re-configurá-las para usar “Warehouse”, em vez de “Storage”
    • PrtScn

    • Automount

    • Dolphin (startup)

    • Kate (session)

    • Conky

  • Na última distro: — Deletar a partição “Storage”, agora esvaziada; e
    • Configurar o Luckybackup para a nova situação

Por motivos práticos, sigo a ordem inversa do Grub.

Sequência inversa

Sequência do Grub — sda1, sda10, sda11, sda12, sda2...

Para lidar de modo racional com as 11 distros Linux instaladas, adotei o hábito de sempre começar pela “última”, — seja para atualizar, seja para qualquer alteração geral, — e terminar com a “primeira”, openSUSE, que controla o Grub (e o Luckybackup).

Desse modo, o Grub do openSUSE pode detectar as mudanças de Kernel de todas as outras distros, atualizadas antes dele.

Acontece que o Grub organiza a sequência das distros pelo ordem alfanumérica dos respectivos dispositivos, — ou seja, primeiro /dev/sda2 (porque o Grub pertence ao openSUSE); — depois, sda10, sda11, sda13, — depois, sda3, sda4 etc.:

Grub, by alphanumeric /dev order

├─sda2    50G  Linux1     openSUSE
├─sda10   30G  Linux9     Void
├─sda11   30G  Linux10    Slackware
├─sda12   30G  Linux11    -
├─sda13   30G  Linux12    MX Linux
├─sda3    30G  Linux2     Arch
├─sda4    30G  Linux3     Debian
├─sda5    30G  Linux4     Fedora
├─sda6    30G  Linux5     KDE Neon
├─sda7    30G  Linux6     PCLinuxOS
├─sda8    30G  Linux7     Mageia
└─sda9    30G  Linux8     Mint

Portanto, foi esta a ordem que segui, percorrendo todas as distros, — a começar pelo Linux Mint (com KDE), que é a “última”, no Grub, — até chegar ao openSUSE, que é a “primeira”, por ser a “dona” do Grub.

Preparação do “novo” HDD

Antigo SSD externo USB2 deslocado para /dev/sdde

Linux8 - Ao iniciar o Linux Mint 20 (com KDE), o recém-plugado HDD 320 GB (298 GiB) tomou o “lugar” de /dev/sdd, com reflexos no uDisks2, visíveis no painel lateral do Dolphin.

Por isso, a partição “Depot2”, do SDD externo USB, deixou de ser montada automaticamente pelo uDisks2. — Agora, o SSD externo USB é /dev/sde, — coisa que não estava prevista, e por isso a montagem automática não se realizou.

Atividade intensa de Read / Write, até desmontar a partição do 3º HDD

Em troca, ocorreu a montagem automática de uma partição vazia, sem rótulo (Label), existente no “novo” HDD, — devido a uma configuração redundante que uso no KDE System Settings / uDisks2.

Por ser a primeira vez que foi montada, isso causou intensa atividade de Read / Write, — que só cessou ao “desmontar” (unmount).

Alterando a tabela de particionamento, de MBR (msdos) para GPT

O 3º HDD estava particionado como MBR (msdos), porque eu pretendia deixá-lo no antigo PC Desktop, — mas para usá-lo no novo PC, achei melhor convertê-lo logo em GPT

Criando a nova partição de dados “Warehouse”

Em seguida, criei nele uma partição de 240 GiB, com rótulo (Label) “Warehouse”, — para substituir “Storage” (65 GiB), criada provisoriamente em Janeiro 2020, e que já estava quase cheia.

Montagem automática da nova partição

Habilitei a montagem automática da nova partição “Warehouse” e reiniciei a sessão KDE (Logout / Login), para conferir o resultado, antes de prosseguir com as demais providências.

Atividade de “ext4-rsv-convert” da nova partição montada

A atividade de “Writeback conversion work” (ext4-rsv-convert), após a primeira montagem da partição recém-criada, se completou em cerca de 9 minutos.

Movendo (quase) tudo para a nova partição

As pastas da antiga partição “Storage” foram movidas para a nova partição “Warehouse”, — exceto a pasta “PrtScn”, cujo conteúdo também foi movido, mas permaneceu (vazia), para que todas as distros ainda possam fazer Capturas de tela, até que a última seja reconfigurada.

Nova localização (path) para salvar as Capturas de tela

Depois de configurar PrtScn para salvar na nova partição, basta levar para lá as últimas Capturas de tela gravadas na antiga.

Configurações do Dolphin e do Kate

No Dolphin, mudei a “página inicial”, — da antiga para a nova partição.

No Kate, reabri os documentos em sua nova localização (path), — de modo que, ao abri-lo, a “sessão” já venha completa, como antes.

Substituição da antiga partição pela nova, no Conky

Enfim, substituí no Conky a antiga partição “Store” pela nova partição “Warehouse”.

Deletando uma partição sem utilidade

Linux7 - No Mageia, a nova partição “Warehouse” também já foi automaticamente montada no início da sessão KDE, — devido à configuração redundante no System settings / uDisks2, — e pude passar logo às demais configurações.

Aproveitei para deletar uma partição “eBooks”, que nunca cheguei a usar.

Configuração do Dolphin e do atalho PrtScn no PCLinuxOS

Linux6 - Também no PCLinuxOS a nova partição “Warehouse” foi automaticamente montada, e passei logo às configurações do Dolphin, PrtScn etc.

Configuração de montagem automática de /dev/sdd1

Linux5 - Tudo parece confirmar que a montagem automática da nova partição “Warehouse” se deve a ter “herdado” a configuração de uDisks2 para /dev/sdd1, — antes atribuída à partição “Depot2”, do SSD externo USB, que agora é /dev/sde1.

A opção de montagem automática ao plugar (On Attach), na coluna da direita, eu só uso para esse SSD externo USB, — que eventualmente pode estar desconectado durante o boot.

Configuração do Conky para exibir a nova partição

Linux4 - As re-configurações não apresentaram novidade no Fedora.

\\\\

— … ≠ • ≠ … —

Ferramentas &tc.

terça-feira, 20 de outubro de 2020

Conky 1.11.6 altera cálculo da Memória usada

Aumento aparente de Memória RAM usada, após o Conky 1.11.6

• Desde Agosto 2020, o Conky passou a mostrar valores muito mais altos de uso de Memória RAM nas distros que já adotaram a versão 1.11.6 — tais como openSUSE Tumbleweed, Debian testing, Fedora, Mageia 8 (beta), Void Linux.

Minha primeira conclusão, — ao percorrer problemas (issues) e propostas (PR, pull requests) no Github do Conky, e me perder no labirinto de links cruzados, — foi de que se tratasse de uma falha, e os desenvolvedores não apenas concordassem, como já estivessem tentando resolver, ou até já tivessem resolvido, e faltasse apenas as distros aplicarem as últimas correções.

Eu estava redondamente enganado.


Índice


  • Confusão e erro meu
  • Falha intermitente (Conky 1.11.5)
  • Novo cálculo (Conky 1.11.6)
  • Conky & htop
  • Conky & /proc/meminfo
  • Comparação precária

Confusão e erro meu


Na verdade, eu tinha embaralhado 2 coisas totalmente distintas: — (a) uma falha real no Conky 1.11.5, rapidamente corrigida no Github (mas não nas distros); e — (b) uma deliberada mudança no cálculo da “Memória usada”, no Conky 1.11.6, discutida no Github pelo menos desde Junho 2019, embora só agora tenha chegado às distros rolling-release (e Fedora).

O Git do Conky mostra vários relatos de erros, desde Maio ou Junho 2019, — e há diversas afirmações de que já foi corrigido no Git, o que dá a impressão de que basta as distros se atualizarem. — Existe até uma afirmação de que a versão 1.11.3 é a última sem problemas.

Sem conhecimentos técnicos, é difícil entender metade do que se fala, — ou sequer, ter certeza sobre quem, ali, sabe o que está falando. — Não é um panorama confortável para um mero usuário.

Eis o quadro que levantei, ao iniciar esta publicação, — com destaque (agora) para o que me poderia ter esclarecido sobre a questão atual, — e que se encontra lá atrás, há mais de 1 ano:

#995 - 2020-08-16 - Not accurate RAM memory usage
                    https://github.com/brndnmtthws/conky/issues/995

                    2020-08-11 - [Void] - conky: update to version 1.11.6 #24229
                    https://github.com/void-linux/void-packages/pull/24229

                    [closed] to...
                    https://github.com/void-linux/void-packages/commit/d88554a2de35a8aa46fd34b9aa33540f574b3f2b

#909 - 2019-11-23 - [CLOSED] - RAM monitor does not work correctly
                    https://github.com/brndnmtthws/conky/issues/909

#899 - 2019-10-30 - [CLOSED] - mem/membar objects don't update correctly
                    https://github.com/brndnmtthws/conky/issues/899

#886 - 2019-09-06 - Negative/too low memory reading
                    https://github.com/brndnmtthws/conky/issues/886

       2020-04-02 - @plikhari
                    At present conky git is not usable due to the monster bugs introduced due to updates.
                    The conky up till 1.11.3 is working fine

                    Draghtnod commented on 4 Apr
                    Thanks for that hint!
                    pacman -U https://archive.archlinux.org/packages/c/conky/conky-1.11.3-1-x86_64.pkg.tar.xz

                    (wrong LUA dependency)

#883 - 2019-08-31 - Wrong RAM values #883
                    https://github.com/brndnmtthws/conky/issues/883

                    [Arch] - FS#63597 - [conky]Unstable memory
                    [Closed by no reason]
                    https://bugs.archlinux.org/task/63597?project=1&string=conky&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=&order=dateopened&sort=desc

       2019-08-18 - [PULL] - Fix for #877 #878     --- Technically explained
                    https://github.com/brndnmtthws/conky/pull/878

#877 - 2019-08-14 - Negative RAM Usage                                  ***
                    https://github.com/brndnmtthws/conky/issues/877

#863 - 2019-07-13 - Display of the Network Speed is incorrect #863
                    https://github.com/brndnmtthws/conky/issues/863

                    [PULL] - Fix 860 #871
                    https://github.com/brndnmtthws/conky/pull/871

#860 - 2019-07-01 - [CLOSED] - Linux: memory report includes cached memory even with 'no_buffers = true'
                    https://github.com/brndnmtthws/conky/issues/860

#859 - 2019-06-28 - [PULL] - linux: Memory statistics should match TOP tools
                    https://github.com/brndnmtthws/conky/pull/859

                    sysdata: add htop-like memory usage #1493        ---  5 Sep 2018
                    https://github.com/ultrabug/py3status/pull/1493

                    The kernel introduced a new field explicitly for running calculations. See this commit: torvalds/linux@34e431b
                    rikvanriel authored and torvalds committed on    --- 21 Jan 2014
                    /proc/meminfo: provide estimated available memory
                    https://github.com/torvalds/linux/commit/34e431b0ae398fc54ea69ff85ec700722c9da773

#857 - 2019-06-28 - Conky memory shows wrong value                                ----------- Conky 1.11.4 --- Arch
                    https://github.com/brndnmtthws/conky/issues/857

#841 - 2019-05-24 - ${memperc} showing wrong values
                    https://github.com/brndnmtthws/conky/issues/841
==========================================================================

Como se vê, ali convivem usuários das mais diversas distros e versões do Conky, e com maior ou menor compreensão daquilo que relatam, respondem, comentam.

Falha intermitente (Conky 1.11.5)


Erros de Memória RAM usada, no Conky 1.11.5

Em Agosto 2019, o Conky 1.11.5 começou a exibir lampejos de uso negativo (ou muito baixo) de Memória RAM — por exemplo, no PCLinuxOS, no openSUSE Tumbleweed, depois no Arch, Fedora, Void.

Era um erro intermitente, — pois logo em seguida voltava a exibir o valor “correto”, — até ocorrer nova oscilação.

Na época, a equipe do Conky corrigiu o problema no Github, — e a equipe do PCLinuxOS aplicou a correção em poucos dias, — mas em outras distros a falha intermitente continuou por meses, ou até por mais de 1 ano.

Não tentei registrar as incontáveis ocorrências daquela falha, — mas ela se intrometeu em várias capturas de tela de outros eventos. — No entanto, bastava olhar outras capturas, imediatamente antes e / ou depois, para ter uma ideia de qual seria o uso aproximado de Memória RAM naqueles momentos:

      Date    Time   Distro          Shown     Probably   Task                      Conky version

2019-08-16   23:38   PCLinuxOS    -682 MiB     960  MiB   Synaptic (updates)        1.11.5-4pclos2019 (2019-08-14)
2019-08-16   23:49   PCLinuxOS    -716 MiB   1.5    GiB   open new Chrome version
2019-08-29   12:38   openSUSE     -479 MiB   1.62   GiB   # zypper dup              1.11.5-1.1  (probably)
2019-08-30   19:24   openSUSE     -660 MiB   1.58   GiB   # zypper dup

2019-09-04   16:47   openSUSE     -110 MiB   1.78   GiB   # zypper dup
2019-09-07   18:56   Arch       -1.94  GiB     913  MiB   # pacman -Syyu            1.11.5-2          (2019-08-31)
2019-09-11   13:49   openSUSE   -1.36  GiB                Restart (all closed)
2019-09-15   14:04   openSUSE     -330 MiB     800  MiB   # snapper ls
2019-09-17   11:24   openSUSE   -1.80  GiB     990  MiB   # zypper dup

2019-10-04   00:47   Arch          160 MiB     660  MiB   # pacman -Syyu
2019-10-08   16:05   Arch           41 MiB     800  MiB   # pacman -Syyu
2019-10-24   12:52   openSUSE     -140 MiB   1.50   GiB   # zypper dup              1.11.5-1.2        (2019-09-21)
2019-10-24   16:15   openSUSE     -229 MiB     871  MiB   $ speedtest-cli
2019-10-31   07:48   Fedora         -6 MiB   1.05   GiB   # dnf upgrade             1.11.5-1.fc31     (2019-10-30)

2019-11-07   19:21   Arch (2)          ...
2019-11-10   16:48   Fedora            ...
2019-11-10   16:57   openSUSE          ...
2019-11-10   19:13   Arch              ...
...
2019-11-16   17:54   openSUSE          ...
2019-11-16   19:03   openSUSE          ...
...
2019-11-23   21:23   Void         -531 MiB   1.60   GiB   # xbps-query              1.11.5_1
2019-11-24   17:05   Arch              ...
2019-11-24   17:05   Arch              ...
2019-11-24   18:43   Void           -4 MiB     690  MiB   # xbps-install -Suv
2019-11-25   03:43   Void              ...
2019-11-28   06:42   Arch              ...
2019-11-28   08:02   Fedora       -441 MiB   1.02   GiB   # dnf upgrade
...
2019-12-01   05:45   Void              ...
2019-12-01   13:28   openSUSE          ...
2019-12-03   10:34   Void (2)          ...
2019-12-05   08:51   openSUSE          ...
2019-12-05   09:57   Fedora            ...
2019-12-08   15:42   Fedora            ...
2019-12-13   15:25   Arch              ...
2019-12-19   10:56   openSUSE          ...
2019-12-19   10:56   openSUSE          ...
2019-12-19   13:06   Fedora            ...
2019-12-24   10:14   Arch              ...
2019-12-31   15:06   openSUSE          ...
2019-12-31   17:18   Fedora            ...

2020-01-02   23:21   Fedora            ...
2020-01-07   13:23   openSUSE          ...
2020-01-07   13:48   openSUSE          ...

Em 2020, essa falha prosseguiu no Fedora 32, Mageia 8 (beta), Void, pelo menos até Agosto, — e no Arch, pelo menos até Outubro.

Mas enfim, aquela oscilação do Conky 1.11.5 não atrapalhava tanto, uma vez que não impedia de ver o valor “correto”, alguns segundos depois.

Novo cálculo (Conky 1.11.6)


Proposta do novo cálculo, em 2014

Agora, no Conky 1.11.6, não se trata de um erro. — O que temos agora é a “correção” do antigo cálculo da “Memória RAM usada”, sugerida ou subscrita por Linus Torvalds desde 2014 (Kernel 3.14), quando se introduziu em /proc/meminfo um campo “MemAvailable”, exatamente para tornar esse cálculo mais acurado:

Currently, the amount of memory that is available for a new workload, without pushing the system into swap, can be estimated from MemFree, Active(file), Inactive(file), and SReclaimable, as well as the "low" watermarks from /proc/zoneinfo.

However, this may change in the future, and user space really should not be expected to know kernel internals to come up with an estimate for the amount of free memory.

It is more convenient to provide such an estimate in /proc/meminfo. If things change in the future, we only have to change it in one place.

Aplicação do novo cálculo ao Conky

Essa mudança no Conky foi pedida em Junho 2019 e aplicada em Outubro 2019 (acima), — cerca de 10 meses antes de o Conky 1.11.6 chegar às distros rolling-release (e ao Fedora).

Conky & htop


Indicações iguais de uso de RAM pelo Conky e pelo htop, em 2019

Infelizmente, essa alteração quebra a “consistência das medidas entre diferentes distros” (e ambientes), — até que todas as distros adotem o Conky 1.11.6 (o que pode demorar anos), — além de dificultar a comparação com os números dos últimos meses e anos.

Para contornar essa inconsistência, — enquanto achei tratar-se de um “erro” do Conky 1.11.6, — pensei em usar o htop, que até o início de 2019 acompanhava o Conky com exatidão:

RAM         Used      Free    Buffer     Cache   Buff/Cache   Available    (used Swap)

Conky   2.4  GiB   828 MiB   101 MiB   794 MiB                1.43 GiB   278 MiB
htop    2.4  GiB                                                         278 MiB
top     2150 MiB   830 MiB                          944 MiB   1243 MiB   278 MiB
free    2.1  GiB   829 MiB                          943 MiB   1.2  GiB   277 MiB

Esta noção vinha de 2017, quando uma série de verificações me mostrou uma convergência quase perfeita entre as medidas do Conky e as do htop — com poucas e ínfimas diferenças, talvez devidas ao ciclo normal de 2 segundos do htop, — que na época, não lembrei de igualar ao ciclo do Conky, de 1 segundo.

No entanto, ao revisar agora aqueles registros de 2017, vejo que no openSUSE Leap o Conky e o htop já divergiam bastante:

------------------------ Conky vs. htop – RAM Memory usage -------------------------

     Date        Time     Distro                Conky     htop      A-B        A/B

2017 Jun. 14   16:11:06   Debian testing          651      636     + 15     +  2.36%
2017 Jun. 14   17:30:52   Debian testing          547      547
2017 Jun. 14   17:34:07   Debian testing          489      487     +  2     +  0.41%
2017 Jun. 16   02:07:16   Debian testing          441      441
2017 Jun. 16   02:07:20   Debian testing          488      486     +  2     +  0.41%
2017 Jun. 16   02:08:08   Debian testing          450      450
2017 Jun. 16   04:41:51   Debian testing          448      448

2017 Jun. 14   17:23:28   Kubuntu 16.04           538      538
2017 Jun. 14   17:26:26   Kubuntu 16.04           479      479
2017 Jun. 14   17:28:21   Kubuntu 16.04           461      461
2017 Jun. 15   14:20:28   Kubuntu 16.04           457      456     +  1     +  0.22%
2017 Jun. 15   14:24:49   Kubuntu 16.04           459      459
2017 Jun. 15   14:26:00   Kubuntu 16.04           435      435
2017 Jun. 16   02:21:56   Kubuntu 16.04           431      431
2017 Jun. 17   16:22:41   Kubuntu 16.04           444      444

2017 Jun. 14   16:22:25   KDE Neon (16.04)        482      482
2017 Jun. 14   17:37:32   KDE Neon (16.04)        487      478     +  9     +  1.88%
2017 Jun. 14   17:40:34   KDE Neon (16.04)        428      420     +  8     +  1.90%
2017 Jun. 16   01:46:54   KDE Neon (16.04)        431      432     -  1     -  0.23%
2017 Jun. 16   01:46:56   KDE Neon (16.04)        436      436
2017 Jun. 16   01:47:47   KDE Neon (16.04)        430      430
2017 Jun. 16   03:00:58   KDE Neon (16.04)        433      433
2017 Jun. 16   05:30:43   KDE Neon (16.04)        420      420

2017 Jun. 14   13:44:11   Mint 18 KDE (16.04)     638      638
2017 Jun. 14   16:53:41   Mint 18 KDE (16.04)     558      558
2017 Jun. 14   17:09:59   Mint 18 KDE (16.04)     510      510
------------------------------------------------------------------------------------
     Date        Time     Distro                Conky     htop      A-B        A/B

2017 Jun. 14   13:19:36   Arch                    556      552     +  4     +  0.72%
2017 Jun. 14   16:58:18   Arch                    549      546     +  3     +  0.55%
2017 Jun. 14   17:00:08   Arch                    467      466     +  1     +  0.21%
2017 Jun. 14   18:23:08   Arch                    471      474     -  3     -  0.63%
2017 Jun. 15   14:44:56   Arch                    475      478     -  3     -  0.63%
2017 Jun. 15   14:46:13   Arch                    458      458
2017 Jun. 15   15:01:01   Arch                    477      475     +  2     +  0.42%
2017 Jun. 15   15:02:18   Arch                    457      457
2017 Jun. 15   19:49:33   Arch                    465      465
2017 Jun. 15   19:49:42   Arch                    490      490
2017 Jun. 15   19:50:19   Arch                    449      449
2017 Jun. 15   19:50:49   Arch                    451      451
2017 Jun. 16   05:36:30   Arch                    482      482
2017 Jun. 16   05:37:12   Arch                    466      466

2017 Jun. 14   18:20:05   Arch  (2)               438      439     -  1     -  0.23%
2017 Jun. 14   18:21:36   Arch  (2)               436      432     +  4     +  0.93%
2017 Jun. 15   14:47:53   Arch  (2)               445      445
2017 Jun. 15   14:49:11   Arch  (2)               418      418
2017 Jun. 15   14:51:19   Arch  (2)               419      419
2017 Jun. 15   14:52:42   Arch  (2)               394      394
2017 Jun. 15   14:56:10   Arch  (2)               420      417     +  3     +  0.72%
2017 Jun. 15   14:57:31   Arch  (2)               405      405
------------------------------------------------------------------------------------
     Date        Time     Distro                Conky     htop      A-B        A/B

2017 Jun. 14   16:32:58   Mageia 6 (sta2)         664      664
2017 Jun. 14   17:43:23   Mageia 6 (sta2)         670      666     +  4     +  0.60%
2017 Jun. 14   17:47:01   Mageia 6 (sta2)         618      618
2017 Jun. 15   22:21:21   Mageia 6 (sta2)         605      584     + 21     +  3.60%
2017 Jun. 15   22:22:04   Mageia 6 (sta2)         596      596
2017 Jun. 15   22:22:34   Mageia 6 (sta2)         599      599
2017 Jun. 15   22:47:51   Mageia 6 (sta2)         583      582     +  1     +  0.17%
2017 Jun. 15   22:48:32   Mageia 6 (sta2)         554      554
2017 Jun. 15   23:19:17   Mageia 6 (sta2)         580      580
2017 Jun. 15   23:20:02   Mageia 6 (sta2)         554      554
2017 Jun. 15   23:20:32   Mageia 6 (sta2)         555      554     +  1     +  0.18%
2017 Jun. 15   23:40:21   Mageia 6 (sta2)         576      574     +  2     +  0.35%
2017 Jun. 15   23:41:10   Mageia 6 (sta2)         550      550
2017 Jun. 16   01:18:54   Mageia 6 (sta2)         582      581     +  1     +  0.17%
2017 Jun. 16   01:19:39   Mageia 6 (sta2)         556      556
2017 Jun. 16   04:56:03   Mageia 6 (sta2)         579      579
2017 Jun. 16   04:56:38   Mageia 6 (sta2)         561      561
------------------------------------------------------------------------------------
     Date        Time     Distro                Conky     htop       A-B        A/B

2017 Jun. 14   15:29:53   openSUSE Leap 42.2      590      480     + 110    + 22.92%
2017 Jun. 14   15:33:25   openSUSE Leap 42.2      577      475     + 102    + 21.47%
2017 Jun. 14   17:14:40   openSUSE Leap 42.2      594      481     + 113    + 23.49%
2017 Jun. 14   17:17:36   openSUSE Leap 42.2      528      437     +  91    + 20.82%
2017 Jun. 15   16:32:21   openSUSE Leap 42.2      517      413     + 104    + 25.18%
2017 Jun. 15   16:32:25   openSUSE Leap 42.2      549      448     + 101    + 22.54%
2017 Jun. 15   16:33:43   openSUSE Leap 42.2      528      470     +  58    + 12.34%
2017 Jun. 15   16:34:42   openSUSE Leap 42.2      622      575     +  47    +  8.17%
2017 Jun. 15   16:39:00   openSUSE Leap 42.2      533      449     +  84    + 18.71%
2017 Jun. 15   16:42:32   openSUSE Leap 42.2      537      437     + 100    + 22.88%
2017 Jun. 15   17:13:52   openSUSE Leap 42.2      594      565     +  29    +  5.13%
2017 Jun. 15   17:59:12   openSUSE Leap 42.2      529      434     +  95    + 21.89%
2017 Jun. 15   18:00:47   openSUSE Leap 42.2      516      457     +  59    + 12.91%
2017 Jun. 15   18:01:47   openSUSE Leap 42.2      516      457     +  59    + 12.91%
2017 Jun. 16   05:10:25   openSUSE Leap 42.2      536      432     + 104    + 24.07%
2017 Jun. 16   05:10:53   openSUSE Leap 42.2      527      455     +  72    + 15.82%

                                             openSUSE Average:     +  83    + 18.20%
------------------------------------------------------------------------------------

Essa estranheza do Conky no openSUSE Leap ficou mais evidente ao levantar o histórico de atualizações das várias distros, de 2016 até o início de 2020, — e constatar que o Leap, sozinho, teve mais versões e revisões do Conky, do que a soma de todas as outras distros, incluindo as rolling-release. — Várias vezes, o Conky era o único pacote a ser atualizado nele:

Oct 2016 — Jan 2020
---------------------------------------------------------------
Debian testing

2016 Oct  1 00:09:04         installed      conky-all 1.9.0-6
2016 Oct 18 00:39:38         upgraded       conky-all 1.10.5-1
2016 Dec 20 10:47:58         upgraded       conky-all 1.10.6-1
2017 Sep 21 21:37:00         upgraded       conky-all 1.10.6-1.1
2018 Mar  6 07:24:12         upgraded       conky-all 1.10.8-1
2018 May 16 15:36:34         upgraded       conky-all 1.10.8-1+b1
---------------------------------------------------------------
KDE Neon

2017-03-22 21:28:45          installed      conky-all 1.10.1-3
---------------------------------------------------------------
Kubuntu 16.04

2016-04-27 18:25:23          installed      conky-all 1.10.1-3
2018-11-02                   (still)        conky-all 1.10.1-3
---------------------------------------------------------------
Mint 18 KDE

2016 Aug 20 11:55:09         installed      conky-all 1.10.1-3
---------------------------------------------------------------
Arch (Revenge)

2017-06-03 18:41             installed      conky 1.10.6-2
2017-11-24 00:47:59          upgraded       conky-1.10.6-3
2018-01-22 07:36:58          upgraded       conky-1.10.7-1
2018-01-24 12:47:23          upgraded       conky-1.10.7-2
2018-02-15 12:02:50          upgraded       conky-1.10.8-1
2018-03-12 17:37:56          upgraded       conky-1.10.8-2
2018-12-08 12:50:10          upgraded       conky-1.11.0-1
2018-12-23 00:11:19          upgraded       conky-1.11.1-1
2019-01-08 22:47:57          upgraded       conky-1.11.2-1
2019-03-02 06:49:07          upgraded       conky-1.11.3-1
2019-06-29 04:53:28          upgraded       conky-1.11.4-1
2019-08-15 10:35:40          upgraded       conky-1.11.5-1
2019-08-31 12:51:59          upgraded       conky-1.11.5-2

     PrtScn 2019-09-07_18-56-41_Arch    Conky-MEM-used-negative
---------------------------------------------------------------
Mageia

2018-11-02 (Mageia 6)        rpm -qa        conky-1.10.6-1
2019-03-17 (Mageia 7)        urpmi conky
2019-04-18 07:38:07          upgraded       conky 1.11.3
---------------------------------------------------------------
Fedora

2019-07-05                   dnf install    conky-1.11.3-1.fc30
2019-10-30                   system-upgrade conky-1.11.5-1.fc31

     PrtScn 2019-10-31   07:48          Conky-MEM-used-negative
---------------------------------------------------------------
PCLinuxOS

2017-12-19 14:41:53          installed      conky 1.10.6-5pclos2017
2018-01-29 17:18:58          upgraded       conky 1.10.7-1pclos2018
2018-02-26 19:44:21          upgraded       conky 1.10.8-1pclos2018
2019-06-29 05:09:05          upgraded       conky 1.11.5-2pclos2019
2019-07-10 11:53:24          upgraded       conky 1.11.5-3pclos2019
2019-08-14 10:54:30          upgraded       conky 1.11.5-4pclos2019

    PrtScn 2019-08-16_23-38-53_PCLinuxOS     Conky-Mem-used-NEGATIVE

2019-08-20 20:02:00          upgraded       conky 1.11.5-5pclos2019
---------------------------------------------------------------
Sabayon

2018-12-01_12-26-26          equo install   conky-1.10.8-r3
2019-01-08 21:59:59          upgraded       conky-1.10.8-r4
---------------------------------------------------------------
Void
                             installed      conky-1.11.5_1

    PrtScn 2019-11-23_21-23-57          Mem-used-very-Low
---------------------------------------------------------------
openSUSE

2017-01-17 03:25:35          | install |    conky|1.10.1-7.1
2017-08-03 23:54:51          | install |    conky|1.10.6-13.1 | packman.inode.at-suse
       (...)
2017-10-28 11:33:13          upgraded       conky-1.10.6-13.16          1 package
2017-10-29 13:51:32          upgraded       conky-1.10.6-13.18         11 packages
2017-10-31 15:07:06          upgraded       conky-1.10.6-13.19          1 package
2017-11-11 01:04:16          upgraded       conky                      11 packages
2017-11-24 01:31:41          upgraded       conky                      57 packages
2017-11-29 00:17:24          upgraded       conky                      11 packages
2017-12-09 09:03:40          upgraded       conky                       1 package
2017-12-12 22:36:55          upgraded       conky                       5 packages
2017-12-13 23:25:26          upgraded       conky                       1 package
2017-12-17 12:58:38          upgraded       conky                      18 packages
2017-12-22 20:52:16          upgraded       conky-1.10.6-15.6          33 packages
2017-12-24 21:59:21          upgraded       conky                       3 packages
2017-12-30 21:20:02          upgraded       conky                      12 packages
2018-01-04 19:05:40          upgraded       conky                       3 packages
2018-01-10 02:24:11          upgraded       conky                       1 package
2018-01-13 14:49:26          upgraded       conky                       1 package
2018-01-15 19:40:31          upgraded       conky                      41 packages
2018-01-16 12:47:29          upgraded       conky                       3 packages
2018-01-19 07:36:24          upgraded       conky                       1 package
2018-01-22 07:50:12          upgraded       conky                       2 packages
2018-01-23 09:08:36          upgraded       conky                       1 package
2018-01-27 20:32:38          upgraded       conky                       3 packages
2018-02-01 09:43:37          upgraded       conky-1.10.6-16.10         25 packages
2018-02-04 09:37:54          upgraded       conky                      18 packages
2018-02-05 16:51:49          upgraded       conky                       4 packages
2018-02-11 21:36:26          upgraded       conky                      60 packages
2018-02-15 13:00:30          upgraded       conky                      33 packages
2018-02-25 19:51:36          upgraded       conky                      85 packages
2018-03-06 01:03:40          upgraded       conky                      38 packages
2018-03-12 21:05:17          upgraded       conky                      70 packages
2018-03-16 16:14:30          upgraded       conky-1.10.8-8.4           28 packages
2018-03-19 10:14:41          upgraded       conky                      21 packages
2018-03-24 18:59:51          upgraded       conky                     102 packages
2018-04-01 18:13:46          upgraded       conky                       5 packages
2018-04-08 11:33:55          upgraded       conky                      11 packages
2018-04-16 20:14:43          upgraded       conky                      10 packages
2018-04-21 15:53:59          upgraded       conky                       6 packages
2018-04-26 22:02:06          upgraded       conky                      46 packages
2018-05-11 16:27:33          upgraded       conky                      32 packages
2018-05-19 12:10:58          upgraded       conky                      30 packages
2018-05-29 19:13:06          upgraded       conky                       6 packages
2018-06-10 17:09:43          upgraded       conky                      11 packages
2018-06-16 19:24:28          upgraded       conky                      63 packages
2018-06-28 12:50:46          upgraded       conky                      10 packages

                       upgrade Leap 42.3 to 15.0
2018-06-28 22:11:09                         conky-1.10.6-lp150.1.2  (???)

2018-07-02 09:17:06    # zypper ar -cfp 90 packman
2018-07-02 09:17:34                         conky will not be upgraded
2018-07-04 16:46:19                         conky will not be upgraded
              (...)
2018-10-14 15:11:43    zypper ps restart    conky     (why??)

2019-05-22 12:25:18    upgrade Leap 15.0 to 15.1

    Problem with installed package conky-doc-1.10.8-lp150.8.11.x86_64
     Solution 1: install conky-doc-1.10.6-lp151.2.4.x86_64 (with vendor change)
                 http://packman.links2linux.de  -->  openSUSE
     Solution 2: keep obsolete conky-doc-1.10.8-lp150.8.11.x86_64

                             upgraded       conky                    2765 packages
                             Downgraded     conky-doc

2019-05-23 13:43:02                         conky will not be upgraded
2019-05-25 19:09:10                         conky will not be upgraded

2019-06-23 16:04:01    upgrade Leap 15.1 to Tumbleweed

2019-06-27 16:07:39      To change this default behavior and allow only required packages, adjust the solver.onlyRequires option in /etc/zypp/zypp.conf.
                         solver.onlyRequires = true
                         Additionally, edit the file /etc/zypp/zypper.conf and change the installRecommends option.
                         installRecommends=false
                         This changes the behavior of all package operations, such as the installation of patches or new packages. To change the behavior of Zypper for a single invocation, add the parameter --no-recommends to your command line.

2019-06-28 08:09:29           upgraded       conky-1.11.4-1.1         198 packages
2019-07-06 19:15:23           upgraded       conky                     72 packages
2019-07-18 22:24:06           upgraded       conky                   2579 packages
2019-08-23 22:50:02           upgraded       conky                    432 packages

    PrtScn 2019-08-29_12-38-42_openSUSE    Conky-MEM-RAM-negative

2019-09-21 08:17:03           upgraded       conky-1.11.5-1.2         166 packages
2019-11-21 06:27:11           upgraded       conky                    794 packages
2019-12-13 10:10:41           upgraded       conky                    338 packages

    PrtScn 2019-12-19_10-56-45_openSUSE    486 MiB changed Minus -249 MiB
---------------------------------------------------------------

Como se vê (acima), só nos 8 meses que vão de Outubro 2017 até Junho 2018, o openSUSE Leap apresentou nada menos que 44 atualizações ou revisões do Conky, — praticamente 1 a cada 5 dias, — como se houvesse uma tentativa incessante de corrigir alguma coisa, sem sucesso.

Para uma comparação: — Em 2020, no openSUSE Tumbleweed, às vezes passam-se meses sem atualização do Conky.

Conky & /proc/meminfo

Memória RAM usada, segundo Conky, htop, inxi, free, top

Depois de teimar alguns dias com os argumentos de Chris Cheney (calc, nos Comentários, abaixo; e no Facebook), acabei deixando de lado a selva de issues e PRs do Conky, para me concentrar só nos 2 ou 3 links indicados por ele, — após alguns dias longe do assunto, para esvaziar a cabeça.

Quando finalmente achei ter entendido, resolvi testar o cálculo indicado por ele (“new”), — em relação ao “antigo” (“old”), — e comparar ambos com o das diferentes versões do Conky, e com o das demais ferramentas: htop, inxi, free, top.

Como não pude entender a fórmula do cálculo “antigo” indicada por ele, arrisquei uma hipótese, usando apenas parte da descrição textual de Linus Torvalds, — sem as “marcas d'água”, — e o resultado se mostrou sempre bastante próximo do indicado pelo htop:

/proc/meminfo (old):

Mem used = MemTotal - [MemFree + Active(file) + Inactive(file) + SReclaimable]

/proc/meminfo (new):

Mem used = MemTotal - MemAvailable

Para obter um quadro tão “simultâneo” quando possível, incluí no próprio Conky o htop, inxi, free, top, executados a cada 10 segundos, — e registrei o início da sessão KDE, ao final do boot de cada distro:

Mem:
Conky  ${alignr}${mem}                       ${color gray40}.${color}
htop ${alignr}${execi 10 export TERM=xterm; echo q | htop | aha --line-fix | html2text | grep "/15" | cut -b 30-34}iB                       ${color gray40}.${color}
inxi ${alignr}${execi 10 inxi --memory-short | grep used | cut -b 52-57}  MiB${alignr}                  ${color gray40}.${color}
free ${alignr}${execi 10 free -m | grep Mem | cut -c 25-32}    MiB${alignr}                  ${color gray40}.${color}
top  ${alignr}${execi 10 top -E m -b -n 1  | grep buff | cut -c 41-50} MiB${alignr}                  ${color gray40}.${color}

O ciclo de 10 segundos evita oscilações súbitas nesses indicadores. — Assim que se atualizam, basta anotar (à mão) só o número indicado pelo próprio Conky, antes de acionar o gnome-screenshot, — pois este, às vezes, captura um valor já alterado por seu acionamento.

Referências:

Em cada distro, passei então ao console virtual tty2, me loguei como root e executei um script simples, para gravar em arquivo TXT essas e outras leituras, — sem abrir o Konsole, pois isso alteraria de modo significativo o uso de Memória RAM:

# cat /root/RAM.sh
date                                               > RAM.txt
echo "                    "                       >> RAM.txt
echo "-----   inxi   -----"                       >> RAM.txt
inxi -m                                           >> RAM.txt
echo "                    "                       >> RAM.txt
echo "-----   free   -----"                       >> RAM.txt
free -m                                           >> RAM.txt
echo "                    "                       >> RAM.txt
echo "-----   top    -----"                       >> RAM.txt
top -E m -b -n 1 | grep buff                       >> RAM.txt
echo "                    "                       >> RAM.txt
echo "-----   htop   -----"                       >> RAM.txt
echo q | htop | aha --line-fix | html2text         >> RAM.txt
echo "                    "                       >> RAM.txt
echo "-----   proc (old)  -----"                  >> RAM.txt
cat /proc/meminfo | grep "MemTotal\|MemFree\|Active(file)\|Inactive(file)\|SReclaimable" >> RAM.txt
echo "                    "                       >> RAM.txt
echo "-----   proc (new)  -----"                  >> RAM.txt
cat /proc/meminfo | grep "MemTotal\|MemAvailable" >> RAM.txt
echo "                    "                       >> RAM.txt
echo "-----   proc (full)  -----"                 >> RAM.txt
cat /proc/meminfo                                 >> RAM.txt
echo "                    "                       >> RAM.txt
date                                              >> RAM.txt

Ainda no tty2, anotei (à mão) também uma leitura “visual” do htop, — pois ainda não consegui instalar o aha e o html2text em todas as distros.

Em seguida, encerrei a sessão root, voltei à sessão KDE em tty7 ou tty1, conforme o caso, — e esperei alguns minutos, até tornar a abaixar o uso extra de Memória RAM (causado pela primeira captura de tela), para fazer novo registro.

Por economia de espaço, indico as medidas como “Conky-htop”, “Conky-inxi” etc., — a seguir, “tty2-inxi”, “tty2-htop” etc., — e os cálculos a partir de /proc/meminfo, como “old” e “new”:

Medidas do uso de Memória RAM no openSUSE

No openSUSE, o Conky indicou uso de Memória RAM próximo ao cálculo “novo”, enquanto o htop se alinhou com o cálculo “antigo”.

O free e o top se alinharam no nível mais baixo de todos, — como tenho notado em todas as distros, desde 2017, — enquanto o inxi ficou entre eles e o htop, sem se alinhar com nada.

(Coloqueí o cálculo “novo” no final, para não ter de refazer toda a sequência de cores do gráfico, que já existia. Cronologicamente, deveria estar ao lado do cálculo “antigo”, pois o /proc/meminfo foi obtido de uma só vez, na etapa tty2).

Medidas de uso de Memória RAM no Arch

No Arch Linux, ficou evidente o alinhamento do Conky com o htop e com o cálculo “antigo”, enquanto o cálculo ”novo” indica o que se pode esperar do próximo Conky 1.11.6, quando chegar.

Do AUR, optei por instalar apenas o aha, para exibir o htop no Conky, — mas não vi benefício em instalar o inxi, que tem indicação de problemas, e afinal de contas não se mostra útil.

No geral, todos os números são relativamente baixos, — comparáveis aos do Void, do Slackware e do MX Linux (adiante).

Medidas de uso de Memória no Debian testing

No Debian testing, o alinhamento do Conky ao cálculo “novo” é quase exato.

De um modo geral, o conjunto dos números indica um uso “mediano” de Memória, — abaixo do Fedora, que se destaca por um uso nitidamente maior.

Medidas de uso de Memória no Fedora 33

No Fedora 33, o alinhamento do Conky ao cálculo “novo” também fica bem nítido.

Medidas de uso de Memória no KDE Neon

No KDE Neon, o Conky se mantém alinhado ao htop e ao cálculo “antigo”, — enquanto o cálculo “novo” dá uma previsão do que o Conky 1.11.6 iria indicar.

Medidas de uso de Memória no PCLinuxOS

No PCLinuxOS, o Conky também se mantém alinhado ao htop, — enquanto o cálculo “novo” dá uma ideia do que o Conky 1.11.6 indicará, quando chegar.

Por falta do aha e / ou do html2text, ainda não incluí o htop no Conky.

No geral, todos os números estão um pouco acima do grupo “intermediário”, — formado pelo Debian testing, KDE Neon, Mageia 8 (beta), Linux Mint 20 (com KDE). — Esse pequeno aumento no uso de Memória RAM ocorreu após uma configuração do UXA, que fiz em Março 2020, por motivos alheios ao caso.

Medidas do uso de Memória no Mageia 8 (beta)

No Mageia 8 (beta), o Conky 1.11.6 se alinhou com o cálculo ”novo”.

Medidas do uso de Memória no Linux Mint 20

No Linux Mint 20 (com KDE), o gráfico é quase idêntico ao do KDE Neon, já que ambos usam a mesma base “Ubuntu 20.04 LTS”.

Medidas do uso de Memória no Void Linux

No Void Linux, o Conky 1.11.6 também se alinhou ao cálculo “Novo”.

O que o distingue, é que todos os números são bem inferiores aos das distros vistas até aqui, — liderando o grupo de menor uso de Memória RAM, — Arch, Slackware, MX Linux.

Medidas do uso de Memória no Slackware KDE (by AlienBOB)

No Slackware, o Conky se mostrou alinhado ao htop e ao cálculo “antigo”, — pois instalei uma versão do Conky, talvez, arbitrária, a partir de um pacote desgarrado, encontrado algures, há uns 2 anos.

Os números também são baixos, embora não tanto quanto no Void Linux.

Medidas do uso de Memória no MX Linux

No MX Linux, o Conky também se mantém alinhado ao htop e ao cálculo “antigo”, por ser uma distro com base no Debian stable, com pacotes antigos.

No geral, os números também são baixos, embora não tanto quanto no Slackware.

Comparação precária


Conky, htop, cálculo “antigo” e “novo”

Incluir o htop no Conky mostrou-se um modo prático de ter o cálculo “antigo” sempre à vista, — como eu teria em uma versão anterior do Conky, — para uma comparação (precária) do uso inicial de Memória RAM entre diferentes distros Linux (neste caso, todas com KDE).

No gráfico (acima), salta à vista quais distros usam mais ou menos Memória RAM, — tanto pelo cálculo “antigo”, quanto pelo “novo”, — independente da versão do Conky em cada uma.

Infelizmente, ainda não encontrei um modo de ter sempre à vista o cálculo “novo”, — exceto nas distros que já adotaram o Conky 1.11.6.

Uso inicial de Memória RAM, corrigido pelo htop

Ao substituir os números de Agosto e Setembro pelos obtidos agora no htop, o gráfico (acima) apresenta um comportamento mais “comparável”, entre distros diferentes, quanto ao uso inicial de Memória RAM, — pois, “certo” ou “errado”, o htop permanece consistente com as versões anteriores do Conky.

Resta um aumento geral no uso inicial de Memória RAM (exceto MX Linux), — que parece brusco, devido ao salto de 3 meses, — mas não escandaloso como o indicado no Conky 1.11.6.

O KDE Neon, por exemplo, já apresentava um aumento antes do upgrade para a base Ubuntu 20.04 Focal Fossa; e depois do upgrade ainda aumentou mais um pouco.

Já o Slackware KDE (by AlienBOB), não apresenta nenhum aumento no uso inicial de Memória RAM, até porque ainda não me acostumei a atualizá-lo, — mas eu não tinha como incluí-lo nesta série (com o htop no final), pois só foi instalado no final de Setembro, depois do último levantamento geral das outras distros, antes do Conky 1.11.6.

\\\\

— … ≠ • ≠ … —


Ferramentas &tc.


quarta-feira, 30 de setembro de 2020

Slackware by Alien - install, config

Slackware by Alien em sessão Plasma KDE

Está é a terceira ou quarta vez que reinstalo o Slackware by Alien Bob; — as primeiras vezes, por tê-lo escangalhado além das minhas possibilidades de consertá-lo; — agora, por simples migração para um novo hardware (e vim adiando, desde Janeiro).

Mais do que nunca, isto não é um “tutorial”. — Só um registro do que fiz, — tateando e cometendo muitos erros.

Pós-instalação


Correção do Grub (externo) para carregar o Slackware

O Grub do openSUSE e do Mageia produziu entradas para “vmlinuz-generic-5.4.66”, e o boot se paralisou em “Kernel panic”. — Nesse primeiro momento, bastou corrigir manualmente para “vmlinuz-huge-5.4.66”, para conseguir carregar o Slackware.

Desabilitando Os-Prober e gerando o Grub

Com isso, pude gerar o arquivo /boot/grub/grub.cfg do próprio Slackware, — e depois disso, o Grub das outras distros já pode ler nele o parâmetro correto:

# grub-install /dev/sda1
Installing for x86_64-efi platform.
Installation finished. No error reported.

# date; grub-mkconfig -o /boot/grub/grub.cfg; date
Sat Sep 26 14:38:40 -03 2020
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-huge-5.4.66
Found initrd image: /boot/initrd.gz
Found linux image: /boot/vmlinuz-huge
Found initrd image: /boot/initrd.gz
Found linux image: /boot/vmlinuz-generic-5.4.66
Found initrd image: /boot/initrd.gz
Found linux image: /boot/vmlinuz-generic
Found initrd image: /boot/initrd.gz
done
Sat Sep 26 14:38:44 -03 2020

Pastas das distros Linux na partição EFI

Note que, para isso, não precisava instalar a “chamada” na partição EFI. — Fiz isso, só para “ver” o que seria gravado lá, pois varia muito de uma distro para outra. — Mas sempre pode ser útil, a qualquer momento.

De qualquer modo, o Grub do Slackware também não precisava perder tempo detectando outras distros, — e primeiro acrescentei uma linha em /etc/default/grub:

GRUB_DISABLE_OS_PROBER=true

Essa edição foi feita no editor interno do mc (Midnight-Commander), logado como root.

Só 10 minutos depois, lembrei de datar os comandos:

$ history
    1                       su
    2                       echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
    3  2020-09-26_14-58-33  history

# history
    1                       cd /usr/lib64/vlc
    2                       find . -name "plugins*.dat" -exec rm -f {} \;
    3                       echo "Generating VLC plugins cache data..."
    4                       DISPLAY="" ./vlc-cache-gen /usr/lib64/vlc/plugins
    5                       grub-install /dev/sda1
    6                       mc
    7                       mc
    8                       date; grub-mkconfig -o /boot/grub/grub.cfg; date
    9                       mc
   10                       mc
   11                       echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
   12  2020-09-26_14-58-44  history

Antes desse momento, eu havia executado (como root) apenas alguns comandos relacionados ao VLC, — talvez sugeridos pelo próprio Slackware, ao abrir o Konsole. — Não fiz anotações sobre isso, nem capturas de tela, e só posso imaginar o objetivo desses comandos.

Opção de montagem em serviços de segundo plano

A montagem automática de partições adicionais me tomou mais de 1 hora, e saiu dos trilhos que eu me havia acostumado a seguir.

13:49 - Ao desativar serviços em segundo plano que não uso, não vi essa opção, — que por sinal, eu nunca vi em nenhuma outra distro, mesmo as que já usam KDE mais recente. — Não vi, não ativei, e talvez esteja ligada ao problema que enfrentei em seguida.

14:05 - Ativei a montagem automática de “dispositivos removíveis” (que não são do sistema) no KDE System settings. — Isso nunca funcionou nas instalações anteriores do Slackware, — mas também nunca atrapalhou.

15:24 - Nova sessão (reiniciei, ou só logout / login?), naturalmente sem montagem das partições adicionais.

15:33 - Colei no /etc/fstab um conjunto de linhas que sempre funcionou para a montagem das partições adicionais, — tanto no Slackware, quando no Debian, LMDE, MX Linux...

15:36 - ... mas ao reiniciar o computador, as partições adicionais não foram montadas.

15:52 - Tentativas de montagem manual retornaram o aviso de que não existiam os pontos de montagem, — coisa que nunca foi problema, nas instalações anteriores.

15:57 - Criei manualmente um ponto de montagem, para teste, — mas não reiniciei, portanto não houve oportunidade de verificar se ia funcionar ou não. — Me limitei a tentar a montagem daquela única partição, pelo Dolphin, e como foi pedida senha, concluí que não resolveu.

xxx

xxx

— … ≠ • ≠ … —

Without-SystemD



    PC desktop UEFI / GPT



    Ferramentas &tc.



    Não-debians