 |
| Particionamento inicial para dualboot 12 distros Linux em UEFI |
Fazer dualboot 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 para UEFI, — quanto mais eu lia, menos gostava. — A impressão era de uma geringonça desconjuntada.
Faltava eu lidar com o assunto na prática, — para constatar que é de uma simplicidade total, — como me diziam.
Ainda acho absurdo ser obrigado a usar uma partição EFI em formato proprietário (Fat32), — mas isso, não vi como evitar.
Isto não é um “tutorial”. — Apenas um registro, para lembrar o que fiz, e como fiz, — começando do modo mais simples.
Í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
- Conteúdo da partição EFI
- Vida após a mudança
- Grub
- Conky
- Antigos HDDs
- Luckybackup
- Partição Swap
- Movendo a /home
- Referências
Nos tempos do BIOS / 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, — coisa estranha ao meu antigo PC, que já pedia aposentadoria urgente, — mas qualquer novo hardware seria UEFI, sem escapatória.
Meu antigo PC foi montado em 2009, com CPU Intel + placa-mãe Asus com “video onboard” (iGPU) Intel, lançadas uns 6 meses antes, — 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, esta se mostrou uma boa fórmula 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 Memory: 4 GB (2 x 2 GB speed: 667 MHz type: DDR2) Graphics: Intel 82G33/G31 Express Integrated Graphics Controller HDD: (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), consumo / dissipação: 65 W;
- Placa-mãe um pouco acima do básico (portas para expansão), com iGPU Intel;
- 1 pente 16 GB RAM (máx.: 4 x 16); e
- um 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)
Memory: 16 GiB speed: 2400 MT/s type: DDR4 (max: 4 x 16 = 64 GiB)
Graphics: Intel UHD Graphics 630 driver: i915 v: kernel
SSD: 480 GB Kingston A400 Sata III
As peças foram adquiridas em 3 lojas, — e pedi a um técnico 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, apertar DEL ou F2 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 consta que a opção “Windows UEFI mode” impede 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 Live PCLinuxOS (em DVD), ú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 removíveis).
- 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 tudo indica que foi um exagero monumental.
- 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 é 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 (ver 13.3.1 - System partition, pág. 498; mastigado), e o Linux não faz questão. — Apenas o Windows “recomenda” que seja a primeira.
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, nos tamanhos que eu queria. — Pretendo adicionar outro SSD, mais tarde.
 |
| Espaço usado por várias distros Linux 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 que as pastas /home vão ocupar, uma vez que meus documentos, fotos etc. ficam em partições próprias.
 |
| Uso de Memória RAM em sessão Live com 11 abas no Chrome (9 do Facebook), sem Swap |
 |
| Uso de CPU e Memória RAM em sessão Live com GoogleEarth no Chrome, sem partição 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 dá conta do recado, sem necessidade imediata de partições Swap.
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), — 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 personalizado”, o Draklive install apresentou o sumário das operações: — Formatar apenas a partição-raiz, — padrão de prudência, pois é comum uma 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 não custava nada verificar.
Date Live Installed Distro
1st PrtScn 1st PrtScn
10-01-2020 14:02 23:51 PCLinuxOS
11-01-2020 16:06 17:14 openSUSE
12-01-2020 12:28 13:59 KDE Neon
12-01-2020 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 de cada 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 torna mais difícil 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.
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).
Fedora
 |
| Particionamento manual do Fedora, com formatação apenas da Root |
No instalador do Fedora (Anaconda), a 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 manualmente teria digitado “/boot/EFI”, por via das dúvidas. — 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, é a de que o Bootloader seria instalado 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 está montada, — e tudo funciona.
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á identifica e pré-seleciona 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 é 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
 |
