[Résolu] réinstaller grub-efi en cas de multi-boot

malbo · Le 29/11/2011, à 15:31

Cas concret : on avait déjà installé une version de Ubuntu (exemple Ubuntu 11.10) dans un système UEFI et on installe une autre version de Ubuntu (exemple Ubuntu 12.04 alpha) en plus de la première. Comme c'est le cas dans une install dans un système Bios, Grub va pointer au démarrage sur le dernier Ubuntu installé (12.04 dans l'exemple) et ça n'est pas forcément souhaitable (dans mon cas, Ubuntu 12.04 est instable et ça me semble risqué de le laisser à ma manœuvre pour gérer le démarrage). Je fais la manip ci-dessous de réinstaller grub pour qu'il pointe sur le première version (Ubuntu 11.10). Les manips sont faites dans VirtualBox configuré en "EFI Enable".
Les manips doivent être faites après choix de démarrage sur la première version (Ubuntu 11.10) dans le menu grub.

ICI JE VALIDE EN MÊME TEMPS LA PROCÉDURE : VOIR LE RÉSUMÉ A LA FIN POUR AVOIR JUSTE LE NÉCESSAIRE

1) Etat des lieux (on observe le fichier grubx64.efi qui contient le pointage vers la partition Ubuntu de démarrage). Résultat de commandes passées dans un terminal :

ls -l /boot/efi/EFI/ubuntu/grubx64.efi
-rwxr-xr-x 1 root root 131072 2011-11-29 14:05 /boot/efi/EFI/ubuntu/grubx64.efi
md5sum /boot/efi/EFI/ubuntu/grubx64.efi
cddd5667f10815c78dc8cba7ea6aee3c  /boot/efi/EFI/ubuntu/grubx64.efi

-----------------------------------------------------
ULTÉRIEUREMENT, je me rends compte que les items 2) et 3) c'est à dire purge de grub-efi et grub-efi-amd64 puis leur réinstallation n'est pas nécessaire. Il suffit de passer la commande "sudo grub-install" depuis l'install Ubuntu choisie pour faire le boulot.

2) Purge de grub-efi et grub-efi-amd64. On passe les commandes suivantes :

sudo apt-get purge grub-efi
sudo apt-get purge grub-efi-amd64

Etat des lieux intermédiaire (rien n'a encore changé):

md5sum /boot/efi/EFI/ubuntu/grubx64.efi
cddd5667f10815c78dc8cba7ea6aee3c  /boot/efi/EFI/ubuntu/grubx64.efi

--------------------------------------------------------

3) Réinstallation de grub-efi (qui va entraîner la réinstall associée de grub-efi-amd64 ):

sudo apt-get install grub-efi

--------------------------------------------------------
4) Etat des lieux final :

ls -l /boot/efi/EFI/ubuntu/grubx64.efi
-rwxr-xr-x 1 root root 131072 2011-11-29 14:19 /boot/efi/EFI/ubuntu/grubx64.efi 
md5sum /boot/efi/EFI/ubuntu/grubx64.efi
ecf9ddcc5007d76e81d05f14bdec7db2  /boot/efi/EFI/ubuntu/grubx64.efi

Il y a bien eu mise à jour du fichier grubx64.efi
On peut vérifier en redémarrant le PC que Grub pointe à présent sur le premier Ubuntu installé (Ubuntu 11.10), l'autre (12.04) étant proposé dans le menu Grub mais c'est bien le grub de Ubuntu 11.10 qui est à présent utilisé.

----------------------------------------------------------------------------------------------------------------------------------------------------

RÉSUMÉ DES COMMANDES :

- Au démarrage du PC, parmi les différentes versions de Ubuntu, sélectionner dans le menu Grub "le Ubuntu" auquel on veut confier la gestion du démarrage et démarrer dessus
- Passer les commandes de purge de grub-efi et grub-efi-amd64 :

sudo apt-get purge grub-efi
sudo apt-get purge grub-efi-amd64

