De nombreux sujets sont ouverts sur les forums pour signaler que l’installation d’Ubuntu (entre autres) sur certains PC en UEFI conduit à une erreur en fin de procédure, ce qui rend l’OS inutilisable. On rencontre de nombreux exemples qui ressemblent à ceci :
« Echec de l’installation de GRUB »
Le paquet GRUB-efi-amd64 n’a pas pu être installé dans /target/. En l’absence du programme de démarrage GRUB, le système installé ne pourra pas démarrer.
L’objet de cette démo est de présenter un moyen de contournement basé sur une installation en simple boot, mais il n’est pas substituable à tous les cas de verrouillage.
Donc, cette démo est informative, et on ne la suit qu’à ses risques et périls.
I. Présentation de la situation
En image, c’est plus parlant. Voici un exemple d’installation défailllante.
Les raisons de ce souci sont multiples… ça peut être
- la partition efi qui est absente ou non inscriptible
- la version de Grub qui n’est pas bonne
- la NVram qui est plombée par le constructeur.
- Une autre raison spécifique à la marque du PC.
Les pistes sont nombreuses, et c’est souvent difficile à résoudre. C’est même parfois définitivement bloquant. Par ailleurs, on peut être tenté de vouloir réparer l’installation en forçant l’installation de grub, mais c’est une piste que je déconseille.
En effet, il faut savoir que des outils de lancement sur USB comme SG2D et Refind parviennent à lancer la version mal installée depuis le noyau grub, mais on aboutit à ceci :
Cette erreur s’explique par le fait que certaines commandes dpkg, certaines désinstallations, entre autres, ne sont pas allées à leur terme. Dès lors, on a sous la main une installation bancale. Je préconise donc de réinstaller intégralement, mais d’une autre manière.
II. Installation de Xubuntu en UEFI sans Grub
1. Les étapes de l’installation
Je choisis Xubuntu pour une question de légèreté, car je fais cette démo depuis un PC virtuel. Par ailleurs, je fais cette démo sur une installation en simple boot (sans Windows) pour une question de clarté. Je parlerai du dual-boot avec Windows au fil des étapes.
J’ai expliqué comment faire une installation sans Grub dans ce sujet, mais je vais en reprendre les grandes lignes.
- Avec gparted, on crée une table de partitions gpt, format attendu pour une installation en UEFI (à noter que pour avoir le clavier en français, un setxkbmap fr préalable dans un terminal ne sera pas superflu).
On en profite pour créer deux partitions. Une partition en fat32 de 100 Mio environ à laquelle on assigne les drapeaux esp et boot pour en faire une partition EFI (dans le cas d’un dual boot, celle-ci existant déjà pour lancer Windows, on n’aura pas besoin créer cette partition efi en fat32). Puis on crée une partition ext4 sur le reste du disque. On aura une structure proche de ceci (capture simplement illustrative, car issue d’une autre installation… ce qui explique le contenu et l’ordre des partitions)
Notre disque est prêt pour l’installation.
On vérifie qu’on est bien en mode UEFI pour notre installation via la commande efibootmgr qui ne doit pas retourner d’erreur. Si on a une erreur, c’est que notre Live USB est exécuté dans un mauvais mode.
*** Alternative à cette commande :
[ -d /sys/firmware/efi ] && echo "Session EFI" || echo "Session non-EFI"
Elle doit retourner « Session EFI« . Si c’est le cas, on passe à la suite.
- Installation via le terminal
Au lieu d’utiliser le raccourci sur le bureau, on lance un terminal et on saisit
ubiquity -b
Les étapes habituelles de l’installation sont proposées, et au moment du choix du type d’installation, on décoche « LVM » et le cryptage, et on choisit « autre chose ». On va simplement utiliser l’option « modifier » pour attribuer à la partition ext4 le point de montage / et on coche le formatage si ce n’est pas automatique (l’idée est de supprimer l’ancienne installation si elle préexiste).
Et c’est parti :
Cette fois, l’installation va effectivement à son terme. Je vais en profiter pour faire le point sur le résultat, avant de passer à la suite.
2. Les constats de l’installation via la commande ubiquity -b
La meilleur chose à faire, c’est de lire un rapport boot-info de la situation initiale après cette installation sans grub. On y constate plusieurs choses :
sda1: __________________________________________________________________________
Operating System:
Boot files: /efi/ubuntu/fwupx64.efi
- La partition EFI a tout de même enregistré un dossier Ubuntu. On y trouve un fichier un peu obscur qui sert à la mise à jour de Xubuntu.
=================== efibootmgr -v BootCurrent: 0001 BootOrder: 0004,0000,0001,0002,0003 Boot0004* Windows Boot Manager HD(1,GPT,13944985-e511-4a06-852e-2787ecc204c5,0x800,0x41800)/File(EFIMicrosoftBootbootmgfw.efi)
- La Nvram n’a pas enregistré d’entrée Ubuntu, mais on trouve (comme sur beaucoup de PC) une entrée « Windows Boot Manager » qui correspond au démarrage d’un ancien Windows, et ce malgré sa désinstallation. On pourrait aussi ne plus rien trouver en relation au disque dur. Cela dépend des PC.
=============================== sda2/etc/fstab: ================================ -------------------------------------------------------------------------------- # /etc/fstab: static file system information. # / was on /dev/sda2 during installation UUID=1a575471-811e-4bd3-babe-2f56e3685750 / ext4 errors=remount-ro 0 1 # /boot/efi was on /dev/sda1 during installation UUID=9AD7-9D52 /boot/efi vfat umask=0077 0 1 /swapfile none swap sw 0 0 --------------------------------------------------------------------------------
- Le fichier fstab montre que la partition efi qu’on a créée est bien montée, ce qui évitera les montages manuels.
On va s’assurer que Grub ne s’est pas installé en passant la commande
ikewdu@ikewdu-virtual-machine:~$ dpkg --get-selections | grep grub grub-common install grub-gfxpayload-lists install grub-pc install grub-pc-bin install grub2-common install ikewdu@ikewdu-virtual-machine:~$
Et surprise ! On voit que l’installation a tout de même mis en place les paquets propres à grub-pc, ce qui ne nous convient absolument pas. On va donc devoir le supprimer, et pour cela, il sera plus simple de lancer notre noyau Linux pour rectifier tout ça.
III. Suppression de grub-pc et installation de grub-efi
1. Démarrage du noyau Linux installé
Pour faire toutes les opérations qui vont suivre, on va éviter de passer par un chroot en utilisant deux outils bien pratiques pour lancer notre Xubuntu installée : Refind ou Supergrub2disk.
J’ai expliqué dans ce sujet la procédure pour créer l’un ou l’autre de ces outils, mais on peut également suivre les préconisations du site du concepteur de Refind ou celles de Malbo, pour SG2D, dans ce tuto très complet.
L’important, c’est de pouvoir lancer cette version installée depuis un CD-Rom ou une clé USB. Si on n’y parvient pas, il faudra utiliser la procédure de chroot, plus complexe mais bien documentée sur le site Ubuntu.
2. Désinstallation des traces de grub-pc
La désinstallation se fait en deux étapes : on purge le système des fichiers grub dont on ne veut pas, puis on supprime le dossier Ubuntu de la partition efi.
- La première partie se limite à
ikewdu@ikewdu-virtual-machine:~$ sudo apt purge grub* [sudo] Mot de passe de ikewdu : Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait [...] ikewdu@ikewdu-virtual-machine:~$ dpkg --get-selections | grep grub ikewdu@ikewdu-virtual-machine:~$
- Quant à la seconde, on la résout en lançant en admin l’explorateur de fichiers (sudo nautilus, sudo thunar, sudo nemo selon la distribution qu’on utilise), puis en supprimant dans /boot/efi/EFI le dossier Ubuntu.
- On peut aussi passer par la commande
rm -r /boot/efi/EFI/ubuntu
Ainsi, nous disposons d’une installation totalement vidée de toute trace de Grub. On peut le vérifier avec un nouveau rapport boot-info.
sda1: __________________________________________________________________________ Operating System: Boot files: boot-info is executed in installed-session (Ubuntu 18.04.1 LTS, bionic, Ubuntu, x86_64) =================== efibootmgr -v BootCurrent: 0001 BootOrder: 0004,0000,0001,0002,0003 Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0) Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0) Boot0002* EFI Network PciRoot(0x0)/Pci(0x11,0x0)/Pci(0x1,0x0)/ Boot0003* EFI Internal Shell Boot0004* Windows Boot Manager HD(1,GPT,13944985-e511-4a06-852e-2787ecc204c5,0x800,0x41800)/File(EFIMicrosoftBootbootmgfw.efi)
On a bien supprimé grub intégralement (notamment de la partition efi), la NVram n’est pas modifiée et pourtant, on a booté sur la version installée.
3. Installation de grub-EFI
Il s’agit en effet de mettre en place la bonne version. Comme de nombreux PC génèrent l’erreur initiale parce que la NVram est verrouillée, on va faire en sorte de n’y rien écrire.
Mais cette fois, on doit passer par un terminal. On peut déjà vérifier quels paquets de grub sont disponibles :
ikewdu@ikewdu-virtual-machine:~$ dpkg --list grub* Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder | État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements |/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais) ||/ Nom Version Architecture Description +++-==============-============-============-================================= un grub <aucune> <aucune> (aucune description n'est disponi ii grub-common 2.02-2ubuntu amd64 GRand Unified Bootloader (common un grub-coreboot <aucune> <aucune> (aucune description n'est disponi un grub-doc <aucune> <aucune> (aucune description n'est disponi un grub-efi <aucune> <aucune> (aucune description n'est disponi un grub-efi-amd64 <aucune> <aucune> (aucune description n'est disponi un grub-efi-ia32 <aucune> <aucune> (aucune description n'est disponi un grub-efi-ia64 <aucune> <aucune> (aucune description n'est disponi un grub-emu <aucune> <aucune> (aucune description n'est disponi ii grub-gfxpayloa 0.7 amd64 GRUB gfxpayload blacklist un grub-ieee1275 <aucune> <aucune> (aucune description n'est disponi un grub-legacy <aucune> <aucune> (aucune description n'est disponi un grub-legacy-do <aucune> <aucune> (aucune description n'est disponi un grub-linuxbios <aucune> <aucune> (aucune description n'est disponi ii grub-pc 2.02-2ubuntu amd64 GRand Unified Bootloader, version ii grub-pc-bin 2.02-2ubuntu amd64 GRand Unified Bootloader, version un grub-xen <aucune> <aucune> (aucune description n'est disponi un grub-yeeloong <aucune> <aucune> (aucune description n'est disponi un grub2 <aucune> <aucune> (aucune description n'est disponi ii grub2-common 2.02-2ubuntu amd64 GRand Unified Bootloader (common ikewdu@ikewdu-virtual-machine:~$
On voit que grub-efi et grub-efi-amd64 sont disponibles. Je vais me contenter du second.
Remarque : en machine virtuelle, je n’ai pas de boot-secure. Si on avait un boot secure actif, on récupérerait aussi shim et shim-signed pour obtenir le fichier shimx64.efi.
ikewdu@ikewdu-virtual-machine:~$ sudo apt install grub-efi-amd64 [sudo] Mot de passe de ikewdu : Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Les paquets supplémentaires suivants seront installés : grub-common grub-efi-amd64-bin grub2-common os-prober Paquets suggérés : multiboot-doc grub-emu xorriso desktop-base Les NOUVEAUX paquets suivants seront installés : grub-common grub-efi-amd64 grub-efi-amd64-bin grub2-common os-prober [...] Paramétrage de grub-efi-amd64-bin (2.02-2ubuntu8.15) ... Paramétrage de grub2-common (2.02-2ubuntu8.15) ... Paramétrage de os-prober (1.74ubuntu1) ... Paramétrage de grub-efi-amd64 (2.02-2ubuntu8.15) ... Creating config file /etc/default/grub with new version Traitement des actions différées (« triggers ») pour ureadahead (0.100.0-20) ... ikewdu@ikewdu-virtual-machine:~$
L’installation des paquets s’est bien déroulée. Comme je suspecte ma NV-ram d’être à l’origine du plantage, je vais demander une installation sans écriture en NVram avec /boot/efi comme cible de mon installation :
ikewdu@ikewdu-virtual-machine:~$ sudo grub-install -v --no-nvram --efi-directory=/boot/efi
grub-install : information : writing 1032 bytes of a fixup block starting at 0xc000.
grub-install : information : reading /usr/lib/grub/x86_64-efi/fshelp.mod.
grub-install : information : reading /usr/lib/grub/x86_64-efi/ext2.mod.
grub-install : information : reading /usr/lib/grub/x86_64-efi/part_gpt.mod.
grub-install : information : kernel_img=0x55ac30c73730, kernel_size=0x18c00.
grub-install : information : the core size is 0x1cc90.
grub-install : information : writing 0x1e000 bytes.
grub-install : information : copying `/boot/grub/x86_64-efi/core.efi' -> `/boot/efi/EFI/ubuntu/grubx64.efi'.
grub-install : information : copying `/boot/grub/x86_64-efi/core.efi' -> `/boot/efi/EFI/BOOT/BOOTX64.EFI'.
grub-install : information : copying `/usr/lib/shim/fbx64.efi' -> `/boot/efi/EFI/BOOT/fbx64.efi'.
grub-install : information : impossible d'ouvrir « /usr/lib/shim/fbx64.efi » : Aucun fichier ou dossier de ce type.
Installation terminée, sans erreur
ikewdu@ikewdu-virtual-machine:~$
Et enfin, on écrit le fichier grub.cfg
ikewdu@ikewdu-virtual-machine:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Création du fichier de configuration GRUB…
Image Linux trouvée : /boot/vmlinuz-4.15.0-96-generic
Image mémoire initiale trouvée : /boot/initrd.img-4.15.0-96-generic
Image Linux trouvée : /boot/vmlinuz-4.15.0-29-generic
Image mémoire initiale trouvée : /boot/initrd.img-4.15.0-29-generic
Adding boot menu entry for EFI firmware configuration
fait
ikewdu@ikewdu-virtual-machine:~$
Notre installation est prête à fonctionner si le PC est capable de sélectionner l’entrée Ubuntu au moment du démarrage. Beaucoup de PC sont capables de le faire. Imaginons que le notre ne soit pas en mesure de réussir.
IV. Utiliser l’entrée « WBM » pour lancer notre Linux
Comme souvent, quand le boot du PC est verrouillé sur « Windows Boot Manager », il faut faire croire au bios qu’il va lancer Windows.
On constate dans le second rapport boot-info que l’installation de grub-efi a créé deux dossiers : un dossier boot et un dossier ubuntu, mais aucune entrée en NVram. On va en profiter pour ajouter un dossier Microsoft en parallèle aux deux précédents. Dans celui-ci, on va créer un dossier boot, et on copie dans ce dossier le fichier grubx64.efi qu’on renomme en bootmgfw.efi.
Ce qui donne ceci :
En fait, notre PC va être persuadé qu’il exécute l’entrée « Windows Boot Manager » présente en NVram alors qu’il exécute grubx64.efi.
Remarque :
La plupart des PC savent identifier la présence des fichiers Windows sur la partition EFI au moment du démarrage et ajouteront l’entrée en NVram. Sinon on peut tenter de l’ajouter manuellement si le bios le permet, et en dernier recours via la commande qui ajoute l’entrée « WBM » en partition 1 avec le chemin de nos faux fichiers Microsoft.
sudo efibootmgr -l d /dev/sda -p 1 -L "Windows Boot Manager" -l '\efi\Microsoft\boot\bootmgfw.efi'
Attention ! Dans le cas d’un dual-boot, le fichier bootmgfw.efi existerait déjà, et il faudrait le renommer préalablement en bootmgfw-origine.efi pour ne pas risquer de perdre son Windows.
Remarque : Dans le cas d’un dual-boot, il serait nécessaire de repasser ensuite par un sudo update-grub pour que le lanceur identifie le fichier bootmgfw-origine.efi et l’ajoute dans la liste de démarrage (non testé).
A ce stade, tout est prêt pour un démarrage sur Ubuntu. Il suffit de tester :
Et c’est bon. Un dernier rapport boot-info nous confirme que le PC pense toujours lancer Windows Boot Manager.
sda1: __________________________________________________________________________
Operating System:
Boot files: /efi/ubuntu/grubx64.efi
/efi/Microsoft/Boot/bootmgfw.efi
=================== efibootmgr -v
BootCurrent: 0004
BootOrder: 0004,0000,0001,0002,0003
Boot0004* Windows Boot Manager PciRoot(0x0)/Pci(0x10,0x0)/SCSI(0,0)/HD(1,GPT,13944985-e511-4a06-852e-2787ecc204c5,0x800,0x41800)/File(EFIMicrosoftBootbootmgfw.efi)
Nous avons bien une partition efi contenant un lanceur Ubuntu (inutilisé) et un faux lanceur Windows qui est actuellement utilisé lors du démarrage. On voit d’ailleurs que Refind lui-même s’y trompe, car lui aussi croit pouvoir lancer un Windows si on l’utilise au boot du PC :
Pour parachever le tout, et afin qu’une mise à jour de notre Xubuntu ne vienne pas annuler tout ce travail, on peut bloquer la mise à jour de grub en passant plusieurs commandes :
apt-mark hold fwupdate
apt-mark hold grub-efi-amd64
apt-mark hold grub-efiRemarque : pour empêcher le secure-boot et les fichiers signés de se mettre à jour, on pourrait ajouter :
apt-mark hold secureboot-db
apt-mark hold fwupdate-signed
Donc, on a contourné les verrouillage de la Nvram, mais rien ne garantit que d’autres verrouillages n’entravent pas ce genre de manipulation. Donc, à suivre avec prudence, et à ses risques et périls.