| 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 são capazes de carregá-lo.
A experiência dos últimos 3 anos (ainda em BIOS / MBR do antigo PC), já me havia mostrado que o Grub do Mageia e o Grub do openSUSE são os mais habilitados (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, — 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. Tempos depois, quando despluguei o SSD para uma experiência (Boot automático pelo DVD) e tornei a plugar, essa opção desapareceu. Será que mexi em alguma coisa?
2020-12-27 - Meses depois, passei a verificar (e corrigir) a prioridade de boot por comandos:
Check boot order:
$ efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0004,0001,000D,0008,0006,000A,0007,0002,0005,000E,0003,0009,000B
Boot0000* opensuse
Boot0001* debian
Boot0002* Fedora
Boot0003* UEFI:CD/DVD Drive
Boot0004* mageia
Boot0005* arch_grub
Boot0006* ubuntu
Boot0007* MX19
Boot0008* neon
Boot0009* UEFI:Removable Device
Boot000A* slackware-14.2+
Boot000B* UEFI:Network Device
Boot000D* pclinuxos
Boot000E* debian
Change boot order:
# efibootmgr -o 0000,0004,0001,000D,0008,0006,000A,0007,0002,0005,000E
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0004,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
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 de outro Grub |
Para Boot a partir de um DVD, tenho usado o Boot Menu, — acesso por F8, dentro do “UEFI Bios Utility”. — Basta clicar 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) |
Optei por criar a partição EFI com 2 GiB, por via das dúvidas, — e depois de instalar 4 distros, apenas 1% do espaço foi ocupado (28 MiB), segundo o Dolphin; — ou 2% (32 MiB), segundo o GParted.
2020-06-01 - Com 7 distros instaladas (Arch, Debian, Mageia), a ocupação da partição EFI ainda é de apenas 2%, no total de 33.8 MiB (35,450,986), 45 files, 15 sub-folders, segundo o Dolphin; — ou 2% (37,92 MiB), segundo o GParted.
Portanto, poderia ter usado só 512 MiB; então, essas 4 distros não ocupariam mais do que uns 6%; e 12 distros talvez ocupassem uns 20%, — mas não posso garantir, pois já vi relatos de que o Deepin ocupa 100 MB, — e ignoro tudo sobre o caso do Windows, que não me interessa.
20-06-01 - Com 7 distros instaladas, apenas Fedora, Debian, openSUSE e KDE Neon (além da pasta /boot/efi/EFI/boot) respondem por quase todo espaço ocupado. — O Filelight não chega a mostrar o espaço, meramente residual, ocupado pelas pastas do Arch, Mageia, PCLinuxOS, e “Ubuntu” (do KDE Neon).
 |
| Montagem da partição EFI em sessão Live |
O conteúdo dessa partição EFI era um mistério, para mim. — Não tinha, sequer, a certeza de que tudo aquilo estivesse mesmo ali, — afinal, só podia ver (ou não) aquelas pastas e arquivos, de “dentro” da distro em uso no momento (montagem dinâmica).
Para obter um retrato objetivo do conteúdo, rodei uma sessão Live e montei a partição EFI na pasta /mnt, que estava vazia (montagem estática, “neutra”, alheia ao sistema).
 |
| Cópia da pasta /mnt com o conteúdo da partição EFI para um Pendrive |
Usando o Midnight-Commander (mc) como Root, copiei a pasta /mnt para um Pendrive, — tendo o cuidado de desmarcar a opção “Preserve attributes”. — Desse modo, obtive uma cópia sem barreiras de “propriedade”, “permissões” etc., e portanto, fácil de examinar a qualquer momento, como usuário comum.
# history
1 apt install mc
3 mount /dev/sda1 /mnt
4 mc
O conteúdo copiado mostrou ser exatamente o mesmo que aparece em /boot/efi, — ou seja, visto “de dentro” de qualquer distro instalada:
# tree /boot/efi # tree /run/media/flavio/Storage/Byteria/EFI_Live-Neon/mnt/
/boot/efi /run/media/flavio/Storage/Byteria/EFI_Live-Neon/mnt/
├── EFI ├── EFI
│ ├── boot │ ├── boot
│ │ ├── BOOTIA32.EFI │ │ ├── BOOTIA32.EFI
│ │ ├── bootx64.efi │ │ ├── bootx64.efi
│ │ ├── fallback.efi │ │ ├── fallback.efi
│ │ ├── fbia32.efi │ │ ├── fbia32.efi
│ │ └── fbx64.efi │ │ └── fbx64.efi
│ ├── fedora │ ├── fedora
│ │ ├── BOOTIA32.CSV │ │ ├── BOOTIA32.CSV
│ │ ├── BOOTX64.CSV │ │ ├── BOOTX64.CSV
│ │ ├── fonts │ │ ├── fonts
│ │ │ └── unicode.pf2 │ │ │ └── unicode.pf2
│ │ ├── gcdia32.efi │ │ ├── gcdia32.efi
│ │ ├── gcdx64.efi │ │ ├── gcdx64.efi
│ │ ├── grub.cfg │ │ ├── grub.cfg
│ │ ├── grubenv │ │ ├── grubenv
│ │ ├── grubia32.efi │ │ ├── grubia32.efi
│ │ ├── grubx64.efi │ │ ├── grubx64.efi
│ │ ├── mmia32.efi │ │ ├── mmia32.efi
│ │ ├── mmx64.efi │ │ ├── mmx64.efi
│ │ ├── shim.efi │ │ ├── shim.efi
│ │ ├── shimia32.efi │ │ ├── shimia32.efi
│ │ ├── shimia32-fedora.efi │ │ ├── shimia32-fedora.efi
│ │ ├── shimx64.efi │ │ ├── shimx64.efi
│ │ └── shimx64-fedora.efi │ │ └── shimx64-fedora.efi
│ ├── neon │ ├── neon
│ │ ├── BOOTX64.CSV │ │ ├── BOOTX64.CSV
│ │ ├── grub.cfg │ │ ├── grub.cfg
│ │ ├── grubx64.efi │ │ ├── grubx64.efi
│ │ ├── mmx64.efi │ │ ├── mmx64.efi
│ │ └── shimx64.efi │ │ └── shimx64.efi
│ ├── opensuse │ ├── opensuse
│ │ ├── boot.csv │ │ ├── boot.csv
│ │ ├── fw │ │ ├── fw
│ │ ├── fwupdx64.efi │ │ ├── fwupdx64.efi
│ │ ├── grub.cfg │ │ ├── grub.cfg
│ │ ├── grub.efi │ │ ├── grub.efi
│ │ ├── grubx64.efi │ │ ├── grubx64.efi
│ │ ├── MokManager.efi │ │ ├── MokManager.efi
│ │ └── shim.efi │ │ └── shim.efi
│ ├── pclinuxos │ ├── pclinuxos
│ │ └── grubx64.efi │ │ └── grubx64.efi
│ └── ubuntu │ └── ubuntu
│ ├── fw │ ├── fw
│ ├── fwupx64.efi │ ├── fwupx64.efi
│ └── grub.cfg │ └── grub.cfg
├── mach_kernel ├── mach_kernel
└── System └── System
└── Library └── Library
└── CoreServices └── CoreServices
└── SystemVersion.plist └── SystemVersion.plist
13 directories, 38 files 13 directories, 38 files
Esse material fica como documentação do estado das coisas até aquele momento, — pois ainda não entendo quase nada disso tudo.
Por enquanto, estou apenas “vendo” como são as coisas, — e colhendo amostras, — para que a teoria faça algum sentido, quando começar a ler mais sobre o assunto.
 |
