Guide d’installation Ubuntu 24.04 LTS : Dual-Boot, Secure Boot et zéro perte de données

Règles de base pour zéro perte de données

« Zéro perte de données » n’est pas un ressenti. C’est une séquence d’états vérifiables :

• Vous savez quel disque vous touchez, par des identifiants stables, pas à l’intuition.
• Vous avez au moins une copie hors ligne des données qui vous importent.
• Vous disposez d’une voie de récupération de démarrage pour les deux systèmes d’exploitation.
• Vous changez une chose à la fois, puis vous validez.

Voici la posture souhaitée : prudent, méthodique, légèrement agacé. C’est l’énergie adéquate pour toute opération qui modifie des partitions.

Décidez de votre architecture cible avant de commencer

La plupart des machines modernes devraient être : firmware UEFI + table de partitions GPT + Secure Boot activé. Si votre système est en BIOS/MBR hérité, vous pouvez toujours faire du dual-boot, mais les modes de défaillance se multiplient. Le guide suppose UEFI/GPT parce que c’est ce que vous devriez utiliser en 2026 à moins de ressusciter une pièce de musée.

Deux choses à ne pas faire

• Ne faites pas « effacer et réinstaller » lorsque l’installateur vous le propose « utilement ». Il fait son travail. Votre travail est de refuser.
• Ne réduisez pas les partitions depuis Linux en premier si Windows est impliqué. Réduisez Windows depuis Windows. Laissez chaque OS gérer ses propres métadonnées de système de fichiers.

Petite blague #1 : Partitioner un disque sans sauvegarde vérifiée, c’est comme faire de la chirurgie parce que vous avez regardé un jour une série médicale—audacieux, bref, et étonnamment coûteux.

Faits intéressants et contexte historique (parce que ce bazar a une histoire)

1. UEFI a remplacé le BIOS comme modèle de firmware grand public dans les années 2010, apportant des entrées de démarrage standardisées et un vrai système de fichiers (FAT) pour les chargeurs d’amorçage dans la partition système EFI (ESP).
2. GPT est devenu la valeur par défaut parce que MBR limite l’espace utilisable et a des limites fragiles de table de partitions ; GPT stocke des en-têtes redondants et supporte de nombreuses partitions proprement.
3. Secure Boot est arrivé pour réduire les bootkits malveillants. Il vérifie les signatures dans la chaîne de démarrage, ce qui est excellent jusqu’au moment où vous avez besoin de pilotes tiers et que vous oubliez ce que « signer » signifie.
4. Ubuntu a adopté shim comme pont pratique : shim signé par Microsoft peut démarrer sur les systèmes Secure Boot puis valider GRUB et les noyaux avec les clés d’Ubuntu.
5. GRUB2 a remplacé l’ancien GRUB avec plus de fonctionnalités et plus de façons de vous embrouiller. Il est flexible, pas psychique.
6. Windows Fast Startup (fonction d’hibernation hybride) a été un danger récurrent pour le dual-boot car il laisse les systèmes de fichiers « pas tout à fait fermés », ce que Linux considère correctement comme non sûr.
7. BitLocker est devenu courant sur les appareils grand public, surtout sur les portables « Modern Standby », et il change la façon d’aborder le redimensionnement et les modifications de démarrage.
8. NVMe a changé la nomenclature : les disques apparaissent comme /dev/nvme0n1 avec des partitions comme /dev/nvme0n1p3, ce qui est facile à mal lire lors d’une installation tendue.
9. Les versions LTS d’Ubuntu sont conçues pour de longues durées opérationnelles ; 24.04 LTS est une version « qu’on garde des années », d’où l’importance d’une installation correcte plutôt que de la nouveauté.

Opérationnellement, le thème est simple : la chaîne de démarrage et la disposition du disque sont une infrastructure partagée. Traitez-les comme en production, pas comme un projet de loisir du week-end.

Vérifications avant vol : matériel, firmware et vérité du disque

Avant de démarrer un quelconque installateur, vous inventoriez. Pas parce que c’est amusant, mais parce que cela prévient les deux catastrophes classiques : (1) écrire sur le mauvais disque et (2) installer dans le mauvais mode de démarrage.

Tâche 1 : Confirmez que vous avez démarré l’installateur en mode UEFI

Démarrez la clé USB live Ubuntu (« Try Ubuntu »). Puis :

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo "UEFI mode" || echo "Legacy BIOS mode"
UEFI mode

Ce que cela signifie : « UEFI mode » est ce que vous voulez pour un dual-boot moderne. Si vous voyez « Legacy BIOS mode », arrêtez et redémarrez la clé USB en sélectionnant l’entrée UEFI dans le menu de démarrage du firmware.

Décision : Procédez uniquement en mode UEFI sauf si vous supportez intentionnellement le BIOS hérité.

Tâche 2 : Identifiez tous les disques et leurs tailles (pour ne pas détruire le mauvais)

cr0x@server:~$ lsblk -e7 -o NAME,PATH,SIZE,TYPE,MODEL,SERIAL
NAME        PATH             SIZE TYPE MODEL                 SERIAL
nvme0n1     /dev/nvme0n1   953.9G disk Samsung SSD 990 PRO   S6Z2...
nvme0n1p1   /dev/nvme0n1p1   100M part
nvme0n1p2   /dev/nvme0n1p2    16M part
nvme0n1p3   /dev/nvme0n1p3   450G part
nvme0n1p4   /dev/nvme0n1p4   900M part
nvme0n1p5   /dev/nvme0n1p5   503G part

Ce que cela signifie : Vous cherchez le disque interne (souvent NVMe) et les partitions existantes. Sur de nombreuses installations Windows, vous verrez un ESP (~100–300MB), un MSR (16MB), la partition Windows (grande), et une partition de récupération.

Décision : Notez le chemin du disque (exemple : /dev/nvme0n1). S’il y a plus d’un disque interne, décidez lequel hébergera Ubuntu.

