Fedora Workstation 43 : la méthode d’une seule clé USB qui fonctionne

février 10, 2026 • février 10, 2026 • Lecture : 32 min • Views: 0

Cet article vous a aidé ?

L’installation d’un système d’exploitation devrait être ennuyeuse. Pourtant, de nombreuses installations de Fedora tournent encore mal pour les mêmes raisons : une clé USB qui ment, un firmware qui « réécrit » l’ordre de démarrage « pour vous aider », et un espace de stockage qui semble correct jusqu’à ce que vous essayiez réellement de le monter.

Ce guide est la méthode à une seule clé USB que j’utilise quand je veux Fedora Workstation 43 opérationnel et stable sans transformer l’après-midi en exercice de criminalistique. Ce n’est pas le chemin le plus « rapide ». C’est celui qui produit une machine en laquelle vous pouvez avoir confiance.

Le principe de la seule clé USB (et ce que vous ne faites pas)

La « méthode une clé USB » est simple : une clé USB, écrite une fois, vérifiée deux fois, utilisée pour installer Fedora Workstation 43 sur la machine cible. Pas de seconde « clé de secours ». Pas de chargeurs d’amorçage en chaîne. Pas d’ISO mystère que vous avez téléchargé il y a six mois et oublié.

Ce que vous faites :

Télécharger l’ISO correcte de Fedora Workstation 43.
Vérifier l’intégrité (checksum) et l’authenticité (signature GPG) d’une manière qui résiste aux proxies d’entreprise, au Wi‑Fi capricieux et à l’optimisme humain.
Écrire la clé USB en utilisant une méthode qui préserve la capacité de démarrage pour les systèmes UEFI.
Démarrer via UEFI, installer avec des valeurs de stockage sensées, puis valider que le système installé démarre proprement et que votre stockage n’est pas silencieusement dégradé.

Ce que vous ne faites pas :

« dd » sans vérifier le périphérique cible. C’est ainsi que l’on apprend ce que ça fait d’effacer son disque de sauvegarde.
Modifier cinq paramètres du firmware à la fois. Vous « réparerez » peut‑être quelque chose, mais vous ne saurez pas quoi, et le prochain redémarrage sera une surprise.
Surcharger la partition le premier jour parce que vous avez lu un billet de blog de 2017.

Faits rapides et contexte (pourquoi les choses sont ainsi)

Points de contexte courts et concrets qui expliquent le comportement actuel de l’installation de Fedora :

Fedora est un terrain d’essai pour Linux d’entreprise depuis deux décennies. Beaucoup de fonctionnalités mûrissent dans Fedora avant d’apparaître dans des distributions d’entreprise à cycle long.
UEFI a remplacé le BIOS, mais le « legacy mode » a persisté. De nombreuses machines livrent encore des options Compatibility Support Module (CSM), ce qui peut créer une ambiguïté de démarrage si vous mélangez les modes.
Fedora est passé à Btrfs par défaut pour Workstation. Cela a changé l’histoire post-installation : snapshots, sous-volumes et questions « où est passé mon espace disque ? » deviennent normales.
Anaconda est puissant et parfois brutal. C’est l’installateur de Fedora depuis longtemps ; il peut tout faire, des installations simples aux configurations LVM complexes, mais il ne vous empêchera pas d’être trop créatif.
Secure Boot est passé de « paranoïa optionnelle » à « friction par défaut ». Beaucoup d’ordinateurs portables sont livrés avec Secure Boot activé ; Fedora s’en sort généralement bien, mais des pilotes tiers peuvent compliquer les choses.
La qualité des médias USB s’est détériorée, pas améliorée. Les clés bon marché sont souvent des déchets re‑réétiquetés. Elles « fonctionnent » jusqu’à ce qu’elles ne fonctionnent plus, et les installateurs sont excellents pour trouver cette limite.
NVMe a changé les modes de défaillance. Les disques NVMe sont rapides et courants ; ils font aussi apparaître des bizarreries de firmware/PCIe qu’on ne voyait pas sur SATA.
Les images live sont un compromis. Elles sont excellentes pour les démarrages rapides et la détection matérielle, mais elles dépendent fortement de la RAM, du modesetting GPU et des paramètres du noyau.

Préparation pour éviter la douleur

Choisir la clé USB comme vous choisiriez un disque de production

Utilisez une clé USB 3.x de marque reconnue, 8–16 Go suffisent. Si vous installez sur plusieurs machines, achetez deux clés identiques et faites-les tourner. Ce n’est pas de la superstition ; cela réduit les variables quand quelque chose échoue.

Règle : si la clé a déjà servi de « installateur Windows + ISOs aléatoires + photos de famille », ne l’utilisez pas pour votre installation Fedora. Prenez-en une propre. Traitez-la comme une infrastructure jetable.

Savoir sur quoi vous installez

Avant de démarrer quoi que ce soit, décidez :

Mono‑boot (Fedora prend toute la machine) ou dual‑boot (Windows/macOS restent) ?
Avez‑vous besoin d’un chiffrement disque complet ?
Le disque cible est‑il un NVMe ? Y a‑t‑il un second disque que vous pourriez effacer par accident ?

Si vous faites du dual‑boot avec Windows, désactivez d’abord Windows « Fast Startup ». Sinon vous aurez des incohérences de système de fichiers et vous blâmerez Fedora. Windows fermera les yeux tout en laissant votre NTFS dans un état « non propre ».

Décidez si Secure Boot vous importe

