Translate

quarta-feira, 15 de janeiro de 2020

Transição para hardware UEFI-GPT

Particionamento inicial para dualboot 12 distros Linux em UEFI

Fazer dualboot / multiboot de várias distros Linux em UEFI não foi o bicho-papão que eu imaginava.

Ao me preparar para a transição de BIOS (legacy) para UEFI, quanto mais eu lia, menos gostava. — A impressão era de uma geringonça desconjuntada.

Faltava lidar com o assunto, na prática, para constatar que é de uma simplicidade absoluta, — como diziam.

Ainda me incomoda, a partição EFI usar um antigo formato proprietário (Fat32), — mas não vejo como evitar. — Enfim, o formato já caiu no domínio público, e a MS não cria mais problema.

Índice

  • Simplificando desde o hardware
  • Secure Boot
  • Particionamento mínimo:
  • Tabela de particionamento GPT
  • Partição EFI
  • Partições-raiz
  • Instalação
  • PCLinuxOS
  • openSUSE
  • Fedora
  • KDE Neon
  • UEFI Bios Utility e efibootmgr
  • Conteúdo da partição EFI
    • Criando uma 2ª partição EFI
  • Vida após a mudança
    • Grub
    • Conky
    • Partição Swap
    • Movendo a /home: Fedora e SELinux
    • Cronologia: — Distros, partições etc.
  • Referências

Nos tempos do BIOS (legacy) / MBR

Simplificando desde o hardware

Hardware com UEFI e SSD Sata III, sem placa de Video (e principalmente, sem Nvidia)

O primeiro requisito era um hardware UEFI, — ausente no meu antigo PC (de 2009), que já pedia aposentadoria, — mas qualquer novo hardware, hoje, seria UEFI.

Meu antigo PC foi montado com CPU + iGPU Intel sobre placa-mãe Asus, lançadas no final de 2008, — e nesses 11 anos nunca tive problema de drivers, em 25 ou 30 distros de todos os ramos principais do Linux. — Como eu não jogo, este comprovou ser um caminho para manter as coisas tão simples quanto possível.
MoBo:     ASUSTeK P5KPL-AM-CKD-VISUM-SI    Bios / Sata II / USB 2.0
CPU:      Dual core Intel Core2 Duo E7300 2660 MHz
iGPU:     Intel 82G33/G31 Express Integrated Graphics Controller
Memory:   4 GB     (2 x 2 GB speed: 667 MHz type: DDR2)
HDDs:     (Sata II)

Agora, com ajuda dos fóruns e de um amigo, montei uma configuração relativamente “atual”, — preços já desinflados, mas com menos de 1 ano de lançamento, — capaz de se manter usável por vários anos:

  • Processador de 6 núcleos (i5, de 9ª geração), 2,9 GHz (turbo dinâmico 800 MHz ~ 4,1 GHz) + iGPU Intel, consumo / dissipação: 65 W;
  • Placa-mãe um pouco acima do básico (portas para expansão);
  • 1 pente 16 GB RAM (máx.: 4 x 16); e
  • 1 SSD modesto (480 GB) mas relativamente “rápido”, para começar.

MoBo:     ASUSTeK TUF B360M-PLUS Gaming/BR    UEFI / Sata III / USB 3.1 (Gen 1, 2)
CPU:      6 × Intel® Core™ i5-9400 CPU @ 2.90 GHz (min/max: 800/4100 MHz)
iGPU:     Intel UHD Graphics 630 driver: i915 v: kernel
Memory:   16 GiB speed: 2400 MT/s type: DDR4   (max: 4 x 16 = 64 GiB)
SSD:      480 GB Kingston A400 Sata III

Adquiri as peças em 3 lojas, — e pedi ao técnico de uma delas que fizesse a montagem, — sem instalar Windows, para não complicar.

Já fiz a montagem, uma vez (2009), mas “delegar” essa tarefa, — preço embutido nas peças de uma das lojas, — é muito mais simples e rápido (40 minutos).

Portanto, comecei com apenas 1 SSD, — vazio, intocado, — o que também simplificou bastante:

  • Sem placa de vídeo — e principalmente, sem Nvidia
  • Sem Windows
  • Sem partições para converter ou redimensionar
  • Sem arquivos — sem necessidade de backup

Secure Boot

Desativando o “Secure Boot” no “UEFI Bios Utility”

Ao ligar o PC, apertei DEL para entrar no “UEFI Bios Utility” — o utilitário para configurar o firmware da máquina.

Me certifiquei de que estava selecionada a opção “Other OS”, — em Advanced Mode (F7) >> Boot >> Secure Boot >> OS Type, — pois vi dizer que a opção “Windows UEFI mode” dificulta a instalação do Linux.

Não mexi em mais nada, — bisbilhotei por toda parte, mas não vi mais nada que precisasse alterar, de início, — e tudo funcionou muito bem, desde o primeiro dia.

No primeiro Boot, com o SSD ainda vazio — portanto, sem Bootloader — carregou o Grub do Live DVD PCLinuxOS, único sistema operacional presente, naquele momento.

A escolha do PCLinuxOS foi obra do acaso, — era o DVD mais recente, que encontrei na gaveta (exceto Arch e Void, mais complicados, que deixei para depois). — Com o PCLinuxOS, eu podia instalar o Conky para monitorar a sessão Live, usar o GParted para particionar, e fazer capturas de tela, com todo conforto.

Particionamento mínimo

Tabela de particionamento GPT

Criando a “Tabela de Particionamento GUID” (GUID Partition Table = GPT)

Com o SSD ainda intocado, o primeiro passo era criar a “Tabela de Particionamento GUID”, — mais conhecida pela sigla “GPT” (GUID Partition Table):

Device >> Create Partition Table

O GParted seleciona “MSDOS” (MBR), por padrão, — e é preciso alterar isso, — em “Select new partition table type”:

msdos >> gpt

Partição EFI

Campos e opções ao criar uma partição EFI (reconstituição posterior)

Cliquei com o botão direito do mouse em “unallocated”, — que era todo o espaço do SSD, — e selecionei “New”, para criar uma partição.

A primeira partição que criei foi a “EFI System Partition”, — nome copiado de algum tutorial.

Em Filesystem, selecionei “Fat32”. — Preenchi o Rótulo (Label) com “EFI”.

Apenas o formato é fundamental, — mas não custa nada preencher os outros campos. — Isso pode facilitar sua vida, no futuro:

  • Filesystem: - Também são aceitos Fat12 e Fat16 (para mídias menores).
  • Partition name: - Já vi usar outros nomes, p.ex.: “EFI System”, “EFI Boot”.
  • Label: - Digitei “EFI”, mas já vi usar “efi”, “EFI Boot”, — e até deixar sem Label.

Resumo da criação da partição EFI de 2 GiB pelo GParted

Os tutoriais sugerem tamanhos de 256 ou 512 MB, — e até de 1 GB, quando o autor se sente inseguro.

Optei por 2 GiB, por via das dúvidas, — digitei “2048” no campo “New size”, — e hoje sei que foi um exagero descomunal.

  • Ver “Conteúdo da partição EFI”, adiante.

Gerenciando as Flags da partição EFI

Depois de criar a partição EFI, atribuí a ela as Flags: — boot, esp.

Right-clck >> Manage Flags >> boot

Ao selecionar “boot“, automaticamente também foi selecionada “esp”, — e desmarcada a flag padrão (msftdata). — Esta operação não precisa de “Apply” posterior.

Exemplo de partição EFI no final (e sem Label)

A partição EFI não precisa ser a primeira. — Isso não é requisito das especificações UEFI (Unified Extensible Firmware Interface (UEFI) Specification - Release 2.11). — Apenas, o Windows “recomenda” que seja a primeira — e você pode ter mais de uma:

13.3.3 Number and Location of System Partitions

UEFI does not impose a restriction on the number or location of System Partitions that can exist on a system. System Partitions are discovered when required by UEFI firmware by examining the partition GUID (...).

Software installation may choose to create and locate an ESP on each target OS boot disk, or may choose to create a single ESP independent of the location of OS boot disks and OS partitions (...).

Partições-raiz

Partições para instalação das primeiras 6 distros

Em seguida, criei as partições para instalação de 12 distros.

Neste primeiro momento, optei por não criar partições /home, nem Swap, para começar do modo mais simples possível, — pois a EFI e a “/” (raiz do sistema Linux) são as únicas realmente indispensáveis.

O SSD de 480 GB não seria suficiente para 12 partições-raiz + 12 partições /home. — Eu pretendia adicionar outro SSD, mas devido à pandemia, só fiz isso em 2023.

Espaço usado pelas distros em partições de 25 GiB (raiz e /home) no antigo PC