Tâche 3 : Confirmez le type de table de partitions (GPT vs MBR)

cr0x@server:~$ sudo parted -l
Model: Samsung SSD 990 PRO (nvme)
Disk /dev/nvme0n1: 1024GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  106MB   105MB   fat32        EFI system partition          boot, esp
 2      106MB   123MB   16.8MB               Microsoft reserved partition  msftres
 3      123MB   483GB   483GB   ntfs         Basic data partition          msftdata
 4      483GB   484GB   944MB   ntfs         Basic data partition          hidden, diag
 5      484GB   1024GB  540GB

Ce que cela signifie : « Partition Table: gpt » confirme que vous êtes à l’ère moderne. Si vous voyez « msdos », vous êtes en MBR/legacy, et le plan change.

Décision : Pour le dual-boot avec Secure Boot, GPT est le chemin le plus fluide. Si MBR apparaît, envisagez une conversion (avancé) ou acceptez la complexité héritée.

Tâche 4 : Confirmez que la partition système EFI (ESP) existe et est en FAT32

cr0x@server:~$ sudo blkid /dev/nvme0n1p1
/dev/nvme0n1p1: UUID="3A1B-2C4D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="..."

Ce que cela signifie : TYPE=vfat et « EFI system partition » est votre ESP. Ubuntu la réutilisera ; vous ne devez pas la formater pendant l’installation.

Décision : Gardez l’ESP. Ne créez pas une seconde ESP sauf si vous avez une raison spécifique (séparation multi-disques ou firmware vendeur très étrange).

Tâche 5 : Vérifiez si Windows est en hibernation / risque Fast Startup (depuis Linux)

cr0x@server:~$ sudo ntfsfix -n /dev/nvme0n1p3
Mounting volume... FAILED
Attempting to correct errors... FAILED
FAILED
NTFS volume is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting).

Ce que cela signifie : L’option -n est un essai à blanc. Si elle indique unsafe/hibernated, ne montez pas la partition Windows en lecture-écriture depuis Linux, et ne la redimensionnez pas depuis des outils Linux.

Décision : Démarrez Windows, désactivez Fast Startup, et effectuez un arrêt complet.

Tâche 6 : Vérifiez l’état de Secure Boot depuis l’environnement live

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Ce que cela signifie : Secure Boot est activé. Bien. Nous allons le garder activé et travailler avec.

Décision : Poursuivez avec Secure Boot activé sauf si vous avez un cas de pilote spécifique qui l’exige désactivé (rare, mais ça arrive).

Sauvegardes qui comptent vraiment (et comment les prouver)

Les sauvegardes ne sont pas « j’ai copié quelques dossiers une fois ». Les sauvegardes sont « je peux restaurer sous pression ». Vous vous apprêtez à modifier les métadonnées les plus critiques de la machine. Donc vous avez besoin de :

• Sauvegarde de fichiers de vos données personnelles (Documents, projets, clés, photos, etc.).
• Clés de récupération pour Windows BitLocker si activé.
• Médias de récupération de démarrage (USB de récupération Windows, et votre clé USB installatrice Ubuntu).

Checklist côté Windows (faire cela dans Windows)

D’un point de vue opérationnel : la meilleure sauvegarde Windows est celle que vous avez déjà testée. Si vous ne l’avez pas fait, faites un rapide test de restauration d’au moins un fichier. Sauvegardez aussi votre clé de récupération BitLocker ailleurs que sur le même appareil.

Tâche 7 : Vérifiez que vous voyez le disque de sauvegarde externe et son système de fichiers (depuis live Ubuntu)

cr0x@server:~$ lsblk -e7 -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
NAME      SIZE TYPE FSTYPE MOUNTPOINT
nvme0n1 953.9G disk
nvme0n1p1 100M part vfat
nvme0n1p3 450G part ntfs
sda     931.5G disk exfat
sda1    931.5G part exfat  /media/ubuntu/BackupDrive

Ce que cela signifie : Votre disque externe est présent (sda1) et monté. Super. S’il n’est pas monté, montez-le via le gestionnaire de fichiers ou udisksctl mount.

Décision : Ne procédez pas tant que la destination de sauvegarde n’est pas accessible.

Tâche 8 : Créez une vérification d’intégrité rapide de vos fichiers les plus importants

cr0x@server:~$ cd /media/ubuntu/BackupDrive
cr0x@server:~$ sha256sum my-keys.tar my-photos.zip > SHA256SUMS.txt
cr0x@server:~$ cat SHA256SUMS.txt
b1f2...  my-keys.tar
9a8c...  my-photos.zip

Ce que cela signifie : Vous avez créé des sommes de contrôle que vous pouvez vérifier plus tard après une copie ou une restauration. C’est comme ça que vous décelez les scénarios « copie réussie » mais « fichier corrompu ».

Décision : Conservez le fichier de sommes de contrôle avec la sauvegarde.

Tâche 9 : Prenez un instantané de la table de partitions actuelle (peu coûteux, preuve utile)

cr0x@server:~$ sudo sgdisk --backup=/media/ubuntu/BackupDrive/nvme0n1-gpt.bin /dev/nvme0n1
cr0x@server:~$ ls -lh /media/ubuntu/BackupDrive/nvme0n1-gpt.bin
-rw-r--r-- 1 root root 17K Feb  5 12:18 /media/ubuntu/BackupDrive/nvme0n1-gpt.bin

Ce que cela signifie : Vous avez maintenant une sauvegarde binaire de la table GPT. Si quelqu’un (y compris vous) crée un bazar, vous avez une chance de restaurer la structure.

Décision : Stockez cela hors machine. C’est petit et inestimable.

Stratégie de partitionnement pour dual-boot UEFI/GPT

Voici la règle centrale : Windows garde ses partitions ; Ubuntu obtient de nouvelles partitions créées à partir de l’espace libre. Votre travail est de créer cet espace libre en toute sécurité, puis de l’assigner proprement.

