Archives pour la catégorie Non classé

Installation Xubuntu 26.04 sur disque secondaire

Le projet, qui fait suite au sujet présentant l’installation d’un Linux totalement indépendant sur le même disque que Windows, est ici d‘installer une Xubuntu 26.04 sur un disque secondaire ou sur un disque externe qui puisse être déplacée sur un autre PC.

Le PC-virtuel équipé de Ws 11 étant configuré en mode UEFI, on va s’assurer (par acquit de conscience) depuis un terminal que notre disque externe est bien initialisé au format GPT. On en profite pour passer le clavier en français, ce qui facilite bien les choses.

!!! Notons qu’on pourrait s’épargner cette phase en lançant directement l’installation.

depart

Les deux disques sda et sdb (notre disque secondaire) étant au format gpt, tout est OK. Dans le cas contraire, pas de souci. On réécrira de toute manière la table de partitions au moment du partitionnement.

1. L’installation sur le disque secondaire

On peut lancer l’installation de manière tout à fait traditionnelle jusqu’à la fenêtre nous demandant comment nous voulons installer Xubuntu. Nous choisirons le partitionnement manuel, qui nous affichera ceci :

partinit

Le disque qui nous intéresse est sdb. Nous allons écrire une nouvelle table de partitions pour le vider intégralement en cliquant sur le bouton proposé. Puis, nous sélectionnons sdb pour périphérique d’amorçage, ce qui va conduire l’installateur Subiquity à créer spontanément une partition sdb1 montée en /boot/efi de 999 Mo. On pourrait la rétrécir, mais c’est sans importance.

creaefi

Enfin, on se positionne sur l’espace libre, puis on clique sur le bouton +. Là encore, tout est quasi automatique, le point de montage excepté qu’il nous faut définir. On va choisir dans la liste le point de montage / qui équivaut à la racine du système.

racine

On valide et on passe à la suite via « suivant ».

On crée son identifiant, son MP, on choisit son fuseau horaire et on s’assure que le résumé proposé nous convient.

Si c’est bon, on continue l’installation. Une fois celle-ci achevée, le programme nous invite à redémarrer, ce que nous faisons immédiatement;

2. Peaufinage de l’installation

2.1. Si le disque est destiné à demeurer dans le PC

grub

L’affichage de grub tel qu’il nous est présenté au redémarrage nous présente un dual-boot tout à fait correct. Les deux systèmes sont identifiés et nous pourrons démarrer sur l’un ou l’autre système à notre convenance.

2.2. Si disque est destiné à voyager de PC en PC

Il ne sera pas possible de conserver le menu de démarrage en l’état, car d’une machine à l’autre, les UUID de partitions vont différer. Nous allons donc modifier grub pour faire en sorte que notre Linux se contente de se lancer tout seul. Pour cela, nous allons modifier le fichier /etc/default/grub avec l’éditeur de texte mousepad (installé par défaut sur Xubuntu).

sudo mousepad /etc/default/grub

modifgrub

On s’assure que l’option « hidden » est présente à la ligne.

A noter qu’on mettrait plutôt « menu » dans le cas d’un dual-boot.

GRUB_TIMEOUT_STYLE=hidden

On supprime le # et on passe de false à true à la ligne

#GRUB_DISABLE_OS_PROBER ---> GRUB_DISABLE_OS_PROBER=true

On enregistre, et on valide avec un sudo update-grub

updategrub

Notre Linux saura désormais démarrer directement, sans Windows. Et si on l’insère dans un autre PC, on devrait être capable de le lancer en paramétrant son BIOS pour démarrer sur USB ou en pointant directement vers le fichier efi/ubuntu/shimx64.efi présent sur la clé.

Le bios de virtualbox n’est pas vraiment significatif, mais ça donne à peu près ceci:

bootfile

 

Récupérer avec testdisk une Xubuntu malencontreusement effacée

Il peut arriver que, par erreur, on efface une partition dont on réalise qu’elle était essentielle, soit parce qu’elle contenait des données, soit parce qu’elle contenait un système d’exploitation qu’on regrette aussitôt qu’il a été supprimé.

C’est ce que j’ai fait dans ce sujet au point B, partie 2 : j’ai supprimé (pour la démo) une Xubuntu 26.04 que je venais d’installer. On va voir si on peut la récupérer.

Initialement, on avait deux OS comme le montre cette image. Une fois mon Linux supprimé, on avait obtenu cette autre situation.

On va voir si une récupération s’avère possible. Pour cela, je vais utiliser une application assez austère, mais très puissante nommée testdisk.

Première chose à faire démarrer sur un outil permettant d’exécuter testdisk. On pourrait le faire depuis Windows, comme l’indique la documentation officielle, mais  je vais le faire depuis une clé d’installation de Xubuntu 26.04 que j’ai sous la main, parce que je trouve que c’est finalement plus simple.

1. La phase d’installation de testdisk

Je l’ai documentée il y a quelques années ici, mais on va reprendre la procédure de A à Z.

On démarre sur la clé Xubuntu, et une fois sur le bureau, on commence par connecter le PC à Internet, soit en filaire, soit pas Wifi. Dans mon cas, le PC est connecté en Ethernet, donc je n’ai rien à faire.

Première opération, lancer un terminal pour passer le clavier en français et installer testdisk, ce qui se fait sans aucune difficulté.

setxkbmap fr
sudo apt install testdisk

testdiskinstall

Puisqu’on a un terminal ouvert, autant faire un point sur l’état du disque et des partitions :

sudo fdisk -l |grep -E "sd|typ"

fdisk

2. Exécution de testdisk et récupération des partitions

On lance testdisk par un « sudo testdisk« , une fenêtre s’ouvre dans laquelle on choisit « no-log » pour aboutir à un affichage des disques présents dans la machine. On le sélectionne, puis on valide par « proceed ».

Rem : tout se fait avec le clavier, testdisk étant une application en mode texte.

testdisk1

Notre disque étant au format gpt, on choisit la ligne « EFI GPT » dans la nouvelle fenêtre ouverte. On valide par « entrée« .

testdis2

Fenêtre suivante, « analyse » et « entrée » pour aboutir à cet écran qui confirme notre fdisk initial. Deux partitions principales sont identifiées. « Quick search » étant déjà sélectionné, on le valide par « entrée ».

testdisk3

Si notre table de partitions n’est pas HS, nos partitions perdues devraient apparaître comme ci-dessous. On prend le temps de bien vérifier que les secteurs de début et de fin sont cohérents et ne se chevauchent pas. En cas contraire, il faudra éliminer les partitions incohérentes avec les flèches gauche et droite de sorte que la lettre P (principale) soit remplacée par D (Delete). Pour l’exemple, j’élimine (provisoirement) la 3e partition pour qu’on puisse voir ce que ça donne :
testdisk4

On peut donc continuer en sélectionnant « entrée » (j’ai rétabli la récupération de la partition 3 dans l’intervalle). Tout étant visiblement correct, on n’a plus qu’à lancer la réécriture de la table de partition par « write« , ce qu’on confirme par « y » dans la fenêtre suivante.

testdisk5

L’application m’invite à redémarrer pour que l’opération soit validée. On la quitte en tapant « q » plusieurs fois et on redémarre.

3. Redémarrage et vérification

Mon PC-virtuel étant initialement constitué d’un dual-boot dont j’ai supprimé l’entrée Ubuntu en NVram, c’est Windows qui démarre directement. Vérifions que les partitions ont été retrouvées :

Elles sont bel et bien présentes :

diskmanagt

Si nos partitions contenaient de simples données, nous pourrions nous arrêter ici.

4. Rétablissement du dual-boot en NVram

En supplément, comme je souhaite retrouver mon dual-boot fonctionnel, je vais recréer une entrée Ubuntu en Nvram avec la version gratuite d’easyuefi : je choisis « gérer les options de démarrage » dans la première fenêtre pour aboutir à ceci :

Remarque : on pourrait le faire aussi depuis le bios, voire depuis un live USB Linux en réinstallant carrément grub sur la partition efi montée. 

easyuefi1

Je choisis de créer une nouvelle entrée « Linux » que je décris comme étant « Xubuntu » et je vais chercher le fichier shimx64.efi dans le dossier ubuntu.

easyuefi2

Je valide quand c’est bon. Mon entrée Xubuntu étant en fin de liste, je la fais remonter en première position pour que le PC boote dessus :

easyuefi3

Il ne reste qu’à redémarrer pour obtenir un grub…

grub

Si tout s’est bien passé, notre Linux perdu va se lancer correctement.

bureau

Installation non invasive de Xubuntu 26.04 sur PC préinstallé W10 ou W11

La démo présentée ici va montrer comment installer un système Linux à côté d’un Windows 10 ou 11 préinstallé, dans l’optique d’une éventuelle évolution aisée à court ou moyen terme, selon qu’on voudra garder les deux systèmes ou seulement l’un d’entre eux.

Par conséquent, toute cette démo sera réalisée en mode EFI, puisque c’est celui appliqué sur l’ensemble du parc des machines modernes.

