Uma proposta de mudança que espera ocorrer para o Fedora 39 tornaria mais fácil ter um sistema opcionalmente livre de GRUB, executando uma instalação limpa com systemd-boot para inicializar em plataformas EFI.Atualmente, o padrão do Fedora é usar um shim e o gerenciador de inicialização GRUB para inicializar em sistemas EFI. No entanto, o systemd-boot já está empacotado no Fedora e existem algumas maneiras de mudar manualmente para usar a solução de inicialização do systemd. A proposta F39 elaborada pelo engenheiro da Arm, Jeremy Linton, permitiria uma instalação mais fácil do Fedora com o systemd-boot. Assim, o Fedora pode facilitar a mudança para o systemd-boot e criar um sistema livre de GRUB.
A proposta atualmente envolve a conclusão do trabalho no instalador do Anaconda, Kickstart e ferramentas relacionadas com foco inicial em permitir que o Fedora Everything gire para opcionalmente permitir a instalação de uma máquina sem GRUB.
Fedora pode facilitar a mudança para o systemd-boot e criar um sistema livre de GRUB
Como primeira passagem, a opção ‘inst.sdboot’ já no anaconda deve funcionar. Tal como está, isso substitui grub+shim pelo carregador systemd-boot e move o kernel + initrd para a partição do sistema EFI (ESP). Ele não tenta criar imagens de kernel unificadas, então a atualização dnf existente, kdumpctl e make install em um diretório fonte do kernel devem funcionar. A grande maioria deste trabalho foi feito, deixando apenas dois itens de ação, removendo o grubby de core e mesclando um pacote de shimming (sdubby) nos repositórios do fedora.
Além disso, existem vários aprimoramentos que podem ser feitos para remover a partição /boot (deixando o EFI em /boot/efi), registrando as chaves do fedora se o modo de inicialização segura é “Setup”, adicionando opções para habilitar shim+systemd-boot, garantindo que haja um pacote assinado pelo systemd-boot, etc.
As vantagens de apenas habilitar o carregador systemd-boot sem UKIs ou reestruturar os pontos de montagem /boot e /boot/efi resultam em uma gama mais ampla de máquinas suportadas e um ambiente mais familiar para usuários e aplicativos. AKA, ao não alterar o processo de compilação HostOnly/initrd, a grande maioria das máquinas UEFI é suportada.Para deixar claro, a intenção não é substituir o grub, mas coexistir como um gerenciador de inicialização alternativo.
Notícias Relacionadas
Mais detalhes sobre esta alteração proposta para o Fedora 39, que ainda precisa ser avaliada pelo Fedora Engineering and Steering Committee (FESCo), podem ser encontrados no Wiki Fedora.
Algumas alterações para o Fedora 39 em discussão
Há uma proposta em andamento para o Fedora 39 aumentar seu vm.max_map_count padrão para satisfazer alguns jogos do Windows rodando no Linux por meio do Steam Play da Valve. Uma proposta revisada foi agora aprovada pelo Comitê de Engenharia e Direção do Fedora. Até este ponto, o Fedora usou o valor vm.max_map_count padrão de 65.530, enquanto o Steam OS da Valve usa um valor de 2147483642 (MAX_INT – 5). Portanto, a expectativa é de que o Fedora 39 vai aumentar seu vm.max_map_count para satisfazer alguns jogos do Steam Play.
A maioria dos softwares funciona bem com o limite do número máximo de mapas de memória para um processo em 65k, mas alguns jogos do Windows como DayZ, Hogwarts Legacy e Counter-Strike 2 precisam de mais do que isso para rodar normalmente no Steam Play.Originalmente, a proposta do Fedora 39 também era usar uma contagem máxima de mapa de memória de 2147483642, mas havia preocupações levantadas se fosse muito altoque o kernel pode ser sobrecarregado com muitos mapeamentos e, por sua vez, levar o manipulador de falta de memória a encerrar outros processos.
Uma das recentes propostas de mudança para o Fedora 39 em desenvolvimento é enviar o mkosi-initrd do systemd como uma alternativa moderna e superior ao Dracut para a construção de initrds. Sendo assim, o Fedora 39 vai enviar mkosi-initrd como uma alternativa moderna ao Dracut.
Inicialmente mkosi-initrd é definido para ser tratado como um construtor alternativo ao Dracot para construir initrds, mas seu escopo inicial pode ser limitado. A intenção com mkosi-initrd é limpar o processo de construção complicado e ineficiente usado atualmente pelo Dracut.
