7 Coisas que Ninguém Te Conta Sobre Dual Boot de Linux e Windows

[msteles]

Tradução do artigo:

7 Things Nobody Tells You About Dual Booting Linux and Windows

7 Coisas que Ninguém Te Conta Sobre Dual Boot de Linux e Windows

Você está considerando fazer um dual boot com Linux e Windows? Quer jogar pelo seguro e evitar possíveis armadilhas antes de mergulhar de cabeça? Depois de uma década quebrando e consertando minhas configurações de multi-boot, compilei sete verdades cruciais que ninguém te conta sobre dual boot. Embora o dual boot não seja a coisa mais tecnicamente desafiadora, ele pode apresentar alguns problemas ao longo do caminho se você não souber o que está fazendo. Felizmente, você tem a mim, e eu venho usando um sistema multi-boot há uma década agora. Não se contente com apenas um sistema operacional. Eu já quebrei minha configuração tentando fazer mudanças, e já vi ela desmoronar quando eu só queria assistir YouTube. Então, falando por experiência, aqui estão sete coisas que eu gostaria de ter sabido antes de criar um sistema de dual boot — que ninguém me avisou!

1. A Ordem de Instalação Importa

Ao montar um PC com dual boot, a ordem em que você instala os dois sistemas operacionais é crucial. Instale o Windows primeiro e, em seguida, o Linux. Isso ocorre porque o Windows sobrescreve o gerenciador de boot (geralmente o GRUB no Linux) se instalado depois, ignorando completamente o Linux e tornando mais difícil recuperar o acesso ao seu sistema Linux sem esforço extra. Se você instalar o Linux primeiro e depois o Windows, terá que reinstalar ou reparar o GRUB manualmente para restaurar a opção de escolher entre os sistemas na inicialização. Planeje com antecedência e comece com o Windows para evitar dores de cabeça.

2. Você Não Pode Acessar Facilmente os Arquivos do Linux a Partir do Windows

O Windows não suporta nativamente Ext4, XFS e Btrfs, os sistemas de arquivos mais comuns do Linux. Assim, se seu fluxo de trabalho exige que você acesse arquivos armazenados na partição Linux a partir do Windows, precisará instalar ferramentas de terceiros. Há uma solução melhor — que é o que eu faço — criar uma partição de dados compartilhada e formatá-la em NTFS ou exFAT, para que ambos os sistemas operacionais possam acessá-la. Se eu quero que um arquivo esteja disponível para ambos os sistemas, eu o mantenho nessa partição e pronto. Acesse seus arquivos Linux a partir do Windows, e vice-versa.

3. O Relógio do Sistema Pode Ficar Bagunçado

Isso me pegou desprevenido quando comecei a fazer dual boot. Toda vez que eu trocava entre Linux e Windows, o relógio do sistema estava errado em um dos sistemas operacionais — geralmente por várias horas. Isso acontece porque o Windows trata o relógio de hardware como horário local, enquanto o Linux o considera UTC (Tempo Universal Coordenado) por padrão. Você pode corrigir isso ajustando o Linux para usar o horário local ou fazendo o Windows usar UTC, mas é um detalhe irritante que ninguém menciona até você perceber que seus horários estão desalinhados.

4. O Secure Boot Pode Complicar as Coisas

O Secure Boot, um recurso de segurança UEFI, pode bloquear o carregamento de gerenciadores de boot do Linux que não sejam assinados por uma chave reconhecida pela Microsoft. Infelizmente, a maioria das distribuições Linux, especialmente as comunitárias, não possui a infraestrutura para ter gerenciadores de boot assinados. Por isso, elas são bloqueadas pelo Secure Boot. Você tem duas opções: manter o Secure Boot ativado e usar apenas distribuições suportadas por grandes empresas, como Ubuntu ou Fedora, que possuem gerenciadores assinados, ou desativar o Secure Boot e usar qualquer distribuição que desejar, mas deixando o Windows vulnerável a ameaças no nível de inicialização. A escolha é sua, mas se optar por desativar o Secure Boot, eu aconselho manter seus dados sensíveis no lado Linux da configuração. O Linux é menos visado por malware. Assim, mesmo com o Secure Boot desativado, seus arquivos mais importantes permanecem, em teoria, mais protegidos. O Linux tem seus benefícios de segurança, mas você ainda pode tomar algumas medidas para torná-lo ainda mais seguro.