Disposition recommandée (pratique, pas théorique)

• ESP (existant) : 100–512MB FAT32, monté sur /boot/efi. Ne pas formater.
• Root Ubuntu : 40–100GB ext4 monté sur /. Plus grand si vous installez des jeux ou de grosses toolchains.
• Swap : optionnel en tant que partition ; Ubuntu peut utiliser un swapfile. Si vous hibernez Linux, prévoyez le swap en conséquence (généralement ≥ RAM).
• /home : partition séparée optionnelle. Utile pour des réinstallations propres, mais pas magique.

Pour la plupart des ordinateurs portables : une partition root + swapfile suffit. Pour les stations de travail où vous réinstallez souvent : un /home séparé est sensé.

À propos du chiffrement : choisissez votre rayon d’impact

Ubuntu propose le chiffrement complet du disque (LUKS). C’est une bonne valeur par défaut si votre modèle de menace inclut « ordinateur perdu » ou « personne curieuse avec un tournevis ». Cela change aussi vos procédures de récupération et peut compliquer certaines réparations dual-boot si vous ne comprenez pas ce qu’il y a à l’intérieur du conteneur chiffré.

Si vous voulez « zéro surprise », choisissez :

• Conserver Windows tel quel (BitLocker reste activé si c’était déjà le cas).
• Chiffrer Ubuntu si vous pouvez tolérer taper une phrase de passe au démarrage et si vous êtes à l’aise avec les étapes de récupération.

Tâche 10 : Mesurez l’espace libre réel et l’utilisation actuelle

cr0x@server:~$ df -hT
Filesystem     Type   Size  Used Avail Use% Mounted on
tmpfs          tmpfs  3.1G  2.1M  3.1G   1% /run
/dev/sr0       iso9660 3.7G 3.7G     0 100% /cdrom
/dev/loop0     squashfs 2.4G 2.4G     0 100% /rofs

Ce que cela signifie : Dans l’environnement live, df n’affiche pas l’utilisation de votre disque interne à moins de le monter. C’est un rappel : ne devinez pas. Si vous avez besoin de l’utilisation Windows, vérifiez dans la gestion des disques Windows.

Décision : Réduisez Windows depuis Windows. Utilisez les outils Linux principalement pour l’identification et la validation.

Combien d’espace allouer ?

Mon seuil d’opinion : 60GB pour le root d’Ubuntu si vous faites du développement, des conteneurs, ou gardez quelques noyaux. Si vous êtes léger, 40GB suffit. Si vous faites du travail sérieux en conteneurs, 100–200GB n’est pas excessif ; les images de conteneurs se multiplient.

Petite blague #2 : L’espace disque est la seule ressource qui diminue dès que vous arrêtez de la surveiller.

Secure Boot : le garder activé, comprendre ce qui change

Secure Boot n’est pas votre ennemi. Il est juste strict. La chaîne de démarrage par défaut d’Ubuntu sur Secure Boot ressemble généralement à :

• Le firmware vérifie shim (signé).
• shim vérifie GRUB (signé).
• GRUB charge le noyau (signé).
• Le noyau applique les règles de signature des modules selon la politique et la configuration.

Quand vous serez invité pour MOK (Machine Owner Key)

Si vous installez des pilotes tiers (fréquent avec NVIDIA), Ubuntu peut demander d’enrôler une clé via MOK. C’est normal. Vous définirez un mot de passe unique pendant l’installation, puis au prochain redémarrage vous aurez un écran bleuâtre du gestionnaire MOK pour enrôler la clé.

Tâche 11 : Vérifiez la disponibilité des outils de vérification Secure Boot et l’état

cr0x@server:~$ sbverify --version
sbverify version 0.9.4
cr0x@server:~$ mokutil --list-enrolled | head
[key 1]
SHA1 Fingerprint: ...

Ce que cela signifie : Vous pouvez inspecter les clés enrôlées et vérifier les binaires EFI si nécessaire. En général vous n’en aurez pas besoin, mais quand quelque chose tombe en panne à 2h du matin, vous serez content que ces outils existent.

Décision : Si Secure Boot est activé et qu’Ubuntu démarre, ne « corrigez » rien. La stabilité vaut mieux que la curiosité.

Une idée paraphrasée utile à garder

Idée paraphrasée (attribuée à Gene Kranz) : « Soyez dur et compétent. » En termes d’exploitation : restez calme, vérifiez, et n’improvisez pas sur les chemins critiques.

Installation : le chemin sûr dans l’installateur Ubuntu

L’installateur d’Ubuntu 24.04 est généralement convivial, ce qui est exactement pourquoi il est dangereux : il fera rapidement de grandes choses irréversibles. Votre travail est de choisir les options qui gardent le contrôle entre vos mains.

Étape 1 : Réduire Windows (faites ceci avant d’installer Ubuntu)

Dans Windows :

• Désactivez Fast Startup.
• Si BitLocker est activé, assurez-vous d’avoir la clé de récupération sauvegardée hors de la machine. Envisagez de suspendre BitLocker avant le redimensionnement, selon la politique de votre environnement.
• Utilisez la gestion des disques pour réduire la partition Windows et laisser de l’espace non alloué.
• Redémarrez Windows une fois, puis effectuez un arrêt complet (pas « redémarrer »).

Oui, c’est agaçant. C’est néanmoins la bonne méthode.

Étape 2 : Démarrer la clé USB live Ubuntu en mode UEFI

Vous avez déjà validé le mode UEFI plus tôt. Refaites-le si vous avez un doute. Les humains se trompent ; les menus firmware sont pires.

Tâche 12 : Confirmez qu’il existe de l’espace non alloué (depuis live Ubuntu)

