Dual boot em drives separados com systemd-boot — o que aprendi tentando não quebrar o PC

1. O problema — rEFInd e a saga dos temas

Sempre quis um gerenciador de boot com cara boa. Fui de rEFInd, que promete tudo isso, mas na prática virou uma fonte constante de dor de cabeça: temas que não carregavam, ícones errados de distro, entradas duplicadas de instalações antigas que eu não usava mais. Tentei configurar, tentei temas diferentes, tentei ajustar manualmente — e com tempo limitado para isso, o negócio nunca ficava como eu queria. Fiz uma breve pesquisa sobre o GRUB, mas ia me demandar tempo que prefiro gastar jogando do que pesquisando e tentando fazer funcionar do jeito que quero.

2. O cenário — dois drives físicos separados

Tenho dois drives de armazenamento: um NVMe de 1TB com CachyOS e um SATA de 512GB com Windows 11. Cada sistema no seu próprio drive, sem partilhar espaço. No Windows, o NVMe está desmontado e sem drivers instalados — o windows sequer o enxerga. No CachyOS, consigo ver o drive SATA, mas mantenho desmontado para não escrever nada por acidente.

3. Por que systemd-boot

A ideia era ter um gerenciador simples, direto, sem precisar ficar martelando teclado e entrar pela interface da BIOS para alternar entre sistemas. Sem tema elaborado, sem firula — só funcionar. O systemd-boot encaixa exatamente nisso, e o CachyOS já vem com o systemd-boot-manager que automatiza a geração de entradas de kernel. Menos coisa para configurar na mão, menos coisa para quebrar.

4. O que eu fiz

Primeiro rodei o lsblk -f para mapear como estavam os drives:

icou claro: o NVMe com CachyOS tem a EFI montada em /boot, e o SATA do Windows tem sua própria partição EFI em sda1. O systemd-boot vive no NVMe — precisava trazer o Windows pra dentro dele.

Montei a EFI do Windows:

sudo mkdir /mnt/win-efi
sudo mount /dev/sda1 /mnt/win-efi

Confirmei que a pasta Microsoft estava lá e copiei pro ESP do CachyOS:

sudo cp -r /mnt/win-efi/EFI/Microsoft /boot/EFI/

Criei a entrada manual do Windows:

sudo nano /boot/loader/entries/windows.conf

title   Windows 11
efi     /EFI/Microsoft/Boot/bootmgfw.efi

Aproveitei pra ajustar o timeout no loader.conf — 5 segundos é pouco pra selecionar o sistema com calma no sofá:

sudo nano /boot/loader/loader.conf

Mudei pra timeout 15.

Reiniciei — e apareceram dois Windows no menu. O firmware já tinha uma entrada automática, e eu criei uma segunda. Rodei o bootctl list pra entender:

(O print abaixo é após eu ter corrigido a entrada manual, infelizmente esqueci de printar as duas entradas do windows.)

sudo bootctl list

A entrada auto-windows já vinha do firmware e é mais confiável. Removi a que criei manualmente:

sudo rm /boot/loader/entries/windows.conf

Reiniciei de novo e o menu apareceu limpo:

O resultado final foi exatamente o que eu queria: um menu simples, sem frescura, que aparece no boot e me deixa escolher entre CachyOS e Windows 11 sem precisar entrar na BIOS.

O systemd-boot não tem auto-detecção de outros drives como o GRUB — mas isso que achei que seria um problema virou vantagem. A configuração é manual, feita uma vez só, e você sabe exatamente o que está lá. Sem os-prober rodando em segundo plano Sem Grub-Customizer pra deixar rastros que se acumulam com o tempo, sem arquivo de configuração verboso pra manter, sem risco de uma atualização resetar tudo.

Se você está pensando em configurar dual boot e cogitando o GRUB porque “é o que todo tutorial usa” — vale considerar o systemd-boot antes. Especialmente se usar CachyOS, que já vem com o systemd-boot-manager gerenciando as entradas de kernel automaticamente. Você configura o Windows uma vez e esquece.