Pour la plupart des portables : laissez Secure Boot activé. Fedora s’intègre généralement bien. Si vous avez besoin de modules noyau propriétaires (certains chipsets Wi‑Fi, certaines piles GPU), prévoyez‑le et acceptez que vous devrez peut‑être enregistrer des clés ou désactiver temporairement Secure Boot.

Une citation pour rester honnête : « L’espoir n’est pas une stratégie » — idée paraphrasée souvent répétée en opérations et fiabilité. Votre plan d’installation doit être testable, pas inspirant.

Créer la clé USB (la méthode sûre et reproductible)

Sur Linux, la voie la moins surprenante est : télécharger l’ISO, vérifier checksum et signature, écrire l’image d’une façon qui préserve sa structure hybride de démarrage, puis confirmer que la clé ressemble à un disque bootable.

Tâche 1 : Identifier le périphérique USB avant d’écrire quoi que ce soit

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,MODEL,MOUNTPOINTS
NAME   SIZE TYPE MODEL            MOUNTPOINTS
nvme0n1 1.8T disk Samsung SSD 990 
├─nvme0n1p1 600M part              /boot/efi
├─nvme0n1p2   1G part              /boot
└─nvme0n1p3 1.8T part              /
sda    14.6G disk SanDisk Ultra
└─sda1 14.6G part                  /run/media/cr0x/OLDLABEL

Ce que cela signifie : Vous pouvez voir la clé USB comme sda, 14.6G, modèle « SanDisk Ultra ».

Décision : Si vous ne pouvez pas identifier clairement le disque USB par taille/modèle, arrêtez. Débranchez les autres disques externes. Relancez lsblk. Ne continuez que lorsque vous êtes sûr du périphérique qui sera écrasé.

Tâche 2 : Démonter tout ce qui est monté depuis cette clé USB

cr0x@server:~$ sudo umount /dev/sda1
umount: /dev/sda1: not mounted.

Ce que cela signifie : Soit c’est déjà démonté, soit ce n’était pas monté. Bien. Vous voulez le disque inactif.

Décision : S’il est monté et refuse de se démonter, fermez les gestionnaires de fichiers et terminaux qui l’utilisent, puis réessayez. N’écrivez pas une image sur un système de fichiers monté.

Tâche 3 : Télécharger l’ISO de Fedora Workstation (exemple de nom de fichier)

cr0x@server:~$ ls -lh Fedora-Workstation-Live-x86_64-43-1.2.iso
-rw-r--r-- 1 cr0x cr0x 2.2G Jan 15 12:03 Fedora-Workstation-Live-x86_64-43-1.2.iso

Ce que cela signifie : L’ISO existe localement et a une taille plausible.

Décision : Si elle est suspectement petite, votre téléchargement est incomplet. Retéléchargez avant de perdre du temps à chercher des erreurs de démarrage causées par un fichier tronqué.

Tâche 4 : Vérifier le checksum (intégrité)

cr0x@server:~$ sha256sum Fedora-Workstation-Live-x86_64-43-1.2.iso
9f2b9d1b0f3b2e7c2c1d7c3d53f7b0a6a7d6a1f4d8c1a6d3e0f9c7b2a1d3e4f5  Fedora-Workstation-Live-x86_64-43-1.2.iso

Ce que cela signifie : Vous avez un hash SHA‑256. En soi il n’est utile que si vous le comparez au fichier de checksum officiel.

Décision : Comparez avec le checksum fourni par le vendeur. Si cela ne correspond pas exactement, supprimez l’ISO et retéléchargez. N’essayez pas quand même. Un média d’installation corrompu est un voleur de temps.

Tâche 5 : Vérifier la signature (authenticité)

Vous vérifiez typiquement le fichier checksum avec GPG. Les noms de fichiers varient, mais le flux est stable : importer les clés de release Fedora, vérifier la signature du fichier CHECKSUM, puis faire confiance à la comparaison des hashes.

cr0x@server:~$ gpg --keyserver keyserver.ubuntu.com --recv-keys 38AB71F4
gpg: key 38AB71F4: public key "Fedora (43) <fedora-43-primary@fedoraproject.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1

Ce que cela signifie : Vous avez importé une clé de release. (Les IDs et UIDs de clé diffèrent selon la release ; considérez ceci comme un modèle, pas un nombre magique.)

Décision : Si vous ne pouvez pas vérifier la signature du fichier checksum, vous n’avez pas d’authenticité. En entreprise, c’est souvent ici que vous découvrez que le proxy remplace les fichiers ou que votre miroir n’est pas digne de confiance.

Tâche 6 : Écrire l’ISO sur la clé USB (image hybride, écriture brute)

Je préfère dd pour une raison : c’est ennuyeux et universel. Il faut juste être prudent. Utilisez status=progress et sync à la fin.

cr0x@server:~$ sudo dd if=Fedora-Workstation-Live-x86_64-43-1.2.iso of=/dev/sda bs=4M status=progress oflag=direct conv=fsync
536870912 bytes (537 MB, 512 MiB) copied, 6 s, 89.3 MB/s
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 26 s, 82.6 MB/s
dd: writing to '/dev/sda': No space left on device
2214592512 bytes (2.2 GB, 2.1 GiB) copied, 27.1 s, 81.7 MB/s

Ce que cela signifie : L’écriture s’est terminée quand la clé s’est remplie. Le « No space left on device » à la fin est normal lorsque la taille de l’ISO correspond à la limite de capacité du périphérique. L’important est que conv=fsync force la vidange des données.

