Sony VAIO avec le bios Insyde H2O EFI ne démarre pas dans GRUB EFI

J'ai acheté un nouvel ordinateur portable Sony Vaio S series. Il utilise Insyde H2O BIOS EFI, et essayer d'installer Linux dessus me rend fou.

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

Ce qui est surprenant, c'est qu'il y a 2 partitions système EFI sur le disque. La partition sda2 est une partition de récupération de 20 Go qui charge les fenêtres avec une interface de récupération de base. Ceci est accessible en appuyant sur le bouton "ASSIST" par opposition au bouton d'alimentation normal. Je suppose que la partition système EFI sda1 (ESP) se charge dans cette récupération.

Le sda3 ESP a des entrées plus étoffées pour Microsoft Windows, qui va en fait dans Windows 7 (comme confirmé par bcdedit.exe sur Windows). Ubuntu est installé sur sda6, et lors de l'installation, j'ai choisi sda3 comme partition de démarrage. Le programme d'installation a correctement créé une application sda3 / EFI / ubuntu / grubx64.efi.

Le vrai problème: pour la vie de moi, je ne peux pas le définir par défaut! J'ai essayé de créer un sda3 / startup.nsh qui s'appelait grubx64.efi, mais cela n'a pas aidé - au redémarrage, le système démarre toujours dans Windows. J'ai essayé d'utiliser efibootmgr, et cela montre que cela a fonctionné:

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

Cependant, au redémarrage, comme vous l'avez deviné, la machine a redémarré directement dans Windows.

Les seules choses auxquelles je peux penser sont:

1. La partition sda1 est en quelque sorte utilisée
2. Remplacez /EFI/Boot/bootx64.efi et /EFI/Microsoft/Boot/bootmgfw.efi par grubx64.efi [mais cela semble vraiment radical].

Est-ce que quelqu'un peut m'aider s'il vous plait? Merci - toute aide est grandement appréciée, car ce problème me rend fou!

J'ai finalement réussi à résoudre ce problème. J'ai remplacé l'EFI / Microsoft / boot / bootmgfw.efi par le grub64.efi. J'ai renommé l'ancien en bootmgfw.efi.old et utilisé grub pour ajouter une option de menu pour y charger en chaîne.

Cela implique que le firmware est codé en dur pour rechercher le chargeur de démarrage Microsoft Windows et ne respecte pas les paramètres efibootmgr ou startup.nsh. C'est vraiment terrible.

J'ai découvert le fonctionnement du processus de démarrage Sony EFI:

1. Regardez dans /EFI/Microsoft/Boot/fwbootmgr.efi; s'il est présent, démarrez-le.
2. Regardez dans tous les sous-répertoires de / EFI / pour grubx64.efi. S'il est présent, démarrez-le.
3. Boot /EFI/Boot/bootx64.efi
4. Affiche un message d'erreur, tel que "Système d'exploitation introuvable".

Sous Linux, l'outil efibootmgr fonctionne, mais il affiche beaucoup de bêtises générées automatiquement, y compris le dernier lecteur USB que vous avez utilisé.

Voici comment j'ai appris tout cela:

1. J'ai ouvert ma nouvelle machine et effondré la partition Windows afin d'installer Linux et Mac côte à côte.
2. J'ai installé Ubuntu 12.10 et le programme d'installation a remplacé fwbootmgr.efi, en sauvegardant l'ancien chargeur de démarrage Windows.
3. J'ai restauré l'ancien chargeur de démarrage de Windows, mais je ne pouvais rien démarrer sauf Windows.
4. J'ai renommé le chargeur de démarrage Windows en quelque chose de faux, puis le Grub BL a pris le relais.
5. J'ai renommé le répertoire ubuntu en quelque chose d'autre, et Grub est toujours chargé, même si j'avais installé rEFInd.

6. La seule façon de faire en sorte que je puisse faire ce que je voulais était la suivante:

7. Déplacez fwbootmgr.efi vers son répertoire parent; rEFInd le trouvera toujours et Windows ne se plaindra pas que vous l'avez renommé.

8. Renommez grubx64.efi en rfgrubx64.efi ou autre chose reconnaissable.
9. Copiez rEFInd de / EFI / refind vers / EFI / boot, renommez /EFI/refind_x64.efi en * .bak et renommez enfin /Boot/refind_x64.efi en bootx64.efi. Vous devriez maintenant pouvoir démarrer Windows BL ou GRUB à partir de rEFInd. Je prévois de mettre à niveau mon installation MacOS vers Clover et de charger Clover à partir de rEFInd également.

(Il est peut-être possible d'utiliser le Gestionnaire de démarrage Windows pour faire tout cela, mais le support EFI d'EeasyBCD est toujours un gâchis dans mon expérience. Je refuse de le toucher à nouveau pendant un certain temps.)

Tout d'abord, vous n'avez pas deux ESP. Un ESP est une partition avec un code de type de partition C12A7328-F81F-11D2-BA4B-00A0C93EC93B, qui s'est séparé identifie comme une partition avec son "indicateur de démarrage" défini. Votre sortie indique que seul / dev / sda3 a son "indicateur de démarrage" défini, vous n'avez donc qu'un seul ESP - / dev / sda3. Sous GPT, les partitions peuvent avoir des noms, et vous avez deux partitions avec le nom "partition système EFI", mais ces noms sont utilisés uniquement à des fins d'identification humaine. Ainsi, je suppose que vous (ou un utilitaire automatique) avez créé un / dev / sda1 avec l'intention d'en faire un ESP, mais soit il y a eu une erreur dans la définition de son code de type de partition, soit un autre utilitaire a incorrectement changé son code de type de C12A7328-F81F-11D2-BA4B-00A0C93EC93B à autre chose.

