Archives mensuelles : avril 2020

Contourner l’erreur d’installation de grub-EFI dans /target/

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.

Mon image

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 :

Mon image

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).

Mon image

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)

Mon image

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

Mon image

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 :

Mon image

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.

Mon image

  • 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 :

Mon image

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 :

Mon image

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 :

Mon image
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-efi

Remarque : 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. 

Contourner avec Refind l’erreur d’installation de Grub sur PC-UEFI

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.

Mon image

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 :

Mon image

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.

Mon image

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 :

Mon image

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.

Mon image

Le résultat est le suivant: tout l’espace de /dev/sdb est occupé par ma nouvelle partition en ext4.

Mon image

A ce stade, je lance l’installation qui va se dérouler normalement, et aller cette fois jusqu’à son terme, sans message d’erreur.

Mon image

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  :

Mon image

 

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 :

Mon image

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 :

Mon image

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é (:

Mon image

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 :

Mon image

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 :

Mon image

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) :

Mon image

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 :

Mon image

On commence par renommer, dans le dossier Refind, le fichier refind_x64.efi en bootmgfw.efi, ce qui correspond au nom du lanceur Windows. :

Mon image

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 :

Mon image

Inversement, on déplace le dossier Refind pour en faire un sous-dossier de Microsoft. On renomme le dossier Refind en Boot :

Mon image

On teste un redémarrage :

Mon image

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 :

Mon image

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.