Décision : Si la vitesse de copie s’effondre à presque zéro pendant des minutes, suspectez une clé USB en fin de vie. Remplacez‑la maintenant, pas après être en plein milieu de l’installation.

Tâche 7 : Confirmer que la clé a maintenant des partitions et semble bootable

cr0x@server:~$ lsblk -f /dev/sda
NAME   FSTYPE FSVER LABEL   UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda    
├─sda1 vfat   FAT16 EFI     4C2A-1B7E                            
├─sda2 iso9660      Fedora-WS-Live 2026-01-15-12-00-00-00        
└─sda3 ext4   1.0   overlay 1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d

Ce que cela signifie : Vous voyez une partition EFI. C’est le signe que le démarrage UEFI devrait fonctionner. Les labels varient, mais la présence compte.

Décision : Si vous ne voyez qu’une seule partition ou un système de fichiers étrange que vous n’attendiez pas, votre écriture a probablement échoué ou vous avez écrit sur le mauvais périphérique. Arrêtez et revérifiez la sélection du périphérique.

Blague #1 : “dd” signifie « disk destroyer » uniquement si vous traitez les noms de périphériques comme un jeu de devinettes.

Démarrer la clé USB sur du matériel réel

Les problèmes de démarrage ne sont généralement pas des problèmes Fedora. Ce sont des problèmes de firmware, de média ou de « j’ai changé trois paramètres du BIOS et maintenant rien n’a de sens ».

Discipline du menu de démarrage UEFI

Utilisez la touche du menu de démarrage de votre machine (souvent F12, F10, Esc) et sélectionnez l’entrée qui dit explicitement UEFI. Si vous voyez deux entrées pour la clé — une « UEFI: SanDisk » et une simple « SanDisk » — choisissez celle en UEFI. Mixer legacy et UEFI crée la confusion de chargeur d’amorçage qui survit aux réinstallations.

Si l’écran devient noir, ne paniquez pas — procédez au triage

Les GPU modernes et le modesetting peuvent provoquer un écran noir pendant le démarrage. Votre travail est de décider s’il s’agit d’un problème GPU, d’un problème de lecture USB ou d’une incompatibilité noyau/firmware. Le « Mode opératoire de diagnostic rapide » plus loin rendra cela mécanique.

Anaconda install: décisions qui comptent

Quand Anaconda démarre, cela semble simple : choisir la langue, choisir le disque, cliquer sur installer. Le problème commence quand vous traitez le stockage comme une préférence occasionnelle. Le stockage est la partie qui mord plus tard.

Le partitionnement par défaut est bon — sauf si vous avez des exigences

Pour un portable mono‑disque, les valeurs par défaut de Fedora sont sensées : partition système UEFI, /boot, et une racine Btrfs avec sous‑volumes. Si vous voulez un chiffrement complet du disque, activez‑le dans l’installateur. Si vous souhaitez un /home séparé, demandez‑vous pourquoi.

Mon avis : ne séparez pas /home à moins d’avoir un besoin spécifique (expériences multi‑boot, politique stricte de rollback, ou vous connaissez votre charge de travail). Avec les sous‑volumes Btrfs, vous pouvez gérer la séparation logiquement sans découper l’espace disque prématurément.

Chiffrement : oui, mais comprenez le compromis

Le chiffrement LUKS est un bon choix par défaut pour les portables. Le compromis est que la performance au démarrage et les workflows de récupération changent. Si vous perdez votre passphrase, aucune énergie SRE ne ressuscitera vos données. Ce n’est pas un problème Fedora ; c’est des mathématiques.

Dual‑boot : politique « ne soyez pas malin »

Si vous faites du dual‑boot avec Windows :

Faites une sauvegarde d’abord.
Réduisez les partitions Windows depuis Windows, pas depuis l’installateur Fedora.
Laissez la partition EFI existante telle quelle ; Fedora peut l’utiliser.

L’objectif est un changement minimal : ajoutez les partitions Fedora, ajoutez des entrées de démarrage, ne réarrangez pas l’univers.

12+ tâches pratiques avec commandes, sorties et décisions

Ces tâches sont écrites comme un runbook d’opérateur : commande, sortie exemple, ce que cela signifie, et la décision suivante. Exécutez‑les depuis l’environnement live quand approprié, et depuis le système installé après le premier démarrage quand indiqué.

Tâche 8 (Live USB) : Confirmer que vous avez démarré en mode UEFI

cr0x@server:~$ test -d /sys/firmware/efi && echo "UEFI boot" || echo "Legacy/CSM boot"
UEFI boot

Ce que cela signifie : Si /sys/firmware/efi existe, vous êtes en mode UEFI.

Décision : Si vous êtes en mode legacy et que votre disque possède déjà une partition EFI (la plupart des systèmes modernes), redémarrez et sélectionnez l’entrée USB UEFI. N’installez pas accidentellement en mode legacy.

Tâche 9 (Live USB) : Inspecter les disques et confirmer la cible

cr0x@server:~$ sudo fdisk -l
Disk /dev/nvme0n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 990
Device           Start        End    Sectors   Size Type
/dev/nvme0n1p1     2048    1230847    1228800   600M EFI System
/dev/nvme0n1p2  1230848    3327999    2097152     1G Linux filesystem
/dev/nvme0n1p3  3328000 3907028991 3903700992   1.8T Linux filesystem