- installer grub-efi qui va réinstaller grub-efi-amd64 qui lui est associé :

sudo apt-get install grub-efi

- redémarrer le PC

Dernière modification par malbo (Le 05/12/2011, à 15:49)

malbo · Le 30/11/2011, à 18:16

Hors sujet mais ça peut servir : faire un chainload vers une autre partition EFI
Dans le cas présent, c'est crétin de chaîner de Ubuntu vers Ubuntu mais ça doit pouvoir servir dans le cas d'un Windows préinstallé en EFI si l'installation "à côté" de Ubuntu est faite avec une partition EFI distincte de la partition EFI Windows préinstallée (voir Nota). Si on veut que tout soit géré par Grub depuis Ubuntu, il faudrait chaîner vers la partition EFI Windows préinstallée en s'inspirant de la méthode ci-dessous.

Etat des lieux :

sudo blkid
/dev/sda1: LABEL="reserve" UUID="35b89685-d81b-400d-be24-0c27869ba397" TYPE="ext2" 
/dev/sda2: SEC_TYPE="msdos" UUID="49BF-CC3B" TYPE="vfat" 
/dev/sda3: UUID="f5f4d7e2-6fbc-4ef1-bed9-1099b16522f9" TYPE="ext4" 
/dev/sda4: UUID="1d116c0b-42a7-45ab-9f22-7a3a5c229779" TYPE="swap" 
/dev/sda5: SEC_TYPE="msdos" UUID="26FD-DB2C" TYPE="vfat" 
/dev/sda6: UUID="1fd813c2-4b23-42a8-8407-829dcac9a8fb" TYPE="ext4" 
/dev/sda7: UUID="a087f471-8098-4b9d-bc43-b3075327b3e1" TYPE="swap" 
/dev/sda8: UUID="80370e15-4e71-431e-b0c1-53b250062320" TYPE="ext4" 
/dev/sda9: UUID="9732012a-6023-4a2e-96c6-0e06c418d263" TYPE="ext4" 
/dev/sda10: UUID="48178bdb-64da-4245-a67e-8040b1c50b60" TYPE="ext4"

sda6 (Ubuntu Precise Alpha) est lié à la partition EFI sda5
sda10 (Ubuntu Natty) est lié à la partition EFI sda2 dont l'UUID est 49BF-CC3B
J'ajoute ce qui suit dans le fichier /etc/grub.d/40_custom dans une session Ubuntu "Précise" en me servant de l'UUID de sda2 :

menuentry "rajout main chainload vers Natty" --class gnu-linux --class gnu --class os {
    search --no-floppy --fs-uuid --set=root 49BF-CC3B  
    chainloader (${root})/efi/ubuntu/grubx64.efi
}

Je passe la commande de mise à jour de grub et au redémarrage du PC, je constate que le chainload fonctionne. J'ai bien d'abord le menu Grub présenté par sda6 (avec Précise en première ligne) et si je choisis l'entrée "rajout main chainload vers Natty", le truc mouline (ça parait bien long) mais on arrive bien sur le menu Grub présenté par sda10 (Natty en première ligne du menu)

Nota : pour un chaînage vers Windows, ce sera /efi/Microsoft/Boot/bootmgfw.efi (au lieu de /efi/ubuntu/grubx64.efi) si j'en crois ce post de l'expert skodabenz : http://ubuntuforums.org/showpost.php?p= … stcount=76
Je me suis d'ailleurs inspiré de son post pour confectionner mon chainload.

Dernière modification par malbo (Le 30/11/2011, à 18:46)

malbo · Le 02/12/2011, à 09:56

j'ai trouvé une meilleure utilisation du mode EFI pour la gestion du multi-boot.
A noter : par rapport au post précédent dans lequel j'avais deux partitions EFI, je suis revenu à la situation normale qui est d'avoir une seule partition EFI depuis laquelle on gère toutes les installations Ubuntu du disque dur.
Le principe est le suivant : au lieu d'avoir un seul fichier grubx64.efi dans /boot/efi/EFI/ubuntu/ (ce qui équivaut en mode Bios à avoir un amorceur de grub dans le MBR) avoir autant de fichiers .efi que d'installations de Ubuntu dans le disque dur.
Application pratique :
1) On démarre sur le Ubuntu utilisé habituellement. supposons que ce soit Natty installé dans sda10. On passe la commande suivante :