| Conteúdo da partição EFI, copiado para um Pendrive e movido para uma partição de documentos |
18 Janeiro 2020 - A partição EFI contém 2 pastas — EFI, com 27,5 MiB; e System, com 12,4 KiB, — no total de 38 arquivos e 13 pastas e subpastas.
 |
| Pesquisa de todos os arquivos da partição EFI, pelo KFind |
O Filelight indica 51 “arquivos”, — somando as pastas. — O KFind é mais correto, ao indicar que encontrou 51 “itens”.
18 Fevereiro 2020 - Ao instalar uma revisão de Kernel (e remover outra), o KDE Neon eliminou 1 pasta e 1 arquivo em /boot/efi/EFI/ubuntu:
$ tree mnt (antigo) # tree /boot/efi
mnt /boot/efi
├── EFI ├── EFI
│ ├── boot │ ├── boot
│ │ ├── BOOTIA32.EFI │ │ ├── BOOTIA32.EFI
│ │ ├── bootx64.efi │ │ ├── bootx64.efi
│ │ ├── fallback.efi │ │ ├── fallback.efi
│ │ ├── fbia32.efi │ │ ├── fbia32.efi
│ │ └── fbx64.efi │ │ └── fbx64.efi
│ ├── fedora │ ├── fedora
│ │ ├── BOOTIA32.CSV │ │ ├── BOOTIA32.CSV
│ │ ├── BOOTX64.CSV │ │ ├── BOOTX64.CSV
│ │ ├── fonts │ │ ├── fonts
│ │ │ └── unicode.pf2 │ │ │ └── unicode.pf2
│ │ ├── gcdia32.efi │ │ ├── gcdia32.efi
│ │ ├── gcdx64.efi │ │ ├── gcdx64.efi
│ │ ├── grub.cfg │ │ ├── grub.cfg
│ │ ├── grubenv │ │ ├── grubenv
│ │ ├── grubia32.efi │ │ ├── grubia32.efi
│ │ ├── grubx64.efi │ │ ├── grubx64.efi
│ │ ├── mmia32.efi │ │ ├── mmia32.efi
│ │ ├── mmx64.efi │ │ ├── mmx64.efi
│ │ ├── shim.efi │ │ ├── shim.efi
│ │ ├── shimia32.efi │ │ ├── shimia32.efi
│ │ ├── shimia32-fedora.efi │ │ ├── shimia32-fedora.efi
│ │ ├── shimx64.efi │ │ ├── shimx64.efi
│ │ └── shimx64-fedora.efi │ │ └── shimx64-fedora.efi
│ ├── neon │ ├── neon
│ │ ├── BOOTX64.CSV │ │ ├── BOOTX64.CSV
│ │ ├── grub.cfg │ │ ├── grub.cfg
│ │ ├── grubx64.efi │ │ ├── grubx64.efi
│ │ ├── mmx64.efi │ │ ├── mmx64.efi
│ │ └── shimx64.efi │ │ └── shimx64.efi
│ ├── opensuse │ ├── opensuse
│ │ ├── boot.csv │ │ ├── boot.csv
│ │ ├── fw │ │ ├── fw
│ │ ├── fwupdx64.efi │ │ ├── fwupdx64.efi
│ │ ├── grub.cfg │ │ ├── grub.cfg
│ │ ├── grub.efi │ │ ├── grub.efi
│ │ ├── grubx64.efi │ │ ├── grubx64.efi
│ │ ├── MokManager.efi │ │ ├── MokManager.efi
│ │ └── shim.efi │ │ └── shim.efi
│ ├── pclinuxos │ ├── pclinuxos
│ │ └── grubx64.efi │ │ └── grubx64.efi
│ └── ubuntu │ └── ubuntu
│ ├── fw │ └── grub.cfg
│ ├── fwupx64.efi ├── mach_kernel
│ └── grub.cfg └── System
├── mach_kernel └── Library
└── System └── CoreServices
└── Library └── SystemVersion.plist
└── CoreServices
└── SystemVersion.plist
13 directories, 38 files 12 directories, 37 files
7 Março 2020 - Também fiz um registro dos atributos dessas pastas e arquivos, — o que permite comparar sua evolução 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*
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 as 25 ou 30 distros que instalei nos últimos anos, — vindo em segundo lugar o Grub do Mageia (que ainda não instalei no novo PC).
Além disso, ele é indispensável para carregar os “instantâneos” (snapshots) do próprio openSUSE, — 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.
 |
