Dúvida: Porque o Pop_OS Não facilita dual... boot?

Existe algum motivo do Pop OS não simplificar mais o dual boot como os outros sistemas Linux fazem que eu desconheço? Tipo, também uso o Windows 10 para algo específico(Jogos), mas quando testo o Pop OS é o único em que o os-prober é todo complicado, tem que editar o arquivo de configuração pra ele reconhecer outros sistemas pelo próprio GRUB sem precisar usar o F12. Não sou leigo em Linux, mas gostaria de saber que só o Pop OS “cria” essa dificuldade.

Sim, existe: ele por sí só já é o suficiente, não precisa de outro OS.

3 curtidas

Talvez queiram monopolizar apenas a distro dele em detrimento de outras, ou mesmo de outros sistemas como do Windows. Eu não sei exatamente o real motivo, mas acho que deveriam dar a opção em alguma parte do instalador, tipo, “opções avançadas de particionamento”, algo assim.
A não possibilidade de fazer dual-boot de forma fácil pode fazer muita gente simplesmente perder o interesse na distro.

1 curtida

Olá @brunnometal, tudo bem contigo?

Existe um motivo técnico para isso, o Pop!_OS utiliza o SystemD-Boot ao invés do GRUB em seu processo de inicialização, é por isso que não é possível detectar outros sistemas durante o boot. Você pode mudar isso manualmente substituindo o SystemDBoot pelo Grub.

:vulcan_salute:

5 curtidas

Na verdade nao precisa substituir o SystemDBoot, da pra adicionar o Windows nele e fazer dual boot tranquilamente, nesse tópico eu postei um passo a passo, você precisa copiar a pasta boot do Windows pra dentro da pasta boot do Pop.

1 curtida

Bem conspiratória essa frase haha :rofl:

Na real o motivo é simples, o Pop não usa o GRUB, usa outro bootloader. O systemd-boot, ele é mais rápido que o GRUB, e não podemos esquecer que o Pop vem pré-instalado com os computadores deles, e nessas máquinas, remover esse componente evita certos problemas de segurança e deixa o boot mais rápido.

É uma forma simples de deixar o produto deles melhor.

Apesar disso, há como fazer dual boot com qualquer sistema usando o Systemd-boot, só funciona de uma forma diferente do GRUB.

Além disso, há outras formas de fazer dual boot. Eu tenho o Pop em Dual Boot com o Tuxedo num PC, e com Windows em outro, cada sistema instalado num SSD diferente, e seleciono o sistema que eu quero dar boot pela F8 da BIOS. É uma situação particular, mas é possível também.

Particularmente, sempre que possível eu prefiro deixar o dual boot sendo gerenciado pela própria BIOS do que depender de um bootloader instalado no disco.

Também acho que um dual boot facilitado seria bem-vindo, mas é contornável.

1 curtida

Pop_OS na verdade é feito para os hardware proprietários da system76
geralmente quem vai adquirir hardware deles, são quem vai usar exclusivamente o Pop_OS

Hahaha, perdão pela ideia conspiranóica, mas é que tipo, não uso o Pop e não sei muito das motivações para que não tenha essa opção. Ao meu ver, não custaria nada ter essa opção assim como outras distros que auto-detectam o Windows e fazem tudo no automático, como no mínimo deixando você escolher o tamanho da partição.

Eles poderiam disponibilizar uma versão que tivesse GRUB para pessoas que pretendem usar a distro deles em outros dispositivos sem ser os deles, que claramente vem de fábrica com a distro pré-instalada ou então tentar adaptar uma forma desse systemd-boot funcionar como o GRUB permitindo o dual-boot.

Não disse que não existia uma forma de fazer, no mundo Linux quase tudo é possível de se fazer, mas provavelmente não é algo tão fácil a um clique, como seria se estivesse na distro.

Sim, mas tem muitos que simplesmente usam a distro sem nem ter comprado os hardwares deles, ainda mais no Brasil que seria um rim importar, ainda mais agora com esse tanto de imposto.

Pois é, já testei a distro umas 2 vezes, e o que mais me afastou dela foi exatamente isso, inclusive formatei o PC faz 2 dias, e acabei optando pelo Debian mesmo, já que não precisa fazer todo um arrudeio pra fazer algo tão simples aparecer logo de cara.

1 curtida

Cheguei a olhar essa matéria e conheço o Grub-Customizer, mas depender de ferramentas de terceiros pra isso. Eles deveriam dar a opção de durante a instalação utilizar o GRUB ou o SystemDBoot. Mas já desisti da idéia de usar ele e instalei o Debian 12 mesmo, que está sumpimpa :ok_hand:

Caramba… Nem lembrava mais desse “pequeno problema” do Pop!_OS.