O único ponto de atenção é o Windows Update — em atualizações grandes ele pode mexer nas entradas EFI. Se isso acontecer, é só repetir os passos de copiar a pasta Microsoft pro ESP do CachyOS. Nada que assuste.

Rapaz, que post sensacional, pedrozord :speech_balloon: ! O seu relato é utilidade pública de altíssimo nível para quem quer fugir da complexidade desnecessária do GRUB ou dos bugs visuais do rEFInd. Parabéns pela didática, pelos prints e por compartilhar a sua saga de forma tão clara!

O systemd-boot é, sem dúvidas, uma das soluções mais elegantes e modernas que temos hoje no ecossistema Linux. Como você bem pontuou, a simplicidade de não ter um os-prober rodando em segundo plano e a ausência daqueles arquivos de configuração gigantescos do GRUB (que dão até medo de editar) trazem uma paz de espírito absurda para quem faz dual boot.

Sobre a sua saga com as entradas duplicadas do Windows, você acabou esbarrando em um comportamento nativo e fantástico do systemd-boot: ele possui detecção automática para o Windows, desde que os arquivos de boot da Microsoft estejam na mesma partição EFI (ESP) que ele.

Quando você rodou o comando para copiar a pasta EFI/Microsoft para dentro do ESP do CachyOS, o systemd-boot escaneou o diretório /EFI/Microsoft/Boot/bootmgfw.efi no momento do boot e criou a entrada auto-windows sozinho! Por isso que a sua entrada manual em windows.conf acabou ficando duplicada. É por essa e outras automatizações silenciosas que ele é tão prático: você só precisa jogar os arquivos lá dentro e ele faz a mágica sem que você precise escrever uma linha de texto.

O CachyOS acertou em cheio ao adotá-lo como padrão junto com o systemd-boot-manager. Para quem tem dois drives separados, essa sua abordagem de centralizar os arquivos de boot no NVMe principal é a receita ideal para um sistema robusto.

Mais uma vez, parabéns pelo guia ‘vapt-vupt’. Esse tópico com certeza vai salvar muita gente que quer um dual boot limpo, minimalista e direto ao ponto. Fixado nos favoritos aqui! :penguin::rocket:

@Danilo_Machado muito obrigado, dediquei um certo tempo criando e revisando esse post para seguir de “norte” para quem precisar.
Lembrando que alguns ajustes se fazem necessários de acordo com cada setup de máquina.

Boa explicação! Eu não sabia exatamente o porquê da entrada duplicada — fazia sentido que fosse algo automático, mas não tinha parado pra entender o mecanismo. Agora ficou claro: ao copiar a pasta EFI/Microsoft pro ESP do CachyOS, o systemd-boot já detecta o bootmgfw.efi sozinho e cria a entrada auto-windows automaticamente. O windows.conf manual era desnecessário desde o início.

@pedrozord Parabéns pela exposição simples, organizada, clara – e obrigado pelas dicas!

Gostaria de entender a “malignidade” do os-prober – e deste detalhe: – “rodando em segundo plano”:

já favoritei, para encontrar com facilidade no futuro. – Não uso systemd-boot, mas existe “alguma coisa dele” no BLS do Fedora.

@frc_kde Confesso que me inspirei na forma em que você faz suas postagens e seus relatos, e fico muito feliz que sirva de ajuda num futuro próximo.

Agora sobre o os-prober: é uma ferramenta do GRUB que escaneia todos os drives em busca de outros sistemas operacionais toda vez que você roda o grub-mkconfig pra atualizar o menu. E o problema recorrente que andei vendo por aí é que diversas vezes ele cria entradas duplicadas.

Não é raro achar relatos disso nos fóruns do Manjaro, Arch, Mint… o problema é recorrente há anos.