5. Você Provavelmente Vai Usar Um Sistema Mais do Que o Outro

Configurei sistemas de dual boot para muitos amigos, e o padrão é quase universal — eles acabam vivendo em um sistema operacional cerca de 90% do tempo, fazendo o dual boot parecer questionavelmente válido dado o espaço em disco e a complexidade que ele adiciona. A melhor solução que tenho para esse problema é dedicar cada sistema operacional a uma tarefa específica. Por exemplo, eu uso o Linux como meu sistema pessoal. É onde tenho todos os meus projetos e arquivos pessoais. Acessos minha conta bancária pelo Linux, faço minha declaração de impostos e também acesso minhas redes sociais. Dessa forma, o Windows vira meu sistema de trabalho por padrão. Ele tem todo o software necessário para o trabalho. Quando faço chamadas de vídeo, meus colegas não ficam confusos com designs de desktop excêntricos. Além disso, mantenho uma barreira digital entre meus casos de uso pessoal e profissional. Essa abordagem baseada em tarefas dá a cada sistema operacional um papel claro. Dito isso, se você ainda assim usar apenas um sistema 90% do tempo, a virtualização pode ser uma alternativa melhor.

6. Atualizações do Windows Podem Quebrar o GRUB

O Windows tem um hábito desagradável de sobrescrever o GRUB durante grandes atualizações, como atualizações de recursos ou reinstalações. Quando isso acontece, você inicializa diretamente no Windows sem a opção de escolher o Linux — até que você reinstale ou repare o GRUB a partir de um live USB do Linux. Isso não acontece toda vez, mas é comum o suficiente para ser um risco real. Faça backup do seu gerenciador de boot ou mantenha um USB de reparo à mão para esses momentos.

7. É Mais Fácil Dizer do Que Fazer

A ideia por trás do dual boot é usar ambos os sistemas operacionais igualmente e maximizar a produtividade. Mas, na prática, gerenciar dois sistemas em uma máquina pode ser complicado. Você terá que lidar com particionamento de disco, resolver conflitos de inicialização e, às vezes, vasculhar fóruns para corrigir problemas inesperados. Não é impossível, mas exige mais esforço do que apenas instalar um único sistema operacional e seguir em frente. Se você não está pronto para um pouco de manutenção, o dual boot pode não ser para você.

O dual boot pode ser uma configuração poderosa para aqueles que realmente precisam de ambos os sistemas operacionais, mas vem com complexidades e compromissos que não são imediatamente óbvios. Espero que meus anos de experiência como um usuário de dual boot Windows-Linux tenham te dado alguma compreensão dos possíveis problemas que você pode esperar, para que você saiba como evitá-los e esteja preparado desde o início.

Por Dibakar Ghosh

[frc_kde]

Se o Dibakar Ghosh tivesse me perguntado, eu podia ter contado o que ninguém contou a ele…

@msteles

Dibakar Ghosh

… afinal, faço dualboot há 18 anos.

@msteles

1. A Ordem de Instalação Importa

Isso era muito comentado nos blogs e fóruns, de 2004 a 2007 – quando finalmente instalei meu primeiro “Linux” (Kurumin), após vários anos lendo revistinhas, tutoriais, e acompanhando as discussões.

Bom, talvez ele não tenha se informado o suficiente, e mergulhou sem planejar com antecedência.

@msteles

2. Você Não Pode Acessar Facilmente os Arquivos do Linux a Partir do Windows

Tendo me informado com antecedência, tratei de reinstalar meu Windows, do mesmo modo como eu estava aprendendo que deveria instalar o “Linux” – dividido em várias partições:

• C:\ para o “sistema” (/)
• D:\ para o Swap do Windows – vulgo “Arquivo de Trocas”, ou algo assim
• E:\ – para as páginas, imagens etc. dos meus sites – então em HTML “estático”
• F:\ para “Meus documentos” e demais arquivos pessoais (/home)