cr0x@server:~$ sudo parted /dev/nvme0n1 unit GiB print free
Model: Samsung SSD 990 PRO (nvme)
Disk /dev/nvme0n1: 953GiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number  Start  End    Size   File system  Name  Flags
        0.00GiB 0.00GiB 0.00GiB Free Space
 1      0.00GiB 0.10GiB 0.10GiB fat32            boot, esp
 2      0.10GiB 0.12GiB 0.02GiB                  msftres
 3      0.12GiB 450.00GiB 449.88GiB ntfs
 4      450.00GiB 451.00GiB 1.00GiB  ntfs        hidden, diag
        451.00GiB 953.00GiB 502.00GiB Free Space

Ce que cela signifie : Le bloc « Free Space » à la fin est l’endroit où Ubuntu ira. Si vous ne voyez pas d’espace libre, vous n’avez pas réduit Windows ou vous regardez le mauvais disque.

Décision : Si l’espace libre manque, arrêtez. N’essayez pas de « bricoler » avec des redimensionnements aléatoires depuis Linux.

Étape 3 : Choisissez « partitionnement manuel » (ou équivalent) dans l’installateur

Si l’installateur propose « Installer aux côtés de Windows », cela peut fonctionner. Il peut aussi se tromper, surtout sur des systèmes avec plusieurs disques, partitions de récupération constructeur, modes RAID, ou BitLocker. Si vous voulez « zéro perte de données », prenez le contrôle manuel.

Partitionnement manuel : ce qu’il faut créer

• Ne formatez pas l’ESP. Définissez-la pour être montée sur /boot/efi.
• Créez une partition ext4 dans l’espace libre pour /.
• Optionnel : créez une partition ext4 pour /home.
• Swap : utilisez un swapfile (par défaut) sauf si vous hibernez.

Tâche 13 : Vérifiez deux fois que vous ne formatez pas la mauvaise partition (contrôle de bon sens)

cr0x@server:~$ sudo lsblk -f /dev/nvme0n1
NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat   FAT32       3A1B-2C4D
├─nvme0n1p2
├─nvme0n1p3 ntfs               1C2D3E4F5A6B7C8D
├─nvme0n1p4 ntfs               9E8D7C6B5A4F3E2D
└─nvme0n1p5

Ce que cela signifie : Vous pouvez voir quelles partitions ont déjà des systèmes de fichiers. L’espace libre n’apparaîtra pas encore comme une partition. Si vous voyez une partition ext4 inattendue, arrêtez et enquêtez.

Décision : Formatez uniquement les nouvelles partitions que vous créez pour Ubuntu. Ne formatez jamais une partition NTFS qui vous importe. Ne formatez jamais l’ESP.

Cible d’installation du chargeur d’amorçage

Sur les systèmes UEFI, le « disque cible du chargeur » doit être le disque qui contient l’ESP (généralement le même disque que Windows). Si vous placez Ubuntu sur un second disque, soyez délibéré : certains firmware ne démarrent de manière fiable que depuis le premier disque.

Installer les mises à jour et pilotes tiers (prudemment)

Si vous avez une carte graphique NVIDIA, l’installateur peut proposer des pilotes propriétaires. Les accepter est acceptable, mais attendez-vous à un enrôlement MOK si Secure Boot est activé.

Vérification post-installation : chemins de démarrage, pilotes, mises à jour

Vous n’êtes pas « terminé » quand le bureau apparaît. Vous êtes terminé quand :

• Ubuntu démarre de manière fiable avec Secure Boot activé.
• Windows démarre toujours.
• Vous pouvez expliquer (brièvement) comment le système démarre.

Tâche 14 : Confirmez l’état de Secure Boot dans Ubuntu installé

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Ce que cela signifie : Vous êtes resté en Secure Boot de bout en bout.

Décision : Si Secure Boot est désactivé de manière inattendue, vérifiez les paramètres du firmware. Ne supposez pas qu’Ubuntu l’a « désactivé ». Les basculements firmware peuvent se produire après des mises à jour ou des événements CMOS.

Tâche 15 : Confirmez les entrées de démarrage EFI (Ubuntu et Windows)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0000
Boot0000* Windows Boot Manager  HD(1,GPT,...)File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0003* ubuntu                HD(1,GPT,...)File(\EFI\ubuntu\shimx64.efi)

Ce que cela signifie : Le firmware connaît les deux chargeurs. Ubuntu utilise shim (shimx64.efi) ce qui est attendu sous Secure Boot.

Décision : Si « Windows Boot Manager » manque, ne paniquez pas. Il peut être recréé, mais vérifiez d’abord le contenu de l’ESP.

Tâche 16 : Inspectez le contenu de l’ESP (confirmez que rien n’a été écrasé)

cr0x@server:~$ sudo mkdir -p /mnt/esp
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ sudo ls -R /mnt/esp/EFI | head -n 50
/mnt/esp/EFI:
Boot
Microsoft
ubuntu

/mnt/esp/EFI/Microsoft:
Boot

/mnt/esp/EFI/ubuntu:
grubx64.efi
mmx64.efi
shimx64.efi

Ce que cela signifie : L’ESP contient les répertoires des deux fournisseurs. C’est l’apparence d’une installation « aux côtés de Windows ».

Décision : Si le répertoire Microsoft manque, vous avez probablement formaté l’ESP ou écrit sur le mauvais disque. La récupération est possible mais vous êtes maintenant en mode réponse à incident.

Tâche 17 : Confirmez que GRUB voit Windows (et corrigez si nécessaire)