Disk /dev/sda: 14.56 GiB, 15634268160 bytes, 30535680 sectors
Disk model: SanDisk Ultra

Ce que cela signifie : Vous pouvez distinguer clairement le NVMe interne de la clé USB.

Décision : Si plusieurs disques internes existent, étiquetez‑les maintenant (physiquement ou par notes). L’interface de l’installateur est correcte, mais les humains ne le sont pas.

Tâche 10 (Live USB) : Vérifier la santé du NVMe (signal rapide, pas gospel)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | sed -n '1,25p'
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.8.0] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 990
Serial Number:                      S7X9NX0W123456A
Firmware Version:                   1B2QJXD7
PCI Vendor/Subsystem ID:            0x144d
IEEE OUI Identifier:                0x002538
Total NVM Capacity:                 2,000,398,934,016 [2.00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      4
Number of Namespaces:               1
Namespace 1 Size/Capacity:          2,000,398,934,016 [2.00 TB]
Namespace 1 Utilization:            500,000,000,000 [500 GB]

Ce que cela signifie : Le périphérique répond et rapporte son identité ; c’est une vérification sanity de base.

Décision : Si smartctl ne peut pas parler au périphérique, votre chemin noyau/firmware live peut être cassé. Mettez à jour le firmware/BIOS si disponible, ou testez un noyau plus récent via un média mis à jour.

Tâche 11 (Live USB) : Rechercher des erreurs de stockage ou USB dans le journal du noyau

cr0x@server:~$ sudo dmesg -T | egrep -i "usb|nvme|i/o error|reset|timeout" | tail -n 15
[Mon Feb  5 10:14:22 2026] usb 2-2: new SuperSpeed USB device number 3 using xhci_hcd
[Mon Feb  5 10:14:23 2026] usb-storage 2-2:1.0: USB Mass Storage device detected
[Mon Feb  5 10:14:23 2026] scsi host6: usb-storage 2-2:1.0
[Mon Feb  5 10:14:24 2026] scsi 6:0:0:0: Direct-Access     SanDisk  Ultra            1.00 PQ: 0 ANSI: 6
[Mon Feb  5 10:14:25 2026] nvme nvme0: pci function 0000:04:00.0
[Mon Feb  5 10:14:25 2026] nvme nvme0: 16/0/0 default/read/poll queues
[Mon Feb  5 10:14:25 2026] nvme0n1: p1 p2 p3

Ce que cela signifie : Pas de timeouts ou storms de reset évidents. L’USB et le NVMe s’énumèrent proprement.

Décision : Si vous voyez des « reset SuperSpeed USB device » répétés ou des erreurs I/O sur l’USB, arrêtez de blâmer Fedora. Remplacez la clé ou essayez un autre port USB (souvent les ports USB‑A du côté opposé sont sur un autre contrôleur).

Tâche 12 (Système installé) : Confirmer l’entrée de démarrage du firmware et le chargeur démarré

cr0x@server:~$ sudo bootctl status
System:
     Firmware: UEFI 2.70 (American Megatrends 5.17)
  Secure Boot: enabled (user)
 TPM2 Support: yes
Boot Loader:
     Product: systemd-boot 253
     Features: ✓ Boot counting  ✓ Menu timeout  ✓ One-shot menu
Current Boot Loader Entry:
         id: fedora.conf
     source: /boot/efi/loader/entries/fedora.conf
      title: Fedora Linux
     linux: /vmlinuz-6.10.8-200.fc43.x86_64

Ce que cela signifie : Vous êtes démarré en mode UEFI et pouvez voir quel chargeur est actif. (Certaines installations peuvent utiliser GRUB ; ceci est un exemple.)

Décision : Si Secure Boot est activé et que vous utilisez des modules tiers plus tard, prévoyez la signature ou l’enregistrement de clés. Si le système a démarré en legacy de façon inattendue, corrigez les paramètres du firmware avant d’empiler la complexité.

Tâche 13 (Installé) : Confirmer vos systèmes de fichiers et les sous‑volumes Btrfs

cr0x@server:~$ findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS | egrep "^/ |^/home |^/boot"
TARGET SOURCE                     FSTYPE OPTIONS
/      /dev/nvme0n1p3[/@]         btrfs  rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/@
/boot  /dev/nvme0n1p2             ext4   rw,relatime
/home  /dev/nvme0n1p3[/@home]     btrfs  rw,relatime,ssd,space_cache=v2,subvolid=257,subvol=/@home

Ce que cela signifie : Root et home sont des sous‑volumes Btrfs ; boot est en ext4. C’est typique et sensé.

Décision : Si / n’est pas ce que vous attendiez (par ex. installé sur le mauvais disque), arrêtez et corrigez maintenant. Migrer plus tard est possible mais inutilement épicé.

Tâche 14 (Installé) : Vérifier la comptabilité d’espace Btrfs (éviter les surprises « disque plein »)

cr0x@server:~$ sudo btrfs filesystem df /
Data, single: total=120.00GiB, used=38.50GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=8.00GiB, used=2.10GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

Ce que cela signifie : Btrfs alloue des « chunks » pour les données et les métadonnées. « total » est alloué ; « used » est ce qui est consommé à l’intérieur des chunks alloués.

Décision : Si les métadonnées sont presque pleines alors que les données ne le sont pas, vous rencontrerez d’étranges erreurs « no space left ». Planifiez un rééquilibrage des métadonnées plus tard, et évitez des charges pathologiques (millions de petits fichiers) sans surveillance.

Tâche 15 (Installé) : Valider le support TRIM/discard (longévité et performance SSD)

cr0x@server:~$ systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; preset: enabled)
     Active: active (waiting) since Mon 2026-02-05 09:55:01 UTC; 8min ago
    Trigger: Mon 2026-02-10 00:00:00 UTC; 4 days left
     Docs: man:fstrim

