Translate

quinta-feira, 9 de abril de 2026

Artix Linux com KDE Plasma, OpenRC e XLibre

KInfoCentre do Artix Linux com KDE Plasma, OpenRC e XLibre
Artix Linux com KDE Plasma, OpenRC e XLibre •

Há muito tempo, eu queria experimentar o Artix Linux — sem SystemD — para conferir a viabilidade de substituir o Arch Linux, dentro dos meus hábitos de trabalho no computador.

Como brinde, agora o Artix vem com XLibre — um fork do X11 com a perspectiva de atualizações de segurança — embora o usuário do KDE possa escolher sessão Plasma Wayland ao fazer Login.

Instalei o Artix em outra partição (dualboot), para experimentar pelo tempo que for necessário, antes de deletar (ou não) meu Arch. — Gostei do Artix, desde o primeiro dia, e quase não quero sair dele — mas ainda pretendo testar e aprender muito mais.

Índice

  • Download, sha256sum, K3b
  • xxxx
  • Capturas de tela
  • Flatpaks-fantasma

Download, sha256sum, K3b

Download e verificação da imagem ISO do Artix Linux

Minha intenção inicial era fazer a instalação por comandos, como fiz com o Arch (2019, 2020), mas a leitura das instruções para compor meu roteiro pessoal me desanimou. — Preciso fazer isso? Um dia, talvez, por diversão e aprendizado. Mas não, necessariamente, agora.

Vi que a Wiki do Artix desestimula esse esforço: — “A menos que você (...) esteja realizando uma instalação em servidor sem interface gráfica, há poucos motivos para usar as imagens básicas”. — Então, examinei as imagens ISO com KDE Plasma, e optei pelas “semanais” (não-testadas), que tinham sido lançadas naquele mesmo dia.

Escolhi OpenRC init, por ser mais “conhecido” e me parecer que tenha uma base maior de desenvolvedores e usuários (Gentoo). — Atualmente, já tenho o Void com Runit — e vejo falar menos do “dinit” e do “s6”.

Baixei a imagem “artix-plasma-openrc-20260407-x86_64.iso” da página de downloads do Artix — fiz a verificação pelo “sha256sum” — e “queimei” pelo K3b em DVD, para guardar.

O download direto prometia durar horas, pois não há espelhos no Brasil. — Baixei por Torrent, em cerca de 1 minuto.

Configuração do Fuso Horário, Teclado, Localização da sessão Live

No menu de boot, alterei o Fuso Horário para BRT, o Teclado para ABNT2, o Idioma / Localização para Reino Unido (en_UK) — e a sessão Live já começou com o horário correto: 12:05.

$ whoami
artix

$ echo $XDG_SESSION_TYPE
x11

$ history
    5  2026-04-07_12-12-52 sudo pacman -Sy
    7  2026-04-07_12-18-10 sudo pacman -S gnome-screenshot
    9  2026-04-07_12-37-16 echo $XDG_SESSION_TYPE
   11  2026-04-07_12-38-50 sudo pacman -S conky
   13  2026-04-07_12-53-48 echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
   14  2026-04-07_12-54-03 source ~/.bashrc
   15  2026-04-07_12-54-08 history

A sessão Live já começou em XLibre (identificado como X11) — o que foi ótimo, para poder usar o “gnome-screenshot” e o Conky.

Não encontrei a senha do Live User (artix) — mas o “sudo” não pediu.

Instalei o “gnome-screenshot” (veio sem KDE Spectacle), o Conky; — configurei os atalhos para salvar as capturas em um Pendrive de 2 GB; — e pude documentar tudo desde o início:

Configuração do gnome-screenshot para documentar a sessão Live

Usei uma configuração do Conky que tenho no Pendrive; — movi para o Pendrive os arquivos do ~/Desktop (manuais em PDF); — e instalei fontes Verdana, mais legíveis e econômicas de espaço vertical.

Iniciando a instalação do Artix pelo Calamares

Ao abrir, o instalador Calamares avisou que a opção “online” é experimental, e recomendou usar a opção “offline”.

Ainda no “Welcome”, alterei o Idioma para Inglês britânico (en_UK). — Ao escolher o Fuso Horário BRT, não percebi que isto incluiria Números e Datas em Português do Brasil. — Se percebesse, teria alterado.

xxxx

Capturas de tela

Falha do gnome-screenshot com o parâmetro “-w” e formato JPG