A experiência dos últimos 3 anos já me havia dado uma boa noção do espaço usado na partição-raiz de cada distro, — incluídas oscilações do cache de pacotes, entre uma limpeza e outra, — bem como do pouco espaço ocupado nas pastas /home, uma vez que meus documentos, fotos etc. ficam em partições próprias.

Uso de RAM em sessão Live com 11 abas no Chrome (9 do Facebook), sem Swap

Uso de CPU e RAM em sessão Live com GoogleEarth no Chrome, sem Swap

Durante a sessão Live, — em que a Memória RAM já é sobrecarregada pela montagem virtual da “árvore” de arquivos de sistema, descompactada da ISO, — alguns testes simples também mostraram que o pente inicial de 16 GB daria conta do recado, sem necessidade imediata de partições Swap.

Restaram 65 GiB, que usei para criar uma partição de documentos — pois não faria sentido espalhá-los em várias /home:

sda       447 GiB
├─sda1      2 GiB   efi
├─sda2     50 GiB   Linux1
├─sda3     30 GiB
├─sda4     30 GiB
├─sda5     30 GiB   Linux4
├─sda6     30 GiB   Linux5
├─sda7     30 GiB   Linux6
├─sda8     30 GiB
├─sda9     30 GiB
├─sda10    30 GiB
├─sda11    30 GiB
├─sda12    30 GiB
├─sda13    30 GiB
└─sda14    65 GiB   Storage

Instalação

PCLinuxOS

Partições Root e /boot/EFI na instalação do PCLinuxOS

No instalador do PCLinuxOS (Draklive install), escolhi a opção de “Particionamento personalizado” (Custom disk partitioning), — pois as partições já estavam prontas. — Bastava escolher.

Atribuí o ponto de montagem “/” à partição Linux6, — e o ponto de montagem /boot/EFI à partição EFI.

Ao clicar em “Done” para concluir a etapa de “Particionamento”, o Draklive install apresentou o sumário das operações: — Formatar apenas a partição-raiz, — padrão de prudência, pois é comum a partição EFI conter o Bootloader de outras distros instaladas antes.

Instalação do Bootloader do PCLinuxOS na EFI System Partition (Boot device)

Chegando à etapa do Bootloader do PCLinuxOS, me certifiquei de que ele seria instalado na partição EFI System Partition (Boot device). — Acho que essa opção foi automática, mas sempre é bom verificar.

      Date           Live      Installed       Distro
               1st PrtScn     1st PrtScn

2020-01-10          14:02          23:51       PCLinuxOS
2020-01-11          16:06          17:14       openSUSE
2020-01-12          12:28          13:59       KDE Neon
2020-01-12          15:05          17:53       Fedora

Terminada a instalação, reiniciei o computador, tudo funcionou de primeira, — apareceu o Menu de inicialização do PCLinuxOS (instalado), carregou sem falha alguma, — e 2 dias depois eu já tinha instalado também o openSUSE, o KDE Neon e o Fedora, para me divertir a valer durante 1 ou 2 meses, até configurar tudo.

openSUSE

Instalação do openSUSE na partição “Linuxs1”, com Bootloader em /boot/efi

Guardadas as peculiaridades de cada distro e seu instalador, segui os mesmos procedimentos também no openSUSE e no Fedora, — cada um na respectiva partição-raiz (Linux1, Linux4), — e todos os Bootloader na mesma partição EFI, onde convivem lado a lado.

Em todos os casos, escolhi “Particionamento manual” (ou “Personalizado”, “Avançado”, “Experiente”), para selecionar as partições destinadas a cada distro, — e ter controle dos procedimentos envolvidos na instalação do Bootloader EFI.

No openSUSE, isso foi um pouco demorado, — pois o instalador é extremamente detalhado, o que dificulta encontrar o caminho, entre tantas alternativas. — Além disso, não havia uma “sessão Live”, que permitisse consultar meu registro da primeira instalação, há 3 anos (e eu reservei o celular para fotos, na falta de PrtScn).

O importante é que, ao concluir as opções, o quadro “Particionamento sugerido” não apresente mais o padrão inicial do instalador, mas seja um sumário do que você pretendia, — caso contrário, tente outra vez. — Tive de fazer isso 2 ou 3 vezes, pelo menos (e alguma coisa não ficou bem, pois acabei sem a geração automática de Snapshots, que tive de configurar depois).

Fedora

Particionamento manual do Fedora, com formatação apenas da Root

No instalador do Fedora (Anaconda), minha primeira providência também foi mudar a opção de Particionamento, — de “Automático” para “Manual”.

A partição de destino (Linux4) estava no último grupo (Desconhecido), pois não era usado pelas outras distros.

A partição EFI, encontrei logo no segundo grupo (openSUSE), mas também está nos grupos KDE Neon e PCLinuxOS. — O ponto de montagem “/boot/efi” deve ter sido automático, ou escolhido de uma lista, pois se eu preenchesse, teria digitado “/boot/EFI”, por hábito. — Também não foi automaticamente marcado para formatar, mas procurei me certificar.

De qualquer modo, ao clicar em “Pronto” (no alto, à esquerda), para prosseguir, ainda foi exibido um Sumário, confirmando que apenas a partição Linux4 seria formatada.

KDE Neon

Instalador do KDE Neon (Calamares?) não indica a montagem da partição EFI

Apenas no instalador do KDE Neon (Ubiquity?), as imagens são equívocas, — como se eu tivesse escolhido apenas a partição-raiz.

A montagem da partição EFI não apareceu na tabela (acima), — nem no sumário apresentado para o usuário conferir e confirmar (ou voltar atrás), antes de iniciar a instalação.

A única indicação, nas imagens, era uma linha avulsa, lá embaixo, de que o Bootloader seria instalado em /dev/sda — ou em /dev/sda1, — o que pode ser pouco, quando o usuário se sente inseguro.

Partição EFI montada no KDE Neon, embora imagens digam que não fiz isso

No entanto, ao carregar o KDE Neon (instalado), a partição EFI estava montada. — Tudo funcionou 100%.

Notei que o KDE Neon também foi o único a criar, — de modo espontâneo, — um arquivo swap (swapfile), de 1,39 GiB.
Na partição-raiz (esq.), o ponto de montagem é manual, e fica indicado na tabela. Na partição EFI, não e não

Para examinar esse comportamento do instalador do KDE Neon, rodei uma nova sessão Live e simulei todos os passos de uma nova instalação.

Na etapa “Disk setup / Installation type”, escolhi a opção “Manual”, — onde você seleciona cada partição que deseja utilizar e vai clicando em “Change”, para definir o Ponto de montagem e outras opções.

Ao selecionar a partição-raiz e clicar em “Change”, o instalador do KDE Neon permite escolher o tipo (ext4), marcar para Formatar (ou não), e o Ponto de montagem “/”, — e tudo isso aparece depois na Tabela (acima, à esq.), para não haver dúvida.

Mas ao editar a partição EFI, o instalador do KDE Neon já identificou e pré-selecionou o tipo (EFI System Partition). — Não permite cometer a burrice de formatar (ótimo); e não pede nem mostra o Ponto de montagem no último campo, que permanece desabilitado (grayed out). — Depois de clicar Ok, o Ponto de montagem não aparece na Tabela; e essa informação também não aparece no sumário (para aprovação), antes de iniciar a instalação em disco.

Ou seja: — Não permite erro, — nem dá certeza de nada, depois.

Relendo este artigo de 2015, vejo que isso já foi um pouco pior:

O Ubuntu (e o Mint) encontrarão e usarão uma partição de inicialização EFI existente, mas não informarão nem mostrarão nada sobre isso, e ainda exibirão a caixa de diálogo antiga que diz que o GRUB será instalado no /dev/sda. Bem, acho que isso é tecnicamente correto, ele será instalado em algum lugar desse disco, mas dar uma dica de que realmente vai para a partição de inicialização EFI, e não para o antigo local do MBR, geraria menos incerteza e preocupação durante a instalação.
openSUSE  /etc/fstab
UUID=7A0B-66EE   /boot/efi    vfat    defaults                     0  2

Fedora    /etc/fstab
UUID=7A0B-66EE   /boot/efi    vfat    umask=0077,shortname=winnt   0  2

KDE Neon  /etc/fstab
UUID=7A0B-66EE   /boot/efi    vfat    umask=0077                   0  1

PCLinuxOS /etc/fstab
UUID=7A0B-66EE   /boot/EFI    vfat    defaults                     0  0

Tempos depois, notei que no PCLinuxOS o ponto de montagem é /boot/EFI; enquanto que nas outras, é /boot/efi; e isso não afeta em nada, pois esse link simbólico é assunto interno de cada uma. — Mais interessante é a diferença de parâmetros (que ainda não procurei entender), nos respectivos arquivos /etc/fstab. — Funciona tudo muito bem, cada distro no seu quadrado.