Ce que cela signifie : Le TRIM hebdomadaire est activé.

Décision : S’il est désactivé, activez‑le sauf si vous avez une raison spécifique de stockage. La plupart des portables en bénéficient, c’est peu risqué.

Tâche 16 (Installé) : Confirmer que noyau, initramfs et chaîne de démarrage sont cohérents

cr0x@server:~$ uname -r
6.10.8-200.fc43.x86_64

cr0x@server:~$ lsinitrd /boot/initramfs-$(uname -r).img >/dev/null && echo "initramfs exists"
initramfs exists

Ce que cela signifie : Le noyau en cours d’exécution a un initramfs correspondant sur disque.

Décision : Si l’initramfs manque, ne redémarrez pas à la légère. Reconstruisez‑le d’abord, sinon vous transformerez un système en cours d’exécution en système non amorçable.

Tâche 17 (Installé) : Vérifier les unités systemd échouées au premier démarrage

cr0x@server:~$ systemctl --failed
  UNIT                          LOAD   ACTIVE SUB    DESCRIPTION
0 loaded units listed.

Ce que cela signifie : Rien d’évident n’est en feu.

Décision : Si des échecs existent, inspectez‑les maintenant. C’est le moment le plus simple pour corriger les services de base.

Tâche 18 (Installé) : Vérifier les logs pour avertissements matériel/driver

cr0x@server:~$ sudo journalctl -b -p warning..alert --no-pager | tail -n 20
Feb 05 09:56:12 fedora kernel: iwlwifi 0000:00:14.3: WRT: Invalid buffer destination
Feb 05 09:56:15 fedora kernel: ACPI BIOS Error (bug): Failure creating named object [\_SB.PCI0.XHCI.RHUB.SS01], AE_ALREADY_EXISTS
Feb 05 09:56:18 fedora gnome-shell[1920]: Window manager warning: Overwriting existing binding of keysym 32 with keysym 32.

Ce que cela signifie : Les avertissements arrivent ; tous ne sont pas actionnables. Les warnings ACPI BIOS sont souvent des bizarreries de firmware.

Décision : Si vous voyez des timeouts NVMe, des erreurs de système de fichiers ou des resets GPU répétés, vous avez un vrai problème de stabilité. Mettez d’abord à jour le BIOS/firmware, puis envisagez des paramètres noyau.

Tâche 19 (Installé) : Confirmer la pile réseau et la résolution DNS (ne présumez pas que le Wi‑Fi fonctionne « assez bien »)

cr0x@server:~$ nmcli device status
DEVICE  TYPE      STATE         CONNECTION
wlp0s20f3 wifi      connected     corp-wifi
lo      loopback  unmanaged     --

cr0x@server:~$ resolvectl status | sed -n '1,25p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.10.10.53
       DNS Servers: 10.10.10.53 10.10.10.54

Ce que cela signifie : NetworkManager voit une interface connectée ; systemd‑resolved a des serveurs DNS.

Décision : Si le DNS manque ou est erroné, corrigez‑le avant d’essayer de faire des mises à jour. Un DNS cassé ressemble à « dnf est en panne », ce qui fait perdre du temps.

Tâche 20 (Installé) : Mettre à jour proprement et confirmer que vous ne mélangez pas les dépôts par accident

cr0x@server:~$ sudo dnf -y upgrade
Last metadata expiration check: 0:12:41 ago on Mon 05 Feb 2026 09:48:31 AM UTC.
Dependencies resolved.
Nothing to do.
Complete!

Ce que cela signifie : Vous êtes à jour et vos dépôts sont cohérents.

Décision : Si vous voyez des conflits de dépendances juste après l’installation, vous avez probablement activé des dépôts supplémentaires trop tôt. Revenez en arrière avant d’avancer.

Tâche 21 (Installé) : Vérifier l’espace de /boot (éviter les échecs de mise à jour du noyau)

cr0x@server:~$ df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  974M  312M  596M  35% /boot

Ce que cela signifie : Il y a beaucoup d’espace. Les mises à jour de noyau ont besoin d’espace dans /boot.

Décision : Si /boot est presque plein, faites le ménage des anciens noyaux avec précaution avant de rencontrer une mise à jour qui échoue à mi‑chemin.

Tâche 22 (Installé) : Vérifier la synchronisation horaire (car TLS et dépôts s’en préoccupent)

cr0x@server:~$ timedatectl status
               Local time: Mon 2026-02-05 10:07:41 UTC
           Universal time: Mon 2026-02-05 10:07:41 UTC
                 RTC time: Mon 2026-02-05 10:07:40
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Ce que cela signifie : L’horloge est synchronisée.

Décision : Si la synchronisation est désactivée, corrigez‑la avant de déboguer des erreurs TLS « aléatoires » ou des échecs de connexion.

Validation post‑installation : traitez votre portable comme un serveur

Une installation Workstation reste un système de production—juste un où le client, c’est vous. Validez les bases : démarrage, stockage, logs et mises à jour. Puis laissez‑le tourner assez longtemps pour prouver sa stabilité.

