Manip dans VirtualBox 4.1.16 avec case cochée pour "Activer EFI (os spéciaux seulement)". J'ai plein de Ubuntu installés en "mode UEFI" (au lieu du classique mode Bios) dans une machine virtuelle et l'envie folle me prend de supprimer la partition EFI depuis le live-CD (virtuel) Gparted. Le scénario, c'est donc une partition EFI écrasée malencontreusement (disparue du disque dur) et qu'il faut reconstituer pour que le PC puisse redémarrer sur le Ubuntu (sda10 dans mon cas) qui est déjà installé sur le disque dur.
- depuis le live-CD Ubuntu (j'ai utilisé un live-CD virtuel Ubuntu 11.10 bien que le Ubuntu installé soit Ubuntu 11.04), avec Gparted, créer une partition de 20 Mo en FAT 16 avec le flag (boot) destinée à devenir la partition EFI, n'importe où sur le disque dur (là ou un espace non-alloué existe et s'il n'en existe pas il faut se débrouiller pour dégager de la place en réduisant une partition existante) puis fermer Gparted.
Comme c'est la première fois que je fais ça et que je ne suis pas certain que Gparted sait faire correctement l'opération, je vérifie en installant gdisk (pour cela, je suis obligé d’activer le dépôt "universe" dans les sources de logiciels) que la partition a bien le code "EF00" qui caractérise une partition EFI
A présent, il faut faire un
chroot vers dans le Ubuntu à réparer (la partition racine du Ubuntu est sda10) :
sudo mkdir /mnt/temp
sudo mount /dev/sda10 /mnt/temp
for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt/temp$i; done
sudo chroot /mnt/temp
Depuis le chroot, passer une commande "blkid -g" puis une commande "blkid" pour récupérer l'UUID de la partition EFI puis avec l'éditeur de texte
nano, modifier le fichier fstab pour remplacer l'UUID obsolete (ben oui, j'ai détruit la partition exprès...) par l'UUID de la partition EFI nouvelle dans la ligne déjà existante dans le point de montage est /boot/efi :
UUID=XXXX-XXXX /boot/efi vfat defaults 0 1
, puis monter la partition par la commande "mount /boot/efi" (vérifier qu'elle est montée correctement en passant un "mount" ensuite)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ATTENTION : L’ÉTAPE SUIVANTE DE DÉSINSTALLATION PUIS RÉINSTALLATION DE GRUB N'EST PAS UTILE DANS LE CAS GÉNÉRAL : ELLE PEUT ÊTRE SAUTÉE --->
passer directement à la commande grub-install
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
- toujours depuis le chroot, désinstaller grub-efi .
apt-get purge grub-efi
puis grub-efi-amd64 .
apt-get purge grub-efi-amd64
puis réinstaller grub-efi (qui réinstallera aussi grub-efi-amd64) :
apt-get install grub-efi
. Vérifier que le fichier /boot/efi/EFI/ubuntu/grubx64.efi existe.
ls -l /boot/efi/EFI/ubuntu/grubx64.efi
résultat : il n'existe pas
bon sang mais c'est bien sûr, il faut passer la commande suivante :
grub-install
ensuite on peut constater que le fichier /boot/efi/EFI/ubuntu/grubx64.efi existe
- démonter le chroot par :
exit
puis par cette commande (cette foutue ligne suivante ne fonctionne pas : rien n'est démonté. tant pis, j'ai la flemme de démonter à la main le contenu de /mnt/temp. heureusement que le live-CD a fait un démontage correct comme j'ai pu le constater en final puisque tout fonctionne...):
for i in /dev/pts /dev /proc /sys; do sudo umount /mnt/temp$i ; done
Arrêt (par les moyens normaux) de la session live-CD.
Au redémarrage de la machine UEFI (VirtualBox), aucune des entrées proposées dans le "Boot Manager" ne permet de démarrer. Il est donc nécessaire de passer par le "Boot Maintenance Manager" (voir
Using Boot Maintenance Menu ) pour faire reconnaître au système UEFI la nouvelle entrée (voir nota). Boot Options > Add boot option ; là, on peut constater que la nouvelle partition EFI est présélectionnée par la grâce d'un automatisme du système EFI qui présente la (ou les) partitions FAT (pas forcément EFI et pas forcément FAT16, ça peut être FAT32) qu'il a trouvé dans le PC et ses périphériques (mais le "Boot Maintenance Manager" veut justement que le chemin vers le fichier .efi soit défini par l'utilisateur afin de créer une nouvelle entrée associée dans le Boot Manager). Je fais donc le boulot (il faut cheminer par EFI > ubuntu > grubx64.efi et valider le tout) en donnant un nom à la nouvelle entrée. Ensuite, sortie par la touche Échap, retour au menu "Boot Manager", sélection de la nouvelle entrée et ça démarre.
Tout fonctionne. J'ai bien réparé le démarrage de mon Ubuntu.
nota : ce qui vient d'être décrit, c'est l'enregistrement d'une entrée pour qu'elle soit proposée dans le "Boot Manager". C'est intéressant mais pas indispensable : on peut utiliser une procédure plus rapide (la première fois) qui est de passer par "Boot Maintenance Manager" > "Boot Options" > "Boot from file" puis de naviguer jusqu'au fichier .efi d'une manière analogue à celle proposée ci-dessus pour arriver à démarrer sur ce fichier .efi. Avantage : on perd moins de temps pour démarrer la première fois. Inconvénient : il n'y a pas de mise en mémoire (contrairement à ce qui est proposé plus haut) et à chaque démarrage, il faut repasser par "Boot Maintenance Manager" > "Boot Options" > "Boot from file". A savoir que cette mise en mémoire (quand on a fait le choix "Add boot option") s'effectue dans un fichier nommé NvVars qui se trouve dans la partition EFI (attention : ce que j'ai écrit là peut être vrai dans le cas particulier où il n'y a qu'une seule partition FAT sur le disque dur qui est la partition EFI mais
c'est faux dans le cas général: voir Edit du 26 sept 2012 ci-dessous).
Edit du 26 sept 2012 : Dans le cas de VirtualBox, le fichier NvVars est placé dans une partition FAT, mais pas forcément dans la partition EFI. D'après mes investigations du jour, le système EFI de VirtualBox prend les partitions dans l'ordre de leur numéro (sda1, sda2, etc..) et pas du tout en fonction de leur position sur le disque. Exemple concret : je supprime ma partition sda1(FAT16) qui contenait le fichier NvVars. Au redémarrage suivant, VirtualBox a créé un nouveau fichier NvVars dans la partition sda4 (FAT16) située tout à la fin du disque dur virtuel. Pourquoi ? il a pris dans l'ordre : partition sda2 sautée (elle est en ext4) ; partition sda3 sautée (elle est en ext4) ; partition sda4 retenue (elle est en FAT). Si je supprime sda4, il va utiliser la prochaine partition FAT dans l'ordre de numérotation et ainsi de suite. Si on supprime la totalité des partitions FAT (pour ne laisser que des ext4 et des swap), au démarrage le "Boot Maintenance Manager" ne peut plus enregistrer d'entrées (Boot Options > Add boot option ne fonctionne pas) et Boot Maintenance Manager" > "Boot Options" > "Boot from file" ne mène à rien puisqu'il n'y a plus aucun fichier .efi. Il est donc impossible de démarrer sur une Ubuntu installée du fait qu'il n'y a plus aucun chargeur d'amorçage.