Eu salvava tudo em E:\ e F:\ – e quando instalei o “Linux” em dualboot, continuei salvando tudo em E:\ e F:\ – de modo que eu podia acessar e editar meus arquivos, tanto pelo Windows quanto pelo “Linux”.

Em 2007:

A partir de 2009:

Fui aprendendo e alterando – e mais tarde reduzi as 2 partições /home. – Atualmente, são ocupadas principalmente pelas pastas .config, .cache, .wine, .local, e pouca coisa mais:

Deletei meu Windows há 9 anos, em 2016 – mas mantive esse mesmo princípio, ao fazer dualboot de 4 distros, e depois 12 distros – afinal, todas podem ler na /home, umas das outras… mas espalhar arquivos em 4 ou 12 /home não é nada prático, no dia-a-dia:

(Atualmente, “Sites” e “Works” são pequenas partições, só para “guardar o lugar na fila” – e os HDDs de backup ficam desplugados durante a semana. – Tenho mais 143 GiB livres no 2º SSD, enquanto penso em “como reorganizar tudo”).

@msteles

3. O Relógio do Sistema Pode Ficar Bagunçado

Achei mais simples configurar os “Linux” para considerarem o Hardware Clock como “hora local” – pois achei trabalhoso configurar o Windows para considerá-lo “UTC”.

@msteles

4. O Secure Boot Pode Complicar as Coisas

Não cheguei a ter esse problema, pois parei no Windows XP – e no antigo PC, não havia “Secure Boot”.

No hardware atual, minha primeira providência foi desabilitar o Secure Boot – pois só iria instalar distros Linux.

@msteles

5. Você Provavelmente Vai Usar Um Sistema Mais do Que o Outro

Com certeza! – Por inércia (e pressão do trabalho), no começo eu passava 90% do tempo no Windows – pois meu fluxo de trabalho estava adaptado a ele.

Eu não pretendia mantê-lo – mas foi só quando bateu o fim do XP, que investi, de verdade, para reorganizar todo meu fluxo de trabalho para o Kubuntu.

Depois, me tornei “produtivo” também no Mint KDE – e mais tarde, no KDE Neon. – O Debian foi o último que consegui domesticar (embora tentasse desde muitos anos).

Com 12 distros, houve épocas em que usei mais o openSUSE Leap, e mais uma ou outra distro.

Agora, já fazem alguns anos, que fico 99% do tempo no Arch – mas ultimamente passei 1 semana inteira no Fedora, 1 semana no openSUSE Tumbleweed etc. – Continuam firmes e fortes (e produtivos, para mim).

@msteles

6. Atualizações do Windows Podem Quebrar o GRUB

Não lembro de ter tido esse problema – mas a verdade é que era XP, e meu hardware era Bios (Legacy) / MBR.

Imagino que esse problema decorra do UEFI – e das versões recentes do Windows (que nunca usei).

Entre distros Linux, todas se respeitam mutuamente.

Mesmo assim, há 3 ou 4 coisas que aprendi, fazendo multiboot de até 12 distros – aqui e aqui.

@msteles

7. É Mais Fácil Dizer do Que Fazer

A ideia por trás do dual boot é usar ambos os sistemas operacionais igualmente e maximizar a produtividade

Outras ideias são possíveis. – Por exemplo, um dia deletei (por descuido!) a partição do KDE Neon – e na mesma época, um upgrade inutilizou o Mint KDE. – Mas eu ainda tinha o Kubuntu, 100% funcional (além do Debian)… e pude continuar com minhas atividades normais, até encontrar tempo (e disposição) para restabelecer aquelas 2 distros.

Reiniciar, escolher outra distro – e prosseguir com minhas atividades normais, em 2 minutos, como se nada tivesse acontecido – é muito melhor do que entrar numas de “restaurar backup”.

Outra vez, deu tilt numa atualização do openSUSE – e 2 minutos depois eu já estava em outra distro, como se nada tivesse acontecido. – Ainda faltava aprender “o que fazer com os snapshots”, e tratei disso 2 ou 3 semanas depois.