UEFI Bios Utility e efibootmgr

Prioridades de Boot no “UEFI Bios Utility”

O Grub do Fedora e o Grub do KDE Neon, instalados depois do openSUSE, não conseguiram detectá-lo, — ou geraram entradas que não eram capazes de carregá-lo.

A experiência dos últimos 3 anos (ainda em BIOS / MBR, no antigo PC), já me havia mostrado que o Grub do openSUSE Tumbleweed era o mais habilitado (por padrão) para detectar e carregar corretamente todas as 25 ou 30 distros que já instalei em dualboot.

Por isso, arrastei o Bootloader do openSUSE para o topo das prioridades de Boot, — em seguida, F10 para salvar e sair, — e desde então é meu Grub de uso diário.

A opção “openSUSE Secure Boot” é uma coisa que deixei passar durante sua instalação, — ou porque não vi, ou porque não tinha certeza sobre isso, naquele momento. — Nunca testei.

2020-12-27 - Meses depois, passei a verificar (e corrigir) a prioridade de boot por comandos — de dentro de qualquer uma das distros:

Check boot order:

# efibootmgr
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0004,0000,0001,000D,0008,0006,000A,0007,0002,0005,000E
Boot0000* opensuse
Boot0001* debian
Boot0002* Fedora
Boot0004* mageia
Boot0005* arch_grub
Boot0006* ubuntu
Boot0007* MX19
Boot0008* neon
Boot000A* slackware-14.2+
Boot000D* pclinuxos
Boot000E* debian


Change boot order:

# efibootmgr -o 0000,0004,0001,000D,0008,0006,000A,0007,0002,0005,000E
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0000,0004,0001,000D,0008,0006,000A,0007,0002,0005,000E
(...)


More:
       efibootmgr - manipulate the UEFI Boot Manager
...
DESCRIPTION
       efibootmgr  is  a userspace application used to modify the UEFI Boot Manager. This application can create and destroy boot
       entries, change the boot order, change the next running boot option, and more.
...
OPTIONS
       The following is a list of options accepted by efibootmgr:
...
       -o | --bootorder XXXX,YYYY,ZZZZ
              Explicitly set BootOrder (hex). Any value from 0 to FFFF is accepted so long  as  it  corresponds  to  an  existing
              Boot#### variable, and zero padding is not required.

Boot Menu para escolha ocasional de um DVD, Pendrive, ou outro Grub

Para Boot a partir de um DVD, tenho usado o Boot Menu, — acesso por F8, dentro do “UEFI Bios Utility”. — Basta clicar ou teclar Enter na opção DVD, para carregar de imediato.

Esse também é o caminho para uso ocasional de outro Grub, — do Fedora, Neon, PCLinuxOS, — sem necessidade de alterar as prioridades (e depois ter de desfazer).

Conteúdo da partição EFI

Partição EFI (sda1) montada na pasta /boot do PCLinuxOS (sda7)

A partição EFI com 2 GiB foi um exagero monumental.

Mesmo quando cheguei a ter 12 distros instaladas, a ocupação da partição EFI nunca passou de 2% (37,92 MiB), segundo o GParted. — Portanto, poderia ter usado só 256 MiB, ou 512 MiB, no máximo.

  • Tenho lido que o Deepin ocupa 100 MB na partição EFI, mas isso ainda caberia em 256 MiB, com folga. De qualquer modo, não está nos meus planos — e nada posso falar sobre o Windows, que parei de usar em 2016.

O conteúdo dessa partição EFI era um mistério, para mim. — Para obter um retrato objetivo, rodei uma sessão Live e montei a partição EFI na pasta /mnt (montagem estática, “neutra”, alheia ao sistema).

O conteúdo copiado mostrou ser o mesmo que aparece em /boot/efi, — ou seja, visto “de dentro” de qualquer distro instalada — com pequenas variações ao longo de 2 meses:

2020-01-16 ---------- from Live KDE Neon                     2020-03-07 ---------- from installed PCLinuxOS

# ls -o -R /mnt                                              # ls -n -R /boot/EFI
/mnt:                                                        /boot/EFI:
total 12                                                     total 12
drwxr-xr-x 8 root 4096 Oct 23 18:02 EFI                      drwxr-xr-x 8 0 0 4096 Oct 23 18:02 EFI/
drwxr-xr-x 3 root 4096 Oct 23 18:05 System                   -rwxr-xr-x 1 0 0   34 Jul 25  2019 mach_kernel*
-rwxr-xr-x 1 root   34 Jul 25 20:04 mach_kernel              drwxr-xr-x 3 0 0 4096 Oct 23 18:05 System/

/mnt/EFI:                                                    /boot/EFI/EFI:
total 24                                                     total 24
drwxr-xr-x 2 root 4096 Oct 23 18:05 boot                     drwxr-xr-x 2 0 0 4096 Oct 23 18:05 boot/
drwxr-xr-x 3 root 4096 Jan 14 18:06 fedora                   drwxr-xr-x 3 0 0 4096 Mar  5 11:34 fedora/
drwxr-xr-x 2 root 4096 Jan 12 16:43 neon                     drwxr-xr-x 2 0 0 4096 Jan 12 16:43 neon/
drwxr-xr-x 3 root 4096 Jan 13 01:39 opensuse                 drwxr-xr-x 3 0 0 4096 Jan 13 01:39 opensuse/
drwxr-xr-x 2 root 4096 Jan 10 20:22 pclinuxos                drwxr-xr-x 2 0 0 4096 Jan 10 20:22 pclinuxos/
drwxr-xr-x 3 root 4096 Jan 12 16:43 ubuntu                   drwxr-xr-x 2 0 0 4096 Feb 19 00:26 ubuntu/

/mnt/EFI/boot:                                               /boot/EFI/EFI/boot:
total 3096                                                   total 3096
-rwxr-xr-x 1 root  975536 Oct  2  2018 BOOTIA32.EFI          -rwxr-xr-x 1 0 0  975536 Oct  2  2018 BOOTIA32.EFI*
-rwxr-xr-x 1 root 1210776 Oct  2  2018 bootx64.efi           -rwxr-xr-x 1 0 0 1210776 Oct  2  2018 bootx64.efi*
-rwxr-xr-x 1 root  358768 Jan 11 17:09 fallback.efi          -rwxr-xr-x 1 0 0  358768 Jan 11 17:09 fallback.efi*
-rwxr-xr-x 1 root  257472 Oct  2  2018 fbia32.efi            -rwxr-xr-x 1 0 0  257472 Oct  2  2018 fbia32.efi*
-rwxr-xr-x 1 root  357248 Oct  2  2018 fbx64.efi             -rwxr-xr-x 1 0 0  357248 Oct  2  2018 fbx64.efi*

/mnt/EFI/fedora:                                             /boot/EFI/EFI/fedora:
total 14840                                                  total 14840
-rwxr-xr-x 1 root     112 Oct  2  2018 BOOTIA32.CSV          -rwxr-xr-x 1 0 0     112 Oct  2  2018 BOOTIA32.CSV*
-rwxr-xr-x 1 root     110 Oct  2  2018 BOOTX64.CSV           -rwxr-xr-x 1 0 0     110 Oct  2  2018 BOOTX64.CSV*
drwxr-xr-x 2 root    4096 Jan 12 21:37 fonts                 drwxr-xr-x 2 0 0    4096 Feb  2 23:47 fonts/
-rwxr-xr-x 1 root 1468744 Dec  5 09:59 gcdia32.efi           -rwxr-xr-x 1 0 0 1468744 Jan 13 17:11 gcdia32.efi*
-rwxr-xr-x 1 root 2271560 Dec  5 09:59 gcdx64.efi            -rwxr-xr-x 1 0 0 2271560 Jan 13 17:11 gcdx64.efi*
-rwxr-xr-x 1 root   12611 Jan 12 15:47 grub.cfg              -rwxr-xr-x 1 0 0   12611 Jan 12 15:47 grub.cfg*
-rwxr-xr-x 1 root    1024 Jan 14 18:06 grubenv               -rwxr-xr-x 1 0 0    1024 Mar  5 11:41 grubenv*
-rwxr-xr-x 1 root 1468744 Dec  5 09:59 grubia32.efi          -rwxr-xr-x 1 0 0 1468744 Jan 13 17:11 grubia32.efi*
-rwxr-xr-x 1 root 2271560 Dec  5 09:59 grubx64.efi           -rwxr-xr-x 1 0 0 2271560 Jan 13 17:11 grubx64.efi*
-rwxr-xr-x 1 root  927824 Oct  2  2018 mmia32.efi            -rwxr-xr-x 1 0 0  927824 Oct  2  2018 mmia32.efi*
-rwxr-xr-x 1 root 1159560 Oct  2  2018 mmx64.efi             -rwxr-xr-x 1 0 0 1159560 Oct  2  2018 mmx64.efi*
-rwxr-xr-x 1 root 1210776 Oct  2  2018 shim.efi              -rwxr-xr-x 1 0 0 1210776 Oct  2  2018 shim.efi*
-rwxr-xr-x 1 root  969264 Oct  2  2018 shimia32-fedora.efi   -rwxr-xr-x 1 0 0  975536 Oct  2  2018 shimia32.efi*
-rwxr-xr-x 1 root  975536 Oct  2  2018 shimia32.efi          -rwxr-xr-x 1 0 0  969264 Oct  2  2018 shimia32-fedora.efi*
-rwxr-xr-x 1 root 1204496 Oct  2  2018 shimx64-fedora.efi    -rwxr-xr-x 1 0 0 1210776 Oct  2  2018 shimx64.efi*
-rwxr-xr-x 1 root 1210776 Oct  2  2018 shimx64.efi           -rwxr-xr-x 1 0 0 1204496 Oct  2  2018 shimx64-fedora.efi*