Il existe plusieurs façons de corriger cela. Le plus simple est de simplement changer le nom de / dev / sda1 pour éviter toute confusion. Si vous pensez que / dev / sda1 ne sert à rien, vous pouvez le sauvegarder et le supprimer. Cela le mettra à l'écart et évitera toute confusion, mais bien sûr, vous aurez alors 273 Mo d'espace disque inutilisé. Alternativement, vous pouvez consacrer l'espace à une autre fin, si nécessaire en changeant le nom et le code de type pour éviter toute confusion. EFI autorise explicitement plusieurs ESP, vous pouvez donc changer le code de type (en définissant le "drapeau de démarrage" en utilisant parted, par exemple) et utiliser les deux ESP; mais cela pourrait prêter à confusion.

Il est probable que ce problème ne soit pas lié à votre incapacité à démarrer Linux, car il semble que tous les fichiers pertinents se trouvent sur / dev / sda3. Plusieurs raisons possibles de ce problème me viennent à l'esprit:

• Il se peut que vous ayez mal saisi quelque chose dans votre commande efibootmgr. Je ne vois aucune faute de frappe évidente, mais si le binaire GRUB ne se trouve pas là où vous l'avez spécifié, la commande ne fonctionnera pas. Les options "--gpt" et "--write-signature" sont presque certainement inutiles, et pourraient vraisemblablement causer des problèmes, mais très probablement pas.
• Votre micrologiciel peut avoir un bogue qui rend les effets de la commande efibootmgr temporaires. Essayez de redémarrer puis tapez "sudo efibootmgr -v" pour voir si l'entrée que vous avez créée a survécu à un redémarrage.
• Votre micrologiciel pourrait avoir un bogue entraînant l'ignorance de la variable d'ordre de démarrage. J'ai une carte mère comme ça; il démarre dans l'ordre dans lequel les entrées de démarrage sont créées, plutôt que dans l'ordre dans lequel elles sont spécifiées par la variable BootOrder. Pour contourner ce bogue, vous devez supprimer toutes les entrées et les recréer dans l'ordre de démarrage que vous souhaitez utiliser.
• Votre binaire grubx64.efi pourrait être endommagé de telle manière que le firmware refuse de le lancer, et ainsi il passe à l'élément suivant dans l'ordre de démarrage.

Vous pouvez essayer d'ajuster votre commande efibootmgr, localiser un nouveau binaire ou autre pour tester ces possibilités. Si tout le reste échoue, je vous recommande de faire ce qui suit:

1. Supprimez toutes les entrées de démarrage à l'aide d'efibootmgr ou de votre micrologiciel (s'il fournit une interface pour ce faire).
2. Copiez grubx64.efi dans EFI / Boot / bootx64.efi sur l'ESP.
3. Si, au redémarrage, vous obtenez toujours Windows, renommez EFI / Microsoft / Boot / bootmgfw.efi en EFI / Microsoft / bootmgfw.efi.

Cela devrait obtenir le démarrage GRUB en utilisant le nom par défaut du chargeur de démarrage (EFI / Boot / bootx64.efi). Un problème avec cela est que GRUB peut ne pas avoir d'entrée de travail pour Windows. Vous pouvez probablement en créer un manuellement; une entrée comme celle-ci devrait fonctionner:

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

Vous pouvez également installer rEFIt ou rEFInd en tant que EFI / Boot / bootx64.efi. Notez que les binaires rEFIt disponibles sur son site ne fonctionneront pas sur les PC basés sur UEFI; vous devrez utiliser la version dans les référentiels Ubuntu. rEFInd est un fork de rEFIt avec de nombreuses corrections de bugs et mises à jour, y compris une meilleure prise en charge UEFI. (rEFIt semble avoir été abandonné il y a environ deux ans.) Ainsi, je recommande d'utiliser rEFInd plutôt que rEFIt - mais je suis le responsable de rEFInd, donc je ne suis pas un observateur indépendant à ce sujet. Malheureusement, AFAIK rEFInd n'est pas (encore) inclus dans les référentiels Ubuntu, vous devrez donc le télécharger et l'installer manuellement.

Même position de départ ici sur une nouvelle série sony vaio e. Merci Rod pour ta réponse.

Juste au cas où quelqu'un aurait besoin d'une procédure pas à pas, voici ce qui a fonctionné pour moi:

Ubuntu 12.04 installé depuis USB avec win7.

montage / dev / sda3 à partir d'une session en direct

• copiez EFI / ubuntu / grubx64.efi vers EFI / Boot /
• renommer EFI / Boot / bootx64.efi en bootx64.efi.old
• renommer EFI / Boot / grubx64.efi en bootx64.efi

maintenant il a démarré directement dans grub2, mais sans entrée win7

après avoir chargé ubuntu j'ai édité

/etc/grub.d/40_custom

ajouter

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

et après

sudo update-grub

tout fonctionne bien

Je propose deux alternatives différentes:

1. N'écrasez pas windows mbr mais utilisez-le pour lancer grub

2. changer les paramètres du bios ( f2ou f3au démarrage) dans les options de démarrage de UEFI à LEGACY, puis il lancera normalement le dernier système installé comme jamais

1. Exécutez Boot-Repair à partir d'un liveCD / liveUSB
2. Cliquez sur le Recommended Repairbouton. (cela installera automatiquement les paramètres corrects pour grub-efi, y compris les paramètres SecureBoot si nécessaire, et renommera les fichiers EFI au cas où le firmware UEFI serait verrouillé sur les fichiers Windows). Indiquez l'URL qui apparaîtra en cas de problème.