gksudo nautilus /boot/efi/EFI/ubuntu

puis on fait un copier-coller du fichier grubx64.efi dans ce même emplacement et on renomme la copie en grubx64_sda10_natty.efi. On a donc deux fichier .efi dans le même emplacement.

2) On redémarre le PC, mais dans le menu Grub, on choisit de démarrer sur Precise qui se trouve dans sda9. Arrivé dans la session Precise, on passe la commande d'installation de Grub afin que le fichier grubx64.efi pointe vers Precise :

sudo grub-install

Quand c'est fait, il faut refaire la même manip que celle faite pour l'autre install :

gksudo nautilus /boot/efi/EFI/ubuntu

puis copier-coller du fichier grubx64.efi dans ce même emplacement et on renomme la copie en grubx64_sda9_precise.efi. Après cela, on se retrouve avec trois fichiers .efi dans l'emplacement :
- grubx64.efi (celui qui vient d'être mis à jour et qui pointe vers sda9_precise)
- grubx64_sda9_precise.efi (qui pointe vers sda9_precise)
- grubx64_sda10_natty.efi (qui pointe vers sda10_natty)

J'espère que vous commencez à comprendre. Cela va permettre de créer autant d'entrées dans le "Boot Manager" du système EFI (une entrée "sda9_precise", une entrée "sda10_natty", etc...). Le système fonctionne, je viens de le tester.

Avantage du procédé : cela permet d'avoir en quelque sorte une sauvegarde d'amorce de chaque installation (l'équivalent d'une sauvegarde de MBR dans un système Bios). Je veux dire qu'en cas d'instabilité du Ubuntu utilisé habituellement et en supposant qu'on ne peut plus démarrer sur lui, il suffit de sélectionner une autre entrée dans le Boot Manager du système EFI pour démarrer sur une autre installation de Ubuntu.

Inconvénient : c'est le revers de la médaille de la qualité exprimée ci-dessus (sauvegarde de l'amorceur). En cas de mise à jour de Grub incluant une modification du contenu de l'amorceur lui-même, seul le fichier grubx64.efi est mis à jour évidemment. Donc en utilisant ces entrées dédiées, on risque de se retrouver à terme avec un amorceur de Grub incompatible avec le Grub installé. C'est évidemment réparable en utilisant la procédure ci-dessus, c'est à dire passer la commande grub-install puis remplacer par copier-coller l'amorceur obsolète mais il faudrait avoir une bonne discipline pour penser à mettre à jour ces amorceurs au fur et à mesure des évolutions de Grub. Pas évident.

Dernière modification par malbo (Le 02/12/2011, à 10:29)

malbo · Le 05/12/2011, à 14:59

Autre manip qui tourne autour du sujet : tentative de forcer l'installateur de Ubuntu à utiliser une partition EFI en FAT32 de 300 Mo (sda1) au lieu de FAT16 (sda7).

J'ai copié tout le contenu de la partition sda7 (qui préexistait et qui avait été créée par une installation précédente de Ubuntu) dans sda1 et j'ai modifié tous les points de montage /boot/efi dans les fstab pour que se soit sur la partition sda1. Ensuite, j'ai même passé des commandes d'installation (sudo grub-install) pour vérifier que j'étais bien capable de mettre à jour l'amorceur qui se trouve sur sda1. résultat : parfait. Les Ubuntu préinstallés utilisent sans rechigner la partition EFI en FAT32.
De plus, depuis le live-CD Gparted, j'ai enlevé le flag sur la partition sda7 (FAT16) pour ne le laisser que sur la partition sda1 (FAT32) afin qu'elle soit vue comme la seule véritable partition EFI

