Fedora 36 terá problemas no dual boot?

Bom dia, tudo bem?

Vi que o Ubuntu poderia ter problemas com o dual boot por cousa do Grub 2.06.
Minha dúvida é se o Fedora vai ser afetado por esse problema também.

Ontem eu fiz dual boot do fedora 36 e windows 10 e deu tudo certo, na verdade não tão certo pq a imagem no fedora ficou cagada, mas aí é outra história

1 curtida

fedora é minha distro principal, tenho dual boot, uso o grub, atualizei ontem para o fedora 36 e está tudo certo, aliás …melhor distro da atualidade na minha opinião, excelente.

1 curtida

-fiz instalação limpa do fedora-36-mate e dual-boot funcionou sem problemas com ubuntu-22.04
-acho que fedora-37 não vai mais rodar em maquinas bios

1 curtida

“Não ache” achismo é FUD, basta uma pesquisa rápida para saber que a proposta para remover suporte a BIOS legado não foi aprovada para a versão 37 do fedora, então achismo não é válido nesse caso, inclusive aqui no fórum tem um tópico falando sobre o assunto.
Em caso de dúvidas não fale sobre o que você “acha” pesquise antes.

Talvez não fui muito claro na pergunta.

Saiu uma matéria aqui no Diolinux falando sobre uma falha de segurança no “os-prober” do GRUB 2.06 e que o Ubuntu não traria suporte ao “os-prober” dificultando a utilização de dual boot.

A dúvida é o Fedora 36 esta utilizando essa versão do GRUB? E será afetado por essa falha de seguraça?

1 curtida

O fedora não vai ter problema com dual boot mesmo trazendo essa versão do grub (na verdade o questionamento seria sobre o os-prober), na postagem sobre o assunto na lista de discussão inclusive mencionam o metodo do fedora/redhat que tem um grub totalmente patcheado downstream.

https://lists.ubuntu.com/archives/ubuntu-devel/2021-December/041769.html

# Options

0. Re-enable os-prober

1. Red Hat only runs os-prober during install time, and
   instead of regenerating grub.cfg when kernels are installed
   writes out drop-in files that are then loaded (it actually
   uses the systemd-boot load entries format, which it has
   patched into grub)

   We could run os-prober during install time, store the
   output somewhere and then reuse the cached output in
   grub-mkconfig.
3 curtidas

Obrigado por chamar atenção para essa “novidade”, que eu ainda não tinha visto – mas que poderá me afetar, pois uso várias distros em dualboot.

Em poucas palavras, não – pois vários colegas já verificaram que o Grub do Fedora 36 continua detectando o Windows e as outras distros:

Verifiquei aqui que o Fedora usa o grub 2.06 pelo menos desde Abril 2021 – ainda Fedora 33 – e se os_prober estivesse desabilitado, muita gente já teria dado o grito:

# date; dnf upgrade --refresh; date
Sun 11 Apr 16:22:36 -03 2021
(...)
grub2-pc      1:2.06~rc1-1.fc33

Vale observar que a “decisão” de desabilitar os_prober partiu da equipe do Grub – o que pode nos levar a pensar que isso afetaria todas as distros, à medida em que cada uma passe a usar o grub 2.06 – mas tudo indica que as distros podem aceitar isso, ou não.

Uso o Grub do openSUSE Tumbleweed como meu “Menu de inicialização”. – Não sei exatamente desde quando ele usa o grub 2.06 – mas pude verificar que isso acontece pelo menos desde Agosto 2021, quando já estava no grub 2.06-4:

# date; zypper dup --allow-vendor-change; date
Sun 22 Aug 19:09:00 -03 2021
(...)
    grub2-x86_64-efi-2.06-4.1.noarch.rpm

Atualmente, já está no grub 2.06-22:

$ rpm -qa --last | grep grub
grub2-branding-openSUSE-84.87.20210910-1.24.noarch Sun 08 May 2022 11:32:28 -03
(...)
grub2-2.06-22.1.x86_64                        Sun 01 May 2022 10:04:35 -03

… e continua detectando as outras distros:

# cp /home/flavio/grub /etc/default/grub

# date; time grub2-mkconfig -o /boot/grub2/grub.cfg; date
Sun  8 May 11:38:08 -03 2022
Generating grub configuration file ...
Found theme: /home/flavio/Grub/theme.txt
Found linux image: /boot/vmlinuz-5.17.4-1-default
Found initrd image: /boot/initrd-5.17.4-1-default
Found linux image: /boot/vmlinuz-5.17.2-1-default
Found initrd image: /boot/initrd-5.17.2-1-default
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Void Linux on /dev/sda10
Found Manjaro Linux (21.2.6) on /dev/sda11
Found MX 21.1 Wildflower (21.1 ) on /dev/sda13
Found Arch Linux (rolling) on /dev/sda3
Found Debian GNU/Linux bookworm/sid on /dev/sda4
Found Fedora Linux 35 (KDE Plasma) on /dev/sda5
Found KDE neon User - Plasma 5.24 (20.04) on /dev/sda6
Found PCLinuxOS on /dev/sda7
Found Mageia 8 (8) on /dev/sda8
Found Slackware 15.0 x86_64 on /dev/sda9
Adding boot menu entry for UEFI Firmware Settings ...
done

real    0m21.968s
user    0m11.880s
sys     0m6.463s
Sun  8 May 11:38:30 -03 2022

Meu “Menu de inicialização” alternativo (para emergências) é o Grub do Mageia, que também já está no grub 2.06, pelo menos desde Julho 2021:

# date; urpmi --auto-update; date
Sun 11 Jul 09:58:20 -03 2021
(...)
  grub2-common                   2.06         1.1.mga8 

… e também continua com os_prober plenamente habilitado:

Disso tudo, a conclusão parece ser a de que a Canonical decidiu aceitar a desabilitação do os_prober por padrão, a partir do Ubuntu LTS 22.04 – e outras distros não aceitaram – ou, talvez, apenas não mexeram na configuração do Grub que eu já tinha (pois instalei e configurei o openSUSE Tumbleweed e o Mageia em 2020, portanto bem antes da chegada do grub 2.06).

Esta segunda hipótese me parece discutível – pois o openSUSE Tumbleweed não tem o menor escrúpulo em reinstalar o /etc/default/grub padrão, a cada atualização dos pacotes do Grub – daí, a necessidade de restabelecer minha versão personalizada, a cada vez que vou atualizar seu Grub.

Mas a versão-padrão não desabilita os_prober – apenas, reduz o tamanho do “Menu de inicialização” (Tema padrão).

Tamanho padrão:

Tamanho personalizado:

Se não hesita em mexer nas minhas configurações, por que não desabilita os_prober?

Re-habilitar os_prober é coisa simples – conforme os colegas já indicaram (acima). – Basta editar o arquivo /etc/default/grub e acrescentar esta linha (ou editá-la, de “true” para “false”, se ela já existe):

GRUB_DISABLE_OS_PROBER=false

Todos advertem que isso introduz uma falha de segurança. – Essa falha já existia (não sei há quanto tempo) – e a única novidade é que, agora, ela foi descoberta.

Isto não significa que todos nós seremos atacados nos próximos dias. – Não entendo o suficiente, para avaliar o grau desse risco. O atacante precisaria ter acesso físico ao meu PC desktop? Precisaria acessar meu PC desktop remotamente, no momento em que uma atualização de Kernel dispara a atualização do Grub, em uma sessão já plenamente iniciada e com as demais medidas de segurança adotadas por cada distro? – O comportamento do openSUSE Tumbleweed e do Mageia sugere que não consideram o risco tão grande assim.

O assunto – que é de 1 anos atrás – só voltou à tona, agora, porque a Canonical decidiu agir diferente, desabilitando uma funcionalidade fundamental no dia-a-dia, e para justificar isso, emitiu um aviso meio alarmante.

Obs.: - Não aconselho Grub Customizer – pois ele cria uma “camada de complexidade” que, às vezes, gera problemas. – Verifiquei isso em meados de 2021, mas infelizmente não lembro os detalhes. Onde será que anotei…

Pela minha experiência pessoal, há muito tempo percebi que o Fedora não estava mais executando a atualização do Grub após instalar novos Kernels (pelo menos desde o Fedora 31), pois adotou um “BLS” – “Boot Loader Specification”.

Com isso, o Grub de outras distros (openSUSE, Mageia) não encontrava informações atualizadas para gerar as entradas para o Fedora – porque o que o os_prober faz é “ler” os arquivos /boot/grub/grub.cfg das outras distros, e no caso do Fedora esse arquivo permanecia desatualizado.

Por isso, tive de editar o arquivo /etc/default/grub do Fedora 31(+), alterando esta linha, de true para false:

GRUB_ENABLE_BLSCFG=false

Isto apenas faz com que o Grub do Fedora passe a gerar suas próprias entradas – para serem lidas pelo os_prober do openSUSE e do Mageia – mas eu ainda preciso executar essa atualização manualmente, pelo comando:

# date; time grub2-mkconfig -o /boot/grub2/grub.cfg; date
Sun  8 May 10:57:28 -03 2022
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.17.5-200.fc35.x86_64
Found initrd image: /boot/initramfs-5.17.5-200.fc35.x86_64.img
Found linux image: /boot/vmlinuz-5.17.4-200.fc35.x86_64
Found initrd image: /boot/initramfs-5.17.4-200.fc35.x86_64.img
Found linux image: /boot/vmlinuz-5.16.20-200.fc35.x86_64
Found initrd image: /boot/initramfs-5.16.20-200.fc35.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 UEFI Firmware Settings ...
done

real    0m12.046s
user    0m5.620s
sys     0m5.895s
Sun  8 May 10:57:40 -03 2022

E se você usa o Grub do Fedora para carregar outras distros, essas entradas também não são atualizadas – pelo simples fato de o Fedora não fazer isso automaticamente. – Você terá de lembrar que a distro X ou Y recebeu novo Kernel, e atualizar manualmente o Grub do Fedora.

(O Grub do Arch também não costuma executar atualização, pois não faz referência à “versão” do Kernel – só indica “linux-lts” [por exemplo], que nunca muda).

Como vê, eu desabilitei os_prober no Fedora – aliás, em todas as outras distros, exceto openSUSE e Mageia – não por motivo de “segurança”, mas porque era uma perda de tempo desnecessária, a cada vez que uma dessas outras distros recebia novo Kernel.

No caso do Kubuntu, por exemplo, minha experiência (usando Synaptic) mostrou que ele executa pelo menos 3 vezes a atualização do Grub, a cada vez que instala nova versão do Kernel – talvez, porque aproveito para remover o mais antigo.

3 curtidas

Eu estou migrando devagarinho para o systemd-boot, ainda preciso verificar como fazer ele reconhecer secure boot mas não é algo urgente.
No mais da gosto de ler suas postagens cara.

2 curtidas

Pesquisei apenas por alto sobre systemd-boot, rEFInd e outras alternativas, e na época tive a sensação de que nenhuma dessas opções oferecia tantos recursos e flexibilidade quanto o Grub.

O Grub é chato, em muitos aspectos, mas já consegui solucionar tantos problemas nele, que acabo achando mais cômodo continuar com ele, por enquanto.

Obrigado!

3 curtidas

Este tópico foi fechado automaticamente 3 dias depois da última resposta. Novas respostas não são mais permitidas.