| Ampliação da área do Menu de inicialização do Grub |
Precisei editar seu “Tema”, — que só exibia 6 itens no Menu de inicialização, — para exibir todas as 4 distros já instaladas, além do acesso aos Snapshots do openSUSE, no final.
Na seção boot_menu do 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).
+ boot_menu {
left = 10%
width = 80%
top = 33% -----------> 10%
height = 34% --------> 81%
item_font = "DejaVu Sans Regular 12"
item_color = "#fff"
item_height = 32
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"
}
No backup de 2018 (Krusader, lado esquerdo), vi que eu tinha alterado para começar a 5% da altura desde o alto da tela (top) e utilizar outros 86% (height), — mas naquela época eu tinha eliminado a logo do openSUSE (no alto). — Para um ajuste simples e rápido, optei agora por 10% (top) e 81% (height).
Com isso, a área útil do Menu de inicialização já permite exibir até 8 ou 9 distros.
Para fazer efeito, atualizei o Grub:
# date && grub2-mkconfig -o /boot/grub2/grub.cfg && date
Fri 6 Mar 12:01:47 -03 2020
Generating grub configuration file ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-5.5.6-1-default
Found initrd image: /boot/initrd-5.5.6-1-default
Found linux image: /boot/vmlinuz-5.5.5-1-default
Found initrd image: /boot/initrd-5.5.5-1-default
Found Fedora 31 (KDE Plasma) on /dev/sda5
Found KDE neon User Edition 5.18 (18.04) on /dev/sda6
Found PCLinuxOS on /dev/sda7
done
Fri 6 Mar 12:02:04 -03 2020
 |
| 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 e do PCLinuxOS, — 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 ele não é perfeito, e qualquer erro introduzido em uma distro é copiado pelo Grub das outras, e com o tempo se espalham e se multiplicam.
Basta que o Grub de 1 distro detecte as outras (e que o das outras detecte apenas cada uma delas mesmas).
# date && grub2-mkconfig -o /boot/grub2/grub.cfg && date Sun 12 Jan 20:15:40 -03 2020 Generating grub configuration file ... mount: /var/lib/os-prober/mount: mount(2) system call failed: No such file or directory.Found openSUSE Tumbleweed on /dev/sda2Found openSUSE Tumbleweed on /dev/sda2Found KDE neon User Edition 5.17 (18.04) on /dev/sda6 Found PCLinuxOS on /dev/sda7 Adding boot menu entry for EFI firmware configuration done Sun 12 Jan 20:15:53 -03 2020
Após desabilitar o Os_Prober, os tempos de “update-grub” caíram para 5’’ no PCLinuxOS, 13’’ no KDE Neon e 8’’ no Fedora.
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 |
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, 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:
# 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 |
A adaptação do Conky ao novo PC começou na primeira sessão Live, — partindo de um antigo arquivo ~/.config/conky/conky.conf. — Ver “\• Resultado final” (CTRL-F no link).
Onde bastavam 2 gráficos de uso de CPU lado a lado (2 x Core2 Duo), agora existem 6:
${cpugraph cpu1 30,120} ${alignr}${cpugraph cpu2 30,120}
CPU1: ${cpu cpu1}% ${alignr}120’’ ${alignr}CPU2: ${cpu cpu2}%
${cpugraph cpu3 30,120} ${alignr}${cpugraph cpu4 30,120}
CPU3: ${cpu cpu3}% ${alignr}120’’ ${alignr}CPU4: ${cpu cpu4}%
${cpugraph cpu5 30,120} ${alignr}${cpugraph cpu6 30,120}
CPU5: ${cpu cpu5}% ${alignr}120’’ ${alignr}CPU6: ${cpu cpu6}%
 |