Googlei “popos dualboot”, encontrei um tópico daqui do Fórum, o tópico me encaminhou para outros 2 tópicos… e foi quase uma viagem a outro mundo:

  • systemd-boot
  • exigência de 512 MB de espaço na partição EFI
  • necessidade de instalar o Grub, os-prober, Grub Customizer e mais algumas coisas, caso queira substituir

Já usei o Grub Customizer, acho que em 2016. – Depois de instalar nova versão LTS do Kubuntu (ou do Mint?), parei de usar – mas alguma coisa dele ficou, em algum lugar (em alguma distro não-reinstalada) – e em 2018 meu Grub enlouqueceu de vez (já então com 12 distros). – Demorava uns 4 minutos para atualizar, e como o apt / Synaptic atualiza o Grub umas 3 vezes seguidas ao instalar / remover revisões do Kernel, minha vida acabou ficando complicada.

Tempos depois, vi que o Manjaro (?) fazia advertências contra o Grub Customizar – então, fiz uma “experiência controlada”, só para “ver” como ele opera. – Ele cria um sub-diretório, cheio de coisas difíceis de entender, e parece que isso não é removido, quando ele é desinstalado.

Acho importante lembrarmos essa “contra-indicação”, sempre que sugerimos instalar e usar o Grub Customizer. – Ele deixa “pegadas” difíceis de eliminar, depois – pois em geral a gente substitui 1 distro, mas quando temos 2 distros, raramente substituímos a outra, no mesmo dia.

O Grub, por si só, já é uma coisa bastante complicada, a longo prazo, mas me acostumei a lidar com ele, sem recorrer a um software que acrescenta camadas adicionais de complexidade. – Sei que parece difícil e chato, quando se propõe editar 2 ou 3 arquivos-de-sistema (eu também achava, nos primeiros anos usando Linux), mas acaba sendo mais “simples” e menos problemático, a longo prazo.

Nunca experimentei instalar o systemd-boot, nem o rEFInd, nem outras alternativas ao Grub. – O Grub não é perfeito, mas pelo que li até agora, nenhum outro oferece tantos recursos, flexibilidade etc. – Sei que o Grub do Debian, dos Buntus, Mint, KDE Neon etc. vem “incapaz” de detectar ou gerar entradas corretas para carregar o Arch, o Manjaro, o openSUSE em partição BtrFS (pelo menos, até a última vez que verifiquei), mas basta “escolher” o Grub do Arch (ou do Manjaro, ou do openSUSE), como “Menu de inicialização”.

(Apenas, lembre de atualizar o Grub do Arch, pois ele não faz isso! – Já vi o Grub do Arch ficar inalterado por mais de 6 meses. – Se você vai usá-lo como Menu de Inicialização, e tem outras distros, o jeito é atualizar manualmente o Grub do Arch, ou do Manjaro).

Ter 2 distros significa que você tem 2 Grub’s – e acho muito mais simples e rápido, apenas usar “o outro Grub” – do que teclar DEL, F8, F12 etc. para entrar na UEFI Bios Utility, a cada boot.

O Grub de uma distro não consegue lidar com o Manjaro? – Passe a usar o Grub do Manjaro! – Em poucos segundos você chega ao “Menu de inicialização”, sem perder tempo, nem ficar tendo trabalho adicional.

Enfim, vejo muitos colegas indicarem Pop!_OS, Zorin etc. aos iniciantes. – Não faço isso, só porque nunca usei essas distros, e seria irresponsável indicar uma distro, para a qual não posso oferecer qualquer ajuda. – Mas essa questão do boot do Pop!_OS me faz ficar com um pé atrás. Isso não é nada “amigável” para um iniciante enfrentar… e instalar o Grub Customizer é algo que eu não recomendaria.

Eu também já remoí “teorias conspiratórias” contra esse negócio de o Arch fugir ao “padrão” que o Grub do Debian, Kubuntu, Mint, KDE Neon conseguem “entender”. – Isso é normal. Tudo que nos frustra, tende a alimentar em nós alguma ideia de que “estão contra mim”.

Algum tempo atrás, o Fedora apareceu com uma outra “invenção” – o tal do BLS (Boot Loader Specification), que não é “entendido” pelo Grub de outras distros. – O Fedora instalava uma nova revisão de Kernel, e quando eu tornava a carregá-lo (pelo Grub de outra distro), levava dias, até perceber que estava usando o Fedora com um Kernel anterior! – Tudo bem. Desabilitei o BLS do Fedora – e agora, faço a atualização do Fedora pelo DNF; e logo em seguida já faço manualmente a atualização do Grub dele.

A regra é: – O Grub de uma distro apenas “lê” as informações do Grub das outras distros. – Se alguma delas não atualizou seu próprio Grub, o Grub da outra não irá “descobrir”, nem corrigir isso.

Ah, o Grub do Slackware também precisa de 1 “pequena mexidinha”, para usar o parâmetro “huge” – caso contrário, o Grub de outras distros não conseguirá carregá-lo.