cr0x@server:~$ sudo grep -R "menuentry 'Windows" -n /boot/grub/grub.cfg | head
1234:menuentry 'Windows Boot Manager (on /dev/nvme0n1p1)' --class windows --class os $menuentry_id_option 'osprober-efi-1C2D3E4F5A6B7C8D' {

Ce que cela signifie : Windows est présent dans la config de GRUB. S’il n’y est pas, os-prober peut être désactivé ou Windows peut être caché à cause d’un état d’hibernation.

Décision : Si Windows n’est pas détecté, assurez-vous d’abord que Windows est bien arrêté et non en hibernation ; puis exécutez update-grub.

cr0x@server:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done

Ce que cela signifie : GRUB peut chaîner vers Windows. C’est l’arrangement dual-boot le plus simple.

Décision : Si Windows n’apparaît toujours pas, utilisez le menu firmware pour démarrer Windows directement et corrigez l’hibernation/Fast Startup.

Tâche 18 : Vérifiez l’état du noyau et des pilotes (surtout sur les portables)

cr0x@server:~$ uname -r
6.8.0-41-generic
cr0x@server:~$ ubuntu-drivers devices | sed -n '1,120p'
== /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0 ==
modalias : pci:v000010DEd000025A2sv00001028sd00000B42bc03sc00i00
vendor   : NVIDIA Corporation
model    : AD104M [GeForce RTX ...]
driver   : nvidia-driver-550 - distro non-free recommended
driver   : xserver-xorg-video-nouveau - distro free builtin

Ce que cela signifie : Vous pouvez voir les pilotes recommandés. Sur les systèmes Secure Boot, l’installation de pilotes propriétaires peut déclencher l’enrôlement MOK.

Décision : Si vous avez besoin de NVIDIA pour votre charge de travail, installez le pilote recommandé et préparez-vous à enrôler MOK au redémarrage. Si vous avez juste besoin d’un bureau fonctionnel et stable, vous pouvez différer.

Tâche 19 : Vérifiez le mode RAID/RST qui peut rendre les disques Linux invisibles

cr0x@server:~$ sudo lspci -nn | grep -i -E "sata|raid|nvme"
00:17.0 SATA controller [0106]: Intel Corporation Device [8086:7ae2]
04:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a80a]

Ce que cela signifie : Cela ne vous dit pas définitivement le mode firmware, mais cela vous aide à repérer les systèmes où Intel RST/RAID peut être impliqué. Si Linux ne voit pas votre disque Windows, le mode de stockage firmware est un suspect principal.

Décision : Si le disque interne disparaît sous Linux, vérifiez le firmware pour les réglages RST/RAID vs AHCI et procédez avec précaution (surtout si Windows est installé).

Tâche 20 : Validez les montages de systèmes de fichiers et fstab (éviter des surprises au démarrage)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS / /boot/efi
/dev/nvme0n1p6 / ext4 rw,relatime,errors=remount-ro
/dev/nvme0n1p1 /boot/efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
cr0x@server:~$ sudo cat /etc/fstab
UUID=... / ext4 errors=remount-ro 0 1
UUID=3A1B-2C4D /boot/efi vfat umask=0077 0 1

Ce que cela signifie : Ubuntu monte l’ESP par UUID. C’est bien. Les noms de périphériques peuvent changer ; les UUID sont stables.

Décision : Si /boot/efi n’est pas monté, les mises à jour de GRUB peuvent s’écrire nulle part et les mises à jour de noyau futures peuvent produire une surprise amusante. Corrigez cela maintenant.

Trois mini-histoires du monde de l’entreprise (pour que vous ne les répétiez pas)

Mini-histoire 1 : Un incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé des portables Ubuntu en dual-boot pour développeurs : Windows pour les apps corporate, Ubuntu pour les outils de build. L’équipe d’imagerie a supposé que « le disque est toujours /dev/nvme0n1 » parce que c’était vrai sur les douze premiers modèles. Puis les achats ont fait ce que font les achats et ont livré une série avec deux disques internes : un petit NVMe pour l’OS et un plus grand SSD SATA pour les données.

Le script d’automatisation a partitionné le premier disque trouvé, installé Ubuntu, et mis à jour les entrées EFI. Sur les modèles à double disque, « premier disque » n’était pas cohérent. Certaines machines se sont retrouvées avec GRUB sur un disque, l’ESP sur un autre, et l’entrée du gestionnaire d’amorçage Windows pointant dans le vide.

Les symptômes étaient chaotiques : une partie des portables démarraient directement sur le firmware, certains démarraient Ubuntu mais pas Windows, d’autres Windows seulement si vous appuyiez frénétiquement sur F12 au bon moment. Ça ressemblait à du « mystère Secure Boot » parce que c’est ce que disent les gens quand ils ne savent pas où vit le chargeur.

La correction fut ennuyeuse et légèrement humiliante : arrêter de se fier aux énumérations, identifier les disques par modèle/série, et cibler explicitement le disque contenant l’ESP. Ils ont aussi ajouté une étape pré-vol : dumper lsblk et efibootmgr dans les logs avant toute modification. Le déploiement suivant a eu un taux d’échec proche de zéro, ce qui est le seul nombre acceptable pour « on a touché au boot ».

Leçon : Les noms de disques ne sont pas des identités. Traitez-les comme des noms d’interface transitoires et utilisez des identifiants stables.

Mini-histoire 2 : Une optimisation qui s’est retournée contre eux

Une autre organisation a tenté « d’optimiser » le temps d’installation en désactivant Secure Boot dans le firmware pendant le provisioning. L’idée était d’éviter les invites MOK, d’accélérer l’installation des pilotes, puis de réactiver Secure Boot à la fin. En laboratoire, ça fonctionnait. En production, ça a produit une petite catastrophe silencieuse.

Sur certaines versions de firmware, basculer Secure Boot réinitialisait des parties de l’ordre de démarrage ou déclenchait un comportement de démarrage « fallback ». Certains appareils ont réactivé Secure Boot mais ont refusé de démarrer des composants précédemment installés non signés ou signés différemment sans un enrôlement propre. D’autres ont réordonné les entrées de démarrage de sorte que Windows dominait à nouveau, et le support recevait des tickets comme « Ubuntu a disparu ».

Pire, l’automatisation supposait que réactiver Secure Boot était un toggle réversible. Ce n’était pas le cas. C’était une transition d’état avec effets secondaires. Le système installé n’était pas cassé ; les hypothèses l’étaient.

Ils ont annulé l’« optimisation », provisionné avec Secure Boot activé dès le premier démarrage, et accepté les minutes supplémentaires. C’est incroyable comme tout va plus vite quand on arrête de se créer des problèmes.