Enfim, dualboot / multiboot pode ser um modo de experimentar outras distros, aprender mais etc. – sem pressa, nas horas de folga – e sem deletar a distro “principal” para começar tudo de novo, numa correria contra o tempo.

[rapoelho]

@msteles

1. A Ordem de Instalação Importa

@msteles

6. Atualizações do Windows Podem Quebrar o GRUB

Mas com a UEFI/GPT, esses problemas não seriam resolvidos?

Pela minha experiência, o Grub e o Boot do Windows ficam em pastas separadas na partição do EFI e são vistos como diapositivos diferentes na UEFI.

@frc_kde

@msteles

5. Você Provavelmente Vai Usar Um Sistema Mais do Que o Outro

Com certeza! – Por inércia (e pressão do trabalho), no começo eu passava 90% do tempo no Windows – pois meu fluxo de trabalho estava adaptado a ele.

Eu não pretendia mantê-lo – mas foi só quando bateu o fim do XP, que investi, de verdade, para reorganizar todo meu fluxo de trabalho para o Kubuntu.

Passei pelo mesmo problema quando estava migrando. Eu até tinha o Dualboot, mas por tudo estar configurado no Windows, eu acabava usando apenas o Windows.

Afinal, as fotos da câmera do meu celular estavam acessíveis de forma fácil e rápida no OneDrive do Windows Explorer, o Epson Scan 2 estava configurado do jeito que eu usava e o XnConvert já estava configurado com as coisas que uso.

Aí vi que um Dualboot não funcionaria. E decidi comprar um notebook, que inicialmente seria um notebook mais fraquinho e que seria apenas para Linux, mas decidi comprar um para substituir o meu velho notebook, que naquela altura do campeonato estava indo para oito anos de uso.

Instalei o Ubuntu no meu novo notebook, mas eu usava ele menos do que queria, pois os meus arquivos estavam no notebook antigo Windows. Mas sempre que possível, eu usava o notebook novo.

Mas a tela do notebooks antigo começou a falhar, até o uso ficar insustentável e com isso, acabei promovendo o notebook novo para principal e migrei de uma vez.

[diogovaladao]

Essa do relógio eu não fazia ideia. Achei que era a bateria, pois meu notebook é muito antigo e nunca troquei, mas não resolveu. Com essa explicação agora eu entendi, agora eu saquei, agora todas as peças se encaixaram.

[Saulo_Ferro_Maciel]

Só verdades, instalei o Windows 11 e tive que desinstalar o Suse pois teve conflito, aí instalei o Ubuntu clássico e agora só uso o Ubuntu e quando me dá vontade de jogar, uso o Windows 11.

[kalebepsouza]

Acho que a dica mais valiosa é desabilitar o SecureBoot. Isso evita muito dor de cabeça. Desativo isso a anos em todas as minhas instalações.

[frc_kde]

Acho que ter de “reiniciar” é chato. – Significa fechar todos os aplicativos e sair de um SO porque ele não tem o que o outro SO tem – e quando entra no outro SO, fica sem o que só o primeiro SO tem. – Para usar o primeiro SO, tem de fechar todos os aplicativos do segundo SO… e assim por diante.

O “ideal”, era poder alternar entre os 2 SOs – como quem alterna entre um aplicativo e outro – mantendo abertos os aplicativos de um SO e do outro, ao mesmo tempo.

Talvez seja o caso de rodar um deles numa VM… mas nunca fiz isso, então não sei se é o caso. – De qualquer modo, precisaria ter o dobro de RAM, pelo menos.

No início dos anos 90, um TI da Câmara ou do Senado ia embora de Brasília e tentou me vender um PCzão que ele tinha – onde alternava entre o Windows, DOS e outro SO – suponho que Unix (ou OS/2?).

Infelizmente, em meados dos anos 90 eu não sabia absolutamente nada, sobre aquela “maravilha”. – Não saberia resolver qualquer problema, que pudesse surgir, depois do cara ir embora para sua terra natal. – Além disso, ele pedia um preço, que percebi ser muito maior, do que cobraria de alguém que entendesse do assunto.

