Le bios Sony VAIO avec Insyde H2O EFI ne démarre pas dans GRUB EFI
J'ai acheté un nouvel ordinateur portable Sony Vaio série S. 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 existe 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 sda1 EFI (ESP) se charge dans cette reprise.
Le fichier sda3 ESP contient des entrées plus étoffées pour Microsoft Windows, qui passe en fait à Windows 7 (comme l'a confirmé bcdedit.exe sous 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 ma vie, je ne peux pas le définir par défaut! J'ai essayé de créer un fichier sda3/startup.nsh qui s'appelait grubx64.efi, mais cela n'a pas aidé - lors du redémarrage, le système démarre toujours sous Windows. J'ai essayé d'utiliser efibootmgr, et ça se voit:
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, lors du redémarrage, comme vous l'avez deviné, la machine a redémarré directement dans Windows.
Les seules choses auxquelles je peux penser sont:
- La partition sda1 est en quelque sorte utilisée
- Remplacez /EFI/Boot/bootx64.efi et /EFI/Microsoft/Boot/bootmgfw.efi avec 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 cette question me rend folle!
J'ai finalement pu résoudre ce problème. J'ai remplacé le fichier EFI/Microsoft/boot/bootmgfw.efi par le fichier grub64.efi. J'ai renommé l'ancien en bootmgfw.efi.old et j'ai utilisé grub pour ajouter une option de menu dans laquelle charger Chainload.
Cela implique que le microprogramme 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:
- Regardez dans /EFI/Microsoft/Boot/fwbootmgr.efi; si présent, démarrez-le.
- Recherchez dans tous les sous-répertoires de/EFI/pour grubx64.efi. Si présent, démarrez-le.
- Démarrer /EFI/Boot/bootx64.efi
- Affiche un message d'erreur, tel que "Système d'exploitation introuvable".
Sous Linux, l'outil efibootmgr fonctionne, mais il affiche de nombreuses absurdités générées automatiquement, y compris le dernier lecteur USB que vous avez utilisé.
Voici comment j'ai appris tout cela:
- J'ai ouvert ma nouvelle machine et j'ai réduit la partition Windows afin d'installer côte à côte Linux et Mac.
- J'ai installé Ubuntu 12.10 et le programme d'installation a remplacé fwbootmgr.efi, en sauvegardant l'ancien chargeur de démarrage Windows.
- J'ai restauré l'ancien programme d'amorçage Windows, mais je n'ai pu démarrer que Windows.
- J'ai renommé le chargeur de démarrage Windows en quelque chose de faux, puis Grub BL a pris le relais.
- J'ai renommé le répertoire ubuntu en quelque chose d'autre, et Grub est toujours chargé, même si j'avais installé rEFInd.
La seule façon pour moi de trouver ce que je voulais était la suivante:
Déplacez fwbootmgr.efi vers son répertoire parent; rEFInd le trouvera toujours et Windows ne se plaindra pas de l'avoir renommé.
- Renommez grubx64.efi en rfgrubx64.efi ou quelque chose d’autre reconnaissable.
- Copiez rEFInd de/EFI/refind vers/EFI/boot, renommez /EFI/refind_x64.efi en * .bak, et enfin renommez /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 depuis 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 reste un désastre dans mon expérience. Je refuse de le toucher pendant un moment.)
Tout d'abord, vous n'avez pas deux ESP. Un ESP est une partition avec un code de type de partition de C12A7328-F81F-11D2-BA4B-00A0C93EC93B, qui est identifié comme une partition avec son "indicateur de démarrage". Votre sortie indique que seul "/ dev/sda3 a son" indicateur de démarrage ", vous n'avez donc qu'un seul ESP -/dev/sda3. Sous GPT, les partitions peuvent avoir des noms et vous avez deux partitions nommées "partition système EFI", mais ces noms sont utilisés uniquement à des fins d'identification humaine. Donc, je suppose que vous (ou un utilitaire automatique) avez créé un fichier/dev/sda1 dans le but de le transformer en ESP, mais il y a eu une erreur lors de la définition de son code de type de partition ou un autre utilitaire a modifié de manière incorrecte son code de type. C12A7328-F81F-11D2-BA4B-00A0C93EC93B à autre chose.
Il y a plusieurs façons de corriger cela. Le plus simple est de 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 vous évitera toute confusion, mais vous disposerez bien entendu de 273 Mo d'espace disque inutilisé. Sinon, vous pouvez également utiliser cet espace, en modifiant si nécessaire le nom et le code du type pour éviter toute confusion. EFI autorise explicitement plusieurs ESP, vous pouvez donc modifier le code de type (en définissant le "drapeau de démarrage" à l'aide de Parted, par exemple) et utiliser les deux ESP; mais cela pourrait être déroutant.
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 entré quelque chose dans votre commande efibootmgr. Je ne vois pas de fautes de frappe évidentes, mais si le binaire GRUB ne se trouve pas à l'emplacement spécifié, la commande ne fonctionnera pas. Les options "--gpt" et "--write-signature" sont presque certainement inutiles et pourraient éventuellement causer des problèmes, mais probablement pas.
- Votre micrologiciel pourrait 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 qui fait que la variable d'ordre de démarrage est ignorée. 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 peut être endommagé de manière à ce que le microprogramme refuse de le lancer. Il passe donc à l'élément suivant de la séquence d'amorçage.
Vous pouvez essayer d’ajuster votre commande efibootmgr, de localiser un nouveau fichier binaire ou d’autre chose pour tester ces possibilités. Si tout échoue, je vous recommande de procéder comme suit:
- Supprimez toutes les entrées de démarrage à l’aide de efibootmgr ou de votre microprogramme (s’il fournit une interface pour le faire).
- Copiez grubx64.efi dans EFI/Boot/bootx64.efi sur l'ESP.
- Si, au redémarrage, vous obtenez toujours Windows, renommez EFI/Microsoft/Boot/bootmgfw.efi en EFI/Microsoft/bootmgfw.efi.
Cela devrait permettre à GRUB de démarrer en utilisant le nom par défaut du chargeur de démarrage (EFI/Boot/bootx64.efi). Un problème avec ceci est que GRUB peut ne pas avoir d’entrée fonctionnelle 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 fichiers 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. Le rapatriement est une branche du rapatriement avec de nombreuses corrections de bogues et mises à jour, y compris un meilleur support UEFI. (Il semble que la confiance ait été abandonnée il y a environ deux ans.) Ainsi, je recommande d'utiliser rEFInd plutôt que rEFIt - mais je suis le responsable de la recherche, donc je ne suis pas un observateur indépendant sur ce point. Malheureusement, AFAIK RFID 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:
Installez Ubuntu 12.04 à partir de l'USB aux côtés de win7.
monter/dev/sda3 depuis live-session
- copier EFI/ubuntu/grubx64.efi dans EFI/Boot /
- renommer EFI/Boot/bootx64.efi en bootx64.efi.old
- renommer EFI/Boot/grubx64.efi en bootx64.efi
maintenant, il démarre directement dans grub2, mais sans entrée dans 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 suggère deux alternatives différentes:
Ne pas écraser Windows MBR mais tilisez-le pour lancer grub
modifier les paramètres du bios (f2 ou f3 au démarrage) dans les options de démarrage d’UEFI à LEGACY, il lancera normalement le dernier système installé
- Exécuter Boot-Repair à partir d'un liveCD/liveUSB
- Cliquez sur le bouton
Recommended Repair. (Ceci installera automatiquement les paramètres corrects pour grub-efi, y compris les paramètres SecureBoot si nécessaire et le changement de nom des fichiers EFI au cas où le micrologiciel UEFI serait verrouillé sur les fichiers Windows). Indiquez l'URL qui apparaîtra s'il y a un problème.