Desde Outubro 2025, o parâmetro “-w” do gnome-screenshot — capturar só a janela ativa — salva arquivos JPG “vazios” (0 byte).

Depois de várias experiências, optei por salvar capturas de janela pelo KDE Spectacle — ou em formato PNG, pelo gnome-screenshot — e agora tive de fazer o mesmo no Artix.

Action                       Command

Fullscreen                   gnome-screenshot -p -f /run/media/flavio/Warehouse/0_PrtScn/$(date +%%F_%%H-%%M-%%S)_Ax.jpg
Fullscreen    - delay 7’’    gnome-screenshot -p -d 7 -f /run/media/flavio/Warehouse/0_PrtScn/$(date +%%F_%%H-%%M-%%S)_Ax.jpg
Active Window                spectacle -p -a -e -b
Active Window - delay 7’’    spectacle -p -d 7000 -a -e -b

No caso do gnome-screenshot, o parâmetro “-f” salva a captura automaticamente (sem mais interação do usuário), na pasta indicada e com nome-de-arquivo no padrão indicado. — O parâmetro “-p” inclui o ponteiro do mouse; e o “-d” retarda pelo número indicado de segundos.

Configuração do KDE Spectacle

No caso do KDE Spectacle, é mais cômodo configurar logo a pasta e o padrão do nome-de-arquivo. — O comando fica mais simples, bastando indicar “-a” para capturar a janela ativa; “-b” para salvar em segundo plano (sem interação); e “-e” para não incluir “decoração”.

Flatpaks-fantasma

Remoção de Flatpaks herdados na partição /home

Eu tinha 9 flatpaks do sistema e 8 flatpaks do usuário, na distro que precedeu o Artix nas partições Linux11 e Home11. — Ao reaproveitar a pasta pessoal na Home11 (não formatada), meu 2º Conky indicou a sobrevivência de 8 flatpaks de usuário — informação do Fastfetch.

Conky (2) - before:

  ${execi 600 fastfetch | grep -o -P '.{0,0}Packages.{0,43}'}

Removing flatpaks:

  2026-04-10 - 14:20   # pacman -S flatpak
  2026-04-10 - 14:28   $ flatpak uninstall org.dupot.easyflatpak org.freedesktop.Platform org.freedesktop.Platform.GL.default org.freedesktop.Platform.GL.default org.freedesktop.Platform.VAAPI.Intel org.freedesktop.Platform.codecs-extra org.gnome.Platform org.gtk.Gtk3theme.Adwaita-dark
  2026-04-10 - 14:30   # pacman -Rns flatpak

Conky (2) - now:

  Packages: ${execi 600 pacman -Q | wc --lines} (pacman), ${execi 600 pacman -Qm | wc --lines} (AUR)

Para eliminá-los, instalei o Flatpak — usei seu comando “uninstall” — e tornei a remover o Flatpak, completamente.

Restou uma questão que eu vinha adiando há tempos: — Eliminar a dependência do Conky em relação ao Fastfetch, Neofetch etc. para extrair informações que podem ser obtidas diretamente.

Este caso mostrou uma lacuna do Fastfetch, que não indica o número de pacotes do AUR (Arch), do Pakman Essentials (openSUSE), ou do RPM Fusion (Fedora), por exemplo:

Distro      Fastfetch count