/mnt/EFI/fedora/fonts:                                       /boot/EFI/EFI/fedora/fonts:
total 2504                                                   total 2504
-rwxr-xr-x 1 root 2560080 Dec  5 09:59 unicode.pf2           -rwxr-xr-x 1 0 0 2560080 Jan 13 17:11 unicode.pf2*

/mnt/EFI/neon:                                               /boot/EFI/EFI/neon:
total 3644                                                   total 3644
-rwxr-xr-x 1 root     108 Jan 12 16:43 BOOTX64.CSV           -rwxr-xr-x 1 0 0     108 Jan 12 16:43 BOOTX64.CSV*
-rwxr-xr-x 1 root     126 Jan 12 16:43 grub.cfg              -rwxr-xr-x 1 0 0     126 Jan 12 16:43 grub.cfg*
-rwxr-xr-x 1 root 1116024 Jan 12 16:43 grubx64.efi           -rwxr-xr-x 1 0 0 1116024 Jan 12 16:43 grubx64.efi*
-rwxr-xr-x 1 root 1269496 Jan 12 16:43 mmx64.efi             -rwxr-xr-x 1 0 0 1269496 Jan 12 16:43 mmx64.efi*
-rwxr-xr-x 1 root 1334816 Jan 12 16:43 shimx64.efi           -rwxr-xr-x 1 0 0 1334816 Jan 12 16:43 shimx64.efi*

/mnt/EFI/opensuse:                                           /boot/EFI/EFI/opensuse:
total 3904                                                   total 3904
-rwxr-xr-x 1 root 1158688 Jan 11 17:09 MokManager.efi        -rwxr-xr-x 1 0 0      58 Feb 25 16:57 boot.csv*
-rwxr-xr-x 1 root      58 Jan 11 17:09 boot.csv              drwxr-xr-x 2 0 0    4096 Jan 13 01:39 fw/
drwxr-xr-x 2 root    4096 Jan 13 01:39 fw                    -rwxr-xr-x 1 0 0   64776 Feb 16 09:43 fwupdx64.efi*
-rwxr-xr-x 1 root   64776 Jan 13 01:39 fwupdx64.efi          -rwxr-xr-x 1 0 0     155 Feb 25 16:57 grub.cfg*
-rwxr-xr-x 1 root     155 Jan 11 17:09 grub.cfg              -rwxr-xr-x 1 0 0 1238896 Feb 25 16:57 grub.efi*
-rwxr-xr-x 1 root 1238880 Jan 11 17:09 grub.efi              -rwxr-xr-x 1 0 0  307200 Feb 25 16:57 grubx64.efi*
-rwxr-xr-x 1 root  307200 Jan 11 17:09 grubx64.efi           -rwxr-xr-x 1 0 0 1158688 Feb 25 16:57 MokManager.efi*
-rwxr-xr-x 1 root 1208968 Jan 11 17:09 shim.efi              -rwxr-xr-x 1 0 0 1208968 Feb 25 16:57 shim.efi*

/mnt/EFI/opensuse/fw:                                        /boot/EFI/EFI/opensuse/fw:
total 0                                                      total 0

/mnt/EFI/pclinuxos:                                          /boot/EFI/EFI/pclinuxos:
total 124                                                    total 124
-rwxr-xr-x 1 root 123904 Jan 10 20:22 grubx64.efi            -rwxr-xr-x 1 0 0 123904 Feb 16 08:09 grubx64.efi*

/mnt/EFI/ubuntu:                                             /boot/EFI/EFI/ubuntu:
total 84                                                     total 4
drwxr-xr-x 2 root  4096 Jan 12 16:43 fw                      -rwxr-xr-x 1 0 0 126 Jan 12 16:43 grub.cfg*
-rwxr-xr-x 1 root 75992 Jan 12 16:43 fwupx64.efi
-rwxr-xr-x 1 root   126 Jan 12 16:43 grub.cfg

/mnt/EFI/ubuntu/fw:
total 0

/mnt/System:                                                 /boot/EFI/System:
total 4                                                      total 4
drwxr-xr-x 3 root 4096 Oct 23 18:05 Library                  drwxr-xr-x 3 0 0 4096 Oct 23 18:05 Library/

/mnt/System/Library:                                         /boot/EFI/System/Library:
total 4                                                      total 4
drwxr-xr-x 2 root 4096 Oct 23 18:05 CoreServices             drwxr-xr-x 2 0 0 4096 Oct 23 18:05 CoreServices/

/mnt/System/Library/CoreServices:                            /boot/EFI/System/Library/CoreServices:
total 4                                                      total 4
-rwxr-xr-x 1 root 384 Jul 25 20:04 SystemVersion.plist       -rwxr-xr-x 1 0 0 384 Jul 25  2019 SystemVersion.plist*

Esse material ficou como documentação do estado das coisas até aquele momento. — Eu estava só “vendo” como são as coisas, e colhendo amostras, para examinar no futuro.

Criando uma 2ª partição EFI

Distros e EFI Bootloaders separados entre 2 SSDs

Ao “mover” metade das minhas distros (Linux7 ~ Linux12) para um 2º SSD, criei a possibilidade de usar o PC, mesmo em caso de falha do 1º. — Para isso, eu precisaria de uma 2ª partição EFI, no 2º SSD.

  • Ver “Cronologia: — Distros, partições etc.”, adiante.

Criei no 2º SSD uma partição Fat32 de 512 MiB, com rótulo (Label) “efi2”. — Por algum motivo, o rótulo tornou-se “EFI2”. — Atribuí a Flag “esp”, e automaticamente o GParted também atribuiu a Flag “boot”.

Copiei o identificador UUID da nova partição EFI2 e substituí o da antiga EFI no /etc/fstab do Mageia, do Void e do MX Linux. — Ao carregá-los, já montaram a nova partição EFI2, em vez da antiga.

Em cada uma dessas 3 distros, executei o comando grub-install (que aprendi ao instalar o Arch), para gerar o respectivo Bootloader na nova partição “EFI2”:

# grub2-install --target=x86_64-efi --efi-directory=/boot/EFI --bootloader-id=Mageia_grub --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.

# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Void_grub --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.

# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=MX_grub --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.

(Acrescentei “_grub” no ID de cada bootloader, para diferenciá-los dos bootloaders existentes na antiga partição “EFI”).

Cada um desses comandos colocou a respectiva distro no topo das prioridades de boot — e usei o efibootmgr para restabelecer a prioridade do openSUSE.

  • Ver “UEFI Bios Utility e efibootmgr” (acima).

Deletando um bootloader obsoleto, na partição EFI, pelo Midnight Commander

Pelo Midnight Commander (mc) em modo root, entrei na antiga partição EFI e deletei alguns bootloaders que já não têm utilidade — como o do Redcore, e um “Ubuntu” (gerado pelo KDE Neon).

Também usei o efibootmgr para deletar antigos bootloaders, que já não têm utilidade — inclusive os do Slackware, e do KDE Neon.

# efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0009,0002,0006,0004,0010,000C,0001,0003,000D,0005,0007,0008
...
Boot0003* mageia
...
Boot000A* slackware-14.2+
Boot000B* neon
...
Boot000F* MX
Boot0010* MX_grub


# efibootmgr -B -b 3
...
# efibootmgr -B -b A
...
# efibootmgr -B -b B
...
# efibootmgr -B -b F
...

Comparação visual das partições “EFI” e “EFI2”