Leçon : N’optimisez pas le chemin critique en changeant les modes de sécurité en cours de route. Si vous voulez Secure Boot activé, laissez-le activé depuis le départ.

Mini-histoire 3 : Une pratique ennuyeuse mais correcte qui a sauvé la mise

Une institution financière avait une politique : avant tout déploiement OS, les techniciens doivent capturer (1) une sauvegarde GPT, (2) une photo du menu de démarrage du firmware montrant le mode de démarrage, et (3) une copie des listes de répertoires EFI de l’ESP après installation. Tout le monde se plaignait que c’était bureaucratique. Tout le monde avait tort.

Un jour, un portable est revenu d’une réparation vendeur avec la carte mère remplacée. Le disque était intact, mais les entrées NVRAM de démarrage avaient disparu—pas d’« ubuntu », pas de « Windows Boot Manager ». La machine démarrée sur le firmware et regardait l’utilisateur comme si elle n’avait jamais entendu parler d’OS.

Le technicien a sorti la liste ESP stockée dans le ticket, a confirmé que \EFI\Microsoft\Boot\bootmgfw.efi et \EFI\ubuntu\shimx64.efi devaient exister, a ensuite monté l’ESP depuis une clé live et vérifié que les répertoires étaient toujours là. Bonne nouvelle. Les données n’étaient pas parties ; ce sont les pointeurs qui avaient disparu.

Ils ont recréé les entrées de boot avec efibootmgr et utilisé l’option « fichier UEFI » du firmware en secours. Pas de repartitionnement. Pas de réinstallation. Pas de perte de données. Le ticket s’est fermé rapidement, ce qui est le plus beau compliment en exploitation.

Leçon : Capturez l’état avant et après les changements. Quand le firmware oublie, pas besoin d’héroïsme—il faut des preuves.

Playbook de diagnostic rapide

Quand le dual-boot casse, les gens s’agitent : réinstaller GRUB, basculer les réglages BIOS, maudire la lune. Ne faites pas ça. Faites ceci dans l’ordre pour identifier rapidement le goulot d’étranglement.

1) Est-ce un problème de mode de démarrage (UEFI vs legacy) ?

• Depuis une clé USB live : vérifiez /sys/firmware/efi.
• Si l’OS installé a été installé en UEFI mais que vous démarrez l’USB de récupération en mode legacy, vous courrez après des fantômes.

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI

Décision : Faites correspondre le mode de démarrage de vos outils à celui du système installé.

2) Le firmware pointe-t-il vers le bon binaire EFI ?

• Utilisez efibootmgr -v dans Ubuntu.
• Si Ubuntu ne démarre pas, utilisez le menu de démarrage du firmware pour choisir Windows Boot Manager ou un chemin de fichier UEFI.

cr0x@server:~$ sudo efibootmgr -v | sed -n '1,20p'
BootCurrent: 0003
BootOrder: 0003,0000
Boot0000* Windows Boot Manager  HD(1,GPT,...)File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0003* ubuntu                HD(1,GPT,...)File(\EFI\ubuntu\shimx64.efi)

Décision : Si des entrées manquent, recréez-les. Si les entrées existent mais ne fonctionnent pas, inspectez l’ESP et les signatures.

3) L’ESP est-elle intacte et montée ?

Si l’ESP a été formatée, vous verrez des répertoires manquants. Si elle n’est simplement pas montée, les mises à jour n’atterrissent pas là où elles doivent être.

cr0x@server:~$ sudo mount | grep -E "/boot/efi|/mnt/esp" || echo "ESP not mounted"
ESP not mounted

Décision : Montez-la, validez les répertoires, puis réparez les entrées de démarrage.

4) Windows est-il « dirty » (hiberné) et bloque la détection ?

Fast Startup de Windows peut faire refuser Linux de monter NTFS, et peut aussi empêcher os-prober. Si Windows est dirty, réparez cela d’abord.

5) Secure Boot bloque-t-il un pilote/module ?

Lorsque la vidéo ou le Wi‑Fi échoue après l’installation, Secure Boot peut appliquer la vérification de signature des modules. Ce n’est pas une raison pour désactiver Secure Boot ; c’est une raison d’installer des pilotes signés ou d’enrôler correctement le MOK.

cr0x@server:~$ dmesg | grep -i -E "secure boot|lockdown|module verification" | tail -n 20
[    0.000000] secureboot: Secure boot enabled
[   12.345678] Lockdown: Loading of unsigned module is restricted; see man kernel_lockdown.7

Décision : Si vous avez besoin de ce module, installez-le via les paquets Ubuntu qui supportent le flux Secure Boot, et enrôlez le MOK quand il est demandé.

6) Ensuite seulement : réparation de GRUB

GRUB est souvent accusé, et parfois coupable. Mais réparez d’abord les problèmes de mode de démarrage/ESP/NVRAM sous-jacents. Sinon vous réinstallez GRUB dans le même contexte cassé.

Erreurs fréquentes : symptômes → cause racine → correction

1) Symptom : la partition Windows se monte en lecture seule ou ne monte pas

Cause racine : Windows était en hibernation ou Fast Startup a laissé le NTFS « dirty ».

Correction : Démarrez Windows, désactivez Fast Startup, effectuez un arrêt complet. Puis réessayez la détection.

cr0x@server:~$ sudo ntfsfix -n /dev/nvme0n1p3
NTFS volume is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting).

2) Symptom : l’installateur n’affiche pas l’option « Installer aux côtés de Windows »

Cause racine : Windows est sous BitLocker et/ou Fast Startup est activé, ou la disposition du disque est inhabituelle (disques dynamiques, mode RAID).

Correction : Utilisez le partitionnement manuel ; assurez-vous qu’il y a de l’espace libre ; confirmez le mode UEFI ; évitez les configurations de disques dynamiques.

