Por que a maioria das distribuições encadeia UEFI e grub?

A maioria das distribuições instala um carregador de inicialização adicional em um sistema UEFI. O UEFI é um gerenciador de inicialização, oferece um menu para selecionar diferentes sistemas operacionais ou kernels individuais. Além disso, as configurações UEFI podem ser facilmente alteradas com ferramentas do espaço do usuário efibootmgr.

Os kernels desde o 3.3 suportam EFI_STUB, o que significa que o kernel pode ser carregado diretamente a partir da UEFI. Por que as distribuições decidem usar um carregador de inicialização adicional? A maioria dos tutoriais sobre Linux / UEFI se concentra principalmente em como configurar o carregador de inicialização adicional (rEFInd, grub2, ELILO etc.) em vez de inicializar o Linux com EFI_STUB.

A única coisa que falta nas distribuições é o suporte. Como a maioria das distribuições encadeia um segundo carregador de inicialização, o kernel não é adicionado ao menu de inicialização UEFI, nem é copiado para a partição do sistema EFI.

Três scripts são suficientes para fazer toda a mágica. Um 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 UEFI. O terceiro script remove o kernel antigo e o initramfs do ESP e exclui a entrada do menu de inicialização UEFI. Isso permite atualizações / purgas totalmente automatizadas do kernel / initramfs sem a interação do usuário. Estou usando essa abordagem há mais de um ano e funcionou perfeitamente.

Por que a maioria das distribuições usa grub em vez de EFI_STUB?

Ligações:

• Como recriar a partição de inicialização EFI?

EDIT: Eu não estou falando sobre remover o suporte ao grub inteiramente, mas para oferecer uma opção para aqueles que querem usá-lo por vários motivos. As distribuições podem fornecer um pacote grub-efipara aqueles que desejam encadear UEFI e grub e um pacote efistub-bootque contém os scripts mencionados acima.

Dado que o UEFI foi definido apenas em 2005, há um monte de equipamentos legados por aí que não suportam as especificações. Para adicionar UEFI a uma distribuição padrão, seria necessário testar dois caminhos de código em vez de um, e não apenas o código de inicialização é notoriamente exigente, mas também um dos bits de código mais irritantes e demorados para testar.

As distros têm recursos limitados e pode não haver nenhuma razão além disso. Pode ser razoavelmente simples e seguro, mas não importa o que exija mais trabalho de manutenção, pois a opção grub deve ser mantida, mesmo que seja para sistemas não UEFI.

Eu tenho certeza que todo mundo tem uma lista de recursos e opções que eles gostariam que as distros adotassem (vou lhe dar algumas páginas, risos), e sem dúvida muitos deles seriam "totalmente fáceis, sem aborrecimentos, honestamente. .. " No entanto, não há uma quantidade infinita de horas por pessoa para implementá-las. Quando confrontados com decisões como esta ("Colocamos trabalho nesse recurso, em comparação com outros?"), As perguntas principais devem ser:

• Isso é necessário? (A resposta aqui é não).
• Quantas pessoas serão beneficiadas e quanto? (IMO: alguns, e não muito)
• Existe uma alternativa razoável pela qual o usuário possa se acomodar sem que façamos nada? (Aparentemente existe.)

A razão pela qual as pessoas usam as distribuições é que todos estão sujeitos a restrições de recursos (caso contrário, basta contratar uma equipe, comprar espaço e equipamento e pedir que façam tudo por você exatamente como você deseja). Portanto, a realidade é que as distribuições refletem as necessidades generalizadas de seus usuários.

Dito isto, acho que com o tempo isso será adotado como uma opção, e eu votei na questão.

A segmentação de gerenciadores de inicialização UEFI, além do grub, complicaria o controle e o suporte da qualidade. As distribuições têm como alvo o grub, e não a especificação UEFI, porque o grub é software livre, hackável, 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 /boot, porque se você fizer isso, a manutenção será sua.

O verdadeiro problema é que as pessoas não entendem como isso funciona. Por exemplo, na sua pergunta, você menciona que três scripts são tudo o que é necessário e a maioria das respostas aqui são sobre toda / qualquer manutenção adicional necessária para fazê-lo funcionar - mas a verdade é que você não precisa desses scripts ou qualquer trabalho adicional.

Tudo o que você precisa é montar o ESP - ou onde quer que você queira manter o kernel - /boot, o que você pode fazer com uma única linha /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 argumento aqui, no entanto, sobre configurações específicas do fabricante. UEFI explicitamente que 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 carregador como o que grubrealmente contribui para mais trabalho, um aplicativo de menu - como o rEFInd - equaliza as diferenças e simplifica tudo.

Eles encadearam o UEFI e o GRUB como uma solução de implementação temporária.

À medida que o suporte à UEFI e os problemas que o acompanham (por exemplo, inicialização segura) forem resolvidos, mais e mais distribuições o usarão diretamente. Enquanto isso, isso ainda é muito novo: o Google Trends mostra uma adoção bastante limitada: http://www.google.com/trends/explore?q=cannot+boot+uefi#q=uefi%2C%20%20efi%2C % 20% 20bios & cmpt = q

Outros já mencionaram possíveis armadilhas ao optar por uma solução UEFI pura e / ou dar suporte a sistemas UEFI não UEFI e puros UEFI 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.

Na verdade, trata-se de controle de qualidade, conforme mencionado: problemas importantes com esse código têm um alto impacto: quando o computador falha ao inicializar novos usuários, ou seja, possíveis conversões do Linux, o descarta como lixo e volta para algo "seguro".

Mas, como eu disse, à medida que a tecnologia obtém mais adoção, ela se tornará o padrão.

É necessário um código extra para solucionar os erros do firmware

Quando não está encadeando o grub, a distribuição depende mais do firmware para inicializar corretamente. Como qualquer software terá problemas, o firmware também é propenso a isso. Agora, as distribuições Linux também terão que escrever para solucionar esses erros de firmware.

Um caso da vida real como exemplo. A placa-mãe Asrock H81 pro BTC P1.80 permite a criação de entradas no menu de inicialização efibootmgr. Pode haver várias entradas do menu de inicialização criadas, e a ordem de inicialização pode ser alterada usando efibootmgr --bootorder XXXX,YYYY,ZZZZou uma próxima opção temporária de inicialização pode ser definida usando efibootmgr --bootnext XXXX. Ambos os comandos retornam a saída, que fornece a idéia de que a ordem de inicialização foi alterada ou a próxima inicialização será executada, por exemplo BootNext: XXXX. No entanto, na reinicialização, o firmware teimoso apenas ignora a opção de inicialização recém-solicitada e reinicia no BootCurrent:valor anterior . Uma alteração permanente na ordem de inicialização só pode ser feita no utilitário de configuração do firmware. E uma alteração não permanente não está disponível.

Penso que, se a inicialização for realizada apenas pela EFI e removermos o gerenciador de inicialização, será difícil para o fornecedor de HW e os fabricantes de sistemas operacionais. O fornecedor de HW terá mais kernels para testar, enquanto nas empresas que fabricam SO, será como se o kernel fosse carregado por FW diferente.

Além disso, com a inicialização direta do kernel da EFI, onde na pilha a inicialização segura se ajustará? No cenário atual, uma vez que o controle vá para o gerenciador de inicialização do SO, verifique se o kernel está assinado corretamente ou não. No caso de carregarmos o kernel diretamente do EFI, acho que ele criará confusão apenas porque toda a pilha será perturbada. Apenas uma opinião de que entendimento eu tenho.