| Localização aleatória das Temperaturas dos Núcleos em hwmon0, hwmon1, hwmon2, no openSUSE |
Para economizar espaço, organizei as temperaturas dos 6 núcleos em apenas 2 linhas, — embora no arquivo de configuração estejam empilhadas, para facilitar o ajuste dos espaçamentos, com barras invertidas (\) para anular quebras de linha, — e por enquanto mantenho 3 variações desse bloco, conforme apareçam em hwmon 1 e 0, ou em hwmon 0 e 1, ou em hwmon 0 e 2.
Onde eu usava um IF / ELSE / ENDIF, agora vou ter de experimentar dois, — um aninhado no outro, — quando houver mais distros com esse problema, que justifiquem investir tempo nisso:
# MB ${alignr}${hwmon 1 temp 1}°C \
# CPU ${alignr}${hwmon 0 temp 1}°C
#
# Core0 ${alignr}${hwmon 0 temp 2}°C \
# Core1 ${alignr}${hwmon 0 temp 3}°C \
# Core2 ${alignr}${hwmon 0 temp 4}°C
# Core3 ${alignr}${hwmon 0 temp 5}°C \
# Core4 ${alignr}${hwmon 0 temp 6}°C \
# Core5 ${alignr}${hwmon 0 temp 7}°C
#
MB ${alignr}${hwmon 0 temp 1}°C \
CPU ${alignr}${hwmon 1 temp 1}°C
Core0 ${alignr}${hwmon 1 temp 2}°C \
Core1 ${alignr}${hwmon 1 temp 3}°C \
Core2 ${alignr}${hwmon 1 temp 4}°C
Core3 ${alignr}${hwmon 1 temp 5}°C \
Core4 ${alignr}${hwmon 1 temp 6}°C \
Core5 ${alignr}${hwmon 1 temp 7}°C
# MB ${alignr}${hwmon 0 temp 1}°C \
# CPU ${alignr}${hwmon 2 temp 1}°C
#
# Core0 ${alignr}${hwmon 2 temp 2}°C \
# Core1 ${alignr}${hwmon 2 temp 3}°C \
# Core2 ${alignr}${hwmon 2 temp 4}°C
# Core3 ${alignr}${hwmon 2 temp 5}°C \
# Core4 ${alignr}${hwmon 2 temp 6}°C \
# Core5 ${alignr}${hwmon 2 temp 7}°C
#
A temperatura que atribuí à placa-mãe (MB), tudo indica que não é dela. — Falta investir tempo na pesquisa do que é aquilo, exatamente, — e na busca das tensões (V), velocidade da ventoinha etc.
Se encontrar tudo isso, — e um modo de obter as temperaturas dos HDDs / SSDs (sem pedir senha), — e houver 12 distros para monitorar seu uso de espaço em disco…
… vai faltar espaço no Conky — e vou ter de fazer algumas opções.
Antigos HDDs
 |
| Remanejamento de partições entre os antigos HDDs e conversão de MBR para GPT |
30 Janeiro 2020 - Os 4 “discos” do antigo PC, — dois HDDs Sata II, um HDD Sata III, um SSD externo USB 2.0, — foram plugados para remanejar as partições e convertê-los de MBR para GPT.
 |