openSUSE    Packages: 4392 (rpm)
Arch        Packages: 1390 (pacman)
Debian      Packages: 3464 (dpkg)
Fedora      Packages: 3111 (rpm)
PCLinuxOS   Packages: 2381 (rpm), 13 (flatpak-system), 1 (flatp
PCLinuxOS   Packages: 2545 (rpm), 11 (flatpak-system), 8 (flatp
Mageia      Packages: 3493 (rpm)
Kubuntu     Packages: 2089 (dpkg)
Void        Packages: 1201 (xbps)
Mint        Packages: 2495 (dpkg)
PCLinuxOS   Packages: 2365 (rpm), 9 (flatpak-system), 8 (flatpa
Mx25        Packages: 2803 (dpkg)
Artix       Packages: 1076 (pacman), 8 (flatpak-user)

Alternativa para exibir também o número de pacotes do AUR, no Conky

Com 2 comandos — “pacman -Q” e “pacman -Qm” — obtive a contagem de pacotes nativos e do AUR, separadamente.

xxxx

___________________
• Publicado em 9 Abril 2026; e desenvolvido até...

— … ≠ “•” ≠ … —

PC desktop UEFI / GPT

terça-feira, 20 de janeiro de 2026

MX Linux 25.1 KDE com SysVinit

KInfoCentre d MX Linux 25.1 KDE (Infinity) com SysVinit
MX Linux 25.1 KDE (Infinity) com SysVinit •

As imagens ISO do MX Linux 25.1 voltaram a incluir SysVinit para o KDE Plasma — desde a versão “beta 1”. — Tratei de baixar e instalar.

  • Isto não é um “tutorial”. — É somente um registro do que eu fiz. — Ao revisar capturas e anotações para elaborar esse registro, encontro erros que na hora não percebi; e isso ajuda a entender e corrigir problemas. — Fico feliz se também for útil a outros colegas.

Eu uso poucos recursos — dos muitos que o MX Linux oferece — por isso, só vou falar dos que conheço.

Índice

  • Boot da sessão Live
  • Instalação do MX Linux
  • Instalando o Grub
  • Testando a instalação
  • Limpando as partições EFI
  • Links úteis

Boot da sessão Live

Opções de boot no Live MX Linux 25.1 KDE beta1 (Infinity)
Opções de boot no Live MX Linux 25.1 KDE beta1 (Infinity) •

O Menu inicial do Live MX Linux 25.1 oferece um mundo de opções, antes de carregar a sessão. — Dá para passar uma tarde inteira explorando os recursos que existem ali. — Escolhi só alguns que já conheço e que sei que me interessam.

Em Opções avançadas >> Opções de Boot, marquei as opções de copiar o sistema para a Memória RAM; — usar horário UTC no relógio do PC; — e exibir menus de texto (que acabaram sendo supérfluos).

Opções do Live MX Linux 25.1 KDE beta1 (Infinity)

Em Idioma / Teclado / Fuso horário, selecionei Inglês da Irlanda (en_IE); teclado ABNT2; e horário BRT. — Em seguida, escolhi SysVinit para iniciar a sessão Live.

  • O “init” escolhido aqui será o do sistema instalado.

Mantive os padrões em todas as opções dos menus em texto

Os menus de texto repetiram as opções já feitas. — Aceitei todas, sem mudar mais nada.

Tela de boas-vindas do MX Linux 25.1

O aplicativo de boas-vindas oferece Instalador, FAQ, Manual do Usuário (já em destaque na Área de Trabalho), acesso à documentação (Wiki) e aos Fóruns (antiX, MX), Vídeos, Aplicativos Populares, Tour guiado.

Merecem especial atenção o MX Tweak, para configurações e ajustes rápidos; — o MX Tools, que oferece muitas ferramentas úteis; — e o lembrete das senhas demo e root.

O Quick System Info (no alto da tela) fornece as informações básicas para que os colegas do Fórum possam ajudá-lo em qualquer problema com seu hardware e / ou com o sistema operacional.

Instalação do MX Linux

Instalador do MX Linux 25, com instruções passo a passo

O Instalador do MX Linux 25.1 verifica a mídia de instalação e apresenta as instruções iniciais, na área principal da janela. — Do lado esquerdo, explicações detalhadas, ao longo de cada etapa do processo. — Embaixo, ainda é possível mudar a configuração do Teclado, se precisar.

Eu já estava na sessão Live há mais de 2 horas, configurando, fazendo anotações, capturando telas e examinando as imagens pelo visualizador “qimgv” (quase tão bom quanto o Gwenview). — Eu também tinha usado o GParted para criar uma partição para o MX Linux (sdb17, ext4, 30 GiB, label: Linux13); — e tinha instalado o Google Chrome, que acabei não usando (mas foi incluído na instalação final no PC).

As instruções do Instalador mandam fechar todos os outros aplicativos. — Mantive abertos o Dolphin, o Kate, o “qimgv” e o Konsole.

  • Siga as recomendações — para que a “persistência” funcione dentro do previsto.

Escolha do esquema de particionamento de disco

No “tipo de instalação”, optei por “personalizar o esquema de disco”, para usar () a partição que eu tinha criado. — Não me interessava apagar o SSD inteiro — nem substituir uma instalação existente.

Escolhi apenas uma partição, para instalar o MX Linux 25.1

Abri o menu suspenso da partição sdb17 (label: Linux13), e selecionei a barra “/” indicativa de partição-raiz. — O Instalador mudou o formato previsto para BtrFS — mas eu tornei a escolher ext4.

  • BtrFS é melhor para “instantâneos” (snapshots), que permitem “voltar atrás”, quando alguma coisa dá errado — mas isso exige mais espaço do que eu tinha (30 GiB). — Uso no openSUSE há 9 anos (nenhum problema até hoje!), mas mesmo com 50 GiB ainda fica apertado.

Antes de prosseguir, o Instalador advertiu que eu precisava selecionar uma partição EFI para montar em /boot/efi — senão, talvez eu não conseguisse inicializar a distro, depois de instalada.

  • O correto seria voltar, e fazer isso.

... mas perguntou se eu queria prosseguir. — Portanto, deu liberdade de escolha. — Decidi correr o risco.

Instalador avisa que a partição pode falhar em futuro próximo

17:36 (a) - O Instalador avisa que vai formatar a partição sdb17. — Essa informação deve ser conferida com muita atenção, pois se houver algum erro na lista das partições a serem formatadas, será impossível recuperá-las depois. — Se necessário, volte atrás e corrija.

17:36 (b) - Mandei prosseguir, e o Instalador deu mais um aviso: — A partição que escolhi tem 5 setores realocados. — Passou no teste, mas oferece risco de falhas em futuro próximo. — Recomendou interromper a instalação e usar o GSmartControl para um exame detalhado.

  • Resolvi prosseguir — por minha conta e risco.

Escolha da partição para instalar o Grub do MX Linux 25.1

Ao fechar o aviso, vi que o Instalador aguardava decisões: — Instalar o Grub? — “Local” para instalar o Grub. — “Partição” para instalar o Grub.

(O resto da instalação tinha ocorrido entre 17:36 e 17:37; e pausou para aguardar essas decisões sobre o Grub).

Sim, eu queria instalar o Grub — a parte que fica em /boot/grub, na partição-raiz. — Mas o “local” (ESP) e a “partição” que ele pedia, dependiam de uma outra coisa, que eu não tinha feito, na etapa do particionamento: — Eu não tinha indicado uma partição EFI (ESP), para ser montada em /boot/efi.

  • O correto seria voltar atrás e escolher uma partição EFI.

Opções de Swap no Instalador do MX Linux 25.1

A seguir, o Instalador ofereceu opções de Swap. — A única opção marcada era “Criar um arquivo Swap” (swap file), pois eu não tinha selecionado minha partição Swap. — Desmarquei a criação do arquivo.

Rede, Localização e Serviços, no Instalador do MX Linux 25.1

Na tela seguinte, pediu as opções de Rede, tais como o nome do PC, o domínio — e servidor Samba (que dispensei). — Tive de escolher um “domínio”, mesmo que fictício.

Em seguida, nova chance de escolher a Localização Regional (Idioma), Fuso horário, Relógio, o formato das horas (12 ou 24h) — e uma opção “avançada” de serviços a serem iniciados automaticamente:

Serviços a serem iniciados automaticamente no MX Linux 25.1

Deixei habilitados os serviços que sei que vou usar — além dos que não tenho certeza. — Desabilitei só o bluetooth e o CUPS, que tenho certeza de que não vou usar.

Configuração do Usuário, senha, Login automático

O Instalador pediu o apelido a ser usado para Login do Usuário — será o nome de sua pasta pessoal — e sua senha.

  • Eu uso sempre o mesmo apelido (ID) — para reaproveitar as pastas pessoais de instalações anteriores.

O MX Linux não costuma habilitar a conta de “super-usuário” (root), mas você tem a liberdade de criá-la. — Já me acostumei a usar o sudo nas distros derivadas do Debian. — Fazer diferente, em uma delas, me deixaria em dúvida na hora de digitar os comandos.

  • Não tenho opinião sobre isso. — Em distros não-Debian, uso a conta root regularmente.

Habilitei o Login automático (Autologin) — e “Salvar as mudanças feitas na sessão Live”, para não ter de fazer de novo as mesmas configurações, depois de instalado.

  • Isso inclui arquivos salvos até o início da instalação efetiva em disco. — Arquivos salvos ou modificados depois disso precisam ser copiados manualmente, antes de encerrar a sessão Live.

Falha na instalação do Grub

Quando cliquei para prosseguir, o Instalador mostrou uma mensagem em letras garrafais dizendo que não conseguiu instalar o Grub.

Sugeriu reiniciar a sessão Live e usar o “Grub Rescue” para “consertar a instalação” — sinal de que só faltou o Grub.

Por que ignorei os avisos do Instalador? — Porque outros instaladores também reclamam, mas geram o arquivo interno de configuração /boot/grub/grub.cfg — mesmo que você não indique uma partição EFI para instalar nela o “bootloader” externo.

  • O Instalador do MX Linux 25.1 está certo. — O boot precisa dessas 2 coisas. — Querer só 1 delas é exceção.

Instalando o Grub

Eu não fazia questão do /boot/efi — mas precisava do /boot/grub/grub.cfg

Assim que fechei o Instalador, não encontrei mais a partição “Linux13”. — Pelo lsblk, vi que o rótulo da partição-raiz tinha sido alterado. — Agora, chamava-se “rootMX25”.

Montei em /mnt, pelo comando mount, e pude examinar a situação pelo Dolphin. — Faltava o arquivo /boot/grub/grub.cfg.

$ lsblk -o name,mountpoint,label,fstype,size | grep sdb17
└─sdb17                      rootMX25  ext4        30G

$ sudo mount /dev/sdb17 /mnt

$ lsblk -o name,mountpoint,label,fstype,size | grep sdb17
└─sdb17 /mnt                 rootMX25  ext4        30G

Chroot Rescue Scan: — Nunca foi tão fácil recuperar uma instalação

Abri o “Chroot Rescue Scan”, que permite “entrar na pele” de uma distro para executar comandos de recuperação. — Ele encontrou todas as distros instaladas no PC, inclusive o antigo MX-23 e o novo MX-25.

Fazer chroot manualmente é chato. — Com esse aplicativo do MX Linux, é um passeio no parque!

“Entrei” no MX Linux 25 (o termo é “visitar”), recém-instalado. — O prompt muda de “$” para “chroot>”:

Gerando o arquivo /boot/grub/grub.cfg no recém-instalado MX Linux 25.1

Executei uma “atualização do Grub”. — Gosto de usar o comando “real” (em vez do “alias” update-grub), para nunca esquecer o que ele faz. — Trata-se de gerar o arquivo /boot/grub/grub.cfg:

chroot> grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found theme: /boot/grub/themes/mx_linux/theme.txt
Found linux image: /boot/vmlinuz-6.12.63+deb13-amd64
Found initrd image: /boot/initrd.img-6.12.63+deb13-amd64
Found Arch Linux (rolling) on /dev/sda3
Found Debian GNU/Linux forky/sid on /dev/sda4
Found Fedora Linux 43 (KDE Plasma Desktop Edition) on /dev/sda5
Found PCLinuxOS on /dev/sda6
Found PCLinuxOS on /dev/sda7
Found Mageia 10 (10) on /dev/sdb1
Found Ubuntu 24.04.3 LTS (24.04) on /dev/sdb2
Found Void Linux on /dev/sdb3
Found Linux Mint 22.3 Zena (22.3) on /dev/sdb4
Found PCLinuxOS on /dev/sdb5
Found MX 23.6 Libretto (23.6) on /dev/sdb6
Adding boot menu entry for EFI firmware configuration
done

Ele gerou “entradas” para outras distros — mas o importante é que gerou “entradas” para ele mesmo. — Agora, o Grub do openSUSE já pode ler esse arquivo e obter os dados para carregar o MX Linux 25.1.

Observe que ele não encontrou o openSUSE. — É comum, o Grub de algumas distros não detectar o openSUSE, instalado em uma partição BtrFS com “instantâneos” do Snapper (shapshots). — É por isso que escolhi o Grub do openSUSE para ser meu “Menu de Inicialização” (UEFI / GPT; Bios (legacy) / MBR) — e o do Mageia, meu “Grub de reserva”.

(É por isso, também, que até hoje eu evito instalar mais alguma distro em partição BtrFS com snapshots: — Isso complica meu dualboot / multiboot, em vários outros aspectos).

Grub do openSUSE, “atualizado” para detectar o MX Linux 25.1

Atualizei o Grub do openSUSE — ele detectou a nova instalação — e agora basta usá-lo, para carregar o MX Linux 25.1.

Testando a instalação

Montagem sem pedir senha — e sessão Plasma X11

19:20 a 21:20 - Testei a nova instalação durante umas 2 horas — ainda com a pasta /home criada dentro da partição-raiz. — Demorou um pouco, até conseguir Login automático em sessão X11 — e a montagem automática das demais partições.

Copiando do fstab do MX-23 as linhas das partições Home e Swap

Passei à fase seguinte da minha migração: — Abri o /etc/fstab do MX-23, copiei as linhas referentes às partições Home12 e Swap — e colei no arquivo /etc/fstab do MX Linux 25.1, pelo editor interno do Midnight Commander — “sudo mc”.

MX Linux 25.1 com a /home do antigo MX-23

21:20 a 0:00 - Ao reiniciar o MX Linux 25.1 (Plasma 6) com as configurações da partição /home do MX-23 (Plasma 5), encontrei as falhas normais nessa transição: — widgets (Weather, Moon) precisavam ser trocados por versões compatíveis; o lançador do System Settings precisava ser corrigido etc.

O Login automático caiu em sessão Plasma Wayland, com o Conky sem linhas ou gráficos — e as regras de janelas (KWin) bagunçadas. — Tornei a configurar o SDDM, e depois disso o Login automático passou a entrar sempre em sessão Plasma X11.

Lista dos pacotes instalados pelo usuário no MX-23

19 Jan. 2026 - 1:00 a 2:00 - Ainda carreguei duas sessões do antigo MX-23, para fazer uma última atualização do sistema (para registro); gerar um relatório “Quick System Info”; salvar uma lista dos meus aplicativos (User Installed Packages) etc. — além de listar todos os pacotes instalados — mas evitei mexer nas configurações, que eu já tinha começado a adaptar ao MX Linux 25.1.

Colando a partição Linux13 na partição Linux12

2:00 - Pelo GParted, copiei a partição do MX Linux 25.1 (sdb17) e “colei” na partição onde estava o MX-23 (sdb6). — Depois, deletei o original, para não ficar com partições duplicadas (e com o mesmo UUID). — Tornei a atualizar o Grub do openSUSE, para refletir a nova situação.

Desabilitando os-prober, quiet, splash no /etc/default/grub

20 Jan. 2026 - Desabilitei a detecção de outras distros (os-prober) pelo Grub do MX Linux 25.1. — Basta ele detectar a si mesmo, para que o Grub do openSUSE encontre as informações necessárias.

Aproveitei para desabilitar “quiet” e “splash”, para exibir tudo que acontece durante o boot — ao invés de uma animação bonitinha, que não dá nenhuma informação.

Essas 2 configurações ficam no arquivo /etc/default/grub — que editei pelo Midnight Commander (sudo mc”, no Konsole). — Para fazer efeito, executei o “update-grub”, para gerar o /boot/grub/grub.cfg com as alterações.

Após eliminar 1 distro (MX-23) e reduzir o /boot/grub/grub.cfg do MX-25, o tempo de “atualização” do Grub do openSUSE caiu de 40’’ para 25’’ a 33’’. — Quanto mais distros, e quanto maior o “grub.cfg” de cada distro, mais tempo cada Grub gastará lendo os demais “grub.cfg”, a cada “atualização”. — Por isso, configurei as coisas para que cada Grub detecte apenas sua própria distro (gerando arquivos grub.cfg pequenos); e só o Grub do openSUSE (e o do Mageia, “reserva”) detectem as demais distros.

Limpando as partições EFI

Prioridade de Boot no utilitário da UEFI Bios da minha placa-mãe

23 Jan. 2026 - Dediquei umas 4 horas a testar e botar ordem nos bootloaders “externos”, nas minhas partições EFI (sda1) e EFI2 (sdb16) — e digo “externos” para distinguir do Grub que está “dentro” de uma distro. — Cada bootloader “externo” apenas indica um “dispositivo de inicialização”, controlado por uma distro.

O utilitário UEFI Bios da minha placa-mãe oferece um modo simples e fácil de definir a prioridade de Boot: — Basta escolher uma distro, do lado direito, e arrastá-la para o topo da pequena lista. — Como eu tenho mais de 4 distros, posso clicar em “Switch all”, e a lista se amplia para exibir até 7 ou 8, podendo rolar para ver outras mais embaixo.

Eu parei de usar esse recurso simples e fácil porque, depois de alguns meses, esse utilitário passou a congelar, sempre que clico numa distro e seguro para arrastar. — Desde então, utilizo o aplicativo efibootmgr em linha de comando (CLI), dentro de qualquer distro, para recolocar o openSUSE no topo (e o Mageia em 2º lugar), sempre que alguma atualização ou nova instalação coloca outra distro lá no alto:

# efibootmgr
BootCurrent: 0000
Timeout: 10 seconds
BootOrder: 0003,0000,0009,0006,0010,000D,0011,0013,0015,0002,0016,0001
Boot0000* opensuse      HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\OPENSUSE\GRUBX64.EFI
Boot0001* debian        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\DEBIAN\SHIMX64.EFI
Boot0002* Ubuntu        HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\UBUNTU\SHIMX64.EFI
Boot0003* pclinuxos     HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\PCLINUXOS\GRUBX64.EFI
Boot0006* arch_grub2    HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\ARCH_GRUB2\GRUBX64.EFI
Boot0009* Mageia_grub   HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\MAGEIA_GRUB\GRUBX64.EFI
Boot000D* Void_grub     HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\VOID_GRUB\GRUBX64.EFI
Boot0010* MX_grub       HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\MX_GRUB\GRUBX64.EFI
Boot0011* Fedora        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\FEDORA\SHIM.EFI0000424f
Boot0013* Fedora        HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\FEDORA\SHIM.EFI0000424f
Boot0015* ubuntu        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\UBUNTU\SHIMX64.EFI0000424f
Boot0016* debian        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\DEBIAN\GRUBX64.EFI0000424f
#
# efibootmgr -o 0000,0009,0006,0010,000D,0011,0013,0015,0002,0016,0001,3
BootCurrent: 0000
Timeout: 10 seconds
BootOrder: 0000,0009,0006,0010,000D,0011,0013,0015,0002,0016,0001,0003
Boot0000* opensuse      HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\OPENSUSE\GRUBX64.EFI
Boot0001* debian        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\DEBIAN\SHIMX64.EFI
Boot0002* Ubuntu        HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\UBUNTU\SHIMX64.EFI
Boot0003* pclinuxos     HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\PCLINUXOS\GRUBX64.EFI
Boot0006* arch_grub2    HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\ARCH_GRUB2\GRUBX64.EFI
Boot0009* Mageia_grub   HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\MAGEIA_GRUB\GRUBX64.EFI
Boot000D* Void_grub     HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\VOID_GRUB\GRUBX64.EFI
Boot0010* MX_grub       HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\MX_GRUB\GRUBX64.EFI
Boot0011* Fedora        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\FEDORA\SHIM.EFI0000424f
Boot0013* Fedora        HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\FEDORA\SHIM.EFI0000424f
Boot0015* ubuntu        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\UBUNTU\SHIMX64.EFI0000424f

Acima: - Um exemplo de 2 semanas antes, quando a instalação de um Kernel colocou o PCLinuxOS no topo das prioridades de Boot.

Boot Menu (F8), para escolher um bootloader qualquer

Para teste ocasional de algum bootloader, vou ao “Boot Menu”, pela tecla F8: — Basta usar as teclas (setas) para cima e para baixo, escolher uma distro, e finalizar com Enter. — Isso não altera a prioridade de boot nas inicializações seguintes.

Acima: - Dois bootloaders “Ubuntu”, com maiúscula (Kubuntu); e “ubuntu”, com minúscula (Mint) — além de uma instalação experimental do Fedora, já eliminada há meses, mas cujo bootloader continuava resistindo a todas as tentativas de removê-lo pelo efibootmgr.

Prioridade de Boot no modo Avançado do utilitário UEFI Bios

Enfim, posso alternar entre esse “modo EZ” e o “modo Avançado”, pela tecla F7 — mas ainda falta alguma coisa. — Talvez haja um modo de deletar bootloaders órfãos, mas até agora não consegui encontrar.

Em geral, tento deletar bootloaders inúteis pelo comando “efibootmgr” — mas às vezes eles continuam presentes na partição EFI ou na EFI2 — “visíveis”, ou “invisíveis” no utilitário UEFI Bios:

# history

  489  2026-01-23_13-23-28 efibootmgr
  490  2026-01-23_13-23-40 efibootmgr -b 10 -B
  491  2026-01-23_13-24-03 efibootmgr -b 13 -B

  495  2026-01-23_14-28-21 date; lsblk -o name,mountpoint,label,fstype,size,FSUSED,UUID
  496  2026-01-23_14-29-11 mount /dev/sdb16 /mnt

Foi o caso de um antigo bootloader “mageia” — que substituí em Abril 2025 por “Mageia_grub”, criado pelo comando “grub-install”. — A pasta ainda está lá, embora vazia:

Bootloaders eliminados pelo efibootmgr, ainda nas partições EFI

Para “ver” esses bootloaders persistentes, o jeito que encontrei é examinar minhas partições EFI (sda1) e EFI2 (sdb16— pelo Dolphin (GUI) — ou por comandos (CLI), como o “tree”, por exemplo:

$ tree -U -L2 -D --timefmt '%Y %m %d' /boot/efi         $ tree -U -L2 -D --timefmt '%Y %m %d' /mnt

/boot/efi                      (/dev/sda1: EFI)         /mnt                    (/dev/sdb16: EFI2)

├── EFI                                                 ├── EFI
│   ├── 2020 01 10  -  pclinuxos                        │   ├── 2025 04 08  -  MX_grub       (*)
│   ├── 2025 07 22  -  boot                             │   ├── 2025 04 08  -  Mageia_grub
│   ├── 2020 01 12  -  opensuse                         │   ├── 2025 04 08  -  Void_grub
│   ├── 2025 07 13  -  ubuntu       (*)                 │   ├── 2025 07 13  -  BOOT
│   ├── 2025 12 23  -  fedora                           │   ├── 2025 03 13  -  fedora        (*)
│   ├── 2020 03 24  -  Debian                           │   ├── 2025 08 04  -  mageia        (*)
│   └── 2023 03 06  -  arch_grub2                       │   ├── 2025 07 13  -  ubuntu        (*)
├── System                                              │   └── 2025 12 28  -  pclinuxos
│   └── Library                                         ├── System
├── System Volume Information                           │   └── Library
└── mach_kernel                                         ├── System Volume Information
                                                        └── mach_kernel
12 directories, 1 file
                                                             13 directories, 1 file

Acima: - Editei as respostas do comando, deixando só as datas das pastas dos bootloaders, para facilitar a visualização.

Pude constatar que, embora o utilitário UEFI Bios e o comando “efibootmgr” mostrem um bootloader “Ubuntu” com maiúscula, lá nas partições EFI a pasta é “ubuntu” com minúscula. — O único modo de distinguir, é lembrando que o bootloader do Kubuntu é o da partição EFI2 (sdb16, no SSD WD Green); enquanto o do Mint é o da partição EFI (sda1, no SSD Kingston).

Deletando antigos bootloaders pelo Midnight Commander (mc) em modo root

Como último recurso de limpeza, abri o Midnight Commander como super-usuário (root) — e deletei as pastas dos bootloaders que não tinham mais nenhuma utilidade: — O 2º “fedora”, o “mageia”, e o “MX_grub” de Abril 2025, agora sem utilidade.

Configurando “Timeout” no Grub do Kubuntu

Ao testar todos os bootloaders, verifiquei que o Kubuntu e o Mint carregavam diretamente, sem exibir o menu do Grub. — Comentei (desabilitei) as linhas “GRUB_TIMEOUT_STYLE=hidden”; configurei o “GRUB_TIMEOUT=10”; e aproveitei para eliminar “quiet splash” em ambos. — Depois, “update-grub”, em ambos, para o Grub do openSUSE ler e incorporar essas mudanças.

A duplicidade de entradas para o Debian, no utilitário UEFI Bios e no efibootmgr, corresponde a 2 opções de Boot, dentro da mesma pasta: — “SHIMX64” e “GRUBX64”. — Não tenho (nem pretendo ter) Windows, e não uso Secure Boot. Vou deletar o “shim”, depois de ler mais um pouco sobre isso.

Depois de esclarecer todas as dúvidas e capinar o matagal de coisas sem utilidade, criei o bootloader para o MX Linux 25.1:

Pasted to /etc/fstab:

UUID=B7B0-A50B /boot/efi vfat noatime,dmask=0002,fmask=0113 0 0

$ sudo mkdir -p /boot/efi

$ sudo mount -all

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

Fiz mais algumas anotações sobre isso no registro sobre o Fedora 42; e no registro da minha transição para UEFI-GPT.

Links úteis

Manual do Usuário do MX Linux 25

xxxx

___________________
• Publicado em 20 Janeiro 2026; e desenvolvido até...

— … ≠ “•” ≠ … —

MX Linux

PC desktop UEFI / GPT