Une des demandes fréquentes sur les forums est de savoir comment installer en mode UEFI un Linux sur un support USB ou sur un disque secondaire, sans impacter l’état et le fonctionnement de son Windows préinstallé. On pourra faire la même expérience pour une installation en Legacy.
I. Installation standard sur un disque secondaire de Xubuntu 19-04
On va partir d’un Windows 10 (pré)installé auquel on ajoute un disque secondaire destiné à recevoir une installation Linux. Le disque secondaire a été préalablement formaté et converti au format gpt depuis ce même Windows, mais c’est parfaitement faisable depuis Linux, avec le logiciel gparted.
La situation initiale est donc la suivante :
1. Essai échoué (!!!) d’installation directe avec l’outil Ubuntu intégré
La première chose à faire est de booter en uefi sur le LiveUSB. On peut vérifier qu’on est bien dans ce mode via la commande suivante qui doit retourner « session efi » :
[ -d /sys/firmware/efi ] && echo "Session EFI" || echo "Session non-EFI"
Si c’est bien le cas, on lance le processus d’installation, jusqu’à obtenir un choix proposant plusieurs types d’installation. Pour maîtriser au mieux la situation, on choisit « autre chose ». Dans mon cas, j’obtiens ceci :
Le disque sdb est mon disque vide, je vais donc l’utiliser pour créer deux partitions (avec la touche +) : une partition efi de 100 Mo en fat32, et une partition ext4 avec le point de montage / avec le reste.
Ce qui donne ceci :
Avant de lancer le processus, je précise à mon installateur de choisir sdb pour y placer grub pour être sûr de ne pas me retrouver avec un grub dans sda.
Comme tout semble bon, on se lance. L’installation se fait de la manière habituelle et au redémarrage, on trouve un grub qui me propose de lancer tout ce que j’ai dans le PC, ce qui déjà n’est pas exactement ce que je souhaitais. Des entrées inutiles insérées dans grub vont être à supprimer.
Ensuite, le passage par un rapport boot-info me présente d’autres surprises :
sda2: File system: vfat Operating System: Boot files: /EFI/ubuntu/grubx64.efi /EFI/ubuntu/mmx64.efi /EFI/ubuntu/shimx64.efi /EFI/Microsoft/Boot/bootmgfw.efi sdb2: File system: vfat Boot sector type: FAT32 Boot sector info: No errors found in the Boot Parameter Block. Operating System: Boot files:
Mes fichiers grub se sont logés, malgré ma demande (!!!), non pas dans la partition efi de mon disque sdb mais dans sda2 , qui est d’ailleurs montée dans fstab.
=================="blkid" output: /dev/sda2 6205-ABC5 vfat /dev/sdb2 0EE5-E1D5 vfat =================== sdb3/etc/fstab: UUID=1c312bcb-c662-47de-913d-558d3696bc9b / 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
Là encore, les choses ne sont pas celles attendues. Comment réparer cela ?
2. Réparation des dysfonctionnements liés à l’installation directe
La première chose à faire, c’est de faire comprendre à Ubuntu qu’on veut utiliser la partition efi de sdb et non celle de sda. Pour ce faire, on va modifier le fichier /etc/fstab pour que soit montée au démarrage suivant la bonne partition. Le résultat de blkid dans boot-info nous donne son uuid. Il suffit donc de réaliser une simple substitution, en l’occurrence :
Une fois la chose faite, on va redémarrer Ubuntu pour que ce montage soit appliqué. On pourra vérifier que la partition sdb2 est bien montée en allant voir le contenu de /boot/efi qui doit être vide.
On peut donc passer à la suite : on réinstalle grub via la commande :
sudo grub-install
Puis, on désactive le fichier 30_os-prober pour ne plus exécuter les entrées non désirées.
sudo chmod -x /etc/grub.d/30_os-prober
Et enfin, on met grub à jour :
sudo update-grub
Le résultat est le suivant :
Au redémarrage, on a bien une entrée pour Ubuntu et les entrées inutiles ont disparu. Il nous reste à nettoyer les entrées obsolètes de grub dans la partition efi de sda, en l’occurrence (selon mon rapport boot-info) sda2. On monte la partition, et on supprime le dossier ubuntu et on vérifie le résultat. Si c’est bon, on démonte la partition.
sudo mkdir /mnt/sda2
sudo mount /dev/sda2 /mnt/sda2
sudo rm -fr /mnt/sda2/EFI/ubuntu
ls /mnt/sda2/EFI
sudo umount /mnt/sda2
sudo rm -fr /mnt/sda2
En image, on obtient ceci :
Notre Ubuntu est bien installé de manière autonome sur la clé, ce que confirme notre nouveau rapport boot-info.
La partition sda2 est débarrassée des fichiers grub :
sda2: File system: vfat
Operating System:
Boot files: /EFI/Boot/bootx64.efi /EFI/Boot/fbx64.efi
/EFI/Boot/mmx64.efi /EFI/Microsoft/Boot/bootmgfw.efi
/EFI/Microsoft/Boot/bootmgr.efi
/EFI/Microsoft/Boot/memtest.efi
Ils sont bien présents sur sdb2 :
sdb2: File system: vfat
Operating System:
Boot files: /EFI/ubuntu/grub.cfg /EFI/BOOT/fbx64.efi
/EFI/BOOT/mmx64.efi /EFI/ubuntu/grubx64.efi
/EFI/ubuntu/mmx64.efi /EFI/ubuntu/shimx64.efi
Et le démarrage prend bien en priorité mon installation de Linux, puis celle de Windows, chacun étant sur une partition efi différente :
=================== efibootmgr -v BootCurrent: 0005 Timeout: 2 seconds BootOrder: 0005,0010,000C,000D,000E,000F,0011 Boot0005* ubuntu HD(2,GPT,dae2fbc5-e304-42f5-840c-1054ae1500f8,0x8000,0x2f800)/File(EFIubuntushimx64.efi) Boot0010* Windows Boot Manager HD(2,GPT,ffcaac27-7335-49f8-8028-b198618d7559,0x96800,0x31800)/File(EFIMicrosoftBootbootmgfw.efi)
Si on débranche, supprime, ou formate le disque sdb, Windows reprendra la main automatiquement comme avant l’installation d’Ubuntu, ce qui est nécessaire pour effectuer la seconde démo.
Mais n’était-il pas possible d’éviter toute cette fastidieuse manipulation ?
II. Installation d’Ubuntu sur disque externe ou usb sans réparation
La situation de départ est la même que pour le point I. A savoir, on dispose d’un disque vierge sur lequel on souhaite installer Ubuntu en uefi de manière indépendante :
Cette fois, on va d’abord passer par gparted pour effectuer quelques modifications sur le disque sda. En cliquant droit sur la partition efi, ici sda2, et en choisissant l’option « manage flags« , on peut modifier la partition efi pour qu’elle semble n’être qu’une partition de données en fat32. On décoche l’option boot et l’option esp. Le résultat sera conforme à ceci :
Mais attention !!!!
A cet instant, Windows n’est plus capable de booter !!! Nous devrons le réparer pour le rendre à nouveau fonctionnel !!!!
On va dès lors retenter une installation dans les mêmes conditions qu’au point 1. Type de partitionnement : « Autre chose« . Et on crée une partition efi de 100 Mo en fat32 et une partition ext4 avec point de montage / sur le reste du disque. On choisit /dev/sdb pour y placer son grub.
L’installation se fait sans problème, et on n’a plus qu’à faire un rapport boot-info pour voir le résultat.
La situation est nettement meilleure. Les fichiers grub sont bien installés dans la bonne partition (sdb1) et la NVram est programmée pour démarrer sur cette installation toute fraîche. Mais il reste plusieurs choses à corriger :
- Windows ne pouvant plus démarrer, on va réactiver les drapeaux ESP et Boot pour redonner à sda2 son statut efi avec l’option « manage flags » par clic droit sur sda2. Il sera alors possible de redémarrer pour régler le second problème :
- Dans mon cas, puisque j’ai d’autres Linux déjà installés, Grub s’est paramétré pour lancer les noyaux de Fedora et Mint présents sur sda, ce que je ne souhaite pas : on va donc désactiver os-prober, comme on l’a fait dans le premier point, via la commande sudo chmod et on met grub à jour :
Cette situation ne se produira pas si on n’a pas d’autre Linux sur le PC. La situation finale est alors la même qu’au premier point. Notre Linux pourra booter sans nuire à Windows qui reprendra la main dès que ce disque sdb sera débranché.