| Antigo particionamento MBR nos HDDs (Sata II e III) + SSD externo (USB 2.0)\ |
As únicas partições que me interessava manter eram Works, Sites, Xtudo, com os arquivos de trabalho, — e Armazem1, Armazem2, com os backups (Works, Sites, XTudo) + arquivos de uso pouco frequente.
Todas essas partições ficaram “congeladas” desde 10 Janeiro. — Nesse meio tempo, trabalhei apenas na partição Storage, — no SSD Sata III (novo).
Àquela altura, eu tinha perdido qualquer interesse nas antigas partições Linux1 a Linux11, Home1 a Home11, Swap1 a Swap 11.
Descartei a ideia de tentar converter as próprias partições, com os “discos”, — o que, de qualquer forma, exigiria backups, por segurança.
Achei mais simples converter o SSD externo (1 TB, USB 2.0) para GPT, com destruição de suas partições, e mover para ele as partições Works, Sites, XTudo, e Armazem1 (mais recente). — Depois, converter os 3 HDDs para GPT e mover de volta aquelas partições (e copiar Armazem2 para Armazem1).
Essas operações de mover / copiar partições foram feitas pelo Krusader e/ou pelo Midnight-Commander (mc), — ambos como super-usuário (Root); — e preservação de atributos (nos casos de cópia).
Aproveitei para alterar os rótulos (Label) de Armazem1, Armazem2 para Depot1, Depot2.
 |
| Instalação do HDD Sata III (1 TB) e de um HDD Sata II (320 GB) |
2 Fevereiro 2020 - Meu maior interesse era aproveitar o espaço restante do HDD Sata III (1 TB) para criar 12 partições “home” e 1 Swap, — e um dos HDDs de 320 GB para abrigar as partições Works, Sites, XTudo, que no momento estão fora de uso, portanto não precisam de elevadas taxas de transferência.
Device Size Year
HDD 320 GB 2009 Sata II
HDD 320 GB 2009 Sata II
HDD 1 TB 2016 7200RPM 64MB Sata III Transfer rate: 6 Gb/s (r/w?)
SSD 1 TB 2011 USB 2.0 Transfer rate: 480 Mb/s
 |
| Criação de 12 partições “home” e 1 Swap no HDD Sata III |
26 Fevereiro 2020 - Como não uso partições /home para arquivos de trabalho, a experiência já me havia mostrado que demora 2 ou 3 anos para ocupar 6 GiB, — por isso, partições de 13 GiB são mais do que suficientes. — Aproveitei a sobra de 5,5 GiB para criar 1 única partição Swap.
Acima - Por distração, criei a Home1 em ext4. Depois, formatei em XFS.
Luckybackup
 |
| Luckybackup, com 2 “perfis”: backup das partições, e backup do “depósito” |
7 Março 2020 - Terminada a conversão dos “discos” antigos para GPT e a reorganização das partições, chegou a hora de reorganizar as tarefas do Luckybackup, — basicamente:
2) Backup das 4 partições de trabalho (Storage, XTudo, Works, Sites) para um “depósito” (Depot1), — onde também ficam arquivos de pouco uso, como fotos digitais antigas (2003-2016), arquivos AutoCAD e Corel (1990-2016) etc.; e
1) Backup do “depósito”, — de Depot1 para Depot2
Prefiro fazer primeiro este último, de modo a preservar o backup da semana anterior, — e só depois fazer o backup da semana que está terminando.
Este é o esquema básico, — com os comandos rsync executados pelo Luckybackup, — e as partições montadas automaticamente, até o momento:
2020-03-07 ─── Luckybackup
Profiles:
1) Depot1 --> Depot2
Depot1 Depot2
└── Backup ───> ├──
├── Distros Linux ───> ├──
├── Sites_backups ───> ├──
├── Colab ───> ├──
├── Fotos digitais ───> ├──
├── Downloads ───> ├──
├── Biblioteca ───> ├──
└── AutoCAD, Corel ───> └──
2) Partitions --> Depot1
Depot1
└── Backup
Storage ───> ├──
Xtudo ───> ├──
Works ───> ├──
Sites ───> └──
Commands:
1) Depot1 --> Depot2
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Depot1/Backup /run/media/flavio/Depot2/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Depot1/AutoCAD_Corel-Draw /run/media/flavio/Depot2/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Depot1/Biblioteca /run/media/flavio/Depot2/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Depot1/Colab /run/media/flavio/Depot2/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Depot1/Distros-Linux /run/media/flavio/Depot2/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Depot1/Downloads /run/media/flavio/Depot2/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Depot1/Fotos-digitais /run/media/flavio/Depot2/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Depot1/sites_backups /run/media/flavio/Depot2/
2) Partitions --> Depot1
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Storage /run/media/flavio/Depot1/Backup/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/XTudo /run/media/flavio/Depot1/Backup/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Works /run/media/flavio/Depot1/Backup/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Sites /run/media/flavio/Depot1/Backup/
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 447.1G 0 disk
├─sda1 8:1 0 2G 0 part /boot/efi
├─sda2 8:2 0 50G 0 part /boot/grub2/x86_64-efi
├─sda3 8:3 0 30G 0 part
├─sda4 8:4 0 30G 0 part
├─sda5 8:5 0 30G 0 part /run/media/flavio/Linux4
├─sda6 8:6 0 30G 0 part /run/media/flavio/Linux5
├─sda7 8:7 0 30G 0 part /run/media/flavio/Linux6
├─sda8 8:8 0 30G 0 part
├─sda9 8:9 0 30G 0 part
├─sda10 8:10 0 30G 0 part
├─sda11 8:11 0 30G 0 part
├─sda12 8:12 0 30G 0 part
├─sda13 8:13 0 30G 0 part
└─sda14 8:14 0 65.1G 0 part /run/media/flavio/Storage
sdb 8:16 0 931.5G 0 disk
├─sdb1 8:17 0 770G 0 part /run/media/flavio/Depot1
├─sdb2 8:18 0 13G 0 part /home
├─sdb3 8:19 0 13G 0 part
├─sdb4 8:20 0 13G 0 part
├─sdb5 8:21 0 13G 0 part /run/media/flavio/Home4
├─sdb6 8:22 0 13G 0 part /run/media/flavio/Home5
├─sdb7 8:23 0 13G 0 part /run/media/flavio/Home6
├─sdb8 8:24 0 13G 0 part
├─sdb9 8:25 0 13G 0 part
├─sdb10 8:26 0 13G 0 part
├─sdb11 8:27 0 13G 0 part
├─sdb12 8:28 0 13G 0 part
├─sdb13 8:29 0 13G 0 part
└─sdb14 8:30 0 5.5G 0 part [SWAP]
sdc 8:32 0 298.1G 0 disk
├─sdc1 8:33 0 150G 0 part /run/media/flavio/XTudo
├─sdc2 8:34 0 130G 0 part /run/media/flavio/Works
└─sdc3 8:35 0 18.1G 0 part /run/media/flavio/Sites
sdd 8:48 0 931.5G 0 disk
└─sdd1 8:49 0 769G 0 part /run/media/flavio/Depot2
sr0 11:0 1 1024M 0 rom
 |
