O Sony VAIO com bios Insyde H2O EFI não inicializa no GRUB EFI

Comprei um novo laptop da série Sony Vaio S. Ele usa o Insyde H2O BIOS EFI, e tentar instalar o Linux nele está me deixando louco.

root@kubuntu:~# parted /dev/sda print
Model: ATA Hitachi HTS72756 (scsi)
Disk /dev/sda: 640GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start  End    Size    File system  Name                          Flags
 1      1049kB  274MB  273MB  fat32        EFI system partition          hidden
 2      274MB  20.8GB  20.6GB  ntfs        Basic data partition          hidden, diag
 3      20.8GB  21.1GB  273MB  fat32        EFI system partition          boot
 4      21.1GB  21.3GB  134MB                Microsoft reserved partition  msftres
 5      21.3GB  342GB  320GB  ntfs        Basic data partition
 6      342GB  358GB  16.1GB  ext4        Basic data partition
 7      358GB  374GB  16.1GB  ntfs        Basic data partition
 8      374GB  640GB  266GB  ntfs        Basic data partition

O que é surpreendente é que existem 2 partições do sistema EFI no disco. A partição sda2 é uma partição de recuperação de 20 GB que carrega janelas com uma interface básica de recuperação. Isso pode ser acessado pressionando o botão "ASSIST", ao contrário do botão de energia normal. Presumo que a partição do sistema sda1 EFI (ESP) seja carregada nessa recuperação.

O sda3 ESP possui entradas mais detalhadas para o Microsoft Windows, que realmente entra no Windows 7 (conforme confirmado pelo bcdedit.exe no Windows). O Ubuntu está instalado no sda6 e, durante a instalação, escolhi o sda3 como minha partição de inicialização. O instalador criou corretamente um aplicativo sda3 / EFI / ubuntu / grubx64.efi.

O verdadeiro problema: para a minha vida, não posso defini-lo como o padrão! Tentei criar um sda3 / startup.nsh chamado grubx64.efi, mas não ajudou - na reinicialização, o sistema ainda inicializa no Windows. Eu tentei usar o efibootmgr, e isso mostra como funcionou:

root@kubuntu:~# efibootmgr 
BootCurrent: 0000
BootOrder: 0000,0001
Boot0000* EFI USB Device
Boot0001* Windows Boot Manager
root@kubuntu:~# efibootmgr --create --gpt --disk /dev/sda --part 3 --write-signature --label "GRUB2" --loader "\\EFI\\ubuntu\\grubx64.efi" 
BootCurrent: 0000
BootOrder: 0002,0000,0001
Boot0000* EFI USB Device
Boot0001* Windows Boot Manager
Boot0002* GRUB2
root@kubuntu:~# efibootmgr
BootCurrent: 0000
BootOrder: 0002,0000,0001
Boot0000* EFI USB Device
Boot0001* Windows Boot Manager
Boot0002* GRUB2

No entanto, ao reiniciar, como você adivinhou, a máquina foi reiniciada diretamente no Windows.

As únicas coisas em que consigo pensar são:

1. A partição sda1 está sendo usada de alguma forma
2. Substitua /EFI/Boot/bootx64.efi e /EFI/Microsoft/Boot/bootmgfw.efi com grubx64.efi [mas isso parece realmente radical].

Alguém por favor pode me ajudar? Obrigado - qualquer ajuda é muito apreciada, pois esse problema está me deixando louco!

Acabei conseguindo resolver isso. Substituí o EFI / Microsoft / boot / bootmgfw.efi pelo grub64.efi. Renomeei o primeiro para bootmgfw.efi.old e usei o grub para adicionar uma opção de menu para carregar em cadeia nele.

Isso implica que o firmware está codificado para procurar o carregador de inicialização do Microsoft Windows e não respeita as configurações do efibootmgr ou o startup.nsh. Isso é realmente terrível.

Descobri como o processo de inicialização Sony EFI funciona:

1. Procure em /EFI/Microsoft/Boot/fwbootmgr.efi; se houver, inicialize-o.
2. Procure em todos os subdiretórios de / EFI / grubx64.efi. Se presente, inicialize-o.
3. Inicialize /EFI/Boot/bootx64.efi
4. Exiba uma mensagem de erro, como "Sistema operacional não encontrado".