L’idée est de proposer un type d’installation qui puisse être facilement rectifié par l’utilisateur selon l’expérience qu’il aura eue avec ce nouvel OS.

On pourra me faire remarquer qu’on pourrait réaliser cette expérience sur une machine virtuelle, mais beaucoup d’utilisateurs de PC semblent être peu à l’aise avec cette technologie, et si on le faisait, on ne saurait pas vraiment comment se comporte le Linux choisi avec le matériel propre au PC réellement utilisé.

Le choix de Xubuntu 26.04 est dû à sa relative légèreté, mais surtout au fait qu’il utilise l’installateur Subiquity, lequel devrait vraisemblablement être bientôt utilisé sur toutes les dérivées, dont Mint.

A. La phase d’installation

1. La préparation de l’installation

Point de départ : un Windows installé sur une partition unique. A noter qu’il tient ici sur deux partitions : une partition efi de 150 Mo (sur laquelle sont installés les fichiers de démarrage de Ws), et le volume C que tout le monde connaît. Un vrai PC en présenterait une de plus au moins, la partition de restauration, voire un volume D ou autre.

depart

On va tout simplement commencer par libérer de l’espace sur le volume C (ou D si on en a un) pour que notre Xubuntu puisse trouver où s’installer. Une centaine de Go est raisonnable pour une utilisation quotidienne, mais pour cette démo, je vais me limiter à 15 Go, ce qui est suffisant pour un simple essai.

Le gestionnaire de disques de Windows sera l’outil le plus simple pour effectuer cette première manipulation : un clic droit sur la partition à réduire, on choisit la taille désirée et on valide.

shrink-C

Le résultat est le suivant :

shrink-result

C’est tout pour Windows. Dès lors, on va pouvoir redémarrer sur sa clé d’installation, en l’occurrence une Xubuntu 26.04 réalisée avec le logiciel Rufus, l’application la plus connue et le plus documentée pour le faire.

2. Démarrage de l’installation et préalables indispensables.

On insère la clé USB, on règle son bios pour démarrer dessus (les informations en bas de l’écran au démarrage du PC indiquent en principe comment s’y prendre selon la marque et le modèle). On devrait logiquement aboutir à cet écran sur lequel on choisit Try or Install Xubuntu.

grub-live

Le programme se lance, jusqu’à l’affichage d’un bureau.

xub-live

L’idée est de mener une installation totalement indépendante de Windows, un peu comme si on utilisait un autre disque dur ou un autre SSD (la procédure serait d’ailleurs la même). On va donc préparer le terrain pour rendre les deux systèmes totalement indépendants l’un de l’autre.

On va donc aller chercher dans le menu, en haut à gauche l’application « Gparted » qu’on va trouver dans l’onglet système.

gparted1

Et on l’exécute. Il devrait nous afficher une fenêtre proche de celle-ci. Nos deux partitions initiales y sont présentes, la partition EFI et la partition NTFS sur laquelle se trouve Windows. Sur l’espace « unallocated », nous allons cliquer droit pour créer une première partition de 150 Mo environ, que nous allons formater en fat32 et cliquer sur add.

gparted2

Même opération sur l’espace restant, mais cette fois, en créant une partition utilisant tout l’espace et formatée en ext4.

gparted3

On valide la création des partitions en cliquant sur l’icône verte en forme de V, puis « Apply » dans  la fenêtre qui s’est ouverte. On clique sur « close » quand l’opération est arrivée à son terme.

gparted4

Il nous reste deux dernières choses à faire avant de quitter Gparted. Pour être assurés que le système installe ses fichiers de démarrage au bon endroit, on va retirer les drapeaux boot et esp de la partition efi en fat32 initiale (sda1), puis  les ajouter sur celle qu’on vient de créer (sda3). Tout se passe par clic droit suivi de « manage flags« , ce qui donne comme résultat.

gparted5

Il est temps de refermer gparted et de cliquer sur l’icône de bureau nous invitant à commencer l’installation.

3. Installation de notre Xubuntu