Com isso, reduzi as “entradas” existentes na antiga partição EFI — de 14 para 6. — Tenho só 5 distros em sda, mas não tive coragem de apagar a pasta /boot, cuja função ainda não conheço.

Não existe uma entrada “boot” no efibootmgr — mas existem entradas “CD / DVD drive”, “Removable device”, e “Network device”. — Editei com indentações, para facilitar a visualização:

$ efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0009,0002,0006,0004,0010,000C,0001,000D,0003,0005,0007
Boot0000* opensuse              HD(1,GPT,329...000)/\EFI\OPENSUSE\GRUBX64.EFI
Boot0001* debian                HD(1,GPT,329...000)/\EFI\DEBIAN\SHIMX64.EFI
Boot0002* Fedora                HD(1,GPT,329...000)/\EFI\FEDORA\SHIM.EFI0000424f
Boot0003* UEFI:CD/DVD Drive                 BBS(129,,0x0)
Boot0004* pclinuxos             HD(1,GPT,329...000)/\EFI\PCLINUXOS\GRUBX64.EFI
Boot0005* UEFI:Removable Device             BBS(130,,0x0)
Boot0006* arch_grub2            HD(1,GPT,329...000)/\EFI\ARCH_GRUB2\GRUBX64.EFI
Boot0007* UEFI:Network Device               BBS(131,,0x0)
Boot0009* Mageia_grub             HD(16,GPT,bae...800)/\EFI\Mageia_grub\grubx64.efi
Boot000C* debian                HD(1,GPT,329...000)/\EFI\DEBIAN\GRUBX64.EFI0000424f
Boot000D* Void_grub               HD(16,GPT,bae...800,0xff800)/\EFI\Void_grub\grubx64.efi
Boot0010* MX_grub                 HD(16,GPT,bae...800,0xff800)/\EFI\MX_grub\grubx64.efi

Pelo efibootmgr, aparecem 2 bootloaders do Debian — shimx64 e grubx64, ambos presentes na pasta /boot/efi/EFI/Debian. — Segundo a IA do Google, o shimx64 é um intermediário que examina se o grub foi alterado. Então, tá.

A pasta do Debian tem 6 itens. — A do Fedora, 14 itens. — A do openSUSE, 8 itens. — A pasta “boot”, 6 itens.

As pastas do Arch, do PCLinuxOS — e as do Mageia, MX Linux, Void, que criei usando o comando que aprendi no Arch — têm apenas 1 arquivo “grubx64.efi”, cada.

Além disso, a antiga partição EFI tem uma pasta “System” e um arquivo “mach_kernel” — que não existe na nova partição EFI2.

“EFI” Partition                                           “EFI2” Partition

$ tree -h -D /boot/efi                                    $ tree -h -D /mnt

[4.0K Dec 31  1969]  /boot/efi                            [4.0K Dec 31  1969]  /mnt
├── [4.0K Apr 10 07:54]  EFI                              └── [4.0K Apr  8 22:59]  EFI
│   ├── [4.0K Mar  6  2023]  arch_grub2                       ├── [4.0K Apr  8 22:29]  Mageia_grub
│   │   └── [148K Mar  6  2023]  grubx64.efi                  │   └── [160K Apr  8 22:29]  grubx64.efi
│   ├── [4.0K Jul 18  2024]  boot                             ├── [4.0K Apr  8 18:19]  MX_grub
│   │   ├── [730K Mar 18  2024]  BOOTIA32.EFI                 │   └── [136K Apr  8 18:19]  grubx64.efi
│   │   ├── [944K Oct 13  2024]  bootx64.efi                  └── [4.0K Apr  8 22:59]  Void_grub
│   │   ├── [350K Jan 11  2020]  fallback.efi                     └── [140K Apr  8 22:59]  grubx64.efi
│   │   ├── [ 69K Mar 18  2024]  fbia32.efi
│   │   ├── [ 86K Oct 13  2024]  fbx64.efi                5 directories, 3 files
│   │   └── [836K Oct 13  2024]  mmx64.efi
│   ├── [4.0K Mar 24  2020]  Debian
│   │   ├── [ 108 Mar 27 13:25]  BOOTX64.CSV
│   │   ├── [ 86K Mar 27 13:25]  fbx64.efi
│   │   ├── [ 126 Mar 27 13:25]  grub.cfg
│   │   ├── [2.6M Mar 27 13:25]  grubx64.efi
│   │   ├── [830K Mar 27 13:25]  mmx64.efi
│   │   └── [935K Mar 27 13:25]  shimx64.efi
│   ├── [4.0K Apr  6 17:56]  fedora
│   │   ├── [ 112 Mar 18  2024]  BOOTIA32.CSV
│   │   ├── [ 110 Mar 18  2024]  BOOTX64.CSV
│   │   ├── [2.9M Mar 24 21:00]  gcdia32.efi
│   │   ├── [3.9M Mar 24 21:00]  gcdx64.efi
│   │   ├── [ 164 Nov 17 14:00]  grub.cfg
│   │   ├── [ 12K Jan 12  2020]  grub.cfg.rpmsave
│   │   ├── [1.0K Jul 11  2021]  grubenv.rpmsave
│   │   ├── [2.9M Mar 24 21:00]  grubia32.efi
│   │   ├── [3.9M Mar 24 21:00]  grubx64.efi
│   │   ├── [658K Mar 18  2024]  mmia32.efi
│   │   ├── [828K Mar 18  2024]  mmx64.efi
│   │   ├── [927K Mar 18  2024]  shim.efi
│   │   ├── [730K Mar 18  2024]  shimia32.efi
│   │   └── [927K Mar 18  2024]  shimx64.efi
│   ├── [4.0K Jan 12  2020]  opensuse
│   │   ├── [  58 Sep 24  2020]  boot.csv
│   │   ├── [4.0K Jan 12  2020]  fw
│   │   ├── [ 62K Sep  2  2020]  fwupdx64.efi
│   │   ├── [ 155 Sep 24  2020]  grub.cfg
│   │   ├── [1.2M Sep 24  2020]  grub.efi
│   │   ├── [328K Apr 13 17:25]  grubx64.efi
│   │   ├── [1.2M Sep 24  2020]  MokManager.efi
│   │   └── [1.3M Sep 24  2020]  shim.efi
│   └── [4.0K Jan 10  2020]  pclinuxos
│       └── [148K Aug 25  2024]  grubx64.efi
├── [  34 Jul 17  2024]  mach_kernel
└── [4.0K Jul 17  2024]  System
    └── [4.0K Jul 17  2024]  Library
        └── [4.0K Nov 17 13:52]  CoreServices
            └── [ 384 Jul 17  2024]  SystemVersion.plist

12 directories, 37 files

xxx

Vida após a mudança

Grub

Ampliação da área do Menu de inicialização do Grub

A experiência já me havia mostrado que o Grub do openSUSE Tumbleweed é o mais habilitado para carregar todas as 25 ou 30 distros que instalei nos últimos anos. — Além disso, ele é indispensável para carregar seus próprios “instantâneos” (snapshots), para “voltar atrás” (rollback), no caso de alguma atualização quebrar o sistema. — Por isso, adotei o Grub do openSUSE como padrão, no novo PC.

Precisei editar seu “Tema”, — que só exibia 6 itens, em um retângulo acanhado, no centro do Menu de inicialização, — para exibir as 4 distros já instaladas (8 itens), além do acesso aos Snapshots do openSUSE, no final.

No arquivo /boot/grub2/themes/openSUSE/theme.txt, a área útil do Menu de inicialização estava definida para começar a 33% da altura da tela, desde o alto (top), e utilizar outros 34% daí para baixo (height). — Alterei essa faixa de altura para 5% e 96%. — Além disso, reduzi a altura dos itens, de 32 para 24.

Para fazer efeito, atualizei o Grub.

+ boot_menu {
  left = 10%
  width = 80%
  top = 33% ----------->  5%  <-----
  height = 34% --------> 96%  <-----

  item_font = "DejaVu Sans Regular 12"
  item_color = "#fff"
  item_height = 32 ---->  24  <-----
  item_spacing = 2

  selected_item_font = "DejaVu Sans Regular 12"
  selected_item_color= "#ffffff"
  selected_item_pixmap_style = "highlight_*.png"

  icon_height = 0
  icon_width = 0

  scrollbar = true
  scrollbar_width = 20
  scrollbar_thumb = "slider_*.png"
}
Grub do openSUSE com 12 distros + 2 linhas

Com isso, consegui que o Grub exibisse até 12 distros (24 itens) e mais 2 linhas — com o acesso ao UEFI Firmware Settings e os Snapshots do openSUSE.

Desabilitando Os_Prober, para não detectar outras distros, e atualizando o Grub em seguida

