Manipulação de erros em scripts de shell de inicialização do EFI

Question

Estou usando um computador, o Dell OptiPlex 9010, que vem com o firmware UEFI, mas não suporta a inicialização de dispositivos PCI-Express NVMe.

Eu trabalhei em torno disso usando DUET para criar uma partição de boot EFI em um pendrive, que tem um driver NVMe que ele carrega e, em seguida, executa o programa de inicialização EFI do meu sistema operacional.

Os comandos para fazer isso são atualmente inseridos manualmente. Aqui está o processo:

1. O computador está desativado.
2. Insira meu pen drive DUET em uma porta USB (eu sempre deixo ligado)
3. Ligue o computador
4. (O UEFI está configurado para inicializar sempre a partir desse dispositivo USB e ignorar os carregadores de inicialização nas outras unidades em que eu me conectei)
5. O dispositivo USB DUET carrega um shell EFI ( EFI Shell version 2.31 [4.653] )
6. (O comando map mostra que o dispositivo USB do DUET é montado automaticamente em fs0: )
7. eu carrego o driver NVMe: load fs0:\EFI\Drivers\NvmExpressDxe-64.efi
8. Eu disparo uma atualização de mapeamentos de volume com map -r , este comando é concluído com sucesso sem nenhum problema.
9. (Meu volume NVMe agora está listado, às vezes como fs1: , mas também como fs0: )
10. inicializo o Windows executando: fs1:\EFI\Boot\Bootx64.efi
11. A tela de inicialização do Windows é exibida e o computador é reiniciado para inicializar o Windows

Eu tentei automatizar isso colocando os comandos dentro de um script startup.nsh (o equivalente EFI do DOS ' autoexec.bat ).

Meu script é este:

echo Step 1
load fs0:\EFI\Drivers\NvmExpressDxe-64.efi
echo Step 2
map -r
echo Step 3
fs0:
echo Step 4
fs0:\EFI\Boot\Bootx64.efi
echo Step 5

(Esse script usa fs0: em vez de fs1: , porque quando startup.nsh é executado, minha unidade NVMe é remapeada para fs0: , mas quando executo os comandos interativamente ele é mapeado para fs1: . Não sei porque ou como isso acontece).

Quando eu inicializo e deixo o shell executar startup.nsh eu recebo esta saída:

startup.nsh> Step 1
startup.nsh> load fs0:\EFI\Drivers\NvmExpressDxe-64.efi
load: Image fs0:\EFI\Drivers\NvmExpressDxe-64.efi loaded at D7C3F000 - Success
startup.nsh> Step 2
startup.nsh> map -r
Device mapping table
  fs0  :PciRoot(0x0)/Pci(0x1c,0x4)/...
  fs1  :PciRoot(0x0)/Pci(0x1c,0x4)/...
  blk0 :PciRoot(0x0)/Pci(0x1c,0x4)/...
  ...
Shell: Cannot read from file - No Media
Shell> _

Portanto, quando map -r é executado dentro de startup.nsh , ele é executado, mas falha com o erro "Não é possível ler o arquivo - Sem mídia" e, em seguida, anula a execução do restante do script (como não há echo Step 3 output), no entanto, se eu digitar manualmente o comando fs0:\EFI\Boot\Bootx64.efi , o Windows carregará bem.

Eu olhei para a documentação dos Comandos Shell da EFI e não vejo nenhum comando como try ou on error resume next ou on error goto :label - então o script está fadado ao fracasso.

    

Answer 1

Posso confirmar que map -r quebra o script de inicialização.

Isso acontece porque o remapeamento altera a localização do script e o shell não pode ler o próximo comando a ser executado. Você pode corrigir isso alterando o modo de shell EFI e usar o método de atualização do mapeamento.

Em suma, em vez de map -r , tente isto:

connect -r
set -v efishellmode 1.1.2
map -u

    

Answer 2

IMHO, sua abordagem é excessivamente complexa. Você está usando o CSM da EFI do seu computador para executar uma segunda implementação de EFI a partir de um disco externo e, em seguida, carregando um driver EFI na segunda implementação da EFI. Várias alternativas me ocorrem:

• Você pode executar um shell EFI no EFI nativo do seu computador e executar o script a partir dele para carregar o driver EFI. Isso elimina o CSM e a segunda implementação da EFI, o que deve reduzir o tempo de inicialização e melhorar a confiabilidade. Dito isso, essa opção provavelmente produziria o mesmo problema que você está vendo.
• Você pode executar meu rEFInd na EFI nativa do computador e configurar seu driver como um que o rEFInd carrega automaticamente. Uma grande ressalva é que o código de carregamento de driver do rEFInd foi bem testado para sistemas de arquivos, mas não para outros tipos de drivers, então não posso prometer que ele carregaria seu driver. Além disso, mesmo que tenha carregado o driver, você poderá encontrar um problema semelhante ao que já está encontrando.
• Você poderia colocar seu (s) carregador (s) de inicialização e, se necessário, o (s) kernel (s) do sistema operacional na mídia que a sua EFI nativa pode ler, evitando a necessidade de um driver NVMe. Como você já está usando uma unidade flash USB para o DUET, você pode usar isso; ou presumivelmente seu computador suporta outros tipos de disco rígido, portanto você pode usar um deles, mesmo que não seja seu tipo de armazenamento primário. Como não sou especialista em Windows, não posso sugerir especificamente como disponibilizar o Windows para fazer isso.

Dito isso, não sei a resposta para sua pergunta direta. É claramente causado pelo remapeamento de dispositivos quando você carrega o novo driver, que "puxa o tapete para fora" do shell.