| Scripts simples para backup de arquivos de configuração /etc/fstab e Conky |
Já faz alguns anos que não tenho acidentes fatais das distros, — ou prefiro consertá-las, mesmo que demore um pouco (afinal tenho outras para continuar trabalhando, nesse meio tempo), — por isso, não costumo fazer backup das partições de sistema nem das partições /home.
Exceção é o openSUSE, — que produz seus próprios “instantâneos” (snapshots), — daí a necessidade de uma partição maior que as outras.
Me limito a fazer backup de alguns arquivos de configuração, — como /etc/fstab e conky.conf, por exemplo, — por meio de alguns scripts simples (sujeitos a erro, como quando a pasta /home muda de lugar).
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 a linha inteira de um backup de arquivos /etc/fstab de cada distro Linux que já instalei, — com as eventuais especificidaded 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.
Em tempo: - No antigo computador, criei 12 partições Swap, uma para cada distro, para evitar possíveis problemas, porque em 2016 o instalador do Debian só funcionava se a partição Swap fosse formatada, e alterava seu identificador UUID. — Isso exigiria corrigir os arquivos /etc/fstab (e alguns outros) de todas as outras distros que compartilhassem a mesma partição Swap, com o novo UUID gerado pelo Debian.
No entanto, depois de 3 anos experimentando várias distros (2017-2019), verifiquei que nenhum outro instalador forçava tal situação, — e posso evitar esse risco improvável, desconectando o disco onde está a partição Swap.
Movendo a /home
 |