Le programme se lance, en proposant de choisir (pas de capture, ici, puisque tout est proposé par défaut):

  • la langue du système, puis celle du clavier,
  • puis invite à procéder à une connexion (filaire ou wifi selon sa situation,
  • un type d’installation (on reste sur interactive),
  • une installation minimale ou desktop (plutôt desktop si on veut les applications de base),
  • l’installation des codecs et des pilotes (on coche les deux)
  • et enfin, le mode d’installation : on va opter pour le partitionnement manuel, puisqu’on veut quelque chose de personnalisé.

partition1

On va retrouver la même structure qu’on avait dans gparted, mais présentée verticalement. On peut voir que la seconde partition vfat a été dotée automatiquement du point de montage /boot/efi. C’est parfait.

partition2

Nous allons donc nous occuper uniquement de la partition ext4 en la sélectionnant, puis en pressant sur le bouton « changer« .

On va lui attribuer le point de montage / en cliquant simplement sur la zone de saisie.

partition3

On valide par OK, ce qui conduit à ce résultat :

partition4

Après s’être assuré que le périphérique d’amorçage est bien dirigé sur notre disque (sda dans mon cas), on peut procéder à la suite de l’installation en cliquant sur « suivant« . On crée un utilisateur, on lui attribue un mot de passe, on laisse cochée (ou pas) la demande de MP à l’ouverture de session, et on poursuit.

user

Après avoir choisi son fuseau horaire, et présenté un résumé de nos choix, Subiquity lance l’installation après qu’on a cliqué sur « installer« .

resume

Et là, on laisse les choses se faire.

4. Important avant de redémarrer

L’installation achevée, on nous propose de redémarrer ou de continuer à tester. C’est ce dernier choix que nous allons privilégier, car il nous reste une chose essentielle à faire : redonner à la première partition fat32 (sda1) ses drapeaux esp et boot. Si nous oublions cette étape, notre Windows ne saura probablement plus comment démarrer tout seul.

On exécute donc à nouveau gparted, et on ajoute à la première partition en fat32 (sda1) ces deux drapeaux, ce qui signifie que nous allons avoir désormais 2 partitions EFI sur notre disque : une pour Windows et une pour Linux. Les fichiers de démarrage seront donc totalement indépendants.

gpartedfinal

On peut même vérifier par un petit efibootmgr que nous allons bien démarrer sur Linux

efibootmgr

5. Tests réalisés au redémarrage de la machine

Malheureusement, au redémarrage, le démarrage se fait directement sur Ubuntu sans qu’un choix soit proposé. Windows n’a pas été pris en compte bien qu’il soit là. Il va être nécessaire de forcer sa détection par grub, le lanceur des deux systèmes. On va ouvrir le fichier de configuration avec l’éditeur de texte de Xfce (mousepad) depuis un terminal via la commande

sudo mousepad /etc/default/grub 

pour modifier une des options :

GRUB_TIMEOUT_STYLE=hidden

pour lui préférer

GRUB_TIMEOUT_STYLE=menu

Mais on va également retirer le dièse (#) devant la ligne :

GRUB_DISABLE_OS_PROBER=false

hiddenmenu

On n’oublie pas d’enregistrer les modifications apportées au fichier, avant de valider l’opération en mettant à jour par la commande

sudo update-grub

qui va détecter la présence de Windows et mettre grub à jour :

update-grub

Tout est prêt pour notre dual-boot. Il ne reste plus qu’à démarrer pour tester:

grubfinal

On obtient bien un menu de démarrage opérationnel avec Ubuntu et Windows. Les deux OS se lancent parfaitement.

6. Vérification depuis Windows

Le gestionnaire de disques de Windows nous montre bien que nous avons deux partitions efi sur le même disque dur.

deuxefi

Et si on assigne une lettre à chaque partition efi (W pour Windows et L pour Linux), on constate par un dir que chacune contient les fichiers de démarrage d’un seul et unique système.

dir

B. Les trois suites possibles

1. On est satisfait de son double démarrage

Pour le coup, on laisse tel quel. Les deux systèmes vont cohabiter sans problème.

2. On n’est pas satisfait de son Linux

Depuis l’invite de commandes de Windows, en mode admin  (car une partition efi résiste au gestionnaire de disques), on supprime via diskpart les deux partitions qu’on a créées pour récupérer l’espace et le réaffecter à son son C (ou son D).

Rem : des applications Windows comme Aoméi font également ça très  bien.

diskpart
sel disk 0
list part
sel part 3
del part override
sel part 4
del part
exit

Ce qui donne concrètement :
delubuntu

Puis on s’assure que l’entrée Ubuntu a été supprimée en NVRAM (ça a été automatique chez moi) pour retrouver son Windows comme à l’origine. On peut le faire depuis le bios ou depuis une application (gratuite) telle que bootice :

bootice

3. On en a marre de Windows

Si, au contraire, on en a marre de Windows, on supprime depuis gparted (soit depuis le live-USB, soit après l’avoir installé) toutes les partitions originelles de Windows. On obtient à peu près ceci :

gparteddel

On récupère l’espace libre pour créer une partition de données ou pour déplacer celles nécessaires à Linux (depuis un LiveUSB obligatoirement pour ce second choix):

gparteddel2

On peut enfin supprimer l’entrée de Windows Boot Manager en Nvram depuis le bios ou depuis son Linux par la commande qui suit  (le 5 correspond au numéro attribué à WBM dans mon PC virtuel) :

 sudo efibootmgr -B -b 5

efibootmgr-del

Rem : le résultat n’est pas visible car je n’ai pas vraiment supprimé ce dual-boot. Ce Tiny W10 peut encore m’être utile.

On n’oubliera pas de rétablir les options de grub comme à l’origine (Cf. point I,6) en remettant hidden à la place de menu si on ne veut plus que grub apparaisse au démarrage.

Commandes utiles pour dépanner un PC sous Linux

Pour établir un état général de son installation Linux, il existe un outil très puissant appelé boot-repair qui permet de réaliser des rapports d’informations (boot-info) très complets. Mais, on n’a pas forcément besoin de tout, et il semble que l’application soit en état de latence prolongée.

Par conséquent, il n’est pas inutile d’apprendre à connaître celles qui permettent de faire un état des lieux pour espérer se dépanner en cas de problème.

Plutôt qu’un ordre alphabétique, on va les proposer par catégories, avec un exemple de résultat obtenu.

1. Identification des caractéristiques du système

  • uname (options principales -a, -r)
ikewdu@PCIKE-LMDE:~$ uname -a
Linux PCIKE-LMDE 6.12.85+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.85-1 (2026-04-30) x86_64 GNU/Linux
  • lsb_release  (option -a notamment)
ikewdu@PCIKE-LMDE:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Linuxmint
Description:	LMDE 7 (gigi)
Release:	7
Codename:	gigi
  • ou plus complet avec cat
ikewdu@PCIKE-LMDE:~$ cat /etc/os-release
PRETTY_NAME="LMDE 7 (gigi)"
NAME="LMDE"
VERSION_ID="7"
VERSION="7 (gigi)"
VERSION_CODENAME=gigi
ID=linuxmint
HOME_URL="https://www.linuxmint.com/"
SUPPORT_URL="https://forums.linuxmint.com/"
BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
PRIVACY_POLICY_URL="https://www.linuxmint.com/"
ID_LIKE=debian
DEBIAN_CODENAME=trixie
DEBIAN_VERSION_FULL=13.0
  • cat /proc/version
ikewdu@PCIKE-LMDE:~$ cat /proc/version
Linux version 6.12.85+deb13-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC Debian 6.12.85-1 (2026-04-30)

On pourra également regarder du côté des commandes lshw ou inxi qui donneront d’autres informations, plus détaillées, sur le matériel.

2. Bios et UEFI

  • Commande od (présence d’un grub dans le secteur 0, même sur disque gpt):
ikewdu@PCIKE-LMDE:~$ sudo od -tx1z -Ax -N 512 /dev/sda |grep -i rub
[sudo: authenticate] Mot de passe :     
000180 7d e8 2e 00 cd 18 eb fe 47 52 55 42 20 00 47 65  >}.......GRUB .Ge
  • Autre moyen de lire le secteur 0 d’un disque avec dd :
ikewdu@PCIKE-LMDE:~$ sudo dd if=/dev/sda bs=512 skip=1 count=1 | hexdump -C
00000000  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000010  99 43 fb 91 00 00 00 00  01 00 00 00 00 00 00 00  |.C..............|
00000020  af c2 e7 0e 00 00 00 00  22 00 00 00 00 00 00 00  |........".......|
1+0 enregistrements lus
1+0 enregistrements écrits
512 octets copiés, 0,000274103 s, 1,9 MB/s00000030  8e c2 e7 0e 00 00 00 00  1c b5 09 0e f7 3d 1f 4f  |.............=.O|
00000040  b3 82 3c ae d4 71 da 5b  02 00 00 00 00 00 00 00  |..<..q.[........|
00000050  80 00 00 00 80 00 00 00  50 c1 c4 ce 00 00 00 00  |........P.......|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
  • La commande pour savoir dans quel mode on boote (Legacy ou UEFI) : [ -d /sys/firmware/efi ]
ikewdu@PCIKE-LMDE:~$ [ -d /sys/firmware/efi ] && echo "Session EFI" || echo "Session non-EFI"
Session EFI
  • Affichage des entrées en NVram en UEFI  (la Nvram de ce PC est plombée) : efibootmgr
ikewdu@PCIKE-LMDE:~$ efibootmgr -v
Skipping unreadable variable "Boot0001": Input/output error
error trace:
 efivarfs.c:275 efivarfs_get_variable(): read failed: Input/output error
 lib.c:140 efi_get_variable(): ops->get_variable failed: Input/output error
  • Etat du secure-boot par mokutil :
ikewdu@PCIKE-LMDE:~$ mokutil --sb-state
Secure Boot disabled

3. Identification des disques et partitions

  • fdisk (options -l, -lu (ou |grep 'chaîne' pour ne voir qu'une partie)
ikewdu@PCIKE-LMDE:~$ sudo fdisk -l |grep -E 'dev|typ'
[sudo] Mot de passe de ikewdu :         
Disk /dev/sda: 119,24 GiB, 128035676160 bytes, 250069680 sectors
Disklabel type: gpt
/dev/sda1       2048   1023999   1021952  499M EFI System
/dev/sda2    1024000   1286143    262144  128M Microsoft reserved
/dev/sda3    1286144 156220371 154934228 73,9G Microsoft basic data
/dev/sda4  248381440 250066943   1685504  823M Windows recovery environment
/dev/sda5  156221440 248381439  92160000 43,9G Linux filesystem
Disk /dev/mmcblk0: 29,12 GiB, 31272206336 bytes, 61078528 sectors
Disklabel type: dos
/dev/mmcblk0p1       2048 61077503 61075456 29,1G  c W95 FAT32 (LBA
  • La commande lsblk (autre manière de voir les partitions. Option -T pour forcer le tri)
ikewdu@PCIKE-LMDE:~$ lsblk -T
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 119,2G  0 disk 
├─sda1        8:1    0   499M  0 part /boot/efi
├─sda2        8:2    0   128M  0 part 
├─sda3        8:3    0  73,9G  0 part 
├─sda4        8:4    0   823M  0 part 
└─sda5        8:5    0  43,9G  0 part /
mmcblk0     179:0    0  29,1G  0 disk 
└─mmcblk0p1 179:1    0  29,1G  0 part /media/ikewdu/MINI-SD

La commande df, pour voir l'occupation des disques

ikewdu@PCIKE-LMDE:~$ df -TH
Sys. de fichiers Type     Taille Utilisé Dispo Uti% Monté sur
udev             devtmpfs   2,0G       0  2,0G   0% /dev
tmpfs            tmpfs      392M    1,7M  390M   1% /run
/dev/sda5        ext4        47G     17G   27G  39% /
tmpfs            tmpfs      2,0G     39M  2,0G   2% /dev/shm
tmpfs            tmpfs      5,3M    8,2k  5,3M   1% /run/lock
tmpfs            tmpfs      2,0G    3,9M  2,0G   1% /tmp
tmpfs            tmpfs      1,1M       0  1,1M   0% /run/credentials/systemd-journald.service
/dev/sda1        vfat       520M     41M  479M   8% /boot/efi
tmpfs            tmpfs      1,1M       0  1,1M   0% /run/credentials/getty@tty1.service
tmpfs            tmpfs      392M    193k  392M   1% /run/user/1000
/dev/mmcblk0p1   vfat        32G     12M   32G   1% /media/ikewdu/MINI-SD
  • blkid ou sudo blkid (affichage des UUID des partitions)
ikewdu@PCIKE-LMDE:~$ blkid
/dev/sda4: LABEL="Winre" BLOCK_SIZE="512" UUID="D45243FD5243E2BA" TYPE="ntfs" PARTUUID="7769ceec-d492-4b0b-bd1e-0e291e03dd38"
/dev/sda5: UUID="657a3c25-e204-4d29-b4ee-0c6e52627497" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="4bfba239-2fe3-4522-bf10-946a28da3b2c"
/dev/sda3: LABEL="Windows10" BLOCK_SIZE="512" UUID="206A0B456A0B16E6" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="85198382-0484-4c68-9c70-83c453720faa"
/dev/sda1: LABEL_FATBOOT="BOOT" LABEL="BOOT" UUID="C40A-8738" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="a828521e-c643-40d3-aed5-3f938cd9bc1d"

4. Voir  la stratégie de montage des partitions (fstab)

  • La commande cat /etc/fstab
ikewdu@PCIKE-LMDE:~$ cat /etc/fstab
#### Static Filesystem Table File
proc	/proc	proc	defaults	0	0
# /dev/sda1
UUID=C40A-8738	/boot/efi	vfat	defaults	0	1
# /dev/sda5
UUID=657a3c25-e204-4d29-b4ee-0c6e52627497	/	ext4	rw,errors=remount-ro	0	1

On notera qu'on dispose également de la commande sudo parted -l qui fournit des résultats proches de fdisk.

4. Le paramétrage de grub

  • La commande cat pour afficher le paramétrage de grub
ikewdu@PCIKE-LMDE:~$ cat /etc/default/grub
# If you change this file or any /etc/default/grub.d/*.cfg file,
# run 'update-grub' afterwards to update /boot/grub/grub.cfg.
# For full documentation of the options in these files, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`( . /etc/os-release && echo ${NAME} )`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

# If your computer has multiple operating systems installed, then you
# probably want to run os-prober. However, if your computer is a host
# for guest OSes installed via LVM or raw disk devices, running
# os-prober can cause damage to those guest OSes as it mounts
# filesystems to look for things.
#GRUB_DISABLE_OS_PROBER=false

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE/GOP/UGA
# you can see them in real GRUB with the command `videoinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
  • La commande cat combinée à grep (pour faire plus propre)
ikewdu@PCIKE-LMDE:~$ cat  | grep -v '#' /etc/default/grub

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`( . /etc/os-release && echo ${NAME} )`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""
  • Lire avec cat la redirection de grub en efi ('debian' à remplacer par le dossier correct).
ikewdu@PCIKE-LMDE:~$ cat /boot/efi/EFI/debian/grub.cfg
search.fs_uuid 657a3c25-e204-4d29-b4ee-0c6e52627497 root hd0,gpt5 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg
  • Voir avec cat tout le fichier de config de grub (pas forcément utile, mais bon...)
ikewdu@PCIKE-LMDE:~$ sudo cat /boot/grub/grub.cfg
[sudo] Mot de passe de ikewdu :         
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
(j'arrête là pour une question de longueur)

 5. Voir le contenu des partitions importantes (EFI notamment)

Les fichiers efi dans la partition de sa distribution avec ls

ikewdu@PCIKE-LMDE:~$ ls -lR /boot/efi/EFI/*/*.efi
-rwxr-xr-x 1 root root 1273656  3 mai    2019 /boot/efi/EFI/Boot/bootx64.efi
-rwxr-xr-x 1 root root   87888 27 nov.  07:47 /boot/efi/EFI/debian/fbx64.efi
-rwxr-xr-x 1 root root 2684352 27 nov.  07:47 /boot/efi/EFI/debian/grubx64.efi
-rwxr-xr-x 1 root root  850176 27 nov.  07:47 /boot/efi/EFI/debian/mmx64.efi
-rwxr-xr-x 1 root root  957136 27 nov.  07:47 /boot/efi/EFI/debian/shimx64.efi

En cas de dual-boot, pour voir aussi les fichiers de Windows avec ls :

ikewdu@PCIKE-LMDE:~$ ls -lR /boot/efi/EFI/*/*.efi && ls -lR /boot/efi/EFI/*/*/*.efi
-rwxr-xr-x 1 root root 1273656  3 mai    2019 /boot/efi/EFI/Boot/bootx64.efi
-rwxr-xr-x 1 root root   87888 27 nov.  07:47 /boot/efi/EFI/debian/fbx64.efi
-rwxr-xr-x 1 root root 2684352 27 nov.  07:47 /boot/efi/EFI/debian/grubx64.efi
-rwxr-xr-x 1 root root  850176 27 nov.  07:47 /boot/efi/EFI/debian/mmx64.efi
-rwxr-xr-x 1 root root  957136 27 nov.  07:47 /boot/efi/EFI/debian/shimx64.efi
-rwxr-xr-x 1 root root 1273656  3 mai    2019 /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
-rwxr-xr-x 1 root root 1256760  3 mai    2019 /boot/efi/EFI/Microsoft/Boot/bootmgr.efi
-rwxr-xr-x 1 root root 1103672  3 mai    2019 /boot/efi/EFI/Microsoft/Boot/memtest.efi

6. Les paquets et leur état

  • Voir si on a des paquets cassés  avec dpkg :
ikewdu@PCIKE-LMDE:~$ dpkg -l | grep -v ^ii

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
+++-==========================================-=====================================-============-================================================================================
hi  grub-efi-amd64                             2.12-9                                amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 version)
hi  grub-efi-amd64-signed                      1+2.12+9                              amd64        GRand Unified Bootloader, version 2 (amd64 UEFI signed by Debian)

 

Installer Xubuntu 26.04 en mbr

Les difficultés rencontrées pour installer une distribution Linux en mode Legacy-mbr étant apparemment assez nombreuses, j’ai donc décidé de proposer une démonstration de ce qu’on peut faire sur un PC réel, doté d’un disque dur mécanique de 640 Go. En résumé :

Marque et Modèle : Packard Bell EasyNote TK87
RAM : 4GiB Mémoire Système
CPU : dual core Intel Core i3 M 380 (-MT MCP-) speed/min/max: 933/933/2533 MHz
CGU : [AMD/ATI] Robson CE [Radeon HD 6370M/7370M]

1. Le choix de la distribution : xubuntu 26.04 (version minimale)

La plupart des novices se tournent vers des distributions comme Linux Mint ou Zorin, c’est pourquoi j’ai choisi une distribution basée elle aussi sur Ubuntu, à savoir Xubuntu 26.04.

  • Ce choix est motivé par le fait qu’elle utilise le nouveau processus d’installation nommé Subiquity, contrairement aux versions 22.xx de Mint qui utilisent encore l’ancien protocole, à savoir Ubiquity*.
  • J’ai également écarté la version LMDE7 de Mint qui utilise l’installateur Calamares (que je préfère personnellement), car peu de gens se tournent vers cette version.

* Un exemple de tuto pour une installation en mbr avec Ubiquity proposé par Enigma7 ici.

2. Création de la clé USB

La plupart des novices utilisant Rufus, on va se servir de cette application. Après avoir téléchargé le fichier ISO de la distribution de son choix, et l’application Rufus, on exécute cette dernière qui nous propose une fenêtre ayant cette apparence :

On prend soin de sélectionner l’image iso téléchargée, le schéma de partition mbr, les modes bios et uefi, et enfin de cocher l’option ajoutant une compatibilité pour les vieux bios. On clique sur « démarrer », et on valide via « continuer » jusqu’au lancement du processus. Quand celui-ci s’achève, la clé est prête.

3. Démarrage sur la clé USB

A ce stade, tout dépend du PC et de la manière dont le bios est configuré. En principe, il est programmé pour démarrer sur USB en priorité, ne serait-ce que pour pouvoir réinstaller Windows. Si ce n’est pas le cas, il faut regarder ce qui est indiqué en bas d’écran au début du démarrage. Sur un Packard Bell, on peut obtenir un menu en pressant F12, ce qui permet de choisir un boot sur USB.

Une fois la clé USB sélectionnée, on choisit la première entrée proposée (try or install Xubuntu) et on attend d’obtenir un bureau en mode graphique.

4. Préalables à l’installation

On pourrait lancer l’installation directement en cliquant sur l’icône idoine, mais personnellement, je préfère toujours m’assurer que tout est correctement préparé pour la future installation. C’est pourquoi, je procède à plusieurs opérations préalables avant de me lancer.

  • Passage du clavier en mode azerty : depuis le menu en haut à gauche, j’ouvre un terminal et je saisis setxkbmap fr (en qwerty, ça donne setxkb,qp fr).
  • Je connecte le wifi (saisir le code est tout de même plus simple en azerty).

  • Je lance une commande sudo parted -l pour m’assurer que le disque est au format dos (mbr) :

Le disque est au format ms-dos. Les deux partitions (obsolètes) seront supprimées par la mise en place d’une nouvelle table de partitions. Tout est donc parfait pour réaliser l’installation en mode Legacy.

5. Installation directe

5.1. La phase initiale de l’installation

On clique sur l’icone nous invitant à installer. Subiquity se lance en proposant les étapes traditionnelles :

    • Choix de la langue

    • Installation des pilotes et codec

Ce qui nous amène inévitablement au choix de la méthode d’installation.

5.2. Du partitionnement manuel à l’installation

Je n’ai pas testé les propositions dites « automatiques » parce que j’aime bien contrôler ce que je fais. En outre, je préfère créer des partitions séparées pour la racine et le home, ce qui impose de passer par le partitionnement manuel. Et tant qu’on y est, profitons-en pour recréer la table de partitions.

Ceci étant fait, on ajoute (via l’icone +) une première partition de 85 Go environ en ext4 avec point de montage /  pour y placer le système.

Même opération pour la partition /home, toujours en ext4 avec cette fois le point de montage /home

Il ne reste plus qu’à valider tout ça pour continuer l’installation. C’est à ce moment qu’on nous demande de créer notre utilisateur :

Ceci fait, Subiquity nous propose un récapitulatif, un choix de créneau horaire (désolé, j’ai oublié de faire les captures d’écran) avant de lancer l’installation :

A ce stade, il n’y a plus qu’à laisser l’installation aller à son terme, et à redémarrer une fois que c’est terminé. Le système redémarre en effet sans le moindre problème.

!!! On notera qu’à aucun moment, la création d’une partition efi ne nous a été proposée, ce qui est un progrès par rapport à la version liée à l’ancien installateur Ubiquity.

5.3. Petit bémol au redémarrage

Tout s’est parfaitement bien passé, si ce n’est que le format de disque a été modifié… On est passé d’un disque dos (mbr) à un disque gpt, ce qui a généré la création d’une mini-partition « bios-grub » pour compenser l’absence de grub dans le secteur zéro. Ce n’est pas rédhibitoire si le PC reconnaît le format gpt, mais c’est plus problématique si ce n’est pas le cas.

Le point 6 va montrer comment éviter cette mésaventure pour s’assurer que le format mbr (à suivre).

6. Conserver le format dos (mbr)

Après plusieurs essais, il semble que le plus simple soit, avant installation, de forcer le format de disque dos (mbr) depuis Gparted si par malchance le disque est initialement configuré au format gpt. Car Subiquity ne saura pas le faire lui-même. Pire, il bloquera l’installation au stade du partitionnement en ne sachant où placer grub si le disque est au format gpt et qu’aucune partition efi n’est détectée.

Cependant, il semble, d’après mes tests, qu’un vieux disque mécanique au format mbr soit moins bien géré au démarrage de Xubuntu s’il demeure en mbr (plus lent de 30 secondes, et grub toujours apparent malgré l’option « hidden »). La recréation de la table de partitions évoquée au début du point 5.2. semble donc préférable dans ce cas particulier.

 

 

 

Deux méthodes de conversion de Windows Legacy vers UEFI

Souvent, on est confronté au désir de faire passer une installation de Windows en mode bios vers une installation UEFI. Ca implique deux préalables :

  1. Le bios doit être compatible uefi. On s’en assure avant toute manipulation.
  2. Le disque au format mbr devra être converti au format gpt.

Nous allons partir de cette situation : un Windows hérité (bios) sur disque mbr (on le voit par la partition active) sur un disque affecté du numéro 0 :
initial

 1. La méthode directe via mbr2gpt

Microsoft a proposé en effet une commande directe pour faire cette opération. Elle  est documentée sur de nombreux sites, et donc je vais aller assez vite.

On peut la saisir depuis Windows lui-même ou depuis une console WinPE (mon choix). Ce qui  donne en substance pour la première commande :

mbr2gpt /validate /disk:0

test

La seconde commande :

mbr2gpt /convert /disk:0

mbr2gpt

La conversion se fait sans difficulté, et Windows va démarrer directement dès qu’on aura basculé le bios de Legacy à UEFI. Le seul bémol, c’est que mbr2gpt a placé la partition efi où bon lui a semblé, et il n’a pas créé de partition msr.

ps-msr

C’est négligeable et facilement récupérable, mais j’aurais préféré contrôler moi-même ces choix. Je vais donc utiliser une autre méthode, un peu plus technique, mais plus personnalisable.

2. La méthode indirecte via gdisk et bcdboot

En partant de la même situation initiale, nous allons devoir procéder en deux temps. Convertir le disque au format gpt, puis recréer les partitions et fichiers de démarrage.

2.1. Conversion du disque via gdisk

On trouve gdisk sur tous les live-usb Linux  et il existe même une version Windows (que je n’ai pas testée). Je vais utiliser une Mint Xfce pour faire cette première opération. J’en profiterai pour supprimer la partition « reserved » devenue inutile (avec gparted, par exemple)./

Mon disque à convertir étant identifié dans gparted par l’appellation /dev/sda, j’exécute gdisk  pour le modifier :

sudo gdisk /dev/sda

Là, il me confirme que mon disque est bien au format mbr.

gdsik

La simple lettre « w » confirmée par un « y » va permettre de le convertir  :

gdisk2

Ici s’arrête l’intervention de gdisk et de Linux. On va pouvoir redémarrer le PC sur une console WinPE ou un disque d’installation de Windows pour finaliser la modification.

2.2. Réparation du démarrage de Windows

A ce stade, il faut démarrer sur une console (ou un support d’installation) jusqu’à obtenir une invite de commandes. On en profite pour basculer le bios en UEFI ; on vérifie depuis WinPE que la conversion en gpt s’est bien faite, ce qui est prouvé par  l’astérisque au retour de « list disk ». On en profite pour vérifier les partitions:

diskpart
list disk
sel disk 0
list part

On n’a plus qu’à créer les partitions que l’on souhaite (une msr de 16 Mio et le reste pour l’EFI) :

create part msr size=16
create part efi

On formate et on assigne une lettre. On peut même vérifier le résultat :

format fs=fat32 quick
assign letter=R
list part

Le tout en images donne ceci :

create-part

Il ne reste qu’à réparer le démarrage pour l’adapter à l’UEFI. On vérifie les lettres assignées aux volumes (EFI et Windows), et on écrit les fichiers de démarrage :

list vol
exit
bcdboot e:\windows /l fr-fr /s r:

Ce qui donne :

bcdboot

On ferme l’invite de commandes et on peut voir que Windows est déjà proposé :

Boot-efi

Il ne reste plus qu’à démarrer.  Le PC tourne en UEFI avec les partitions telles qu’on les souhaitait.

final

Notre conversion s’est achevée sans heurt, et avec la structure que nous désirions.

Installer ubuntu 21-04 en uefi directement avec Refind

Le lanceur Grub est traditionnellement installé avec Ubuntu, mais ce lanceur est devenu une telle usine-à-gaz qu’on peut être tenté de lui substituer Refind,  qui est bien plus qu’une solution alternative. Beaucoup de tutoriels existent, mais ils sont souvent complexes et peu explicites. Cette démonstration présuppose une installation complète sur un disque vierge.

depart

La désactivation du « secure-boot » dans le bios sera préférable. Et à noter que le partitionnement pourrait se faire directement pour obtenir une structure proche de celle présentée un peu plus loin dans cette démo*.

* Tout se passe sur le disque sdb, le disque sda étant associé à une autre installation sans intérêt ici.

I. Installation d’Ubuntu sans grub

1. L’installation via ubiquity -b

On démarre bien entendu sur le support d’installation, et on choisit « d’essayer Ubuntu », en profitant bien sûr pour le passer en français.

Une fois sur le bureau, on va choisir non pas d’installer via le raccourci proposé, mais en lançant un terminal, et en tapant la commande :

ubiquity -b

Celle-ci va lancer l’installation avec une petite différence : grub ne sera pas installé*.

* A noter que l’installateur Calamares, sur Debian, permet d’éviter l’installation de grub de manière graphique. 

ubiquity

Autrement dit, en fin d’installation, Ubuntu ne sera pas capable de démarrer.

Les étapes habituelles vont être proposées, et au choix de partitionnement, on va préférer choisir « autre chose » afin de partitionner le disque à notre convenance. Deux partitions au minimum seront  ajoutées par le bouton + :

  • Une partition efi en fat32 de 100 Mo environ montée avec le point de montage boot/esp.
  • Une partition racine en ext4 sur le reste du disque :

montage-parts

On obtient  le résultat suivant  (vu depuis gparted, que j’ai utilisé en réalité pour le partitionnement) :

cree-partitions

A ce stade, on peut poursuivre l’installation que va aller à son terme.  L’installateur va nous proposer de « redémarrer » ou de « continuer à tester » . Nous allons choisir la seconde option, car Ubuntu ne fonctionnerait pas en l’état..

2. Etat des lieux au terme de l’installation

Le plus simple est de faire le point via un terminal, pour estimer la situation :

ubuntu@ubuntu:~$ sudo fdisk -l |grep "/dev/sdb"
Disque /dev/sdb : 16 GiB, 17179869184 octets, 33554432 secteurs
/dev/sdb1      2048   194559   192512    94M Système EFI
/dev/sdb2    194560 33552383 33357824  15,9G Système de fichiers Linux

Nous avons bien deux partitions, sdb1 et sdb2, l’une pour l’EFI, l’autre pour notre Ubuntu

ubuntu@ubuntu:~$ sudo efibootmgr
BootCurrent: 0001
BootOrder: 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
Boot0003* EFI Internal Shell (Unsupported option)

Aucune entrée n’a été créée dans la NVram du bios-uefi. Notre Linux n’est pas fonctionnel.

II. Installation de Refind

1. Téléchargement de Refind

En fait, le terme installation n’est pas approprié. Nous allons simplement télécharger les fichiers nécessaires au démarrage, et ce directement sur notre live-usb. La procédure est assez simple, parce qu’elle est automatique et en trois commandes:

ubuntu@ubuntu:~$ sudo add-apt-repository universe
Adding component(s) 'universe' to all repositories.
Press [ENTER] to continue or Ctrl-c to cancel.

Je vous épargne les lignes affichées pour passer à la seconde commande :

ubuntu@ubuntu:~$ sudo apt update
Ign :1 cdrom://Ubuntu 21.04 _Hirsute Hippo_ - Alpha amd64 (20210116) hirsute InRelease
Atteint :2 cdrom://Ubuntu 21.04 _Hirsute Hippo_ - Alpha amd64 (20210116) hirsute Release
Atteint :4 http://archive.ubuntu.com/ubuntu hirsute InRelease
Atteint :5 http://archive.ubuntu.com/ubuntu hirsute-updates InRelease  
Atteint :6 http://security.ubuntu.com/ubuntu hirsute-security InRelease
Lecture des listes de paquets... Fait               
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait

Idem. Et enfin  la dernière :

ubuntu@ubuntu:~$ sudo apt install refind
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Les NOUVEAUX paquets suivants seront installés :
  refind
0 mis à jour, 1 nouvellement installés, 0 à enlever et 1073 non mis à jour.

Une fenêtre nous proposant d’installer Refinf en partition ESP. Il suffira de décliner cette proposition.

Refind, une fois téléchargé, verra tous ses dossiers importants  installés dans /usr/share/refind. On pourra le vérifier :

ubuntu@ubuntu:~$ ls /usr/share/refind/*
/usr/share/refind/refind-install

/usr/share/refind/banners:
refind_banner-alpha.png  refind_banner.png  refind_banner.svg

/usr/share/refind/fonts:
liberation-mono-regular-12.png  nimbus-mono-14.png  ubuntu-mono-14.png
liberation-mono-regular-14.png  nimbus-mono-16.png  ubuntu-mono-16.png
liberation-mono-regular-24.png  nimbus-mono-24.png  ubuntu-mono-24.png
liberation-mono-regular-28.png  nimbus-mono-28.png  ubuntu-mono-28.png
mkfont.sh                       README.txt
nimbus-mono-12.png              ubuntu-mono-12.png

/usr/share/refind/refind:
drivers_x64  icons  refind.conf-sample  refind_x64.efi  tools_x64
ubuntu@ubuntu:~$

En dernière ligne s’affiche un fichier « sample » que nous allons modifier immédiatement :

sudo mv /usr/share/refind/refind/refind.conf-sample /usr/share/refind/refind/refind.conf

Nous avons tous les outils nécessaires pour installer Refind sur la partition efi

2. Installation de Refind en partition efi

2.1. Cas général

Si le PC n’est pas verrouillé au niveau du bios, il est assez simple d’installer Refind en montant la partition sdb1 (EFI), en créant un dossier provisoire /efi/refind, et en y copiant simplement les fichiers nécessaires :

ubuntu@ubuntu:~$ sudo mount /dev/sdb1 /mnt/sdb1
ubuntu@ubuntu:~$ sudo mkdir -p /mnt/sdb1/efi/refind
ubuntu@ubuntu:~$ sudo cp -rv /usr/share/refind/refind/* /mnt/sdb1/efi/refind 
'/usr/share/refind/refind/drivers_x64' -> '/mnt/sdb1/efi/refind/drivers_x64' 
'/usr/share/refind/refind/drivers_x64/btrfs_x64.efi' -> '/mnt/sdb1/efi/refind/drivers_x64/btrfs_x64.efi' 
'/usr/share/refind/refind/drivers_x64/ext2_x64.efi' -> '/mnt/sdb1/efi/refind/drivers_x64/ext2_x64.efi' 
'/usr/share/refind/refind/drivers_x64/ext4_x64.efi' -> '/mnt/sdb1/efi/refind/drivers_x64/ext4_x64.efi' 
'/usr/share/refind/refind/drivers_x64/hfs_x64.efi' -> '/mnt/sdb1/efi/refind/drivers_x64/hfs_x64.efi'

Nous pouvons constater que seul le sous-dossier /refind aura été nécessaire.
Un aperçu du résultat de la copie :

refind-cree-dossiers

A nouveau, je passe sur la liste complète des fichiers copiés. Notre Refind serait sans doute déjà opérationnel dans la plupart des cas. Pour être sûr du démarrage de Refind, nous allons ajouter une entrée de démarrage la  NVram du bios-uefi :

ubuntu@ubuntu:~$ sudo efibootmgr --create --disk /dev/sdb --part 1 --label "Refind-efiboomgr" --loader "efi\refind\refind_x64.efi"
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
Boot0003* EFI Internal Shell (Unsupported option)
Boot0004* Refind-efiboomgr
ubuntu@ubuntu:~$

Exemple en image :

montage-parts

Si le bios UEFI n’est pas « verrouillé », l’entrée sera ajoutée automatiquement. On n’a plus qu’à tester en redémarrant enfin sur la version installée :

refind

2.2. Cas particuliers

Certains PC, plus ou moins verrouillés, n’autorisent pas l’écriture en NVRam et empêchent de démarrer tant sur Grub que sur Refind. On peut rencontrer pas mal de situations qui demanderaient chacune  des précisions. La plus courante est l »obligation d’ajouter une entrée Ubuntu depuis le bios  lui-même.

3. Paramétrages de Refind

En allant sur le site de Rod Smith (l’auteur) ou sur d’autres tutoriels comme celui du site Ubuntu, on pourra paramétrer Refind pour le rendre plus fonctionnel. Je n’entre pas dans le détail.

Installations automatiques hybrides sous Ubuntu 21.04

Depuis la version 20.10, on peut constater qu’il est de plus en plus difficile d’installer une distribution Ubuntu en mode Legacy. La question a déjà été traitée dans ce sujet par malbo pour cette version 20.10. Il a constaté l’évolution de l’installation de grub : ce qui est vrai pour Ubuntu le sera probablement pour ses dérivées. La version 21.04 suit malheureusement le même chemin.

Je fais rarement des tests sur les distributions non officielles, mais cette fois, je vais faire une exception : tester l’installation d’une Ubuntu 21.04 en mode Legacy, sur un disque mbr (dos). 

1. Installation automatique d’Ubuntu 21.04

Je ne détaille pas cette possibilité qui est bien expliquée par malbo sur la version 20.10. L’installateur Ubiquity ne laisse guère le choix. Soit « effacer le disque intégralement », ce qui convertit le disque au format gpt, et donc conduit à une installation UEFI ; soit passer par « autre chose », et accepter la création d’une partition efi, ce qui conduit au même résultat.  On a un exemple de ce résultat dans le rapport boot-info de ce sujet .

On constate que le PC fonctionne en uefi :

BIOS is EFI-compatible, and is setup in EFI-mode for this installed-session.

Le disque est pourtant au format dos :

fdisk -l (filtered): ___________________________________________________________

Disk sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk identifier: 0x5de0dddf
Type d'étiquette de disque : dos
      Boot      Start        End    Sectors   Size Id Type
sda1             2048   48828219   48826172  23.3G 83 Linux
sda2         48830462 1953523711 1904693250 908.2G  5 Extended
sda5         48830464   52733951    3903488   1.9G 82 Linux swap / Solaris
sda6         52736000 1947267249 1894531250 903.4G 83 Linux
sda7  *    1947269120 1953523711    6254592     3G ef EFI (FAT-12/16/32)

Enfin, la partition EFI est activée par un drapeau boot, et pourtant elle est incluse dans une partition étendue. Tout ceci est assez surprenant. Et pourtant, c’est fonctionnel. Mais Windows, en dual-boot, doit peu aimer cette situation.

2. Tests manuels d’installation

2.1. Forçage de l’installation en mode Legacy sans partition efi 

Le Bios réglé en mode Legacy, avec un disque dos. Je force la création d’une petite partition NTFS pour simuler l’idée  que le disque n’est pas vierge, et je crée avec Gparted  une partition ext4 que j’associe à / pour mon installation d’Ubuntu. Je passe outre un message d’avertissement me signalant l’absence de partition EFI, ce qui me conduit à une erreur GRUB en fin  d’installation. Je teste néanmoins un redémarrage, et là, surprise, Ubuntu 21.04 démarre. Le retour de quelques commandes propose ceci  (car boot-repair est inopérant) :

test@test-virtual-machine:~$ sudo od -tx1z -Ax -N 512 /dev/sda |grep -i rub
000180 7d e8 2e 00 cd 18 eb fe 47 52 55 42 20 00 47 65  >}.......GRUB .Ge<

test@test-virtualmmachine:~$ cat /etc/issue
Ubuntu Hirsute Hippo (development branch) \n \l

test@test-virtual-machine:~$ [ -d /sys/firmware/efi ] && echo "Session EFI" || echo "Session non-EFI"
Session non-EFI

test@test-virtual-machine:~$ sudo fdisk -l
Périphérique Amorçage   Début      Fin Secteurs Taille Id Type
/dev/sda1    *           2048  4028415  4026368   1,9G  7 HPFS/NTFS/exFAT
/dev/sda2             4028416 62914559 58886144  28,1G 83 Linux

test@test-virtual-machine:~$ dpkg --get-selections | grep grub
grub-common					install
grub-efi-amd64-bin				install
grub-efi-amd64-signed				install
grub-gfxpayload-lists				install
grub-pc						install
grub-pc-bin					install
grub2-common					install

Un grub a bien été installé dans le mbr, malgré le message d'erreur. Les versions Legacy et UEFI de Grub sont installées, et l'installation fonctionne sans partition efi. Mais elle n'est pas allée à son terme. On peut prévoir des soucis à venir

 2.2. Acceptation de la partition efi, avec création manuelle en partition primaire 

Toujours en mode Legacy, sur disque ms-dos, avec une partition NTFS présente, je crée cette fois la partition efi souhaitée (et je force son installation en primaire via « autre chose« , contrairement à ce qui est proposé par défaut pour être sûr de booter également en UEFI). L’installation se fait sans heurt.

Quelques commandes en Legacy :

Test@test-virtual-machine:~$ sudo od -tx1z -Ax -N 512 /dev/sda |grep -i rub
000180 7d e8 2e 00 cd 18 eb fe 47 52 55 42 20 00 47 65  >}.......GRUB .Ge<

test@test-virtual-machine:~$ [ -d /sys/firmware/efi ] && echo "Session EFI" || echo "Session non-EFI"
Session non-EFI

test@test-virtual-machine:~$ sudo parted -l
Table de partitions : msdos
Drapeaux de disque : 
Numéro  Début   Fin     Taille  Type      Système de fichiers  Fanions
 1      1049kB  2063MB  2062MB  primary   ntfs
 2      2064MB  32,1GB  30,0GB  extended
 5      2064MB  32,1GB  30,0GB  logical   ext4
 3      32,1GB  32,2GB  149MB   primary   fat32                démarrage, esp

test@test-virtual-machine:~$ dpkg --get-selections | grep grub
grub-efi-amd64-signed				install
grub-pc						install

On constate que les deux versions de Grub sont installées, et qu'un Grub est toujours présent dans le mbr. Donc, Ubuntu peut fonctionner en mode Legacy.

Quelques commandes en UEFI:  

test@test-virtual-machine:~$ [ -d /sys/firmware/efi ] && echo "Session EFI" || echo "Session non-EFI"
Session EFI

test@test-virtual-machine:~$ sudo efibootmgr -v
BootCurrent: 0000
BootOrder: 0004,0000,0001,0002,0003
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)
Boot0004* ubuntu	HD(3,MBR,0x72e662bb,0x3bb8800,0x47000)/File(\EFI\ubuntu\shimx64.efi)

La même installation fonctionne également dans le mode UEFI. Une entrée « Boot4 Ubuntu » s’est créée spontanément au premier démarrage en UEFI. L’installation est donc opérationnelle sur un PC hybride. Mais la partition efi reste montée dans fstab, ce qui signifie qu’on ne peut supprimer la partition efi dans opérer une modification.

 2.3. Acceptation de la partition efi, avec création automatique en partition logique

L’installation par défaut proposant la création d’une partition EFI logique, au sein d’une partition étendue. Il n’est pas nécessaire de tester une nouvelle fois en Legacy, car l’installation est identique dans ce mode. La question est : cela bootera-t-il en UEFI ?

Test@test-virtual-machine:~$ sudo efibootmgr -v 
BootCurrent: 0000
BootOrder: 0005,0004,0000,0001,0002,0003
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)
Boot0004* ubuntu	HD(3,MBR,0x72e662bb,0x3bb8800,0x47000)/File(\EFI\ubuntu\shimx64.efi)
Boot0005* ubuntu	HD(2,MBR,0x72e662bb,0x3d7ffe,0x37e0802)/HD(2,MBR,0x0,0x3b2a000,0x8e800)/File(\EFI\ubuntu\shimx64.efi)

test@test-virtual-machine:~$ sudo ls /boot/efi/EFI/Boot
BOOTX64.EFI  fbx64.efi	mmx64.efi

test@test-virtual-machine:~$ sudo fdisk -l
Périphérique Amorçage    Début      Fin Secteurs Taille Id Type
/dev/sda1                 2048  4028415  4026368   1,9G  7 HPFS/NTFS/exFAT
/dev/sda2              4030462 62621695 58591234  27,9G  5 Étendue
/dev/sda5              4030464 62035967 58005504  27,7G 83 Linux
/dev/sda6    *        62038016 62621695   583680   285M ef EFI (FAT-12/16/32)

Sur la machine virtuelle, tout s’est très bien passé, même avec une partition efi logique. L’entrée « Boot5 Ubuntu » s’est créée.  Mais c’est sur Vmware, dont c’est très « théorique ». Avec les dual-boot Windows et les Nvram plombées, ça promet de nombreux plantages. En  voici un premier exemple : https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1912044

 3. Une installation complète réussie en Legacy traditionnel

L’idée est d’aboutir au résultat du point 2.1, mais en finalisant l’installation. Première opération, lancer le live-usb d’Ubuntu en mode Legacy-bios, et choisir « essayer Ubuntu« . On commence par préparer son disque pour une installation traditionnelle :

3.1. Création d’une partition unique en ext4, sur disque ms-dos

L’opération assez classique est faite depuis Gparted, intégré au live Ubuntu :Mon image

3.2. Installation d’Ubuntu sans Grub

Au lieu de cliquer sur l’icone d’installation, je choisis de passer par un Terminal, et de taper :

ubiquity -b 

Cette commande indique à Ubiquity qu’on ne veut pas installer Grub tout de suite.  On suit les indications habituelles, jusqu’à la proposition « Autre chose« , qu’on sélectionne. Là, on indique à Ubiquity qu’on veut que la partition racine soit liée à la partition ext4 qu’on a préalablement créée :

Mon image

Il suffit de presser « continuer » pour aboutir à cet avertissement : on l’ignore tout simplement en continuant malgré tout.

Mon image

Et on a eu bien raison, car l’installation va cette fois à son terme, sans encombre.

Mon image

Le souci, c’est qu’on n’a aucun grub pour démarrer, même si les fichiers nécessaires sont visiblement bien présents pour l’installation.

Mon image

Il nous faut donc finit d’installer grub. Je choisis de le faire par le biais d’un chroot en « continuant à tester » avec le live d’Ubuntu.

3.3. Mise en place de Grub Legacy dans le mbr

Le principe est de monter les outils pour installer grub, et on peut le faire de deux manières. En redémarrant sur Super Grub 2 disk qui saura lancer notre installation sans grub, ou en chrootant depuis le live USB qu’on n’a pas quitté. Je choisis la seconde option en m’appuyant sur ceci. La procédure est fiable, et fonctionne plutôt sans surprise.

La première étape conduit à ceci :

Mon image

Il ne reste plus qu’à installer créer le fichier grub.cfg et à installer grub dans le mbr  ; deux commandes suffisent :

Mon image

La troisième commande vérifie que grub a bien été ajouté dans le mbr. Et au redémarrage, nous obtenons une Ubuntu 21.04 toute propre et installée en mode Legacy.

Mon image

Bilan : pas de partition fat32 active parasite, pas de fichier fstab à modifier, et pas d’entrées « uefi » dans le menu grub. On est dans du classique.

Créer une clé d’installation de Windows UEFI et Legacy depuis LinuxMint

Sous Windows, la création de clé USB d’installation est plutôt facile : on peut utiliser l’outil maison de M$ appelé « Média Creation Tools » (MCT) ou des logiciels de création tels que Rufus qui font le travail plutôt correctement.

Sous Linux, c’est moins évident. Des outils tels que Etcher, Ventoy, Woeusb, voire la commande dd existent, mais ils demandent pas mal de manipulations et on n’est pas certain du résultat. Par ailleurs, ces outils créent un format particulier sur la clé que seuls les spécialistes savent récupérer.

S’ajoute à ces difficultés le problème des fichiers de plus de 4 Go, dont on sait qu’ils ne sont pas utilisables sur les partitions fat32, format « attendu » pour l’UEFI. Or, /source/install.wim peut dépasser les 4 Go.

L’idée de cette démo est de fabriquer une clé qui soit l’exacte réplique d’une clé d’installation faite avec l’outils M$.

I. Observation d’une clé opérationnelle fabriquée sous Windows avec MCT

Le plus simple est d’en voir des captures d’écran

1.1. Le contenu de la clé

Mon image

On peut noter qu’on a bien les tous les éléments pour booter sur DVD, sur clé en Legacy et en UEFI.

1.2. Vue du partitionnement depuis gparted

Mon image

Le clé est bien au format mbr (ms-dos) et la partition en fat32 s’est vu attribuer les drapeaux boot et lba.

1.3. Vue depuis un rapport boot-info

 => Windows 7/8/2012 is installed in the MBR of /dev/sdb.

sdb1: __________________________________________________________________________
    File system:       vfat
    Boot sector type:  Windows 8/2012: FAT32
    Boot files:        /efi/boot/bootx64.efi /efi/microsoft/boot/cdboot.efi 
                       /efi/microsoft/boot/cdboot_noprompt.efi 
                       /efi/microsoft/boot/memtest.efi /bootmgr /boot/bcd

fdisk -l (filtered): ___________________________________________________________
Disk sdb: 7.3 GiB, 7811891200 bytes, 15257600 sectors
Disk identifier: 0x0238cbf8
      Boot Start      End  Sectors  Size Id Type
sdb1  *     2048 15257599 15255552  7.3G  c W95 FAT32 (LBA)

La clé s’appuie bien un mbr adapté à Windows, elle possède les fichiers de démarrage pour L’UEFI. Elle sait donc démarrer ne Legacy et en UEFI. La suite de la démo va s’efforcer de reproduire exactement le même schéma, tant pour le partitionnement que pour le contenu.

2. Création d’une clé d’installation avec une ISO de Windows contenant un fichier /sources/install.wim  inférieur à 4 Go

Le souci des images iso de Windows 10, c’est qu’elles contiennent quasi toutes les versions de l’OS, ce qui conduit à un alourdissement des fichiers qui pour certains, dépassent les 4 Go. Or, le format fat32 ne sait pas gérer ces fichiers. On peut donc récupérer sur ce site des images iso contenant un fichier /source/install.esd réduit à ce dont on a besoin. C’est mon choix pour cette partie de démo. Dans le point 3, nous verrons le second cas.

2.1. Partitionnement de la clé usb

Le plus simple est d’utiliser gparted qu’on peut installer facilement sur LinuxMint, depuis la logithèque. On l’exécute, et on insère une clé USB vierge dont on voit la constitution ici:

Mon image

Comme l’image l’indique, on va donc créer une nouvelle table de partitions de type ms-dos (qui signifie « mbr ») car on veut qu’elle boote aussi bien en Legacy qu’en UEFI.

Rem. Pour une clé purement UEFI, on choisirait gpt, et toutes les manipulations sur le mbr qui vont suivre au point 2.3  seraient inutiles, car le mbr n’est pas utilisé dans ce mode. 

On crée une partition fat32 sur l’ensemble de la clé, et par clic droit, on lui associe les drapeaux boot et lba, comme pour la clé faite sous Windows.

Mon image

On peut dès lors ajouter le contenu complet de l’ISO de Windows 10 qu’on ouvre avec le gestionnaire d’archives, et qu’on décompresse en direction de la clé USB.

Remarque 1 : certains gestionnaires d’archive par défaut ne fonctionnent pas et peinent à lire ou à extraire le contenu de l’ISO W10. Le gestionnaire d’archives de Mate, « Engrampa », fonctionne parfaitement.

Remarque 2 : On peut aussi le faire depuis un terminal. Si l’iso s’appelle Windows10.iso et qu’elle est dans le dossier /home/ikewdu/Bureau :

sudo mkdir /media/iso
sudo mount -o loop /home/ikewdu/Bureau/windows10.iso /media/iso

Et on n’a plus qu’à copier le contenu du dossier /media/iso vers la clé USB

2.2. Résultats de l’opération de formatage et d’extraction de l’ISO Windows

La clé semble identique à celle créé sous Windows (le contenu de la clé est plus léger chez moi, car j’ai extrait le contenu de l’ISO de Dart, dont j’avais besoin pour un dépannage) :

Mon image

On vérifie avec un rapport boot-info :

=> libparted MBR boot code is installed in the MBR of /dev/sdb.

sdb1: __________________________________________________________________________

File system:       vfat
    Boot sector type:  Windows 8/2012: FAT32
    Boot files:        /efi/boot/bootx64.efi /efi/microsoft/boot/cdboot.efi 
                       /efi/microsoft/boot/cdboot_noprompt.efi 
                       /efi/microsoft/boot/memtest.efi /bootmgr /boot/bcd
fdisk -l (filtered): ___________________________________________________________ Disk sdb: 7.3 GiB, 7811891200 bytes, 15257600 sectors Disk identifier: 0x41b88db7 Boot Start End Sectors Size Id Type sdb1 * 2048 15255551 15253504 7.3G c W95 FAT32 (LBA)

Il n’y a qu’une différence, mais elle est de taille : la clé contient « libparted » dans le mbr et non les éléments nécessaires à Windows.

Bilan : la clé sera fonctionnelle en UEFI car le PC va trouver /efi/boot/bootx64.efi, mais pas en Legacy, car « Libparted » ne sera pas capable de lancer /bootmgr.

2. 3. Adaptation du mbr à Windows

On a besoin pour rectifier le mbr d’ajouter un outil à notre Linux Mint : il s’agit de ms-sys. Il permet de réécrire le mbr de toutes les manières possibles : on le trouve ici.

On choisit la dernière version, et on extrait le dossier contenu dans le  fichier compressé qu’on place par exemple sur le bureau :

Mon image

On installe le logiciel en suivant les recommandations du concepteur du logiciel :

ikewdu@ikewdu-fixe ~ $ cd Bureau
ikewdu@ikewdu-fixe ~/Bureau $ cd ms-sys-2.7.0
ikewdu@ikewdu-fixe ~/Bureau/ms-sys-2.7.0 $ make
mkdir -p build/dep
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT build/dep/partition_info.d src/partition_info.c > build/dep/partition_info.d
mkdir -p build/obj
mkdir -p build/bin
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o build/obj/partition_info.o (...)

Je fais l’impasse sur la liste des processus d’installation, pour ne proposer que la seconde commande :

ikewdu@ikewdu-fixe ~/Bureau/ms-sys-2.7.0 $ su
Mot de passe : 
ikewdu-fixe ms-sys-2.7.0 # make install
install -d /usr/local/bin
install -m 755 build/bin/ms-sys /usr/local/bin/ms-sys (...)

Idem. L’installation est faite, il ne reste plus qu’à réécrire le mbr.  En tapant ms-sys, on obtient toutes les options disponibles :

ikewdu@ikewdu-fixe ~ $ ms-sys
Utilisation :
 ms-sys [paramètres] [périphérique]
Paramètres :
 -1, --fat12 Écrit un secteur de démarrage pour FAT12 de type disquette
 -2, --fat32nt5 Write a FAT32 partition NT5.0 boot record to device (etc.)

Deux d’entre elles m’intéressent :

-8, --fat32nt6 Write a FAT32 partition NT6.0 boot record to device-7, 
-7  --mbr7 Écrit un Master Boot Record de type Windows 7

On va donc les appliquer à la clé USB :

ikewdu@ikewdu-fixe ~ $ sudo ms-sys -8 /dev/sdb1
[sudo] Mot de passe de ikewdu
Secteur de démarrage FAT32 NT6.0 écrit avec succès sur /dev/sdb1
ikewdu@ikewdu-fixe ~ $ sudo ms-sys -7 /dev/sdb
Master Boot Record de type Windows 7 écrit avec succès sur /dev/sdb
ikewdu@ikewdu-fixe ~ $

On vérifie avec boot-info que l’opération s’est bien passée :

 => Windows 7/8/2012 is installed in the MBR of /dev/sdb.

Il ne reste plus qu’à tester la clé. Et effectivement, le menu de démarrage d’un autre PC UEFI / Legacy me propose les deux formats de boot pour la clé :

Mon image

3. Création d’une clé avec un fichier wim de plus de 4 Go

On va maintenant imaginer qu’on est confronté à une image ISO de Windows qui contient un fichier install.wim supérieur à 4 Go. Comme c’est le cas ici.

On rappelle que le fat32 ne tolère pas de dépasser cette limite de 4 Go. On aurait donc la solution de créer une clé usb avec une partition NTFS, mais on risque de ne pas booter en UEFI. Une solution existe pour régler ce souci.

3.1. Préparation de la clé USB

A nouveau, on utilise gparted. On recrée une table de partitions ms-dos (comme en 2.1), mais cette fois, on va créer deux partitions : une partition fat32 de 1 Go à laquelle on appliquera les drapeaux boot et lba, et une simple partition NTFS sur le reste de la clé. On aboutira à ceci :

Mon image

On en profite, puisqu’on a vu comment faire au point 2.3.,  pour réparer le mbr afin de le rendre compatible avec Windows. C’est la partition /dev/sdb1 qui est concernée :

ikewdu@ikewdu-fixe ~ $ sudo ms-sys -8 /dev/sdb1
[sudo] Mot de passe de ikewdu : 
Secteur de démarrage FAT32 NT6.0 écrit avec succès sur /dev/sdb1
ikewdu@ikewdu-fixe ~ $ sudo ms-sys -7 /dev/sdb
Master Boot Record de type Windows 7 écrit avec succès sur /dev/sdb
ikewdu@ikewdu-fixe ~ $

La clé est prête et bootable. Reste à installer les fichiers de Windows 10 issus de l’image ISO

3.2. Décompression et adaptation de la clé USB à Windows 10

Pour cette partie, je m’inspire et j’adapte ce que propose ce tutoriel.

La première chose à faire est d’ouvrir l’image ISO avec le gestionnaire d’archives, et de copier le contenu intégral sur la partition NTFS, autrement dit, dans mon cas, /dev/sdb2 :

Mon image

Lorsque c’est terminé, on copie les fichiers bootmgr et bootmgr.efi, puis les dossiers boot et efi de la partition NTFS (/dev/sdb2) vers la partition fat32 (/dev/sdb1).

Mon image

Enfin, on crée sur la partition fat32 (/dev/sdb1) un nouveau dossier appelé sources, on y copie le seul fichier boot.wim (c’est le fichier qui contient le programme d’installation de Windows) qui se trouve dans le dossier sources de la partition NTFS (/dev/sdb2). Le résultat est le suivant :

Mon image

Nb. J’ai même ajouté « setup.exe » dans mon élan, mais ce n’est pas préjudiciable.

La clé est prête : elle va booter, lancer le programme d’installation, soit en Legacy, soit en UEFI (test fait sur deux PC), et le problème des fichiers supérieurs 4 Go ne sera plus pénalisant.