Etat des lieux initial depuis Ubuntu installé sur sda6 avec gdisk :

sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.6.14

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 105027584 sectors, 50.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): BEB0FB41-1E8A-4BB0-BFCC-AD76122FAA14
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 105027550
Partitions will be aligned on 1-sector boundaries
Total free space is 13306376 sectors (6.3 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          616447   300.0 MiB   EF00  
   2        93169585       104985991   5.6 GiB     0700  
   5        83403959        93169584   4.7 GiB     0700  
   6        13800974        32386911   8.9 GiB     0700  
   7       104986624       105025535   19.0 MiB    0700  
  12        32386912        34480127   1022.1 MiB  8200  
  13        34519191        54107081   9.3 GiB     0700  
  14        54146145        67640285   6.4 GiB     0700  
  15        67640286        69732082   1021.4 MiB  8200  
  16        69771146        81312161   5.5 GiB     0700  
  17        81312162        83403958   1021.4 MiB  8200

Etat initial du fichier grubx64.efi qui se trouve dans sda1 :

ls -l /boot/efi/EFI/ubuntu/grubx64.efi
-rwxr-xr-x 1 root root 131072 2011-12-05 12:04 /boot/efi/EFI/ubuntu/grubx64.efi
md5sum /boot/efi/EFI/ubuntu/grubx64.efi
195ec164d7ac4b8cd90cca5e436f2bb7  /boot/efi/EFI/ubuntu/grubx64.efi

------------------------------------------------------------------------------------
installation en mode "Autre chose" de Ubuntu 11.10 sur sda3 (créée pendant l'installation puisque c'était en partitionnement manuel.
--------------------------------------------------------------------------------

Résultat après install dans sda3 (par rapport au précédent, moi je n'y vois que la partition sda3 qui est la partition racine de la nouvelle install):

sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.6.14

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 105027584 sectors, 50.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): BEB0FB41-1E8A-4BB0-BFCC-AD76122FAA14
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 105027550
Partitions will be aligned on 1-sector boundaries
Total free space is 122782 sectors (60.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          616447   300.0 MiB   EF00  
   2        93169585       104985991   5.6 GiB     0700  
   3          616448        13800041   6.3 GiB     0700  
   5        83403959        93169584   4.7 GiB     0700  
   6        13800974        32386911   8.9 GiB     0700  
   7       104986624       105025535   19.0 MiB    0700  
  12        32386912        34480127   1022.1 MiB  8200  
  13        34519191        54107081   9.3 GiB     0700  
  14        54146145        67640285   6.4 GiB     0700  
  15        67640286        69732082   1021.4 MiB  8200  
  16        69771146        81312161   5.5 GiB     0700  
  17        81312162        83403958   1021.4 MiB  8200

Vérif de l'état du fichier grubx64.efi qui se trouve dans sda1:

ls -l /boot/efi/EFI/ubuntu/grubx64.efi
-rwxr-xr-x 1 root root 131072 2011-12-05 12:04 /boot/efi/EFI/ubuntu/grubx64.efi
md5sum /boot/efi/EFI/ubuntu/grubx64.efi
195ec164d7ac4b8cd90cca5e436f2bb7  /boot/efi/EFI/ubuntu/grubx64.efi

Il n'a pas changé. Après vérif complète, il s'avère que cette dernière installation de Ubuntu dans sda3 s'est faite en prenant la partition sda7 qui est en FAT16 (bien qu'elle n'était pas bootable), c'est à dire que le fichier fstab de sda3 contient bien le point de montage de la partition sda7. Par contre, il n'y a pas eu de mise à jour du fichier grubx64.efi, ni dans sda1(comme constaté ci-dessus) ni dans sda7 (je l'ai vérifié en faisant un redémarrage du PC). Cette dernière installation de Ubuntu sur sda3 n'a donc pas installé du tout son amorceur.

Voici des rapports de bug existants sur le format de la partition EFI :
https://bugs.launchpad.net/ubuntu/+sour … bug/769669
https://bugs.launchpad.net/ubuntu/+sour … bug/811485

Le point commun entre ces rapports de bug et ce que j'ai observé, c'est que l'installateur de Ubuntu refuse d'écrire dans la partition FAT32. Par contre, je n'observe pas de désastre comme dans le rapport de bug #769669 (reformatage de la partition EFI).

Dernière modification par malbo (Le 05/12/2011, à 15:55)

coala · Le 05/12/2011, à 23:06

Je suis cette discussion avec intérêt, en effet je possède depuis peu (une semaine) un pc portable de marque HP (ProBook 4330s) et j'essaye en vain d'installer Ubuntu 11.10 via le partitionnement manuel. Cet ordinateur est équipé d'un UEFI.

Je souhaitais passer à Fedora sur ce nouveau pc mais je rencontre le même problème, idem avec d'autres distributions, et j'aime bien installer Ubuntu en mode partitionnement manuel pour avoir la main sur la taille des partitions et séparer le /boot et le /home.

En cherchant un peu j'ai fini par découvrir que c'était un UEFI, et après avoir lu quelques doc et sujets sur les forum (c'est bien compliqué) je n'ai toujours pas trouvé la solution. Certes il y a bien une doc sur le wiki ArchLinux ou encore FedoraWiki, Ubuntu.org (tous en Anglais) mais la procédure est bien compliquée pour un débutant / moyen et puis ce sont surtout des explications pour les possesseurs de Mac.

Donc en découvrant ce post (mais aussi ceux là récents et sur le même sujet http://forum.ubuntu-fr.org/viewtopic.php?pid=7317451 & http://forum.ubuntu-fr.org/viewtopic.php?id=734681) je me demande si cela serait pas une bonne idée que de rédiger une page dans la Documentation, celle-ci ne parle pas de grub-efi (uniquement rEFIt, pour Mac) et pourrait servir à bien des utilisateurs (pas que débutants).
L'UEFI est amené à être de plus en plus utilisé.

Bref j'utilise pour le moment un autre pc comme machine de travail, le hp pouvant servir de machine de test par rapport à l'UEFI si besoin. Si je peut apporter ma modeste contribution sur Ubuntu et l'UEFI...

malbo · Le 05/12/2011, à 23:38

Merci pour ton post coala.
Comme dit au début, j'utilise un PC virtuel (VirtualBox). Il y a des avantages à cela mais je ne peux pas voir la cohabitation Windows 7/Ubuntu parce que Win7 ne veut pas s'installer en mode UEFI dans VirtualBox. C'est bien dommage parce que le sujet qui m'intéresse, c'est ça : Windows préinstallé en mode UEFI et install de Ubuntu en mode UEFI également. C'est pour cette raison que j'ai étudié dans le post #4 le coup de la partition EFI en FAT32 : c'est parce que Windows 7 utilise ce format.
Concernant ton PC HP ProBook 4330s, si ton partitionnement est identique à celui trouvé par sylv1mada pour son HP Probook 4330s dans ce post : http://forum.ubuntu-fr.org/viewtopic.ph … 1#p7106621
tu peux voir qu'il est mentionné "Table de partitions : msdos" donc Windows n'est pas préinstallé d'origine en mode EFI mais en mode Bios. Si tu veux de l'aide pour créer ton dual-boot en mode Bios, je te prie de créer une nouvelle discussion dans la rubrique "Questions et informations avant l'installation" pour ton cas personnel dans laquelle tu répondrais à cette demande de fourniture d'un rapport "Boot Info Script" dès le premier post pour gagner du temps : http://forum.ubuntu-fr.org/viewtopic.php?id=614071
Si tu crées cette nouvelle discussion comme je te le propose, donne ici le lien vers cette nouvelle discussion afin que je puisse éventuellement t'aider.

Au contraire, si ton souhait est de virer complètement le partitionnement actuel de type MBR/Bios pour tout reconstruire en table de partition GPT, j'ai bien dit "tout" virer, ne rien garder des partitions actuelles, ce qui peut impliquer (je n'en suis pas sûr, je ne connais pas suffisamment HP) la perte des logiciels de protection préinstallés que tu as actuellement du fait que tu vas probablement devoir installer en mode UEFI un Win7 "tout nu" sans la glu logicielle fournie par HP. Là, c'est pareil : crée une nouvelle discussion dans la rubrique "Questions et informations avant l'installation" en précisant ce que tu veux faire (virer Bios pour tout passer en UEFI) et donne ici le lien vers cette nouvelle discussion pour que je puisse t'aider si je peux.

Dernière modification par malbo (Le 06/12/2011, à 08:48)

coala · Le 06/12/2011, à 11:21

Merci pour ton aide malbo.
C'est plutôt la seconde solution qui m'intéresse, je n'ai pas besoin de Windows en dual-boot. De plus j'ai, un peu par ignorance, supprimé les partitions d'origines, même si j'ai fait une sauvegarde de la partition recovery et du mbr.

Je ne vais pas m'étendre d'avantage ici. J'ai lu les deux liens que tu m'as fourni mais ils ne répondent pas totalement à mes questions (je garde de côté le "Boot Info Script" c'est bon a savoir). Je vais créer un nouveau sujet dans la rubrique "Questions et informations avant l'installation" comme conseillé.

ps : j'ajouterai le lien dans la journée, je n'ai pas mon pc avec moi en ce moment. Bon finalement ça sera un peu plus tard, je n'ai pas mon pc pour le moment (07/12/11)

Dernière modification par coala (Le 07/12/2011, à 20:25)

ikewdu · Le 14/04/2014, à 06:44

Salut,

Je déterre ce vieux tuto, mais comme la situation m'intéresse, je prends cette liberté car ce sujet est exactement celui qui correspond à ma question. Comme toi, je me penche sur le fonctionnement de grub en uefi, et certaines choses me dépassent un peu. Je résume: J'installe un W8 en uefi avec Vmware. J'installe en parallèle un xubuntu 13.10 en passant par "autre chose", partitions manuelles, etc. Tout est bien, grub s'installe et tout fonctionne... J'en profite pour faire une copie du contenu de la partition efi pour faire quelques tests.

1. Je restaure l'efi avec bcdboot c:\windows (d'abord sans formatage de partition efi, puis avec formatage). W8 reprend seul la main. Normal. Je restaure les fichiers efi d'ubuntu avec les commandes mountvol et copy de W8. Tout est ok, je retrouve mon dual-boot. Bref, depuis un DVD W7 ou W8, on répare absolument tout ce que l'on veut, si on a été prévoyant.

2. Les choses sont plus complexes sous Linux. Si je restaure l'efi original de W8 et que je tente de réinstaller grub depuis le live-cd d'ubuntu (partant du principe que la version installée n'est plus accessible), ce n'est pas la même affaire.

- La copie des mêmes fichiers efi sauvegardés, une fois les partitions montées, fonctionne, mais au reboot, vmware renvoie un message d'erreur (trop rapide à lire) et le démarrage échoue. Problèmes de droits ou autres ? mystère.

- Je me dis, tentons une réinstallation de grub dans les règles de l'art... naïvement, je tente sudo grub-install (et d'autres commandes trouvées ça et là, avec toutes sortes d'extensions possibles, montage des partitions, rien à faire). Je tente même de le faire via la procédure chroot proposée par ubuntu pour réinstaller grub (en adaptant à mes partitions sda2(efi) et sda5 (linux), j'aboutis toujours à un message d'erreur sur le montage de /boot/grub. Même les procédures trouvées sur les sites US (rarement claires, d'ailleurs) n'aboutissent pas.

- Pourtant, boot-repair y parvient, lui (comme l'installateur, d'ailleurs) La réinstallation de grub à la "sauce boot-repair" fonctionne sans problème ... mais les deux étant un peu obscurs, ce qui m'intéresse, c'est bien sûr une réinstallation manuelle et propre de grub.efi

Donc, voici mes questions :

a. Es-tu parvenu à réinstaller complètement grub.efi depuis un live-cd ? Perso, je sèche.

b. Fais-tu le même constat que moi ? L'installateur ubuntu ajoute un dossier grub nommé efi/ubuntu (avec ses 4 fichiers efi) et semble ne plus modifier efi/boot/bootx64.efi (ce qui était le cas auparavant). Le fichier est identique à celui d'origine après installation. J'ai même tenté un renommage de "bootx64.efi" en bootx64.old" ce qui ne change absolument rien au démarrage lorsque le dual-boot fonctionne. J'en déduis donc que vmware lance efi/ubuntu avant efi/boot, même lorsque "windows boot manager" est mis en tête de liste dans l'ordre de boot du bios.

coala · Le 14/04/2014, à 09:35

Salut ikewdu,

Je pourrais difficilement t'apporter une réponse. Au moment de mes posts j'ai bien essayé en vain d'installer à la main Grub-efi sans plus de succès. Le bios de mon PC possédant un bios legacy (fonctionnement d'un bios classique) j'ai laissé tombé l'uefi.

a. Il y a deux ans oui, de ce que je me souvient, mais entièrement avec l'installeur automatique (pas de partitionnement à la main). Donc ça ne me convenait pas.

b. Je ne m'en souvient plus.

En espérant que malbo ou quelqu'un d'autre puisse d'apporter une solution...

ikewdu · Le 14/04/2014, à 23:10

Re,

Je me réponds à moi-même. J'ai trouvé comment réinstaller grub.efi depuis le live-cd en m'inspirant de ce site :

http://superuser.com/questions/376470/h … -grub2-efi

sudo mount /dev/sda5 /mnt #sda5 est ma partition Linux
sudo mount /dev/sda2 /mnt/boot/efi #sda2 est ma partition efi
for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done  (pn monte tout ce qui est nécessaire pour chrooter)
sudo cp /etc/resolv.conf /mnt/etc/ #active le réseau après le chroot
modprobe efivars # efivars semble nécessaire au chroot
sudo chroot /mnt

Ici, les commandes proposées sur le lien fonctionnent mais n'écrivent rien dans la partition boot/efi. J'ai remplacé par un simple

grub-install
sudo update-grub

Le dossier ubuntu et ses quatre fichiers sont ajoutés. On n'a plus qu'à démonter le tout...

Ctrl+D pour sortir du chroot

for i in /sys /proc /dev/pts /dev; do sudo umount /mnt$i; done
sudo umount /mnt/boot/efi 
sudo umount /mnt 
sudo reboot

Dernière modification par ikewdu (Le 15/04/2014, à 06:36)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 29/11/2011, à 15:31

[Résolu] réinstaller grub-efi en cas de multi-boot

#2 Le 30/11/2011, à 18:16

Re : [Résolu] réinstaller grub-efi en cas de multi-boot

#3 Le 02/12/2011, à 09:56

Re : [Résolu] réinstaller grub-efi en cas de multi-boot

#4 Le 05/12/2011, à 14:59

Re : [Résolu] réinstaller grub-efi en cas de multi-boot

#5 Le 05/12/2011, à 23:06

Re : [Résolu] réinstaller grub-efi en cas de multi-boot

#6 Le 05/12/2011, à 23:38

Re : [Résolu] réinstaller grub-efi en cas de multi-boot

#7 Le 06/12/2011, à 11:21

Re : [Résolu] réinstaller grub-efi en cas de multi-boot

#8 Le 14/04/2014, à 06:44

Re : [Résolu] réinstaller grub-efi en cas de multi-boot

#9 Le 14/04/2014, à 09:35

Re : [Résolu] réinstaller grub-efi en cas de multi-boot

#10 Le 14/04/2014, à 23:10

Re : [Résolu] réinstaller grub-efi en cas de multi-boot

Pied de page des forums