Vérification GPU : rendez‑la ennuyeuse

Si vous avez un portable avec GPU hybride, résistez à l’envie d’installer immédiatement les pilotes propriétaires. Confirmez d’abord que le système est stable avec la pile par défaut. Si vous avez besoin du pilote propriétaire pour le travail, installez‑le avec un plan de retour arrière (au minimum : sachez comment accéder à un TTY et supprimer les paquets).

Vérification stockage : faites confiance mais vérifiez

Si vous avez activé le chiffrement, testez un redémarrage immédiatement. Si vous utilisez Btrfs, apprenez deux commandes (btrfs filesystem df et btrfs device stats) et utilisez‑les chaque fois que les performances semblent « mauvaises ».

Blague #2 : Mon incident préféré est celui qui n’arrive jamais parce que vous avez redémarré une fois volontairement.

Mode opératoire de diagnostic rapide

Quand quelque chose tourne mal, la rapidité vient de l’ordre. N’allez pas vers des correctifs exotiques. Identifiez le goulot en trois passes : mode de démarrage, média, puis stockage/logs.

Première passe : confirmer le mode de démarrage et la cible de démarrage

Vérifier UEFI vs legacy : Dans l’environnement live, vérifiez /sys/firmware/efi. Si vous avez installé dans un mode et démarrez dans l’autre, vous poursuivrez des fantômes.
Confirmer la sélection du disque : Utilisez lsblk et fdisk -l. Assurez‑vous que l’OS est sur le disque que vous pensez.
Regarder l’entrée de démarrage : Après installation, utilisez bootctl status ou efibootmgr -v.

Deuxième passe : valider l’USB et l’environnement de l’installateur

Erreurs USB : Vérifiez dmesg pour resets/timeouts.
Essayez un autre port : Préférez les ports directs de la carte mère. Évitez les hubs frontaux et stations d’accueil pendant l’installation.
Suspectez la clé : Si l’installation bloque à des pourcentages aléatoires ou lance des erreurs I/O, changez la clé. Ne négociez pas avec un média défectueux.

Troisième passe : localiser les défaillances de stockage ou de pilote

Détection du stockage : Si le NVMe n’apparaît pas, souvent c’est une configuration firmware/BIOS (mode RAID vs AHCI, VMD, etc.).
Journaux noyau : journalctl -b -p warning..alert et dmesg sont votre sérum de vérité.
État du système de fichiers : Sur Btrfs, vérifiez btrfs device stats et btrfs filesystem df. Sur ext4, cherchez des replays de journal et des erreurs.

Erreurs courantes : symptôme → cause → correction

1) Symptom : la clé USB démarre sur une machine, pas sur une autre

Cause : Vous sélectionnez l’entrée legacy sur une machine et UEFI sur une autre, ou le firmware bloque certains chemins de démarrage USB.

Correction : Utilisez le menu de démarrage et choisissez l’entrée UEFI explicite. Désactivez CSM/legacy si possible. Vérifiez que l’environnement live affiche UEFI boot avec la vérification de la Tâche 8.

2) Symptom : l’installateur se fige ou lance des erreurs I/O en cours

Cause : Clé USB défectueuse, port USB défaillant ou chemin contrôleur USB instable (docks/hubs).

Correction : Vérifiez dmesg pour des resets USB. Changez de port. Remplacez la clé. Réécrivez l’ISO après vérification du checksum.

3) Symptom : « Aucun périphérique bootable » après une installation réussie

Cause : L’ordre de démarrage du firmware ne s’est pas mis à jour, ou l’entrée EFI n’a pas été créée parce que vous avez installé en mode legacy, ou vous vous êtes trompé de disque.

Correction : Redémarrez sur la clé USB, confirmez le mode UEFI, puis inspectez les entrées EFI avec efibootmgr -v (depuis l’environnement live). Corrigez l’ordre de démarrage dans le firmware. Si vous avez installé en legacy sur un système UEFI, réinstallez en mode UEFI plutôt que de bricoler.

4) Symptom : Fedora démarre, mais le Wi‑Fi est complètement absent

Cause : Chipset non supporté, firmware manquant, ou Secure Boot bloque un module de pilote tiers.

Correction : Vérifiez lspci -nn et journalctl -b pour des échecs de chargement de pilote/firmware. Si vous devez utiliser un module tiers, planifiez la démarche Secure Boot (signature/enregistrement) plutôt que de bricoler des interrupteurs au hasard.

5) Symptom : avertissements « disque plein » sur Btrfs alors qu’il reste beaucoup d’espace

Cause : Épuisement des métadonnées Btrfs ou déséquilibre d’allocation des chunks.

Correction : Confirmez avec btrfs filesystem df /. Envisagez un rééquilibrage contrôlé plus tard. Évitez les suppressions paniquées ; comprenez si les données ou les métadonnées sont le goulot.

6) Symptom : Windows Dual‑boot signale des erreurs de disque

Cause : Fast Startup/hibernation de Windows a laissé le NTFS sale ; Linux le monte en lecture seule ou déclenche des invites de réparation.

Correction : Désactivez Fast Startup dans Windows, éteignez complètement, puis démarrez Fedora. Ne « forcez » pas le montage NTFS en lecture‑écriture à moins d’aimer vivre dangereusement.

7) Symptom : l’installateur ne voit pas le SSD interne

Cause : Mode de stockage BIOS réglé sur RAID/VMD, ou le contrôleur est masqué derrière une abstraction firmware.

