Sony VAIO con il BIOS EFI Insyde H2O non si avvia in GRUB EFI

Ho comprato un nuovo laptop Sony Vaio serie S. Utilizza Insyde H2O BIOS EFI e provare a installare Linux su di esso mi sta facendo impazzire.

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

Ciò che sorprende è che ci sono 2 partizioni di sistema EFI sul disco. La partizione sda2 è una partizione di ripristino da 20 GB che carica Windows con un'interfaccia di ripristino di base. Questo è accessibile premendo il pulsante "ASSIST" rispetto al normale pulsante di accensione. Presumo che la partizione di sistema EFI sda1 (ESP) venga caricata in questo ripristino.

L'ESP sda3 ha voci più elaborate per Microsoft Windows, che in realtà va su Windows 7 (come confermato da bcdedit.exe su Windows). Ubuntu è installato su sda6 e durante l'installazione ho scelto sda3 come partizione di avvio. Il programma di installazione ha creato correttamente un'applicazione sda3 / EFI / ubuntu / grubx64.efi.

Il vero problema: per la mia vita, non posso impostarlo come predefinito! Ho provato a creare un sda3 / startup.nsh che si chiamava grubx64.efi, ma non ha aiutato - al riavvio, il sistema si avvia ancora su Windows. Ho provato a usare efibootmgr, e questo dimostra come ha funzionato:

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

Tuttavia, al riavvio, come hai intuito, il computer si è riavviato direttamente in Windows.

Le uniche cose che mi vengono in mente sono:

1. La partizione sda1 viene in qualche modo utilizzata
2. Sovrascrivi /EFI/Boot/bootx64.efi e /EFI/Microsoft/Boot/bootmgfw.efi con grubx64.efi [ma questo sembra davvero radicale].

Per favore qualcuno può aiutarmi? Grazie - ogni aiuto è molto apprezzato, poiché questo problema mi sta facendo impazzire!

Alla fine sono stato in grado di risolverlo. Ho sostituito EFI / Microsoft / boot / bootmgfw.efi con grub64.efi. Ho rinominato il primo in bootmgfw.efi.old e ho usato grub per aggiungere un'opzione di menu per caricarlo in catena.

Ciò implica che il firmware è codificato per cercare il bootloader di Microsoft Windows e non rispetta le impostazioni di efibootmgr o startup.nsh. È davvero terribile.

Ho scoperto come funziona il processo di avvio di Sony EFI:

1. Cerca in /EFI/Microsoft/Boot/fwbootmgr.efi; se presente, avviarlo.
2. Cerca in tutte le sottodirectory di / EFI / per grubx64.efi. Se presente, avvialo.
3. Avviare /EFI/Boot/bootx64.efi
4. Visualizza un messaggio di errore, ad esempio "Sistema operativo non trovato".

Sotto Linux, lo strumento efibootmgr funziona, ma mostra molte sciocchezze generate automaticamente, inclusa l'ultima unità USB che hai usato.

Ecco come ho imparato tutto questo:

1. Ho aperto la mia nuova macchina e ho compresso la partizione di Windows per installare Linux e Mac fianco a fianco.
2. Ho installato Ubuntu 12.10 e il programma di installazione ha sovrascritto fwbootmgr.efi, eseguendo il backup del vecchio bootloader di Windows.
3. Ho ripristinato il vecchio bootloader di Windows, ma non sono riuscito ad avviare nulla tranne Windows.
4. Ho rinominato il bootloader di Windows in qualcosa di falso, e poi Grub BL ha preso il controllo.
5. Ho rinominato la directory di Ubuntu in qualcos'altro e Grub è stato ancora caricato, anche se avevo installato rEFInd.

6. L'unico modo in cui sono riuscito a trovare REF per fare quello che volevo era questo:

7. Sposta fwbootmgr.efi nella sua directory principale; rEFInd lo troverà comunque e Windows non si lamenterà di averlo rinominato.

8. Rinomina grubx64.efi in rfgrubx64.efi o qualcos'altro riconoscibile.
9. Copia rEFInd da / EFI / refind in / EFI / boot, rinomina /EFI/refind_x64.efi in * .bak e infine rinomina /Boot/refind_x64.efi in bootx64.efi. Ora dovresti essere in grado di avviare Windows BL o GRUB da rEFInd. Ho intenzione di aggiornare la mia installazione di MacOS a Clover e caricare anche Clover da rEFInd.

