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
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…
Les pistes sont nombreuses, et c’est souvent difficile à résoudre. C’est même parfois définitivement bloquant.
L’idée de cette démo n’est pas de donner de solution « à tout prix », mais de proposer des pistes de contournement. On pourrait le faire avec Grub (proposé prochainement), mais on peut aussi utiliser Refind, le lanceur créé par Rod Smith à partir de Refit.
Pourquoi ce choix ? Il fonctionne bien, il est assez ergonomique, et il est facile à gérer.
Je rédige cette démo en même temps que je traite (bien ou mal) ce cas qui est typique des blocages qu’on rencontre. L’installation est impeccable, et ça échoue à la fin.
I. Situation initiale : faire une installation sans grub
1. La situation de départ
On va partir d’un Windows 10 installé en dual-boot avec une Mint (que je ne prends pas en compte) sur un disque unique. L’idée est d’installer Xubuntu (plus légère en PC virtuel) sur un second disque. Le gestionnaire de disque présente ceci :
On dispose bien d’un PC en UEFI avec disques GPT. Une partition efi étant présente sur le disque 0, on n’en créera pas d’autre.
Le disque 1 servira à l’installation d’Ubuntu . Ainsi, le logiciel EasyUEFI montre que pour l’instant, seul « Windows Boot Manager » est enregistré en NVRAM. c’est la partition 2 du disque 0 qui gère le démarrage.
C’est d’ailleurs confirmé par la commande efibootmgr, saisie sur le liveUSB de Xubuntu :
xubuntu@xubuntu:~$ efibootmgr
BootCurrent: 000D
Timeout: 2 seconds
BootOrder: 0010,000C,000D,0011,0007,000E
Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot0002* EFI Network
Boot0003* EFI Internal Shell (Unsupported option)
Boot0007* EFI Network
Boot0008* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot0009* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot000A* EFI Network
Boot000B* EFI Internal Shell (Unsupported option)
Boot000C* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot000D* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot000E* EFI Internal Shell (Unsupported option)
Boot0010* Windows Boot Manager
Boot0011* EFI VMware Virtual SCSI Hard Drive (1.0)
2. Installation de Xubuntu sans Grub
On va démarrer sur le live-USB d’installation d’Ubuntu en mode « essayer Ubuntu » pour obtenir un bureau, et on va lancer un terminal pour déclencher l’installation dans un mode particulier, à savoir sans Grub. On va taper :
ubiquity -b
On obtient un classique processus d’installation qui apparaît ici :
Comme je ne veux pas créer de partition efi, je vais passer par « autre chose« , et créer sur /dev/sdb une simple partition ext4 avec comme point de montage « /« . Pour une installation « sans Windows », cas que je ne traite pas car peu fréquent, je créerais bien sûr une partition efi. Mais dans mon cas, cette partition EFI existe déjà sur le premier disque nommé ici /dev/sda
Par conséquent, je sélectionne l’espace libre sur /dev/sdb, puis je clique sur + et je crée une partition ext4 avec montage / sur l’ensemble du disque.
Le résultat est le suivant: tout l’espace de /dev/sdb est occupé par ma nouvelle partition en ext4.
A ce stade, je lance l’installation qui va se dérouler normalement, et aller cette fois jusqu’à son terme, sans message d’erreur.
On obtient un Xubuntu bien installée, mais non exécutable, et sans grub… Un rapport boot-info nous le montre. Les extraits suivants notamment :
Boot Info Script 71f6c5c + Boot-Repair extra info [Boot-Info 18apr2020]
============================= Boot Info Summary: ===============================
=> Windows 7/8/2012 is installed in the MBR of /dev/sda.
=> No boot loader is installed in the MBR of /dev/sdb.
sda1: __________________________________________________________________________
File system: ntfs
Boot sector type: Windows 8/2012: NTFS
Boot sector info: No errors found in the Boot Parameter Block.
Operating System:
Boot files:
sda2: __________________________________________________________________________
File system: vfat
Boot sector type: Windows 8/2012: FAT32
Boot sector info: No errors found in the Boot Parameter Block.
Operating System:
Boot files: /efi/Microsoft/Boot/bootmgfw.efi
/efi/Microsoft/Boot/bootmgr.efi
/efi/Microsoft/Boot/memtest.efi
sda3: __________________________________________________________________________
File system:
Boot sector type: -
Boot sector info:
sda4: __________________________________________________________________________
File system: ntfs
Boot sector type: Windows 8/2012: NTFS
Boot sector info: No errors found in the Boot Parameter Block.
Operating System:
Boot files: /Windows/System32/winload.exe
=================== efibootmgr -v
BootCurrent: 000D
Timeout: 2 seconds
BootOrder: 0010,000C,000D,0011,0007,000E
Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0) PciRoot(0x0)/Pci(0x15,0x0)/Pci(0x0,0x0)/SCSI(0,0)
Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0) PciRoot(0x0)/Pci(0x11,0x0)/Pci(0x4,0x0)/Sata(1,0,0)
Boot0002* EFI Network PciRoot(0x0)/Pci(0x16,0x0)/Pci(0x0,0x0)/MAC(000c29cab49f,0)
Boot0003* EFI Internal Shell (Unsupported option) MemoryMapped(11,0x49fcb000,0x4a355fff)/FvFile(c57ad6b7-0515-40a8-9d21-551652854e37)
Boot0007* EFI Network PciRoot(0x0)/Pci(0x16,0x0)/Pci(0x0,0x0)/MAC(000c290e546d,0)
Boot0008* EFI VMware Virtual SCSI Hard Drive (0.0) PciRoot(0x0)/Pci(0x15,0x0)/Pci(0x0,0x0)/SCSI(0,0)
Boot0009* EFI VMware Virtual SATA CDROM Drive (1.0) PciRoot(0x0)/Pci(0x11,0x0)/Pci(0x4,0x0)/Sata(1,0,0)
Boot000A* EFI Network PciRoot(0x0)/Pci(0x16,0x0)/Pci(0x0,0x0)/MAC(000c29cab49f,0)
Boot000B* EFI Internal Shell (Unsupported option) MemoryMapped(11,0x49fcb000,0x4a355fff)/FvFile(c57ad6b7-0515-40a8-9d21-551652854e37)
Boot000C* EFI VMware Virtual SCSI Hard Drive (0.0) PciRoot(0x0)/Pci(0x15,0x0)/Pci(0x0,0x0)/SCSI(0,0)
Boot000D* EFI VMware Virtual SATA CDROM Drive (1.0) PciRoot(0x0)/Pci(0x11,0x0)/Pci(0x4,0x0)/Sata(1,0,0)
Boot000E* EFI Internal Shell (Unsupported option) MemoryMapped(11,0xbefab018,0xbf416017)/FvFile(c57ad6b7-0515-40a8-9d21-551652854e37)
Boot0010* Windows Boot Manager HD(2,GPT,ffcaac27-7335-49f8-8028-b198618d7559,0x96800,0x31800)/File(EFIMicrosoftBootbootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0011* EFI VMware Virtual SCSI Hard Drive (1.0) PciRoot(0x0)/Pci(0x15,0x0)/Pci(0x0,0x0)/SCSI(1,0)
II. La mise en place d’un lanceur : Refind
1. Créer une clé USB de Refind
Refind est un lanceur EFI qui peut remplacer grub. Il est présent dans les paquets d’Ubuntu et peut être installé directement, mais je choisis d’éviter cette solution pour ne pas échouer sur le même écueil qu’avec Grub : un échec avant la fin de la procédure.
Le site du concepteur, bien qu’en anglais, est explicite. Il y présente toutes les déclinaisons de son outil. Il est nécessaire, dès maintenant, de fabriquer une clé USB Refind, car on va en avoir besoin pour faire démarrer notre Xubuntu. Elle nous servira aussi à récupérer les outils nécessaires pour notre démarrage.
(La version USB se présente sous forme de fichier zip dans lequel se trouve un fichier img qu’on peut convertir en USB avec la commande dd (Cf. le fichier explicatif joint au zip). On peut aussi utiliser Etcher, Rufus qui savent utiliser la commande dd de manière plus sécurisée. On peut enfin utiliser la solution proposée dans le TIP, qui explique comment utiliser l’outil d’installation maison de Rod Smith.)
Personnellement, je préfère créer une clé en fat32 bootable moi-même depuis Windows, et y copier le contenu de l’image iso de la version CD, qui a tous les éléments nécessaires au boot en uefi. J’ai expliqué la procédure dans ce sujet.
J’ai ainsi une clé directement opérationnelle pour booter en UEFI. (A noter qu’on peut aussi utiliser SG2D pour lancer son noyau Linux en suivant ma démo pour SG2D dans le lien précédent, ou mieux encore, ce tuto très complet de malbo ).
2. Démarrage avec la clé USB Refind
Si la clé est correctement faite, il suffit de l’insérer, de la mettre en priorité dans l’ordre de boot du PC, et on arrive à ceci :
Refind détecte chez moi un Windows, une vieille version de Mint (on peut les tester), et ma xubuntu au noyau 4.15. Il suffit de la sélectionner avec le clavier et de la lancer.
On est sur notre nouvelle Xubuntu. Cette technique a l’énorme avantage de nous épargner la longue et laborieuse procédure de chroot qu’imposerait un live-CD.
Mais bien évidemment, ce passage par l’usb n’est qu’une solution provisoire… Le but est d’ajouter Refind au démarrage du PC. On pourrait le faire proprement avec des commandes, mais comme je veux simplifier, on va le faire moins proprement en mode graphique.
Pour ce faire, on va lancer l’explorateur de sa distribution en mode administrateur. Comme la version Xubuntu utilise Thunar, on tape la commande :
sudo thunar
Avec Ubuntu, ce serait sudo nautilus. C’est aussi l’occasion de voir et d’explorer le contenu de ma clé USB Refind qui est issu de l’image ISO que j’ai décompressée en entier :
On va pouvoir s’en servir pour la suite de notre installation.
III. Les stratégies de dépannage
Je préfère le dire tout de suite, aucune stratégie n’offre la garantie de réussite, car les marques ont tendance à bloquer différemment leurs machines. Donc, je vais présenter les choses de la situation la plus normale à la situation la plus verrouillée.
1. La situation normale: ajout de refind en efi et en NVram
Dans une installation classique (avec grub ou autre), le lanceur de Linux s’installe à la fois dans la partition efi et en Nvram. On va reproduire cette situation. Le rapport boot-info précédent a montré une chose intéressante. La partition efi est montée par le biais du fichier fstab :
=============================== sdb1/etc/fstab: ================================
--------------------------------------------------------------------------------
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sdb1 during installation
UUID=9a6e9fd2-6cb1-4a51-b1cb-88d74ae4ce04 / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda2 during installation
UUID=6205-ABC5 /boot/efi vfat umask=0077 0 1
/swapfile none swap sw 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0
--------------------------------------------------------------------------------
On va donc l’explorer avec notre explorateur de fichiers ouvert en superutilisateur. Il suffit de se rendre sur le dossier /boot/efi pour en voir le contenu :
On constate qu’on trouve un sous-dossier EFI qui contient lui-même un sous-dossier Microsoft. Nous allons ajouter à côté de ce dossier nommé Microsoft un nouveau dossier appelé Refind.
Dans ce dossier Refind, nous allons ajouter certains éléments contenus dans la clé USB Refind, notamment ceux qui suivent choisis dans le dossier Refind de la clé (:
On n’oubliera pas le fichier refind-conf-sample que j’ai oublié sur la capture. Ils seront à copier dans le nouveau dossier Refind de notre partition /boot/efi/EFI/Refind
Le résultat est le suivant :
On en profite alors pour renommer le fichier refind.conf-sample en refind.conf
A ce stade, certains PC sont capables de lancer Refind au redémarrage si on choisit de passer par le boot-menu du PC (touche ESC, F9, F11, F12 selon les marques), car ces PC explorent la partition EFI au démarrage et ils adaptent leur NVram en fonction de ce qu’ils y trouvent.
Mais pour beaucoup d’autres, ce n’est pas le cas, et il faut ajouter soi-même cette entrée par une commande précise.
ikewdu@ikewdu-virtual-machine:~$ sudo efibootmgr -c -d /dev/sda -p 2 -L "Refind" -l '\efi\Refind\refind_x64.efi'
BootCurrent: 000D
Timeout: 2 seconds
BootOrder: 0004,0006,000C,000D,0011,0007,000E
Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot0002* EFI Network
Boot0003* EFI Internal Shell (Unsupported option)
Boot0006* Windows Boot Manager
Boot0007* EFI Network
Boot0008* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot0009* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot000A* EFI Network
Boot000B* EFI Internal Shell (Unsupported option)
Boot000C* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot000D* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot000E* EFI Internal Shell (Unsupported option)
Boot0011* EFI VMware Virtual SCSI Hard Drive (1.0)
Boot0004* Refind
ikewdu@ikewdu-virtual-machine:~$
Explication de la commande : on demande l’écriture dans la NVRAM d’une entrée « Refind » qui pointera sur la partition 2 du disque /dev/sda, en suivant le chemin EFI\Refind\Refind_x64.efi.
Si le PC n’est pas bloquant, une entrée Refind a été ajoutée et elle est placée en tête dans la liste de démarrage. Au prochain redémarrage, le PC lancera Refind qui permettra de choisir entre Windows et Xubuntu.
2. Le cas de PC programmés pour booter sur bootx64.efi
On en voit de moins en moins, mais certains PC ne savent démarrer que sur le dossier efi/boot/bootx64.efi. Pour y parvenir, on va utiliser la même stratégie qu’au point précédent, mais au lieu de créer dans /boot/efi/EFI un dossier « refind », on y crée un dossier « boot ». On y copie les mêmes éléments, et on en profite pour renommer refind_x64.efi en bootx64.efi. On aboutira à cette situation :
Et on écrit cette fois en Nvram la ligne suivante:
ikewdu@ikewdu-virtual-machine:~$ sudo efibootmgr -c -d /dev/sda -p 2 -L "Windows Boot Manager" -l '\efi\Boot\bootx64.efi'
BootCurrent: 000D
Timeout: 2 seconds
BootOrder: 0004,0006,000C,000D,0011,0007,000E
Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot0002* EFI Network
Boot0003* EFI Internal Shell (Unsupported option)
Boot0006* Windows Boot Manager
Boot0007* EFI Network
Boot0008* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot0009* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot000A* EFI Network
Boot000B* EFI Internal Shell (Unsupported option)
Boot000C* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot000D* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot000E* EFI Internal Shell (Unsupported option)
Boot0011* EFI VMware Virtual SCSI Hard Drive (1.0)
Boot0004* Windows Boot Manager
ikewdu@ikewdu-virtual-machine:~$
La commande ressemble à la précédente, mais on a simplement simulé une entrée « Windows Boot Manager » en Nvram, pointant vers \EFI\boot\bootx64.efi. Cette entrée suffira à tromper le bios-uefi et sera probablement considérée comme valable sur ce genre de PC.
Remarque pour les points 1 et 2 : de nombreux PC présentent une option dans le bios-UEFI permettant de remplacer avantageusement la commande efibootmgr si elle n’est pas enregistrée.
3. Le cas de Nvram verrouillée (par Windows bcdedit)
Le problème, c’est que de nombreux PC (portables, surtout) verrouillent la NVram et le bios-UEFI ne présente aucune alternative, et la commande efibootmgr n’est pas enregistrée par le PC. Bilan, celui-ci continue de démarrer sur Windows.
Nous allons repartir de la situation normale, avec un dossier Microsoft et un dossier REfind. On a ceci après copie du dossier « Refind » sur la partition EFI (Cf. point 1 de cette partie III) :
On va faire cette fois une manipulation depuis Windows. On démarre sur Windows. On va utiliser la commande bcdedit pour modifier le chemin de démarrage de Windows : on lance une invite de commandes en mode admin (on tape cmd en zone de recherche, et on ouvre par clic droit) :
C:\windows\system32>bcdedit /set {bootmgr} path efi\refind\refind_x64.efi
L’opération a réussi.
La commande redirige le lanceur bootmgr de Windows vers le chemin de notre dossier Refind sur la partition EFI. On vérifie que la commande a bien redirigé bootmgr vers le lanceur Refind :
C:\windows\system32>bcdedit /v
Gestionnaire de démarrage Windows
---------------------------------
identificateur {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device partition=\Device\HarddiskVolume2
path efi\refind\refind_x64.efi
description Windows Boot Manager
locale fr-fr
inherit {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
default {01187ce9-8426-11ea-9d69-000c290e546d}
resumeobject {01187ce8-8426-11ea-9d69-000c290e546d}
displayorder {01187ce9-8426-11ea-9d69-000c290e546d}
{a5a30fa2-3d06-4e9f-b5f4-a01df9d1fcba}
toolsdisplayorder {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout 30
Chargeur de démarrage Windows
-----------------------------
identificateur {01187ce9-8426-11ea-9d69-000c290e546d}
device partition=C:
path \windows\system32\winload.efi
description Windows 10
locale fr-fr
inherit {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \windows
resumeobject {01187ce8-8426-11ea-9d69-000c290e546d}
nx OptIn
bootmenupolicy Standard
On peut cette fois démarrer notre Windows et notre Linux sans avoir modifié la Nvram. Le bémol de cette solution est qu’elle risque de devoir être renouvelée à chaque mise à niveau de Windows.
4. Le cas de la NVram verrouillée (par substitution de dossiers)
L’idée est de faire croire au PC qu’on lance un fichier efi pour Windows alors qu’on lui substitue le lanceur Refind. On repart de cette situation initiale déjà rencontrée : on a créé le dossier Refind à côté de celui de Microsoft :
On commence par renommer, dans le dossier Refind, le fichier refind_x64.efi en bootmgfw.efi, ce qui correspond au nom du lanceur Windows. :
On se rend ensuite dans le dossier Microsoft, et on fait remonter par couper /coller le dossier Boot intégralement au niveau supérieur pour qu’il s’ajoute à Refind et Microsoft :
Inversement, on déplace le dossier Refind pour en faire un sous-dossier de Microsoft. On renomme le dossier Refind en Boot :
On teste un redémarrage :
On constate que l’entrée en Nvram « Windows Boot Manager » fait bien démarrer Refind, qui lui, est capable de lancer Xubuntu et Windows qu’il va chercher dans le dossier /efi/boot. On pzut vérifier que Windows démarre correctement, et une fenêtre EasyUEFI confirme que le PC croit avoir seulement Windows comme moyen pour démarrer :
On a exactement le même retour qu’avant l’installation de Xubuntu.
5. Le cas du simple boot avec Nvram verrouillée
Dans le cas d’un simple boot (qui n’est pas mon sujet) avec Nvram verrouillée, une solution très acceptable, proche de la précédente, consiste à
- créer un dossier Microsoft sur la partition efi,
- placer le dossier Refind depuis la clé USB dans le /boot/efi/EFI/Microsoft
- renommer le dossier Refind en Boot pour simuler la structure traditionnelle de Windows.
- renommer le fichier refind_x64.efi en bootmgfw.efi
Le PC croira exécuter un lanceur Windows, et sera là encore trompé. Je ne développe pas car le principe est le même qu’aux points précédents.