Correction : Passez en AHCI (si approprié pour votre plateforme), ou désactivez VMD quand c’est sûr. Puis réessayez. Si c’est un portable géré par l’entreprise, coordonnez‑vous avec le service IT — changer cela peut casser l’image préinstallée.

Listes de contrôle / plan pas à pas

Plan d’installation One‑USB (le chemin minimal et correct)

Choisir une clé USB connue bonne (neuve ou de confiance).
Télécharger l’ISO Fedora Workstation 43.
Vérifier checksum et signature (intégrité + authenticité).
Identifier le périphérique USB avec lsblk.
Écrire l’ISO sur /dev/sdX (disque entier, pas partition) en utilisant dd avec flush.
Confirmer que la clé possède une partition EFI via lsblk -f.
Démarrer via l’entrée USB UEFI (pas legacy).
Dans l’environnement live, confirmer le mode de démarrage UEFI.
Dans Anaconda, choisir le disque cible correct. Si dual‑boot, soyez conservateur et ne réorganisez pas les partitions existantes.
Activer le chiffrement si c’est un portable et que vos données comptent.
Terminer l’installation, redémarrer, et tester immédiatement un second redémarrage (oui, vraiment).
Exécuter la validation post‑install : unités échouées, logs, systèmes de fichiers, espace de boot, mises à jour.

Checklist « si c’est un portable d’entreprise »

Confirmer si Secure Boot doit rester activé (la politique le demande souvent).
Confirmer si les paramètres du BIOS sont verrouillés (certains le sont).
Vérifier si les changements de mode disque (AHCI/RAID/VMD) sont autorisés ; ils peuvent briquer l’image fournisseur.
S’assurer d’un chemin de récupération approuvé par l’IT (même si vous ne l’utilisez jamais).
Confirmer la compatibilité du client VPN avant d’effacer quoi que ce soit.

Checklist « si vous avez besoin de dual‑boot »

Sauvegarder les données Windows (et vérifier que la sauvegarde s’ouvre).
Désactiver Windows Fast Startup ; éteindre complètement.
Réduire la partition Windows depuis les outils Windows.
Pendant l’installation Fedora, ne supprimez ni ne reformatez la partition EFI existante.
Après installation, confirmer que les deux entrées de démarrage existent et que le firmware ne réinitialise pas silencieusement l’ordre de démarrage.

Trois mini‑récits d’entreprise (pour ne pas les répéter)

Mini‑récit #1 : L’incident causé par une mauvaise hypothèse

Une petite équipe d’ingénierie standardisa sur « une clé installateur pour tout ». La clé vivait dans un tiroir, voyageait entre bureaux, et servait à tout : installations Fedora, mises à jour de firmware, « copie rapide d’un bundle de logs », etc. Ça marchait assez souvent pour sembler fiable.

Puis un nouveau modèle de portable arriva. L’installation démarra, commença à copier des paquets, et mourut avec des erreurs I/O intermittentes. L’équipe supposa que le nouveau portable avait un SSD défectueux. Ils ouvrirent un ticket, puis un autre. Ils permutèrent le portable. Même problème. Maintenant c’était un « lot défectueux ». Quelqu’un suggéra que le port USB était capricieux. Ils essayèrent un autre port. Même problème.

L’hypothèse erronée était simple : « Si ça démarre, le média USB est bon. » Le démarrage lit relativement peu. L’installation lit continuellement, avec un débit soutenu. La clé avait la mémoire en train de céder ; elle pouvait servir un noyau et un initramfs, mais se brisait sous charge.

La correction fut ennuyeuse : remplacer la clé et adopter une politique — le média d’installation USB est à usage unique, et toute erreur I/O pendant l’installation justifie sa mise à la poubelle. Ils ajoutèrent aussi une vérification rapide de dmesg pendant les installations pour détecter les storms de resets. L’incident se termina non pas par un patch intelligent, mais par une corbeille.

Mini‑récit #2 : L’optimisation qui a mal tourné

Une organisation plus grande eut une initiative « accélérer le provisioning des portables ». Quelqu’un décida que l’écriture des ISOs avec parallélisme agressif et cache serait un gain de temps. Ils utilisèrent une station de travail rapide et un duplicateur USB et crachèrent des clés en masse. Sur le papier, c’était merveilleux : plus de clés par heure, moins de temps humain.

Le retour de bâton arriva plus tard : un sous‑ensemble de ces clés démarraient sur certaines machines mais pas d’autres. Les échecs n’étaient pas cohérents, ce qui est le pire. Le débogage bouffa des jours parce que l’équipe traitait chaque portable comme une fleur unique.

Finalement, quelqu’un compara les tables de partitions d’une clé « bonne » et d’une clé « mauvaise ». Les clés mauvaises avaient des incohérences subtiles — suffisantes pour embrouiller des firmwares plus pointilleux. Le « gain » du duplicateur ne préservait pas fidèlement la mise en page hybride de l’image à chaque fois.

La remédiation fut d’abandonner le pipeline astucieux et de standardiser une méthode d’écriture vérifiée par clé, plus une étape de validation post‑écriture : lsblk -f doit montrer une partition EFI. Le provisioning ralentit légèrement. Les incidents furent beaucoup moins fréquents. C’est un compromis que la plupart des SRE acceptent sans hésiter.