(Forse è possibile utilizzare Windows Boot Manager per fare tutto questo, ma il supporto EFI di EeasyBCD è ancora un disastro nella mia esperienza. Mi rifiuto di toccarlo di nuovo per un po '.)

Innanzitutto, non hai due ESP. Un ESP è una partizione con un codice del tipo di partizione di C12A7328-F81F-11D2-BA4B-00A0C93EC93B, che parted identifica come una partizione con il suo set di "flag di avvio". Il tuo output indica che solo / dev / sda3 ha il suo "flag di avvio" impostato, quindi hai un solo ESP - / dev / sda3. In GPT, le partizioni possono avere nomi e hai due partizioni con il nome "partizione di sistema EFI", ma questi nomi sono usati solo a scopo di identificazione umana. Quindi, la mia ipotesi è che tu (o qualche utilità automatica) hai creato un / dev / sda1 con l'intento di renderlo un ESP, ma o c'è stato un errore nell'impostazione del suo codice del tipo di partizione o qualche altra utility ha modificato erroneamente il suo codice del tipo da C12A7328-F81F-11D2-BA4B-00A0C93EC93B a qualcos'altro.

Esistono diversi modi per correggere questo. Il più semplice è semplicemente cambiare il nome di / dev / sda1 per evitare confusione. Se ritieni che / dev / sda1 non abbia alcuno scopo, puoi eseguirne il backup ed eliminarlo. Questo lo toglierà di mezzo ed eviterà confusione, ma ovviamente avrai 273 MB di spazio su disco inutilizzato. In alternativa, è possibile dedicare lo spazio ad altri scopi, se necessario modificando il nome e il codice del tipo per evitare confusione. EFI consente esplicitamente più ESP, quindi è possibile modificare il codice del tipo (impostando il "flag di avvio" utilizzando parted, ad esempio) e utilizzare entrambi gli ESP; ma questo potrebbe essere fonte di confusione.

È probabile che questo problema non sia correlato alla tua incapacità di avviare Linux, poiché sembra che tutti i file rilevanti siano su / dev / sda3. Mi vengono in mente diverse possibili ragioni per questo problema:

• Potrebbe essere che hai sbagliato a digitare qualcosa nel tuo comando efibootmgr. Non vedo errori di battitura ovvi, ma se il binario di GRUB non si trova dove hai specificato, il comando non funzionerà. Le opzioni "--gpt" e "--write-signature" sono quasi certamente superflue e potrebbero probabilmente causare problemi, ma molto probabilmente non lo sono.
• Il tuo firmware potrebbe avere un bug che causa effetti temporanei del comando efibootmgr. Prova a riavviare e quindi digita "sudo efibootmgr -v" per vedere se la voce che hai creato è sopravvissuta al riavvio.
• Il firmware potrebbe contenere un bug che causa l'ignoramento della variabile dell'ordine di avvio. Ho una scheda madre del genere; si avvia nell'ordine in cui vengono create le voci di avvio, anziché nell'ordine in cui sono specificate dalla variabile BootOrder. Per aggirare questo errore, è necessario eliminare tutte le voci e ricrearle nell'ordine di avvio che si desidera utilizzare.
• Il tuo binario grubx64.efi potrebbe essere danneggiato in modo tale che il firmware si rifiuti di avviarlo, quindi passa all'elemento successivo nell'ordine di avvio.

Puoi provare a regolare il tuo comando efibootmgr, individuare un nuovo binario o quant'altro per testare queste possibilità. Se tutto il resto fallisce, ti consiglio di fare quanto segue:

1. Elimina tutte le voci di avvio usando efibootmgr o il tuo firmware (se fornisce un'interfaccia per farlo).
2. Copia grubx64.efi su EFI / Boot / bootx64.efi sull'ESP.
3. Se al riavvio si ottiene ancora Windows, rinominare EFI / Microsoft / Boot / bootmgfw.efi in EFI / Microsoft / bootmgfw.efi.

Questo dovrebbe avviare GRUB usando il nome predefinito per il boot loader (EFI / Boot / bootx64.efi). Un problema è che GRUB potrebbe non avere una voce funzionante per Windows. Probabilmente puoi crearne uno manualmente; una voce come questa dovrebbe funzionare:

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

In alternativa, è possibile installare rEFIt o rEFInd come EFI / Boot / bootx64.efi. Si noti che i binari rEFIt disponibili dal suo sito non funzioneranno su PC basati su UEFI; dovrai usare la versione nei repository Ubuntu. rEFInd è un fork di rEFIt con numerose correzioni e aggiornamenti di bug, incluso un migliore supporto UEFI. (rEF Sembra essere stato abbandonato circa due anni fa.) Pertanto, raccomando di usare rEFInd piuttosto che rEFIt - ma sono il manutentore di rEFInd, quindi non sono un osservatore indipendente su questo punteggio. Sfortunatamente, AFAIK rEFInd non è (ancora) incluso nei repository di Ubuntu, quindi dovrai scaricarlo e installarlo manualmente.

Stessa posizione di partenza qui su una nuova serie sony vaio e. Grazie Rod per la tua risposta.

Nel caso in cui qualcuno abbia bisogno di una procedura dettagliata, questo è ciò che ha funzionato per me:

Ubuntu 12.04 installato da USB insieme a win7.

montaggio / dev / sda3 da live-session

• copia EFI / ubuntu / grubx64.efi su EFI / Boot /
• rinominare EFI / Boot / bootx64.efi in bootx64.efi.old
• rinominare EFI / Boot / grubx64.efi in bootx64.efi

ora si è avviato direttamente in grub2, ma senza voce win7

dopo aver caricato Ubuntu ho modificato

/etc/grub.d/40_custom

aggiungendo

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

e dopo

sudo update-grub

tutto funziona bene

Suggerisco due diverse alternative:

1. Non sovrascrivere windows mbr ma usalo per avviare grub

2. modifica le impostazioni del BIOS ( f2o f3all'avvio) nelle opzioni di avvio da UEFI a LEGACY, quindi avvierà normalmente l'ultimo sistema installato come sempre

1. Esegui Boot-Repair da un liveCD / liveUSB
2. Fai clic sul Recommended Repairpulsante (questo installerà automaticamente i parametri corretti per grub-efi, inclusi i parametri SecureBoot se necessario, e rinominando i file EFI nel caso in cui il firmware UEFI sia bloccato su file Windows). Indica l'URL che verrà visualizzato in caso di problemi.