A maioria das distribuições instala um gerenciador de inicialização adicional em um sistema UEFI. UEFI
em si é um gerenciador de partida, ele oferece um menu para selecionar diferentes
sistemas ou núcleos individuais. Além disso, as configurações de UEFI podem ser facilmente
alterado com ferramentas de espaço do usuário como efibootmgr .
Kernels desde 3.3 suportam EFI_STUB, o que significa que o kernel pode ser carregado diretamente do UEFI. Qual é a razão pela qual as distribuições decidem usar um loader de boot adicional? A maioria dos tutoriais sobre Linux / UEFI se concentra principalmente em como configurar o gerenciador de inicialização adicional (rEFInd, grub2, ELILO, etc.) em vez de inicializando o Linux com EFI_STUB.
A única coisa que falta nas distribuições é o suporte. Já que a maioria distribuições encadear um segundo carregador de inicialização, o kernel não é adicionado ao o menu de inicialização UEFI, nem é copiado para a partição do sistema EFI.
Três scripts são suficientes para fazer toda a magia. Aquele que copia o initramfs para o ESP. Um segundo copia o kernel para o ESP e cria uma nova entrada no menu de inicialização do UEFI. O terceiro script remove o antigo kernel e initramfs do ESP e apaga a inicialização UEFI entrada do menu. Isso permite que o kernel / initramfs totalmente automatizado atualizações / expurgos sem interação do usuário. Eu estou usando essa abordagem desde mais de um ano e tem funcionado perfeitamente.
Por que a maioria das distribuições usa o grub em vez de EFI_STUB?
Links:
EDIT: Eu não estou falando sobre como remover o suporte ao grub inteiramente, mas para oferecer um
escolha para aqueles que querem usá-lo por várias razões. Distribuições poderiam
fornecer um pacote grub-efi para aqueles que querem encadear UEFI e grub e um
pacote efistub-boot que contém os scripts que eu mencionei acima.
Dado que o UEFI era apenas definido em 2005 , há um monte de equipamentos legados por aí que não suporte a especificação. Adicionar UEFI a uma distribuição padrão exigiria o teste de dois caminhos de código em vez de um, e não apenas o código de inicialização é notoriamente complexo, como é um dos bits de código mais irritantemente demorados para testar.
As distribuições têm recursos limitados e pode não haver nenhuma razão além disso. Pode ser razoavelmente simples e seguro, mas independentemente de , será necessário mais trabalho de manutenção porque a opção grub deve ser mantida, mesmo que apenas para sistemas não UEFI.
Tenho certeza de que todo mundo tem uma lista de recursos e opções que gostariam que as distros adotassem (darei algumas páginas, lol), e sem dúvida muitos desses seriam "totalmente fáceis, sem aborrecimentos honestamente ... ". No entanto, não há uma quantidade infinita de pessoas-hora para implementá-las. Quando confrontados com decisões como essa ("Nós colocamos o trabalho neste recurso, contra alguns outros?"), As perguntas principais devem ser:
A razão pela qual as pessoas usam distros é porque todos estão sujeitas a restrições de recursos (caso contrário, apenas contrate uma equipe, compre espaço e equipamentos, e faça-os fazer exatamente por você quer). Portanto, a realidade é que as distros refletem as necessidades generalizadas de seus usuários.
Dito isso, acho que, com o tempo, isso será adotado como opção e fiz a pergunta.
A segmentação de carregadores de inicialização UEFI além do grub complicaria o controle de qualidade e o suporte. As distribuições são direcionadas ao grub em vez da especificação UEFI, porque o grub é software livre, hackable, mais flexível e de alta qualidade. Você ainda pode obter uma inicialização UEFI pura seguindo um tutorial e montando a partição UEFI em /boot , porque se você fizer isso, a manutenção estará em você.
O problema real é que as pessoas não entendem como isso funciona. Por exemplo, na sua pergunta você menciona que são necessários três scripts, e a maioria das respostas aqui são sobre toda e qualquer manutenção adicional que seria necessária para que funcionasse - mas a verdade é que você não precisa desses scripts ou qualquer trabalho adicional.
Tudo que você precisa é ligar o ESP - ou onde você quiser manter o kernel - acima de /boot , o que você pode fazer com uma única linha em /etc/fstab . Faça isso e todos os scripts atuais de atualização do kernel simplesmente continuarão funcionando.
Meu '/ etc / fstab' se parece com:
LABEL=ESP /esp vfat defaults 0 2
#
#^ i like a separate mount point - not necessary though
#
/esp/EFI/arch_root /boot none bind,defaults 0 2
#
#^ i keep separate installations in separate directories
#
Há um bom ponto aqui, porém, sobre configurações específicas do fabricante. O UEFI explicitamente faz não especificar a interface para um menu de inicialização. Isso está em jogo e não será consistente entre as máquinas. É chato, mas é verdade.
E assim, enquanto um loader como grub na verdade só faz para mais funcionar, um aplicativo de menu - como rEFInd - equaliza as diferenças e simplifica tudo.
Eles encadearam o UEFI e o GRUB como uma solução de implementação temporária.
Como o suporte a UEFI e os problemas associados (por exemplo, inicialização segura) são resolvidos, mais e mais distribuições o usarão diretamente. Nesse meio tempo, isso ainda é muito novo: o Google Trends mostra uma adoção bastante limitada: link
Outros mencionaram as possíveis desvantagens de se optar por uma solução UEFI pura e / ou suportar sistemas UEFI não-UEFI e puros simultaneamente. Um kernel UEFI pode funcionar em um sistema não UEFY, mas as ferramentas de atualização do kernel precisam atualizar um menu GRUB OU um menu de inicialização UEFI OU ambos, etc etc.
Realmente é sobre controle de qualidade como mencionado: importante problemas com este código têm um alto impacto: Quando o computador não consegue inicializar novos usuários, ou seja, potenciais convertidos do Linux, vai descartá-lo como lixo e voltar para algo "seguro".
Mas, como eu disse, à medida que a tecnologia adquire mais adoção, ela se tornará o padrão.
Quando não está encadeando o grub, a distribuição está confiando mais no firmware para inicializar corretamente. Como qualquer software terá problemas, o firmware também é propenso a isso. Agora as distribuições do Linux terão que escrever para solucionar esses erros de firmware também.
Um caso da vida real como um exemplo. A placa-mãe Asrock H81 pro BTC P1.80 permite a criação de entradas no menu de inicialização com efibootmgr . Pode haver várias entradas no menu de inicialização criadas, e a ordem de inicialização pode ser alterada usando efibootmgr --bootorder XXXX,YYYY,ZZZZ ou uma próxima opção de inicialização temporária pode ser definida usando efibootmgr --bootnext XXXX . Ambos os comandos retornam a saída, o que lhe dá a ideia de que a ordem de inicialização mudou ou a próxima inicialização será executada, por exemplo, BootNext: XXXX . No entanto, ao reiniciar, o firmware teimoso simplesmente ignora a opção de inicialização recém-solicitada e reinicializa no valor BootCurrent: anterior. Uma mudança permanente de ordem de inicialização só pode ser feita a partir do utilitário de configuração de firmware. E uma mudança não permanente não está disponível.
Acho que, se a inicialização for feita apenas pela EFI e removermos o bootloader, será difícil para os fabricantes de HW e para os fabricantes de sistemas operacionais. O fornecedor de HW terá mais kernels para testar, enquanto para as empresas que produzem o SO, será como se o kernel fosse carregado por diferentes FWs.
Além disso, com a inicialização direta do kernel da EFI, onde a inicialização segura da pilha se encaixa? No cenário atual, uma vez que o controle vai para o gerenciador de inicialização do sistema operacional, o gerenciador de inicialização verifica se o kernel está corretamente assinado ou não. No caso de carregarmos o kernel diretamente do EFI, então eu acho que ele criará bagunça apenas quando a pilha inteira for perturbada. Apenas uma opinião de que compreensão eu tenho.
Tags boot grub2 uefi boot-loader