3) Symptom : après l’installation, la machine démarre directement sur Windows

Cause racine : L’ordre de démarrage du firmware préfère toujours Windows Boot Manager, ou l’entrée Ubuntu n’a pas été créée.

Correction : Réglez l’ordre de démarrage dans le firmware, ou depuis Ubuntu :

cr0x@server:~$ sudo efibootmgr
BootCurrent: 0000
BootOrder: 0000,0003
Boot0000* Windows Boot Manager
Boot0003* ubuntu
cr0x@server:~$ sudo efibootmgr -o 0003,0000

Décision : Si le firmware revient sans cesse en arrière, vérifiez les politiques du vendeur « Windows-first » ou les mises à jour firmware qui réinitialisent la NVRAM.

4) Symptom : après l’installation, la machine démarre sur le firmware avec « No bootable device »

Cause racine : Entrées de démarrage manquantes (NVRAM réinitialisée), ESP introuvable, ou ESP corrompue.

Correction : Depuis une clé live, montez l’ESP et vérifiez la présence des binaires EFI. Recréez les entrées avec efibootmgr. Si des binaires manquent, il peut être nécessaire de réinstaller GRUB/shim sur l’ESP.

5) Symptom : Ubuntu démarre, mais pas de Wi‑Fi

Cause racine : Paquet firmware manquant, ou Secure Boot bloque un module hors arbre, ou le périphérique n’est pas pris en charge.

Correction : Identifiez le périphérique, installez le firmware correct, vérifiez dmesg.

cr0x@server:~$ lspci -nn | grep -i network
02:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6E(802.11ax) [8086:2725]
cr0x@server:~$ dmesg | grep -i firmware | tail -n 20
[    8.123456] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-*.ucode failed with error -2

Décision : Installez le paquet firmware manquant via apt (nécessite le réseau ; utilisez Ethernet ou tethering USB si besoin).

6) Symptom : écran noir après l’installation du pilote NVIDIA avec Secure Boot activé

Cause racine : Enrôlement MOK non complété, ou le module a échoué à la vérification de signature.

Correction : Redémarrez, enrôlez le MOK quand il est demandé. Si vous avez raté l’étape, réinstallez le paquet du pilote et répétez le flux MOK, ou démarrez temporairement avec le pilote libre pour récupérer.

7) Symptom : le menu GRUB n’affiche pas Windows

Cause racine : os-prober ne tourne pas, hibernation Windows, ou fichiers de démarrage Windows non présents sur l’ESP attendu.

Correction : Assurez-vous que Windows est complètement arrêté, puis exécutez update-grub. Vérifiez que l’ESP contient le répertoire du chargeur Microsoft.

8) Symptom : invite de récupération BitLocker après l’installation d’Ubuntu

Cause racine : La configuration de démarrage a changé (attendu) et BitLocker demande une vérification via la clé de récupération.

Correction : Entrez la clé de récupération, puis dans Windows envisagez de « suspendre et reprendre BitLocker » pour qu’il se ré-allie à l’état de démarrage modifié. Ne désactivez pas BitLocker définitivement sauf si la politique l’autorise et que vous comprenez le risque.

Listes de contrôle / plan pas-à-pas

Plan A : Windows mono-disque + Ubuntu en dual-boot (standard, recommandé)

1. Dans Windows : Sauvegardez les fichiers critiques sur un disque externe. Sauvegardez la clé de récupération BitLocker hors de l’appareil.
2. Dans Windows : Désactivez Fast Startup. Arrêt complet.
3. Dans Windows : Réduisez la partition Windows en laissant de l’espace non alloué.
4. Démarrez la clé USB Ubuntu (UEFI) : Validez le mode UEFI (/sys/firmware/efi existe).
5. Depuis le live Ubuntu : Enregistrez la sortie de lsblk et parted -l (captures d’écran ou texte sauvegardé).
6. Depuis le live Ubuntu : Sauvegardez la GPT (sgdisk --backup) sur disque externe.
7. Installateur : Utilisez le partitionnement manuel. Sélectionnez l’ESP, montez-la sur /boot/efi, ne pas formater.
8. Installateur : Créez ext4 pour / dans l’espace libre. Optionnel /home.
9. Installateur : Gardez Secure Boot activé. Si demandé, définissez un mot de passe MOK (notez-le temporairement).
10. Premier redémarrage : Complétez l’enrôlement MOK si demandé.
11. Dans Ubuntu : Exécutez efibootmgr -v, confirmez les entrées pour Windows et ubuntu.
12. Dans Ubuntu : Exécutez update-grub et confirmez la détection de Windows.
13. Test de démarrage : Démarrez Windows depuis GRUB et depuis le menu firmware. Confirmez le comportement de BitLocker.

Plan B : Ubuntu sur un second disque, Windows sur le premier disque (fonctionne, mais soyez délibéré)

1. Confirmez quel disque contient l’ESP. Habituellement le disque Windows.
2. Décidez si vous placerez les fichiers EFI d’Ubuntu sur l’ESP existante ou si vous créerez une seconde ESP sur le disque Ubuntu. Préférez une ESP unique sauf raison contraire.
3. Installez Ubuntu en partitionnement manuel, en sélectionnant explicitement le bon disque/ESP.
4. Vérifiez l’ordre de démarrage firmware et assurez-vous que les deux entrées restent après redémarrages et mises à jour.

Plan C : Si quelque chose tourne mal, n’« essayez des choses » au hasard

1. Démarrez une clé live Ubuntu en mode UEFI.
2. Identifiez les disques (lsblk), trouvez l’ESP (blkid), montez-la, listez /EFI.
3. Vérifiez les entrées NVRAM (efibootmgr -v).
4. Ce n’est qu’ensuite que vous tentez la réparation : recréer les entrées ou réinstaller GRUB sur l’ESP.