| 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:
- Copiar a pasta pessoal do usuário /home/USER para a nova partição, — preservando todos os atributos, — proprietário, grupo, permissões etc.
- Renomear a antiga pasta: — /home/USER_OLD — para manter de reserva
- 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 de sistema.
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=100, às vezes, — 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 tudo desmontado, 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 dessa máquina fantástica:
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 de ext4 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 (talvez no SDDM), 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 (sdb5: 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 e documentar 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
Observações
 |
| Evolução das distros Linux e progressos pessoais com as instalações |
Todas 4 distros estão usando mais Memória RAM, no novo PC, do que no antigo. — Aloquei 1.024 MB para o vídeo onboard (iGPU) em 21 Fevereiro, mas não fez diferença nas médias até 6 Março, quando desfiz a alocação, de volta para 64 MB, no UEFI Bios Utility.
Já esperava que o uso de Memória RAM aumentasse um pouco, ao instalar os widgets Weather e Moon Phase nas 4 distros (na virada de Janeiro para Fevereiro), e se estabilizasse no novo patamar, — mas continuou aumentando de Fevereiro para Março, exceto no PCLinuxOS. — Tudo bem. Se há grande folga de Memória RAM, é melhor usar mesmo.
O espaço ocupado nas partições de sistema se normalizou em 8 Março, quando deletei o arquivo Swap do KDE Neon e esvaziei as pastas /home, que agora remetem às partições Home. — Exceção é o openSUSE, que está com um número exagerado de Snapshots semanais, diários, horários, além dos pre+post de cada instalação ou atualização de pacotes. — Posso reduzir bastante o limite de Snapshots a serem mantidos, e o “cleaner” se encarrega de eliminar o excesso.
Uma péssima surpresa é que até agora o vetusto Dreamweaver não acabou de carregar, — mesmo deixando de um dia para outro. — Falta pesquisar, pois talvez seja alguma bobagem à toa.
O GoogleEarth ainda não funcionou no PCLinuxOS, mesmo tentando 3 ou 4 versões diferentes e outras dicas, que resolvem o problema para vários usuários no Forum. — O fato é que o PCLinuxOS não tem mais intenção de suportá-lo, — e dualboot dispensa arrancar os cabelos por tão pouco.
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.
- Setting up a multi-boot of 5 Linux distributions (2017)
- UEFI multi-boot, my way (2015)
- gerenciadores de inicialização - UbuntuPIT
- gerenciadores de inicialização - Debian Wiki
- rEFInd - SourceForge, Developer, artigo em pt_BR
- Booting into UEFI Mode - The Good, the Bad, and the Ugly
- Convert between MBR and GPT - Arch Wiki
- LinuxBoot
- CoreBoot
- TianoCore
xxxx
____________________
• Publicado inicialmente em 15 Janeiro 2020.
• Desenvolvido até...
— … ≠ • ≠ … —
PC desktop UEFI / GPT
- Transição para hardware UEFI-GPT
- Arch Linux - install, config
- Debian testing - install, config
- Linux Mint 20 (beta) "Ulyana" + Plasma KDE
- Upgrade para o Fedora 32
- Void + KDE
- MX Linux 19.2 KDE Beta 2
- KDE Neon upgrade 20.04 Focal Fossa
Ferramentas &tc.
- Conky erra Memória RAM usada
- Transição para hardware UEFI-GPT
- Speedtest de banda larga de “200 megas”
- Conky - monitor do sistema
- Consertando pequenos problemas do Gimp 2.10
- Pré-visualização de arquivos no Dolphin
- Limpeza do Cooler da CPU
- Escolhendo Grub entre vários Linux
- Teste de memória com o Memtest86
- De volta ao Gnome-screenshot
- Konqueror como gerenciador de arquivos
- Substituição da fonte de energia do computador
- Facebook sobrecarrega visitar e compartilhar “Páginas”
- Corrigindo pontos de montagem no Linux Mint 18 KDE
- Política de Kernel do Linux Mint vs. Kubuntu, KDE Neon & Debian
- KDE “light” eliminando o PIM
- Conky - configuração em andamento
- Google Earth sem placa 3D no Xenial
- Linux ficou sem Administrador. Que fazer?
- Particionamento de disco para vários Linux
- Padronizando PrintScreen no Linux (com Shutter) e no Windows
- Montagem automática de partições adicionais (Cinnamon e Gnome)
- Boot com “Live USB” (Pendrive) do Linux Mint Cinnamon
- Repositórios de software Linux e gerenciador de pacotes Synaptic
- Monitorando a temperatura da CPU no Linux e Windows
- Conversão em massa de TIFF em JPEG
- Meu Wi-Fi parou de funcionar. E agora?
- Cópia de artigos da mídia para citação
- Lua, Júpiter e Vênus em ISO 1600
- Como se livrar do SPAM da Claro que te interrompe de 30 em 30 segundos
- Quantas pessoas cabem na Avenida Paulista?
- A batalha da Comunicação no Facebook
- O Aeroporto de Cláudio documentado no Google Earth
- O apagão do Facebook não será noticiado
- Blog, microblog e redes sociais
- Adeus ao Orkut
- Bookmark para encontrar um post “favorito” no Facebook
- Sincronização do Google Chrome
- Fotos em alta resolução no Facebook
- Sincronizando pastas de documentos entre Linux e Windows
- Dual-boot, Linux, Windows e Grub-customizer
- Listas, Grupos, Fóruns, Comunidades
- Mandar fotos por email para Grupos do Facebook
- Limitando emails de notificação do Facebook
- Conexão 3G pelo “chaveirinho” da TIM