[kalebepsouza]

@rapoelho

Pela minha experiência, o Grub e o Boot do Windows ficam em pastas separadas na partição do EFI e são vistos como diapositivos diferentes na UEFI.

O que fica separado são os arquivos EFI de inicialização. E ai o Windows pode em algum update recriar a partição efi e apagar a entrada (Pasta da distro) do Linux nessa partição. Mas não é tão comum como a galera pensa. Tenho 2 computadores em dual a muito tempo e só lembro de ter ocorrido uma vez isso e anos atrás. Nunca mais vi esse problema. Mas foi bem simples e fácil corrigir com um live boot linux.

[frc_kde]

E se fizer uma partição EFI para o Linux – separada da partição EFI criada pelo Windows?

@kalebepsouza

o Windows pode em algum update recriar a partição efi e apagar a entrada

[Fey]

@msteles

5. Você Provavelmente Vai Usar Um Sistema Mais do Que o Outro

Pior que me identifiquei muito com o número 5. Eu tinha feito um dual boot um tempo atrás de Pop Os e Windows 11. Pop OS para as tarefas do dia a dia enquanto o Windows 11 mais voltado para jogos e edição de vídeo e no final das contas, acabei mais utilizando o Windows 11 e deixei de lado o Pop OS.

[Natanael.755]

Alguns detalhes não são reais:

@msteles

. O Linux é menos visado por malware.

Na verdade é o exato oposto e o motivo é simples: no Linux estão os dados que realmente valem a pena, o que causa essa impressão é porque por padrão o Linux tem menos vetores de ataque

@msteles

Assim, mesmo com o Secure Boot desativado, seus arquivos mais importantes permanecem, em teoria, mais protegidos

Na verdade nem teoria nem hipótese, mas desinformação, desde 2022 o Secureboot está quebrado e sem esperança de correção para a maioria das pessoas, a única forma de ter segurança com Secureboot hoje é usar o utilitário mokutil para eliminar as chaves padrões e subir as suas próprias chaves e reassinar todos os sistemas operacionais (e nesse caso não depende de chaves da Microsoft) do contrário é puro efeito placebo

[frc_kde]

A propósito…

@frc_kde

E se fizer uma partição EFI para o Linux – separada da partição EFI criada pelo Windows?

@kalebepsouza

o Windows pode em algum update recriar a partição efi e apagar a entrada

Fiz agora a separação da minha antiga partição EFI em 2 partições EFI – embora eu não tenha Windows. – Foi só uma precaução, para poder usar o PC, caso 1 dos 2 SSDs pare de funcionar:

“EFI” Partition                                           “EFI2” Partition

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

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

12 directories, 37 files

Comentei isso em outro tópico, mas achei que ficou meio confuso – então, sintetizei melhor aqui. – CTRL+F “Criando uma 2ª partição EFI” (sem as aspas).

[Rimana21]

@msteles

Você Provavelmente Vai Usar Um Sistema Mais do Que o Outro

Essa é uma das coisas que eu mais me identifico, separar os recursos para ambos os sistemas para não fazer as mesmas coisas.
Como por exemplo:
No meu peppermint eu costumo usá-lo para emuladores, aplicações 3D, jogos e algumas programações em linha de comando fazendo o meu xodó de sistema enquanto que recentemente troquei o linux mint pelo ubuntu para executar aplicações mais pesadas e jogos de maiores configurações somente para esse propósito, no dual-boot isso ajudou muito, divisão de recursos para os sistemas e cada um faz o seu.

Na minha opinião um dual-boot mais seguro e reforçado seria a instalação dos sistemas em discos de armazenamentos separados ao invés de particionados já que o reparo na inicialização de boot do GRUB nesse caso é mais eficiente “Se caaauuusssoo um dia acontecer.”

Nota: O comando no terminal “sudo update-grub” no peppermint não funciona exatamente pois ele só identifica outras distros mas não reescreve a tabela fazendo mudar outro sistema para fazer essa atualização.