Desde quando aprendi a ter esses “pequenos cuidados”, já tem alguns anos que não tenho “problemas de Grub”, com minhas 12 distros – cada uma, mais “diferente” das outras.

Uso o Grub do openSUSE – e mantenho o do Mageia (o 2º melhor) como “reserva”. – Nas outras distros, desabilito o os-prober, porque basta o Grub de cada uma detectar a si mesma (para serem detectadas pelo do openSUSE), sem ficar perdendo tempo, pois não vou usá-los como Menu de Inicialização.

1 curtida

As motivações é bem simples, o POP OS e feito e otimizado para computadores e notebooks que eles vendem e preferem utilizar o systemd para gerenciar o boot por questão de performance e por ser “mais pratico e simples” de lidar.

Até poderiam mais não é o foco deles (eu mesmo não o faria) e outras distros estão seguindo o mesmo caminho como o Twmbleweed esse mês também migrou para o systemd-boot.

Curiosamente os hardwares não são proprietários. É uma empresa que costuma fazer open hardware também, além de open source. Apenas as coisas que não dependem diretamente deles, como os firmwares da Intel ou drivers da NVIDIA é que são fechados.

Eles nem usam uma BIOS tradicional nos PCs deles, usam o Coreboot.

1 curtida

Fazendo isso eles só estão perdendo uma parcela de usuários que poderiam estar usando a distro, mas não o fazem porque não há como fazer dualboot.

https://wiki.archlinux.org/title/systemd-boot

See the Boot Loader Specification for details on all configuration options.
systemd-boot will automatically check at boot time for Windows Boot Manager at the location /EFI/Microsoft/Boot/Bootmgfw.efi, UEFI shell /shellx64.efi and EFI Default Loader /EFI/BOOT/bootx64.efi, as well as specially prepared kernel files found in /EFI/Linux/. When detected, corresponding entries with titles auto-windows, auto-efi-shell and auto-efi-default, respectively, will be generated. These entries do not require manual loader configuration. However, it does not auto-detect other EFI applications (unlike rEFInd), so for booting the Linux kernel, manual configuration entries must be created.
Tip:

The available boot entries which have been configured can be listed with the command bootctl list.
An example entry file is located at /usr/share/systemd/bootctl/arch.conf.
The kernel parameters for scenarios such as LVM, LUKS, dm-crypt or Btrfs can be found on the relevant pages.

Note: If external microcode initramfs images are used (e.g. when using Booster as the initramfs generator), /boot/amd-ucode.img or /boot/intel-ucode.img must be specified in a separate initrd and always be placed first, before the main initramfs image

Não sei se é diferente no Pop-OS mas pelo que pude apurar, totalmente possível… Só parece que a partição de boot tem que ser a mesma, só que isso não é uma tarefa fácil por assim dizer, qualquer erro e tu não vai mais bootar em sistema nenhum, vai ter que recorrer a um Live CD pra consertar

É só copiar os arquivos da partição de boot do Windows para a partição do PopOS, você vai conseguir usar o próprio systemd-boot pra fazer o dual boot:

1 curtida

Essa pra mim é uma questão séria… Existe uma solução “milenar” para dar boot em um sistema linux, e que funciona universalmente. É claro que a tecnologia avança, mas pra mim não passa de overengineering por parte do systemD fazer algo como um bootloader, que ainda por cima quebra compatibilidade com o modo tradicional de fazer as coisas.

Toda vez que leio algo sobre o systemD sendo mais que um init system é disso que estão falando, de como ele dificulta a forma tradicional de se fazer as coisas. E mesmo na sua missão principal que é ser um sistema de inicialização não é difícil encontrar relatos de desenvolvedores linux que se sentem frustrados em ter que trabalhar com o systemD não seguindo o padrão como init systems funcionam.

É claro que o systemD é hegemônico e tem o poder de introduzir ou mesmo forçar novos padrões, mas pra mim não faz sentido uma fabricante de computadores outsider no mercado complicar uma coisa que a maioria dos usuários linux já sabe como funciona. Ainda que se argumente que o systemD-boot é mais rápido, o quão mais rápido ele tem tem que ser pra valer a pena substituir a forma padrão de se fazer as coisas por ele (especialmente quando sua instalação está em um ssd m.2 moderno).

Esse problema do bootloader é facilmente “resolvível”, mas caso essa substituição não tivesse sido feita não haveria o que se resolver em primeiro lugar. A system76 escolhe o que é melhor pra ela, mas como usuário não tenho como deixar de expressar minha insatisfação com a escolha.

1 curtida

Não creio que seja uma parcela significativa. Almém do mais, @brunot já deu a dica.

Não sei sobre dualboot com outras distros mas depois que entendi o sistema de boot do Pop!_OS acho a coisa mais simples que tem realizar um dualboot entre Pop e Windows e ainda com a certeza que o Windows não irá tocar na configuração de boot.