Desabilitei Os_Prober nos arquivos /etc/default/grub do Fedora, do KDE Neon, do PCLinuxOS, e das outras distros instaladas depois, — para que não percam tempo detectando as demais distros, — e em seguida atualizei o Grub de cada uma, para que a mudança fizesse efeito.

Essa é uma norma que adotei desde quando o Grub enlouqueceu com 12 distros em dualboot, — pois qualquer erro introduzido no Grub de uma distro (eu desconfio do Grub Customizer!) é replicado no Grub das outras, e com o tempo se espalham e se multiplicam. — Além disso, o Os_Prober aumenta o tempo gasto a cada atualização de Kernel. Não existe necessidade de que todas as distros detectem todas as outras.

Basta que o Grub de 1 distro detecte as outras (e que o das outras detecte apenas elas mesmas). — O Grub do Mageia é o único que se mostrou capaz de carregar o openSUSE, em caso de necessidade — por isso, adotei como “Grub de reserva”.

Note que, no início, o Grub do Fedora detectava as outras distros, mas não ele mesmo.

Desabilitando BLS no /etc/default/grub do Fedora

É que, hoje em dia, o Fedora não atualiza seu Grub automaticamente, ao instalar ou remover revisões de Kernel. — Na verdade, nem gera /boot/grub2/grub.cfg. — Seu Grub se limita a exibir as opções de uma pasta /boot/loader/entries, onde mantém indicadores atualizados das suas versões de Kernel:

ls -n /media/Linux4/boot/loader/entries/
total 16
-rw-r--r-- 1 0 0 329 Jan 12 17:47 163e33fb611946fd998c9750b0d09e04-0-rescue.conf
-rw-r--r-- 1 0 0 263 Feb 20 16:27 163e33fb611946fd998c9750b0d09e04-5.4.20-200.fc31.x86_64.conf
-rw-r--r-- 1 0 0 259 Feb 22 01:15 163e33fb611946fd998c9750b0d09e04-5.5.5-200.fc31.x86_64.conf
-rw-r--r-- 1 0 0 259 Mar  5 08:41 163e33fb611946fd998c9750b0d09e04-5.5.7-200.fc31.x86_64.conf

No entanto, o Grub de outras distros (ainda) não sabe ler informações nessa pasta do Fedora, — por isso, preciso que ele gere um arquivo /boot/grub2/grub.cfg “tradicional”, com seus Kernels, — para ser lido pelo Grub do openSUSE.

Para isso, desabilito “BootLoaderSpec” (BLS) em seu arquivo /etc/default/grub, — e executo manualmente o “update-grub” no Fedora, sempre que ele instala e remove revisões de Kernel.

Com esses ajustes, o Grub do Fedora passou a detectar o próprio Fedora, — para ser lido pelo Grub do openSUSE (e pelo do Mageia):

# date && grub2-mkconfig -o /boot/grub2/grub.cfg && date
Mon  9 Mar 11:06:52 -03 2020
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.5.7-200.fc31.x86_64
Found initrd image: /boot/initramfs-5.5.7-200.fc31.x86_64.img
Found linux image: /boot/vmlinuz-5.5.5-200.fc31.x86_64
Found initrd image: /boot/initramfs-5.5.5-200.fc31.x86_64.img
Found linux image: /boot/vmlinuz-5.4.20-200.fc31.x86_64
Found initrd image: /boot/initramfs-5.4.20-200.fc31.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-163e33fb611946fd998c9750b0d09e04
Found initrd image: /boot/initramfs-0-rescue-163e33fb611946fd998c9750b0d09e04.img
Adding boot menu entry for EFI firmware configuration
done
Mon  9 Mar 11:07:00 -03 2020

Conky

Início da adaptação do Conky, ainda na primeira sessão Live

Comecei a adaptar o Conky ao novo PC, já na primeira sessão Live, — partindo de um antigo ~/.config/conky/conky.conf. — Onde havia 2 gráficos de uso de CPU, agora existem 6.

Desdobramento do Conky em 2 instâncias

Com o tempo, desdobrei o Conky em 2 instâncias. — A primeira, com informações mais sensíveis, continua atualizando a cada 1 segundo — enquanto a outra, com informações “menos urgentes”, se atualiza a cada 10 segundos.

Acréscimo de informações do lm-sensors

No novo PC, de 2020 a 2022, o lm-sensors não encontrava informações sobre as tensões elétricas ou a velocidade de rotação da ventoinha do cooler da CPU, por exemplo — e por volta de 2024, passou a apresentar estas e muitas outras informações.

Após alguma atualização — do Kernel? do lm-sensors? — a pasta /sys/class/hwmon/ passou a conter 4 sub-pastas (hwmon0 ~ hwmon3) — e o comando sensors passou a exibir muitos itens que antes não apareciam — inclusive tensões elétricas, rotação da ventoinha etc.

Partição Swap

Desabilitando o Swapfile do Neon, ao incluir a partição Swap no /etc/fstab

Incluir partição Swap em uma distro Linux já instalada é procedimento simples: — Basta incluir uma linha com seu UUID em /etc/fstab, — e executar um comando # swapon --all, que ativa todas as partições Swap existentes no /etc/fstab (a menos que estejam com a opção noauto).

openSUSE

UUID=2ae5ec7d-42bd-4d6b-9597-7473984c75fe  swap     swap    defaults        0  0

Fedora

UUID=2ae5ec7d-42bd-4d6b-9597-7473984c75fe  swap     swap    defaults        0  0

KDE Neon

# /swapfile                                none     swap    sw              0  0
UUID=2ae5ec7d-42bd-4d6b-9597-7473984c75fe  none     swap    sw              0  0

PCLinuxOS

UUID=2ae5ec7d-42bd-4d6b-9597-7473984c75fe  swap     swap    defaults        0  0

Por precaução, copiei as linhas de um backup de arquivos fstab de cada distro Linux instalada no antigo PC, — com as eventuais especificidades de cada uma, — e apenas mudei o UUID.

Desabilitando o Swapfile e habilitando a partição Swap incluída no /etc/fstab

Apenas no caso do KDE Neon, o instalador havia criado automaticamente um arquivo Swap (Swapfile), — e tratei de desativá-lo no /etc/fstab.

Naquele primeiro momento, fiz a partição Swap com 5 GB; e tempos depois, ampliei para 11 GB — mas durante 5 anos, só vi ser utilizada 1 única vez. — Não uso Hibernate (só Sleep); e até agora 16 GB RAM parecem mais do que suficientes para os aplicativos que utilizo (não faço edição de vídeo, nem outras tarefas muito pesadas).

Movendo a /home: Fedora e SELinux

Cópia da pasta de usuário para outra partição, pelo Midnight-Commander, preservando atributos

Mover a pasta /home para uma partição separada costuma ser um procedimento simples:

  1. Copiar a pasta pessoal do usuário /home/USER para a nova partição, — preservando todos os atributos, — proprietário, grupo, permissões etc.
  2. Renomear a antiga pasta: — /home/USER_OLD — para manter de reserva
  3. Incluir a nova pasta no arquivo /etc/fstab

Na maioria dos casos, recomenda-se fazer tudo isso a partir de uma sessão Live, — pois a pasta do usuário não deve estar em uso. — Caso queira reduzir a partição de sistema (para criar a /home), ela também não pode estar em uso.

Aproveitando que tenho várias distros em dualboot, prefiro trabalhar a partir do openSUSE, — que permite usar o Krusader como super-usuário (root), — e a partir dele, o Kate ou o KWrite para edição de arquivos dos outros sistemas.