Tâche 21 : Recréer une entrée Windows Boot Manager manquante (si le fichier existe)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "Windows Boot Manager" -l '\EFI\Microsoft\Boot\bootmgfw.efi'
BootCurrent: 0003
BootOrder: 0004,0003,0000
Boot0004* Windows Boot Manager

Ce que cela signifie : Vous avez créé une nouvelle entrée NVRAM pointant sur le binaire Microsoft EFI sur la partition 1 (l’ESP).

Décision : Si cela échoue, vérifiez le numéro de partition ESP et le chemin ; les barres obliques inverses comptent dans les chemins EFI.

Tâche 22 : Recréer une entrée Ubuntu manquante (chemin shim)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "ubuntu" -l '\EFI\ubuntu\shimx64.efi'
Boot0005* ubuntu

Ce que cela signifie : Vous avez recréé l’entrée Ubuntu Secure Boot.

Décision : Mettez-la en premier dans l’ordre de démarrage si vous le souhaitez.

Tâche 23 : Définir explicitement l’ordre de démarrage (parce que la « serviabilité » du firmware est un fléau)

cr0x@server:~$ sudo efibootmgr -o 0005,0004
BootOrder: 0005,0004

Ce que cela signifie : Le firmware essaiera Ubuntu en premier, puis Windows.

Décision : Si l’ordre ne tient pas, vérifiez les paramètres vendor du firmware qui verrouillent l’ordre de démarrage, ou les mises à jour BIOS qui réinitialisent la NVRAM.

FAQ

1) Dois-je désactiver Secure Boot pour Ubuntu 24.04 ?

Non, pas par défaut. Ubuntu prend bien en charge Secure Boot. Désactivez-le seulement si vous avez un blocage spécifique que vous comprenez (généralement un module noyau niche).

2) Ubuntu écrasera-t-il Windows ?

Seulement si vous lui dites de le faire. L’option dangereuse est « Effacer le disque et installer Ubuntu ». Utilisez le partitionnement manuel et ne formatez jamais les partitions Windows ni l’ESP.

3) Ai-je besoin d’une partition /home séparée ?

Pas obligatoire. C’est utile si vous réinstallez fréquemment Ubuntu et voulez isoler les données utilisateur. Si vous n’êtes pas discipliné avec les sauvegardes, une partition /home séparée ne vous sauvera pas de vous-même.

4) Une partition swap est-elle requise ?

Non. Ubuntu peut utiliser un swapfile. Si vous prévoyez d’hiberner Linux, vous devriez dimensionner le swap de manière appropriée et tester l’hibernation. Sinon, le swapfile est plus simple et généralement suffisant.

5) Pourquoi BitLocker demande-t-il une clé de récupération après l’installation d’Ubuntu ?

Parce que la configuration de démarrage a changé et BitLocker fait son travail : il a détecté un nouvel environnement de démarrage. Entrez la clé de récupération, puis laissez Windows se re-sceller (souvent en suspendant/reprenant BitLocker une fois). Ne perdez pas cette clé.

6) Mon installateur ne voit pas mon disque interne. Que faire ?

Cause fréquente sur certains portables : le mode stockage firmware est réglé sur Intel RST/RAID. Linux peut ne pas voir le disque comme attendu. Passer en AHCI peut aider mais doit être fait soigneusement pour ne pas casser le démarrage Windows. Si vous ne connaissez pas la procédure, arrêtez et planifiez le changement.

7) GRUB n’affiche pas Windows, mais Windows démarre depuis le menu firmware. Est-ce grave ?

Pas catastrophique. Cela veut dire que GRUB n’a pas détecté Windows ou n’est pas configuré pour l’afficher. Corrigez l’hibernation/Fast Startup de Windows, puis exécutez update-grub. Vous pouvez aussi vous contenter de la sélection firmware, mais c’est moins pratique.

8) Puis-je partager une partition de données entre Windows et Ubuntu ?

Oui, généralement via NTFS ou exFAT. NTFS convient pour une partition de données partagée si vous veillez à ce que Windows soit complètement arrêté (pas de Fast Startup/hibernation). Pour la fiabilité, évitez de stocker des données sensibles aux permissions Linux sur NTFS.

9) Dois-je choisir « installer Ubuntu aux côtés de Windows » ou le partitionnement manuel ?

Si vous voulez le taux de réussite le plus élevé face aux dispositions OEM bizarres, choisissez le partitionnement manuel. L’option « alongside » peut fonctionner, mais c’est un raccourci d’automatisation ; vous supportez le risque.

10) Si je casse le chargeur d’amorçage, mes données sont-elles perdues ?

Généralement non. Les problèmes de démarrage concernent souvent les entrées NVRAM ou le contenu de l’ESP. Vos fichiers sont typiquement intacts. Le danger est la repartition panique. Arrêtez-vous, montez l’ESP, inspectez, puis réparez les entrées de démarrage.

Conclusion : prochaines étapes une fois que vous démarrez proprement

Si vous pouvez démarrer Ubuntu et Windows de manière fiable avec Secure Boot activé, vous avez déjà fait la partie difficile : vous avez rendu la chaîne de démarrage ennuyeuse à nouveau. Gardez-la comme ça.

Prochaines étapes pratiques :

• Mettez à jour Ubuntu et redémarrez une fois pour confirmer que les mises à jour du noyau ne cassent pas le flux Secure Boot.
• Confirmez les sauvegardes : vérifiez une somme de contrôle depuis votre disque de sauvegarde et restaurez un fichier en test.
• Documentez votre layout : sauvegardez la sortie de lsblk, parted -l, et efibootmgr -v quelque part en sécurité.
• Décidez de votre OS par défaut : réglez l’ordre de démarrage firmware en conséquence, et gardez l’autre OS accessible via GRUB ou le menu firmware.
• Garder Fast Startup de Windows désactivé si vous accédez régulièrement aux partitions Windows depuis Linux.

C’est tout. Pas de mysticisme. Juste des changements disciplinés, des états vérifiés, et la satisfaction tranquille d’un système qui démarre de la même manière deux fois.