No Linux, a ferramenta efibootmgr funciona, mas exibe muitas bobagens geradas automaticamente, incluindo a última unidade USB que você usou.

Aqui está como eu aprendi tudo isso:

1. Abri minha nova máquina e derrubei a partição do Windows para instalar o Linux e o Mac lado a lado.
2. Instalei o Ubuntu 12.10 e o instalador substituiu o fwbootmgr.efi, fazendo o backup do antigo carregador de inicialização do Windows.
3. Eu restaurei o antigo carregador de inicialização do Windows, mas não consegui inicializar nada, exceto o Windows.
4. Renomeei o gerenciador de inicialização do Windows para algo falso e, em seguida, o Grub BL assumiu.
5. Renomeei o diretório do ubuntu para outra coisa, e o Grub ainda estava carregado, mesmo que eu tivesse instalado o rEFInd.

6. A única maneira de conseguir que eu fizesse o que queria era:

7. Mova fwbootmgr.efi para o diretório pai; O rEFInd ainda o encontrará e o Windows não reclamará que você o renomeou.

8. Renomeie grubx64.efi para rfgrubx64.efi ou algo mais reconhecível.
9. Copie o rEFInd de / EFI / refind para / EFI / boot, renomeie /EFI/refind_x64.efi para * .bak e, finalmente, renomeie /Boot/refind_x64.efi para bootx64.efi. Agora você deve conseguir inicializar o Windows BL ou GRUB a partir do rEFInd. Pretendo atualizar minha instalação do MacOS para o Clover e carregar o Clover também do rEFInd.

(Talvez seja possível usar o Gerenciador de Inicialização do Windows para fazer tudo isso, mas o suporte à EFI do EeasyBCD ainda é uma bagunça na minha experiência. Eu me recuso a tocá-lo novamente por um tempo.)

Primeiro, você não tem dois ESPs. Um ESP é uma partição com um código de tipo de partição C12A7328-F81F-11D2-BA4B-00A0C93EC93B, que partiu identifica como uma partição com seu conjunto de "sinalizador de inicialização". Sua saída indica que apenas / dev / sda3 tem seu "sinalizador de inicialização" definido, então você tem apenas um ESP - / dev / sda3. Na GPT, as partições podem ter nomes e você tem duas partições com o nome "partição do sistema EFI", mas esses nomes são usados ​​apenas para fins de identificação humana. Portanto, meu palpite é que você (ou algum utilitário automático) criou um / dev / sda1 com a intenção de torná-lo um ESP, mas houve um erro ao definir seu código de tipo de partição ou algum outro utilitário alterou indevidamente seu código de tipo de C12A7328-F81F-11D2-BA4B-00A0C93EC93B para outra coisa.

Existem várias maneiras de corrigir isso. O mais simples é apenas mudar o nome de / dev / sda1 para evitar confusão. Se você acha que / dev / sda1 não serve para nada, faça o backup e exclua-o. Isso o desviará do caminho e evitará confusão, mas é claro que você terá 273 MB de espaço em disco não utilizado. Como alternativa, você pode dedicar o espaço a algum outro objetivo, se necessário, alterar o nome e o código do tipo para evitar confusão. O EFI permite explicitamente vários ESPs, para que você possa alterar o código de tipo (configurando o "sinalizador de inicialização" usando parted, por exemplo) e use os dois ESPs; mas isso pode ser confuso.

As chances são de que esse problema não esteja relacionado à sua incapacidade de inicializar o Linux, pois parece que todos os arquivos relevantes estão em / dev / sda3. Várias razões possíveis para esse problema me ocorrem:

• Pode ser que você digitou algo errado no seu comando efibootmgr. Não vejo erros de digitação óbvios, mas se o binário do GRUB não estiver localizado onde você especificou, o comando não funcionará. As opções "--gpt" e "--write-signature" são quase certamente desnecessárias e podem estar causando problemas, mas provavelmente não o são.
• Seu firmware pode ter um bug que está causando efeitos temporários no comando efibootmgr. Tente reiniciar e digite "sudo efibootmgr -v" para ver se a entrada que você criou sobreviveu a uma reinicialização.
• Seu firmware pode ter um bug que está fazendo com que a variável de ordem de inicialização seja ignorada. Eu tenho uma placa-mãe assim; ele é inicializado na ordem em que as entradas de inicialização são criadas, e não na ordem em que são especificadas pela variável BootOrder. Para contornar esse bug, você teria que excluir todas as entradas e recriá-las na ordem de inicialização que deseja usar.
• Seu binário grubx64.efi pode ser danificado de tal forma que o firmware se recusa a iniciá-lo e, portanto, prossegue para o próximo item na ordem de inicialização.

Você pode tentar ajustar seu comando efibootmgr, localizar um novo binário ou outros enfeites para testar essas possibilidades. Se tudo mais falhar, recomendo que você faça o seguinte:

1. Exclua todas as entradas de inicialização usando o efibootmgr ou seu firmware (se houver uma interface para fazer isso).
2. Copie grubx64.efi para EFI / Boot / bootx64.efi no ESP.
3. Se, ao reiniciar, você ainda obter o Windows, renomeie EFI / Microsoft / Boot / bootmgfw.efi para EFI / Microsoft / bootmgfw.efi.

Isso deve iniciar o GRUB usando o nome padrão para o carregador de inicialização (EFI / Boot / bootx64.efi). Um problema é que o GRUB pode não ter uma entrada funcional para o Windows. Você provavelmente pode criar um manualmente; uma entrada como esta deve funcionar:

menuentry "Windows 7" {
    set root='(hd0,gpt3)'
    chainloader /EFI/Microsoft/bootmgfw.efi
}

Alternativamente, você pode instalar rEFIt ou reencontrar como EFI / boot / BOOTX64.EFI. Observe que os binários de rEFIt disponíveis em seu site não funcionarão em PCs baseados em UEFI; você precisará usar a versão nos repositórios do Ubuntu. O rEFInd é um fork do rEFIt com várias correções e atualizações de erros, incluindo melhor suporte à UEFI. (O rEFIt parece ter sido abandonado há cerca de dois anos.) Portanto, recomendo o uso do rEFInd em vez do rEFIt - mas sou o mantenedor do rEFInd, por isso não sou um observador independente nessa questão. Infelizmente, o AFAIK rEFInd ainda não está incluído nos repositórios do Ubuntu, então você deverá fazer o download e instalá-lo manualmente.

A mesma posição inicial aqui em uma nova série sony vaio e. Obrigado Rod pela sua resposta.

Apenas no caso de alguém precisar de uma explicação, é isso que funcionou para mim:

Instalou o ubuntu 12.04 do USB ao lado do win7.

montagem / dev / sda3 a partir da sessão ao vivo

• copie EFI / ubuntu / grubx64.efi para EFI / Boot /
• renomeie EFI / Boot / bootx64.efi para bootx64.efi.old
• renomeie EFI / Boot / grubx64.efi para bootx64.efi

agora ele inicializou diretamente no grub2, mas sem a entrada win7

depois de carregar o ubuntu eu editei

/etc/grub.d/40_custom

adicionando

menuentry "Windows 7" {
    set root='(hd0,gpt3)'
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

e depois

sudo update-grub

tudo funciona bem

Sugiro duas alternativas diferentes:

1. Não sobrescreva o windows mbr, mas use-o para iniciar o grub

2. alterar as configurações da BIOS ( f2ou f3na inicialização) nas opções de inicialização do UEFI para o LEGACY, ele normalmente iniciará o último sistema instalado como sempre

1. Execute o Reparo de inicialização a partir de um liveCD / liveUSB
2. Clique no Recommended Repairbotão (isso instalará automaticamente os parâmetros corretos para o grub-efi, incluindo os parâmetros do SecureBoot, se necessário, e renomeará os arquivos EFI, caso o firmware UEFI esteja bloqueado nos arquivos do Windows). Indique o URL que aparecerá se houver algum problema.