@pedrozord agradeço a “inspiração”, he he!

Essa “duplicação” não é do Grub – mas sim, do “Grub-Customizer” – que é um pacote de terceiros, e existem muitas recomendações para não usá-lo.

Veja os links que você postou:

No Fórum do Arch:

  • Grub-Customizer creates duplicate entries in grub.

No Fórum do Mint:

  • Multiple and Duplicated Grub Menu items: Grub Customiser Problems

No Fórum do Manjaro, tem esse link:

  • Grub conflicts with grub-customizer

Eu usei o Grub-Customizer – acho que em 2014 – e 4 anos depois meu Grub estava totalmente enlouquecido. Fiz umas anotações aqui.

Ele cria uma sub-pasta, difícil de entender – e mesmo que você desinstale, os efeitos continuam se propagando e multiplicando. – No meu caso, após 4 anos virou uma avalanche.

Nunca mais usei o Grub-Customizer – e já fazem 8 anos que não tive mais nenhum problema desse tipo.

Quanto ao “os-prober”, eu desativo em todas as distros – exceto no openSUSE, que é o Grub que eu uso.

Nas outras distros, basta o Grub de cada uma detectar ela mesma – para o Grub do openSUSE extrair os dados necessários.

Mas, você resolveu seu problema – e não há razão para voltar a usar o Grub.

@frc_kde Obrigado pela correção, não fiz a distinção na hora, e agora com sua orientação e com mais calma vi o erro que cometi, sendo que o verdadeiro culpado é o Grub-Customizer.
Acessei seu link, e o seu relato me assustou, quase 90 mil linhas!

Vou aproveitar e corrigir o post, muito obrigado pela observação!

Agora, fiquei curioso pra ver a situação atual dos meus Grubs…

/boot/grub*/grub.cfg
-----------------------------------------------------------------------------------------------------
     distro       size   lines              date         kernel      events
     ------       ----   -----              ----------   ------      ----------
01 - openSUSE    48606     980   os-prober  2026-05-31
02 - Arch         7216     217              2023-03-06   linux-lts   2023-03-06   pacman -S linux-lts
03 - Debian       8703     260              2026-05-31
04 - Fedora       8967     274              2026-05-31
06 - PCLinuxOS   10454     290              2026-05-23
07 - Mageia      69452    1320   os-prober  2026-05-24
09 - Void         6591     194              2026-05-24
11 - Artix        6227     215              2026-04-11   linux       2026-04-07   distro installation
12 - Mx25         8370     244              2026-05-31
-----------------------------------------------------------------------------------------------------
  • O grub.cfg do openSUSE – que é meu “Menu de inicialização” – está com menos de 1 mil linhas.

  • O do Mageia – meu “Menu de emergência” – está com 1.320 linhas.

  • Os outros – com os-prober desabilitado – estão com +/- 200 a 300 linhas.

As datas correspondem +/- às últimas atualizações – nos Domingos de 24 e 31 Maio, quando cada distro recebeu sua atualização de Kernel mais recente.

  • Às vezes começo no Sábado após 21:00, para adiantar – aproveitando que “em Londres, já é amanhã”.

Exceções são o Arch Linux e seu “derivado” Artix – que nunca atualizam o grub.cfg, a menos que você mude de Kernel – “linux”, “linux-lts” etc.

O Arch Linux não coloca “numeração” no “nome-de-arquivo” do Kernel – por isso, não precisa atualizar o Grub, jamais! (As “opções avançadas” são, apenas, “fallback”). – Mais um fator (entre vários outros), para as atualizações do pacman serem tão rápidas.

  • Em Março 2023, troquei o Kernel corrente “linux” pelo “linux-lts”, no Arch. – Foi a última vez que atualizou o grub.cfg.

  • Instalei o Artix em 7 Abril – mas só no dia 11 lembrei de desabilitar os-prober – e atualizei o grub.cfg.