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

31

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:

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.

boot grub2 boot-loader uefi Marco
fonte
4
Por que eles deveriam? Eles já estabeleceram métodos para lidar / gerar arquivo de configuração do grub. Além disso, ajuda se todos os sistemas (não UEFI e UEFI) se comportarem da mesma forma.
21813 Ulrich Dangel
Parece legal. Mas, de acordo com esse link, você pode fazê-lo se quiser, talvez seja um desastre em potencial para as distros fazerem isso automaticamente. Betcha alguns eventualmente lhe dará a opção tho.
Goldilocks
11
@Bakuriu Um sistema mais fácil de entender, uma sequência de inicialização mais simples, código menos executado e tempo de inicialização um pouco mais rápido, por exemplo.
21813 Marco Marco
4
Essa pergunta deve ser adiada, pois o motivo da retenção fornecido está errado. A pergunta tem uma resposta incontestável simples: UEFI não fornece um menu de inicialização. Algumas implementações fazem. Alguns não, porque para atingir o tempo de inicialização desejado para o Windows 8, o BIOS nem sequer inicializa os dispositivos de entrada . Muito menos esperar para ver se o usuário pressiona uma tecla. Então você teria que passar pelo Windows para acessar o Linux ou vice-versa. O primeiro funciona em alguns sistemas, mas duvido que a especificação o garanta. O último não funciona (você pode entrar na configuração UEFI do GRUB, mas não do Linux).
sourcejedi
11
@sourcejedi Você afirma que não corresponde às suas fontes. A UEFI fornece um menu de inicialização (embora a interface do usuário seja inconsistente entre os fornecedores). mjg59 significava que você não pode acessar o menu de inicialização sem compromisso filosófico (aceitando o EU8 do W8). Mas esse problema será o mesmo para instaladores com gerenciadores de inicialização não-EFISTUB grub. Portanto, não responde por que preferimos o grub ao EFISTUB.
Lingzhu Xiang 21/07

Respostas:

10

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.

msw
fonte
5
Não é apenas demorado e irritante para testar, é o código mais irritante que pode dar errado. Considere: o que você prefere, algum tipo de problema enquanto o sistema está funcionando normalmente quase sempre ou não consegue nem inicializar o sistema? O gerenciador de inicialização é definitivamente uma das partes do software que eu mais sinto em não tocar, a menos que seja necessário.
um CVn
O comentário acima de @ MichaelKjörling deve estar em uma resposta. Mudar para um novo gerenciador de inicialização é muito, muito arriscado. Os criadores de distribuidores desejam que seus usuários tenham uma boa experiência, mas, mais do que isso, desejam que todos os novos usuários em potencial tenham uma experiência perfeita pela primeira vez. Lamento chamar a distribuição de "distro", mas me senti bem em conjunto com os criadores.
21413 Johan Johan
@Johan msw é livre para editar esse ponto para a resposta, eu não me importo. (Não basta ser uma resposta por si só, IMO.) Tanto Tobu quanto goldlilocks também abordam a questão.
um CVn
3

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.

Cachinhos Dourados
fonte
2

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.

Tobu
fonte
sua afirmação de qualidade é discutível, mas acho que a razão pela qual ela é direcionada não tem nada a ver com isso. eles já têm milhares de linhas de scripts shell mal escritos para lidar com isso; então, por que eles querem 20 bons?
Mikeerv #
1

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.

mikeserv
fonte
11
Eu não entendo como isso poderia funcionar. Observe que os nomes dos arquivos do kernel e do initramfs incluem a versão. Se não houver scripts, você inicializará seu kernel antigo após instalar um novo. Ou formulado de maneira diferente: Como você altera o kernel padrão para apontar para o novo? (Meus scripts usam efobootmgrpara atualizar a ordem de inicialização e alterar o kernel padrão).
16139 Marco Marco
@Marco - bem, o caminho de inicialização padrão é \EFI\BOOT\BOOTX64.efie poderia ser nomeado para isso. o UEFI não pode (por especificação) manipular argumentos para o kernel em primeiro lugar - e, portanto, a imagem initramfs / kernel precisa ser ligada nesse caso. mas não sei o que você quer dizer com o nome da versão - acho que apenas os debians fazem isso, e considero improdutivo de qualquer maneira. o nome convencional para o seu kernel é vmlinuz. De qualquer forma, a maneira certa de fazer isso é com um gerenciador de inicialização e não um carregador . Use um aplicativo EFI que encontre seu kernel e passe seu nome para o EFI para inicializar - como o rEFInd.
mikeserv
Eu uso o Debian e o nome do kernel é, por exemplo, o vmlinuz-4.2.0-1-amd64que deixo como está e depois o uso efibootmgrpara adicioná-lo à lista de inicialização e torná-lo padrão. Vejo que nomear o kernel BOOTX64.efipode ser uma solução. Mas, de qualquer forma, eu precisaria ter um script para fazer isso e, além disso, isso não permite facilmente manter vários kernels se todos tiverem o mesmo nome.
Marco
@Marco - você não precisa de um script inteiro e separado - seu gerenciador de pacotes - apt, provavelmente - estará executando algum script de qualquer maneira quando um kernel estiver instalado para construir o initramfs. provavelmente está fazendo centenas de coisas para descobrir o nome do seu kernel, mas apenas uma única linha extra fará o renomear para o que você quiser. e você pode facilmente manter quantos núcleos desejar, se mantiver uma árvore de inicialização . O rEFInd lida com isso, tornando a imagem de inicialização padrão a imagem do kernel modificada mais recentemente em seus caminhos de pesquisa.
mikeserv
Modificar scripts de ações instalados pelo gerenciador de pacotes é uma má idéia. Eles podem ser atualizados, o que, por sua vez, limpa suas alterações e, nesse caso em particular, pode até resultar em um sistema não inicializável. Existem diretórios para scripts de usuário que são chamados após uma instalação do kernel / initramfs e que devem ser usados ​​exatamente para uma finalidade como esta. BTW: Você está sugerindo editar scripts nos seus comentários. No entanto, em sua resposta, você declara “você não precisa desses scripts ou de qualquer trabalho adicional”, o que não é verdade (pelo menos para o Debian).
1616 Marco
0

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.

Johan
fonte
Espero que não - mas isso é principalmente porque eu tenho preocupações graves sobre os modos de bloqueio do UEFI e "promessa" da Microsoft para se certificar de que haverá sempre uma imagem assinado para Linux para uso ...
Shadur
0

É 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.

Pro Backup
fonte
-2

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.

Shubham
fonte
isso é bobagem. a razão pela qual o carregador de inicialização verifica a chave é porque o UEFI não. O carregamento em cadeia é redundante para garantir a inicialização segura de um kernel assinado; basta verificar a chave no firmware - da maneira como deve funcionar.
mikeserv