Mas para copiar a pasta do usuário, o Midnight-Commander (# mc) se mostrou menos perigoso do que o Krusader, — pois mantém os atributos dos arquivos e subpastas, por padrão, mesmo que você esqueça de verificar (diálogo na imagem, acima). — Se precisar, ele também permite edição como super-usuário (root), com as opções de usar o vi / vim, o nano, ou seu próprio editor interno (mcedit).

Preservação dos atributos da pasta /home do KDE Neon, diferentes dos do openSUSE

O identificador UID do super-usuário (Root) é sempre 0, — e no meu caso, o UID do usuário é 1000 em todas as distros, — o que simplifica o acesso e evita criar problemas, ao usar uma distro para copiar ou editar arquivos de outra.

O grupo-padrão do usuário costuma ser GID=1000, — ou GID=1002, ou 100, — mas isso nunca me criou problemas.

Acima - Foram preservados os atributos de usuário e grupo UID:GID=1000:1000 da pasta /home do KDE Neon, — apesar de a cópia ter sido feita como super-usuário (0:0), — e apesar de o openSUSE usar UID-GID=1000:100.

Edição do /etc/fstab do KDE Neon, com parâmetros (backup) da instalação anterior

Ainda no openSUSE, usei o “Krusader root-mode” para abrir o /etc/fstab no Kate como super-usuário (fundo branco).

Para manter os parâmetros específicos do KDE Neon, copiei a linha da /home de um backup do /etc/fstab da instalação anterior (antigo PC), — e alterei apenas o identificador UUID, para a nova partição /home.

openSUSE

# UUID=e93c93ad-8397-4e94-bb26-26c769b1ee1d  /home     btrfs   subvol=/@/home   0  0
UUID=ddd0f13e-7def-4668-8910-0f5f3f011fe4    /home     xfs     defaults         1  2

Fedora

UUID=727546b6-57a8-46be-997e-ba1f8b21ba54    /home     ext4    defaults         1  2

KDE Neon

UUID=93cfce0e-eee4-4972-a6d7-680c7e57a554    /home     ext4    defaults         0  2

PCLinuxOS

UUID=c82ea2d1-e58a-4fd3-a476-995d9d03b6c7    /home     ext4    defaults         1  2

Deletando a antiga pasta de usuário, após testar o funcionamento da /home separada no PCLinuxOS

8 Março 2020 - Os mesmos procedimentos, foram usados para mover a /home do PCLinuxOS para uma partição separada.

A mudança no KDE Neon foi feita das 8:05 às 8:20; testada às 8:25; e às 8:40 voltei ao openSUSE para deletar a pasta flavio_OLD.

A mudança no PCLinuxOS foi feita das 9:06 às 9:17; testada às 9:21; e às 9:32 voltei ao openSUSE para deletar a pasta antiga.

Depois que a pasta /home se torna ponto de montagem de outra partição, fica difícil acessar o que de fato esteja nela mesma. — Acho mais simples reiniciar, carregar outra distro instalada (bem mais rápido que uma sessão Live, com poucas ferramentas etc.), e abrir o Krusader ou o Midnight-Commander.

Embora o Midnight-Commander (# mc) seja mais seguro para copiar as pastas de usuário para outra partição, com preservação dos atributos, o Krusader (root mode) é mais cômodo para edição pelo Kate ou KWrite, e também é mais simples para renomear ou deletar coisas rapidamente, pois reabre nas mesmas pastas de antes.

Recurso de mover a pasta de usuário para outro local, pelo YaST2 (detalhe posterior)

Em 26 Fevereiro, eu já tinha notado que o YaST2 oferece um recurso de mover a pasta de usuário para outro local, — e suponho que seria o caminho mais indicado de fazer isso, no caso do openSUSE, para manter a consistência do sistema de Subvolumes BtrFS, — mas deixei de explorar esse caminho, naquele momento, e acabei não lembrando disso, mais tarde, na hora em que resolvi fazer a mudança.

Acima - Colagem (posterior) de detalhe capturado após rápida exploração em 9 Março. Note que só explorei as partições montadas em /run/media/$USER (via udisks2). — Ignoro os passos seguintes, bem como, se a partição de destino deveria estar montada em /mnt ou em outro ponto qualquer. Seria recomendável estudar a documentação, antes de seguir adiante.

Ao esquecer dessa possibilidade, talvez tenha perdido uma ótima oportunidade de fazer tudo certo, — e ver em funcionamento mais uma habilidade desse mecanismo fantástico, que é o openSUSE:

YaST2 >> Security and Users >> User and Group >> User >> Edit >> Details >> Home Directory >> [Move to New Location] >> Browse >> Choose ... (???)

Montagem da partição Home1 (sdb2) em /mnt e cópia da pasta de usuário pelo Midnight-Commander (mc)

29 Fevereiro 2020 - O que acabei fazendo, foi apenas sair da sessão de usuário do openSUSE (Logout), e da tela de Login passar para tty2, logar como root, montar a partição Home1 (sdb2) em /mnt e usar o Midnight-Commander (mc) para copiar a pasta de usuário para a nova localização.

5:39 - Partição Home1 (sdb2) formatada para XFS pelo GParted, no openSUSE
6:08 - Montagem da Home1 (sdb2) em /mnt e cópia da pasta de usuário
6:13 - Inserida no /etc/fstab a linha de /home copiada de um backup (antigo PC), com a nova UUID
A linha /home como Subvolume BtrFS conflitava com a linha /home em partição XFS

Depois disso, não consegui fazer Login como usuário, — até editar outra vez o /etc/fstab e eliminar uma outra linha de /home — que apontava para um Subvolume BtrFS:

6:47 - Correção do /etc/fstab
Localizando e montando a antiga pasta de usuário, para deletar no Dolphin “root-mode”

Encontrar a pasta flavio_OLD foi mais complicado. — Naturalmente, no openSUSE, /home agora é mero ponto de montagem para outra partição. — Tentei pelo Fedora, e descobri que a pasta /home propriamente dita estava absolutamente vazia.

Sempre foi mero ponto de montagem, — só que, para um Subvolume BtrFS.

A pasta flavio_OLD não estava “fisicamente” ali. — Fui encontrá-la no Subvolume BtrFS “ID 263”. — Então, tive de descobrir o comando capaz de montá-lo em /mnt, para deletá-la:

# btrfs subvolume list /
...
ID 263 gen 49101 top level 256 path @/home
...

# mount -t btrfs /dev/sda2 /mnt/ -o subvolid=263


=====   Summary   =====

# history | grep "2020-02-29"
  ...
  660  2020-02-29_06-02-40   # mount /dev/sdb2 /mnt
  663  2020-02-29_06-03-14   # mc
  668  2020-02-29_06-22-36   # mv /home/flavio flavio_OLD
  ...
  686  2020-02-29_11-17-38   # btrfs subvolume list /
  ...
  713  2020-02-29_12-18-17   # mount -t btrfs /dev/sda2 /mnt/ -o subvolid=263
  ...

Com isso, o espaço usado na partição de sistema caiu de 23,9 GiB para 18,8 GiB. — Ainda não descobri como deletar aquele Subvolume ID 263, agora inútil, — mas estando vazio e desmontado, já não incomoda.

Edição do /etc/fstab no KWrite para configurar a /home em outra partição

27 Fevereiro 2020 - A mudança da /home para outra partição foi relativamente simples e rápida no openSUSE, no KDE Neon e no PCLinuxOS, porque primeiro tentei no Fedora, — ocorreu alguma falha, que impediu o Login automático ao reiniciar o computador, — e isso me fez tomar mais cuidado dali em diante.

14:56 - Editei o /etc/fstab no KWrite para configurar a /home em uma partição separada (Home4), — parâmetros copiados de um backup do antigo PC, com UUID atual. — Logout como usuário e Login em tty2 como Root.

15:13 - Montagem da partição pelo comando — # mount /dev/sdb5 /mnt

15:19 - Pasta de usuário movida (não copiada) para a partição “Home4”. — Reboot.

15:40 - Não fez Login automático do usuário; e falharam várias tentativas de Login manual. — O carregamento da sessão KDE Plasma parava em “Starting Terminate Plymouth Boot Screen”, ou em alguma outra mensagem que às vezes se alterna com ela, no final do boot (verbose).

Infelizmente, depois disso, cometi vários erros, — trabalhando o resto da tarde no PCLinuxOS, — em vez de examinar vários detalhes, de modo racional.

Ao carregar o KDE Plasma, descobri que o Auto-Login tinha sido desabilitado

19:28 - Só à noite, tentei Login como usuário em tty2, — e obtive uma pista significativa:

-- flavio: /home/flavio: change directory failed: Permission denied
Logging in with home = "/"

19:49 - Resolvido com o comando: — # restorecon -Rv /home

NAME
       restorecon - restore file(s) default SELinux security contexts.
...
DESCRIPTION
...
       This program is primarily used to set the security context (extended attributes) on one or more files.
...
       -R, -r change files and directories file labels recursively (descend directories).

       -v     show changes in file labels. Multiple -v options increase the verbosity. Note that the -v and -p options
              are mutually exclusive.

19:54 - Finalmente, consegui carregar uma sessão KDE Plasma, — e descobri que o Login automático de usuário tinha sido desabilitado. — Tornei a configurar, e nunca mais falhou.

Dois anos depois, descobri que o Fedora é a única das minhas distros onde o SELinux estava ativado — embora o openSUSE também tenha as ferramentas para isso:

2022-07-08 --- SELinux


01 - openSUSE

$ id -Z
id: --context (-Z) works only on an SELinux-enabled kernel

# getenforce
Disabled

# sestatus
SELinux status:                 disabled


02 - Arch

$ id -Z
id: --context (-Z) works only on an SELinux-enabled kernel

# getenforce
bash: getenforce: command not found

# sestatus
bash: sestatus: command not found


03 - Debian testing

(idem)


04 - Fedora

$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

# getenforce
Enforcing

# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33


05 - KDE Neon

$ id -Z
id: --context (-Z) works only on an SELinux-enabled kernel

$ sestatus

Command 'sestatus' not found, but can be installed with:
sudo apt install policycoreutils

$ getenforce

Command 'getenforce' not found, but can be installed with:
sudo apt install selinux-utils


06 - PCLinuxOS

(idem)


07 - Mageia

(idem)


08 - Slackware

(idem)


09 - Void

(idem)


10 - Manjaro

(idem)


11 - Redcore

(idem)


12 - MX Linux

$ id -Z
id: --context (-Z) works only on an SELinux-enabled kernel

# sestatus
Command 'sestatus' not found, but can be installed with:
apt install policycoreutils

# getenforce
Command 'getenforce' not found, but can be installed with:
apt install selinux-utils

Cronologia: — Distros, partições etc.

Plugando antigos HDDs de 320 GB (Sata II) e 1 TB (Sata III)

Essa cronologia não é completa, nem detalhada, nem exata — e serve, apenas, para situar o relato na situação geral de cada momento — após a instalação das primeiras 4 distros em Janeiro 2020.

As unidades de disco citadas — das atuais até as mais antigas e já descartadas:

Internal SSDs

Sata #1   /dev/sda   SSD   Sata III   Kingston   SA400S37480G      480 GB   (probably 2019)
Sata #2   /dev/sdb   SSD   Sata III   WD         WD Green 2.5      480 GB   (2022)

External HDDs & Portable SSD

USB 3.0 / 5 Gb/s     HDD   Sata III   Seagate    ST1000DM010         1 TB   (probably 2021)
USB 3.0 / 6 Gb/s     HDD   Sata III   Seagate    ST1000DM003         1 TB   (2016)

USB 2.0              SSD   USB 2.0    Samsung    S2 Portable         1 TB   (2011)

Discarded            HDD   Sata II    Maxtor     MAXTOR_STM332061  320 GB   (2008)
Discarded            HDD   Sata II    Samsung    SAMSUNG_HD322HJ   320 GB   (2008)

2020-01-30 - Pluguei os antigos HDDs Sata II / III — e comecei a mover as partições de documentos, de uns para outros — para esvaziar e, em seguida, converter cada unidade, de MBR para GPT.

2020-02-26 - Criei 12 partições /home separadas, em um HDD Sata III, menos antigo (fabricação: 2016) — e comecei a mover / copiar as pastas pessoais (/home/$USER), das 4 distros já instaladas. — Depois disso, as novas distros já foram instaladas com partições /home separadas.

2020-03-04 - Desativei o arquivo swap (swapfile) do KDE Neon — e configurei uma partição Swap para as 4 distros já instaladas. — Depois disso, as novas distros já foram instaladas com a partição Swap configurada.

  • Ver “Partição Swap” (acima).

2020-03-24 - Linux3 - Instalei o Debian Buster, pela manhã, e transformei em Debian Testing no mesmo dia, à tarde.

2020-04-15 - Linux2 - Instalei o Arch Linux, pelo método “RTFM”.

2020-05-18 - Linux7 - Instalei o Mageia 7 — por pouco tempo.

2020-06-12 - Linux8 - Instalei o Mint 20 (Beta) Xfce, e em seguida instalei nele o KDE Plasma.

2020-07-02 - Linux7 - Instalei o Mageia 8 Alpha 1, em substituição ao Mageia 7.

2020-07-13 - Linux9 - Instalei o Void + KDE Plasma.

2020-07-22 - Linux12 - Instalei o MX Linux 19.2 KDE Beta 2.

2020-09-26 - Linux10 - Instalei o Slackware by AlienBob.

2021-01-10 - Pluguei mais um antigo HDD (Sata II).

2021-02-18 - Linux11 - Instalei o Slackware 15 Alpha 1.

2021-04-26 - Linux10 - Instalei o Manjaro em substituição ao Slackware by AlienBob.

2021-05-23 - Reorganizei várias pastas dentro das partições de backup — que eu ainda fazia pelo Luckybackup em modo root.

2021-07-09 - Busca de possíveis causas para falhas ocasionais em algumas partições de HDDs, usando GSmartControl.

2021-08-09 - Linux6 - Instalei o PCLinuxOS Darkstar, em substituição ao instalado 1 ano antes.

2021-08-26 - Linux12 - Instalei o MX Linux 21 Beta 1.

2021-10-22 - Linux12 - Instalei o MX Linux 21.

2021-11-12 - Incorporação de um novo HDD, mais novo que os outros.

2022-02-05 - Linux8 - Instalei o Slackware 15.

2022-06-12 - Linux11 - Instalei o Redcore.

2023-04-19 - Nova busca de possíveis causas para falhas ocasionais em algumas partições de HDDs.

2023-05-01 - Instalei um 2º SSD — “movi” para ele metade das minhas distros (Linux7 ~ Linux12) — e passei os HDDs para “gavetas” (cases) USB3, para acesso apenas ocasional.

Average Boot Time (sec)

             Oct 2021   Jun 2023    Diff   Delta      Jan 2020

openSUSE         42’’       33’’     - 9    -22%          15’’
Arch             32’’       19’’     -13    -41%
Debian           23’’       17’’     - 6    -27%
Fedora           40’’       36’’     - 4    -10%          15’’
Neon             27’’       23’’     - 4    -15%          10’’
PCLinuxOS        25’’       18’’     - 7    -27%          16’’
Mageia           37’’       18’’     -19    -51%
Slackware        31’’       15’’     -16    -52%
Void             34’’       19’’     -15    -43%
Manjaro          31’’       19’’     -12    -40%
Redcore                     14’’
MX Linux         35’’       22’’     -13    -38%

Após mover a partição Swap, as partições /home e as partições de documentos do HDD para SSDs Sata III, o tempo de boot diminuiu drasticamente (não pretendo investir em NMVe, no momento).

Esses tempos eram ainda menores em Janeiro 2020, quando eu ainda não usava partições Swap e /home; e a montagem automática envolvia apenas 3 ou 5 partições extras (todas em SSD Sata III).

2023-07-04 - Linux7 - Fiz upgrade do Mageia 8 para Cauldron.

2023-07-31 - Linux12 - Instalei o MX Linux 23.

2024-12-01 - Deletei KDE Neon (Linux5), Slackware (Linux8), Manjaro (Linux10), Redcore (Linux11).

2025-04-08 - Criei uma 2ª partição EFI (efi2), para as distros instaladas no 2º SSD, de modo que possam ser usadas caso o 1º SSD venha a falhar — e vice-versa.

  • Ver “Criando uma 2ª partição EFI” (acima).

Referências

Dezenas de leituras feitas nos últimos 3 anos me deram alguma noção teórica, com inúmeros conceitos que eu ainda precisava aprender, mas isso me criou tamanho acúmulo de cultura inútil, que não servia como guia prático, com as lacunas mais básicas, na hora da ação. — No momento de colocar em prática, senti necessidade de procurar guias simples (1 e 2), de usuários médios, voltados para “o que fazer”.

Preferi usar o Grub, com o qual já estou familiarizado, e deixei para o futuro qualquer experiência com os demais gerenciadores de inicialização (3, 4 e 5).

Guardei uma avaliação muito antiga (6) sobre o bom, o ruim e o feio no UEFI, — e também um guia de conversão de partições MBR em GPT (7), que preferi não tentar, para não complicar a transição, que eu queria manter simples.

Pesquisei sobre possíveis alternativas ao UEFI (8, 9, 10), mas não estou certo de que realmente sejam isso. — Mesmo que sejam, envolveriam muito estudo (em um momento crítico), e introduziriam uma enorme complicação no processo.

  1. Setting up a multi-boot of 5 Linux distributions (2017)
  2. UEFI multi-boot, my way (2015)
  3. gerenciadores de inicialização - UbuntuPIT
  4. gerenciadores de inicialização - Debian Wiki
  5. rEFInd - SourceForge, Developer, artigo em pt_BR
  6. Booting into UEFI Mode - The Good, the Bad, and the Ugly
  7. Convert between MBR and GPT - Arch Wiki
  8. LinuxBoot
  9. CoreBoot
  10. TianoCore

xxxx

____________________
• Publicado inicialmente em 15 Janeiro 2020.
• Desenvolvido até 17 Abril 2025

— … ≠ • ≠ … —

PC desktop UEFI / GPT



Ferramentas &tc.


Postado por Mboaba às quarta-feira, janeiro 15, 2020 0 comentários
Marcadores: , , , , ,
Assinar: Postagens (Atom)