Mini‑récit #3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Un service financier utilisait Fedora Workstation sur des portables d’analystes parce que leurs workflows étaient axés conteneurs et la sécurité voulait du chiffrement. L’équipe, par nature prudente, adopta une règle des « deux redémarrages » : après installation et mises à jour, redémarrez deux fois avant de livrer la machine à l’utilisateur.

Une semaine, un lot de portables commença à échouer après le premier redémarrage post‑install. Le premier redémarrage fonctionnait, le second non. Agaçant. Sans la règle, ces machines auraient été livrées « fonctionnelles » puis auraient échoué un lundi matin, dans les mains d’utilisateurs pressés.

Parce qu’ils reproduisirent le problème en provisioning, ils avaient des logs et un environnement contrôlé. Le coupable fut une incohérence de chaîne de démarrage déclenchée par un bug firmware quand l’ordre de démarrage changeait. Le second redémarrage faisait ressortir l’état défectueux de façon fiable.

La correction fut un ajustement de paramètre firmware et s’assurer d’une sélection UEFI only pendant l’installation. La pratique salvatrice n’était ni du monitoring exotique ni un nouvel outil. C’était la discipline de redémarrer deux fois quand la machine est sur l’établi, quand la correction est peu coûteuse.

FAQ

Q1 : Pourquoi « une clé USB » alors que je pourrais utiliser Ventoy ou un outil multi‑ISO ?

Parce que vous voulez moins de variables. Les outils multi‑ISO conviennent aux passionnés, mais quand un démarrage échoue vous avez ajouté une couche à déboguer. Une clé, une image, un chemin connu‑bon.

Q2 : Dois‑je utiliser Fedora Media Writer plutôt que dd ?

Si vous êtes sur un poste de travail et préférez une GUI, Fedora Media Writer est un bon choix. J’aime encore dd quand je veux une méthode déterministe et scriptable et que je suis déjà sur Linux. L’important est la vérification et la sélection correcte du périphérique, pas l’outil exact.

Q3 : Pourquoi dd a‑t‑il indiqué « No space left on device » ?

Souvent c’est normal quand la taille de l’image atteint la fin du périphérique. Ce qui compte, c’est que la copie soit complète et que vous ayez un layout de partition valide ensuite (lsblk -f). Si l’écriture s’est arrêtée de façon suspecte, c’est autre chose.

Q4 : Ai‑je besoin d’une partition /home séparée sur Fedora Workstation 43 ?

Généralement non. Les valeurs par défaut Btrfs de Fedora vous offrent une séparation logique via des sous‑volumes sans frontières de partition strictes. Séparez /home seulement si vous avez une raison opérationnelle claire.

Q5 : Le chiffrement complet du disque en vaut‑il la peine ?

Sur les portables, oui. Le seul argument honnête contre est « je ne peux pas gérer la perte de la passphrase » ou « mon modèle de menace n’inclut pas la perte d’appareil ». Si votre portable sort de votre domicile, chiffrez‑le.

Q6 : Ma machine ne démarre la clé qu’en mode legacy. Que faire ?

D’abord, vérifiez les paramètres du firmware : désactivez CSM/legacy si possible et assurez‑vous que le démarrage UEFI est activé. Essayez un autre port USB. Si le firmware est vraiment cassé, vous pouvez installer en legacy — mais restez cohérent et acceptez les limitations du chargeur. La cohérence compte plus que l’idéologie.

Q7 : L’installateur ne voit pas mon SSD interne (NVMe). Fedora manque‑t‑il de pilotes ?

Parfois, mais souvent c’est la configuration BIOS (RAID/VMD). Vérifiez le mode de stockage du firmware. Sur les appareils gérés, coordonnez les changements car cela peut affecter les images de récupération et les outils de conformité.

Q8 : Fedora est installé, mais le système boot toujours sur Windows.

Cela vient généralement de l’ordre de démarrage du firmware. Allez dans la configuration du firmware et placez Fedora (ou l’entrée du chargeur Linux) au‑dessus de Windows Boot Manager. Vérifiez aussi si le firmware a une fonctionnalité « restaurer l’ordre de démarrage ».

Q9 : Comment savoir si ma clé USB est le problème ?

Cherchez des resets/timeouts USB dans dmesg pendant la session live et pendant l’installation. Si des erreurs apparaissent, remplacez la clé. Les médias USB sont bon marché ; votre temps ne l’est pas.

Q10 : Après l’installation, quels sont les trois contrôles les plus importants ?

1) systemctl --failed (services), 2) journalctl -b -p warning..alert (logs), 3) findmnt et btrfs filesystem df (réalité du stockage vs hypothèses).

Conclusion : prochaines étapes à réaliser

Si vous ne faites rien d’autre, réalisez ces étapes après votre installation Fedora Workstation 43 :

Redémarrez deux fois et confirmez la stabilité. Cela attrape les incohérences d’ordre de démarrage et d’initramfs pendant que vous vous souvenez encore de ce que vous avez changé.
Exécutez les commandes de validation : unités échouées, logs d’avertissement, montages des systèmes de fichiers et espace de boot.
Mettez le système à jour et confirmez que la gestion des paquets est propre avant d’ajouter des dépôts tiers ou des pilotes.
Notez ce que vous avez fait : choix du layout disque, statut du chiffrement, réglage Secure Boot. Votre vous futur considérera cette note comme de l’or.

La méthode une clé USB n’est pas glamour. C’est un petit rituel qui vous achète quelque chose de rare dans les installations Linux de bureau : un résultat ennuyeux. Et l’ennui, c’est ce que vous voulez.