Installation de Kali Linux 2025.4 : la méthode sûre (pour ne pas briquer votre portable)

Les règles : comment ne pas briquer son portable

Installer Kali en toute sécurité n’est pas une question de commandes magiques. C’est refuser de faire des changements irréversibles sans un plan de retour en arrière.

Règle 1 : Traitez votre disque interne comme en production

Le disque de votre portable est un point de défaillance unique avec une valeur sentimentale. Vous n’y « expérimentez » pas. Vous le modifiez avec un plan, une sauvegarde et un moyen de revenir en arrière.

Règle 2 : Préférez la virtualisation sauf si vous avez un besoin réel

Si votre objectif est d’apprendre des outils, de faire des labs et des CTF, utilisez une VM. Vous faites des snapshots. Vous revenez en arrière. Vous ne touchez pas à votre partition EFI à 2 h du matin. Le compromis : l’injection Wi‑Fi et certains périphériques USB peuvent être complexes, et les performances sont limitées par l’hôte.

Règle 3 : Ne faites jamais confiance au sélecteur de disque de l’installateur

Les installateurs sont polis. Ils détruiront volontiers le mauvais disque tout en affichant le nom correct du disque. Votre travail est de prouver l’identité du disque cible en utilisant des identifiants stables (modèle NVMe + taille + numéro de série quand possible).

Règle 4 : Les problèmes de démarrage sont normaux ; la perte de données est optionnelle

GRUB peut être réparé. Les entrées EFI peuvent être recréées. Le chargeur de Windows peut être récupéré. Ce que vous ne pouvez pas récupérer, c’est la seule copie de vos photos, de vos clés SSH ou de la proposition dont vous aviez besoin hier.

Règle 5 : « Ça marche maintenant » n’est pas la même chose que « démarrera après des mises à jour »

Beaucoup d’événements de briquage surviennent après la première mise à jour du noyau ou le premier changement de réglage du firmware. Votre installation doit survivre : mises à jour du noyau, rebuild d’initramfs et reset du BIOS.

Une citation à coller sur votre écran : « L’espoir n’est pas une stratégie. » — idée paraphrasée, souvent répétée dans les cercles d’opérations et de fiabilité.

Faits intéressants et contexte historique

• Kali a remplacé BackTrack en 2013, passant d’« une distribution boîte à outils » à une plateforme Debian structurée avec des paquets reproductibles et une meilleure hygiène des mises à jour.
• Kali suit Debian testing dans de nombreux domaines, ce qui veut dire : vous obtenez les outils de sécurité plus récents plus vite, et vous héritez d’un peu plus d’instabilité qu’une distro workstation stable.
• UEFI est devenu l’ère par défaut pour les PC grand public dans les années 2010. Aujourd’hui, la plupart des histoires « ça ne démarre plus » sont en réalité des « l’entrée EFI a disparu ou l’ordre de démarrage a changé ».
• Secure Boot a commencé à l’ère Windows pour réduire le risque de bootkit. Le support Linux a mûri, mais les noyaux personnalisés et modules non signés peuvent encore provoquer des surprises.
• NVMe a changé le mode de défaillance : c’est assez rapide pour que les installateurs finissent vite, ce qui enlève le temps dont vous disposiez auparavant pour réaliser que vous avez choisi le mauvais disque.
• Le chiffrement complet du disque (FDE) est devenu courant sur les portables au fur et à mesure que le modèle de risque de vol a évolué. Les installations modernes doivent partir du principe que la perte du disque est inévitable et planifier en conséquence.
• GRUB n’est pas le seul chargeur de démarrage. systemd-boot et les gestionnaires constructeur existent, mais GRUB reste courant car il gère bien les menus complexes dual-boot et noyaux — quand il est correctement configuré.
• Le firmware Wi‑Fi et les licences sont encore une contrainte réelle : le noyau peut supporter une puce, mais le blob firmware peut ne pas être inclus par défaut dans certaines voies d’installation.

Choisissez votre voie d’installation (VM, dual-boot ou remplacement total)

Option A : VM (recommandée pour la plupart)

Utilisez un hyperviseur et gardez votre OS hôte stable. Vous faites des snapshots. Vous revenez en arrière. Vous ne touchez pas à votre EFI à 2 h du matin. Le compromis : l’injection Wi‑Fi et certains périphériques USB peuvent être délicats, et les performances sont limitées par l’hôte.

Option B : Dual-boot (raisonnable, mais discipline requise)

Le dual-boot est viable si vous pouvez tolérer la complexité du chargeur et si vous respectez les limites de partition. Le risque n’est pas théorique : les mises à jour Windows peuvent réécrire les priorités de démarrage ; les mises à jour Linux peuvent modifier GRUB ; les mises à jour firmware peuvent effacer les entrées EFI.

Option C : Remplacement total (histoire de démarrage la plus propre, engagement maximal)

Effacer le disque est l’installation la plus simple. C’est aussi la plus susceptible de vous faire regretter. Ne le faites que si le portable est dédié à Kali ou si vous avez une sauvegarde vérifiée et testée de tout ce qui compte.

Règle de décision : si vous ne pouvez pas expliquer votre plan de partition sur papier, ne faites pas de dual-boot. VM jusqu’à ce que vous puissiez.

Pré-vol : inventoriez la machine avant de toucher aux disques

C’est ici que vous évitez 80 % des catastrophes. Vous allez répondre à trois questions : quel disque est-ce, comment démarre-t-il, et qu’est-ce qui s’y trouve actuellement ?

Tâche 1 : Confirmer le mode de démarrage (UEFI vs legacy)

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

Ce que ça signifie : Si vous voyez UEFI, vous devez installer Kali en mode UEFI et utiliser une EFI System Partition (ESP). Si ça indique Legacy, arrêtez et reconsidérez — la plupart des machines modernes devraient fonctionner en UEFI. Mélanger les modes est une configuration classique « ça démarre une fois, puis plus jamais ».

Décision : Si le mode legacy est activé, passez en UEFI dans les paramètres du firmware sauf si vous avez une exigence forte.

Tâche 2 : Identifier les disques et leurs tailles (pour ne pas effacer le mauvais)

cr0x@server:~$ lsblk -o NAME,MODEL,SIZE,TYPE,FSTYPE,MOUNTPOINTS
NAME        MODEL               SIZE TYPE FSTYPE MOUNTPOINTS
nvme0n1     SAMSUNG MZVLQ512H 476.9G disk
├─nvme0n1p1                     260M part vfat   /boot/efi
├─nvme0n1p2                      16M part
├─nvme0n1p3                   300.0G part ntfs
└─nvme0n1p4                   176.6G part ntfs
sda         SanDisk Ultra USB   57.3G disk
└─sda1                             57G part exfat

Ce que ça signifie : Vous avez un NVMe interne (nvme0n1) et une clé USB externe (sda). Notez le modèle et la taille. La partition EFI est déjà présente (vfat à /boot/efi).

Décision : Notez le nom et la taille du disque interne. Vous le reverrez avant le partitionnement.

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

cr0x@server:~$ sudo parted -l | sed -n '1,40p'
Model: Samsung SSD (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Ce que ça signifie : GPT est la norme moderne avec UEFI. Bien. Si vous voyez MBR/msdos sur un portable UEFI, vous pouvez encore démarrer, mais vous vous exposez à des cas limites étranges.

Décision : Gardez GPT pour les installations UEFI.

Tâche 4 : Vérifier l’état de Secure Boot (depuis Linux, si possible)

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

Ce que ça signifie : Secure Boot est activé. Kali peut fonctionner avec dans certains scénarios, mais les modules noyau tiers (NVIDIA, modules VirtualBox, certains pilotes Wi‑Fi) compliquent souvent les choses.

Décision : Si vous avez besoin de modules tiers ou que vous n’êtes pas prêt à enregistrer des clés, envisagez de désactiver Secure Boot. Si c’est un portable d’entreprise soumis à une politique, ne luttez pas contre la politique du firmware — utilisez plutôt une VM.

Tâche 5 : Récupérer les entrées de démarrage EFI actuelles (pour pouvoir récupérer plus tard)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0001* Windows Boot Manager  HD(1,GPT,...)File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0002* UEFI: SanDisk, Partition 1  PciRoot(...)USB(...)HD(1,...)File(\EFI\BOOT\BOOTX64.EFI)
Boot0003* UEFI OS  HD(1,GPT,...)File(\EFI\debian\grubx64.efi)

Ce que ça signifie : La machine démarre actuellement via « UEFI OS » pointant vers un chemin GRUB de style Debian. Windows Boot Manager est toujours présent.

Décision : Sauvegardez cette sortie (photo, notes). Si les entrées de démarrage disparaissent, vous les recréerez.

Tâche 6 : Vérifier la RAM disponible et les signaux de santé du disque

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi       2.1Gi       9.8Gi       200Mi       3.1Gi        12Gi
Swap:            0B          0B          0B

Ce que ça signifie : Beaucoup de mémoire pour l’installation et les futures toolchains. Peu de RAM rend certaines installations de bureau pénibles et vous oriente vers des environnements plus légers.

Décision : Si vous avez 8 GiB ou moins, envisagez un bureau plus léger ou une VM avec ressources ajustées.

cr0x@server:~$ sudo smartctl -H /dev/nvme0n1
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.0-amd64] (local build)
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Ce que ça signifie : La santé du disque est OK. Si SMART échoue, n’installez rien. Remplacez d’abord le disque.

Décision : Tout avertissement SMART est un panneau arrêt, pas une suggestion.

Vérifiez l’ISO et créez une clé USB qui ne vous mentira pas

« L’installateur a planté » veut souvent dire « la clé USB est de la merde » ou « le téléchargement ISO était corrompu ». Vous allez vérifier les deux. Oui, même si vous avez une connexion rapide. Surtout si vous avez une connexion rapide.

Tâche 7 : Vérifier la somme de contrôle de l’ISO

cr0x@server:~$ sha256sum kali-linux-2025.4-installer-amd64.iso
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  kali-linux-2025.4-installer-amd64.iso

Ce que ça signifie : Vous obtenez un hash SHA-256. Vous devez le comparer au hash officiel publié pour ce fichier exact. Si ça ne correspond pas, n’écrivez pas l’image sur la clé USB.

Décision : Incompatibilité signifie retélécharger ; incompatibilité répétée signifie que votre miroir ou votre stockage est suspect.

Tâche 8 : Identifier le périphérique USB avant d’écrire

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,TRAN
NAME      SIZE MODEL               TRAN
nvme0n1 476.9G SAMSUNG MZVLQ512H   nvme
sda      57.3G SanDisk Ultra USB   usb

Ce que ça signifie : La clé USB est /dev/sda. Pas /dev/sda1. Le disque entier.

Décision : Si vous n’êtes pas à 110 % sûr du périphérique USB, débranchez-le et relancez la commande.

Tâche 9 : Écrire l’ISO avec dd (prudemment) et sync

cr0x@server:~$ sudo dd if=kali-linux-2025.4-installer-amd64.iso of=/dev/sda bs=4M status=progress conv=fsync
1736441856 bytes (1.7 GB, 1.6 GiB) copied, 12 s, 145 MB/s
...
4700000000 bytes (4.7 GB, 4.4 GiB) copied, 38 s, 124 MB/s

Ce que ça signifie : Les données ont été écrites directement sur le périphérique USB. conv=fsync force un vidage pour que vous n’éjectiez pas la clé trop tôt et ne créiez pas une clé qui « boot parfois ».

Décision : Si la vitesse d’écriture est très instable ou si des erreurs surviennent, utilisez une autre clé USB. Les médias bon marché sont les tueurs silencieux des projets du week-end.

Blague #1 : Si votre clé USB était gratuite à une conférence, elle est là pour vous enseigner l’ingénierie de la résilience.

Tâche 10 : Valider le média écrit (contrôle ponctuel, pas parfait mais utile)

cr0x@server:~$ sudo cmp -n 1048576 kali-linux-2025.4-installer-amd64.iso /dev/sda && echo "First 1MiB matches"
First 1MiB matches

Ce que ça signifie : Le premier 1 MiB correspond à l’ISO. Cela ne prouve pas que la clé soit parfaite sur toute sa longueur, mais ça attrape rapidement les échecs d’écriture courants.

Décision : Si ça échoue, réécrivez ; si ça échoue deux fois, remplacez la clé.

Paramètres UEFI/BIOS : Secure Boot, TPM et l’ordre réel de démarrage

Les réglages du firmware sont l’endroit où les portables vont cacher des problèmes. Votre objectif est un démarrage stable, pas une adhésion religieuse aux valeurs par défaut.

Secure Boot : choisissez délibérément

Si vous voulez l’expérience la plus simple, désactivez Secure Boot pour Kali. Si vous devez garder Secure Boot activé pour la politique, préparez-vous à passer du temps sur les noyaux/modules signés et éventuellement l’enregistrement MOK.

Position pratique : pour un portable personnel, désactivez Secure Boot à moins que vous en ayez besoin et compreniez la signature des modules. Pour un portable d’entreprise, n’installez pas Kali sur la machine bare metal à moins d’être autorisé et prêt pour les conséquences politiques.

TPM et BitLocker (réalité du dual-boot Windows)

Sur les systèmes Windows avec BitLocker, changer la configuration de démarrage peut déclencher des invites de clé de récupération. Ce n’est pas un problème Kali ; c’est Windows qui protège. Récupérez et stockez votre clé de récupération avant de modifier les partitions ou le chargeur de démarrage.

Fast Boot et les bizarreries « Windows Modern Standby »

Désactivez Windows Fast Startup avant un dual-boot. Il peut laisser NTFS en état d’hibernation et faire voir à Linux un disque « dirty ». Cela mène à des montages en lecture seule, ou pire, à un montage forcé et à la corruption du système de fichiers.

Ordre de démarrage : n’y faites pas confiance, gérez-le

L’ordre de démarrage UEFI n’est pas un contrat. Les mises à jour du firmware et du système d’exploitation le réécrivent. La stratégie de sécurité : gardez un ESP propre, conservez Windows Boot Manager intact, et assurez-vous de pouvoir sélectionner manuellement l’entrée de démarrage depuis le menu firmware.

Schéma de disque qui survit aux mises à jour (et à votre futur vous)

Le meilleur schéma de disque est celui que vous pouvez expliquer sous stress. Vous voulez simple, nommé, et récupérable. La complexité convient aux serveurs ; les portables sont l’endroit où la complexité vient mourir.

Schémas recommandés

Schéma 1 : Kali seul (UEFI) avec chiffrement

• ESP (existant ou nouveau) : 512 MiB, FAT32, monté sur /boot/efi
• /boot : 1 GiB, ext4 (non chiffré, requis pour certains setups)
• Conteneur LUKS : le reste du disque
• À l’intérieur de LUKS : LVM (optionnel) ou partitions simples pour / et swap

Pourquoi : c’est prévisible. Le démarrage reste démarrable ; la racine est chiffrée.

Schéma 2 : Dual-boot avec Windows (UEFI) et Kali chiffré

• Conservez l’ESP existant utilisé par Windows
• Réduisez la partition Windows depuis Windows (pas depuis Linux)
• Créez les partitions Kali dans l’espace libéré : /boot + racine chiffrée

Pourquoi : réduire NTFS depuis Windows réduit le risque. Conserver un seul ESP évite la confusion du firmware.

Choix du système de fichiers : ext4 vs btrfs

Ext4 est le défaut « ennuyeux mais correct » pour un portable Kali. Les snapshots btrfs sont agréables, mais ils ajoutent une couche supplémentaire à déboguer quand vous essayez de réparer un boot cassé en urgence.

Tâche 11 : Valider l’espace libre et les partitions Windows (dual-boot)

cr0x@server:~$ sudo ntfsresize --info --force /dev/nvme0n1p3
ntfsresize v2022.10.3 (libntfs-3g)
Device name        : /dev/nvme0n1p3
NTFS volume version: 3.1
Cluster size       : 4096 bytes
Current volume size: 322122543104 bytes (322123 MB)
Current device size: 322122547200 bytes (322123 MB)
Checking filesystem consistency ...
Accounting clusters ...
You might resize at 250000 MB or above.

Ce que ça signifie : Il donne une estimation de taille minimale sûre. Vous devriez toujours réduire depuis Windows Disk Management, mais ceci vous donne une vérification de sanity.

Décision : Si le système de fichiers est incohérent, démarrez Windows et lancez une vérification du système de fichiers. Ne forcez pas les changements depuis Linux.

Étapes d’installation pour éviter « oups, mauvais disque »

Quand vous démarrez l’installateur depuis la clé USB, choisissez le mode d’installation que vous voulez vraiment. L’installateur graphique est correct. La sécurité vient de vos décisions de disque, pas du thème de l’UI.

Avant de cliquer sur « continuer » au partitionnement

Revérifiez l’identité du disque. Encore. Faites comme si vous réalisiez une chirurgie et que le patient avait deux reins identiques.

Tâche 12 : Confirmer le disque cible par le chemin persistant

cr0x@server:~$ ls -l /dev/disk/by-id/ | sed -n '1,20p'
total 0
lrwxrwxrwx 1 root root  13 Feb  5 10:12 nvme-SAMSUNG_MZVLQ512HBLU-00B00_S4G9NX0R123456 -> ../../nvme0n1
lrwxrwxrwx 1 root root  10 Feb  5 10:12 usb-SanDisk_Ultra_USB_4C530001230105114103-0:0 -> ../../sda

Ce que ça signifie : Le NVMe interne a un chemin by-id stable. C’est ainsi que vous vous assurez de ne pas confondre /dev/sda et /dev/nvme0n1 quand les périphériques se réordonnent.

Décision : Si vous avez plusieurs disques internes, choisissez par-id quand un outil le permet. Sinon, au moins vérifiez modèle et taille de façon répétée.

Partitionnement : faites-le manuellement si vous dual-bootez

Le partitionnement guidé est pratique et dangereux quand vous avez des données qui comptent. Pour le dual-boot, utilisez le partitionnement manuel pour garder intactes les partitions Windows.

Cible d’installation de GRUB : soyez explicite

Sur les systèmes UEFI, GRUB s’installe dans l’ESP et enregistre une entrée EFI. Si vous choisissez le mauvais ESP (disques externes, anciens ESP, partitions constructeur), vous obtenez un système qui ne démarre que lorsque la clé USB est insérée. C’est une blague mignonne une fois.

Tâche 13 : Après l’installation, confirmez le montage et le contenu de l’ESP

cr0x@server:~$ findmnt /boot/efi
TARGET    SOURCE         FSTYPE OPTIONS
/boot/efi /dev/nvme0n1p1 vfat   rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro

Ce que ça signifie : L’ESP est monté là où on l’attend. Si c’est manquant, les mises à jour du chargeur de démarrage peuvent s’installer nulle part, et votre prochain reboot devient une chasse au trésor.

Décision : Si l’ESP n’est pas monté, corrigez /etc/fstab avant toute autre action.

Tâche 14 : Confirmer que le répertoire EFI contient des entrées pour Kali/GRUB et Windows

cr0x@server:~$ sudo ls -R /boot/efi/EFI | sed -n '1,80p'
/boot/efi/EFI:
BOOT
Microsoft
kali

/boot/efi/EFI/Microsoft:
Boot

/boot/efi/EFI/kali:
grubx64.efi
shimx64.efi

Ce que ça signifie : Les deux entrées Windows et Kali existent. Si Microsoft manque sur une machine dual-boot, vous avez peut-être écrasé ou reformaté l’ESP — récupérable, mais pénible.

Décision : Si l’ESP a été reformaté, restaurez les fichiers de démarrage Windows avant de vous déclarer victorieux.

Chiffrement intégral du disque, fait raisonnablement

Le chiffrement n’est pas optionnel sur un portable qui sort de chez vous. Modèle de menace : vol, perte, « prêté pour cinq minutes ». Mais le chiffrement doit être démarrable et maintenable, sinon vous le désactiverez plus tard par frustration.

Ce qu’il faut chiffrer (et ce qu’il ne faut pas)

Chiffrez / et le swap. Gardez l’ESP non chiffré (obligatoire). Gardez /boot non chiffré dans la plupart des setups pour simplifier les mises à jour du noyau. Oui, un attaquant peut voir votre noyau et l’initramfs. Il ne pourra toujours pas lire vos fichiers sans la phrase de passe.

Stratégie de phrase de passe

Utilisez une phrase de passe longue que vous pouvez taper sur un clavier de portable pourri dans un aéroport. Si vous dépendez d’un gestionnaire de mots de passe qui nécessite que le portable ait démarré, vous avez créé un paradoxe élégant.

Tâche 15 : Confirmer que LUKS est utilisé et mappé correctement

cr0x@server:~$ sudo lsblk -o NAME,TYPE,FSTYPE,SIZE,MOUNTPOINTS
NAME               TYPE  FSTYPE      SIZE MOUNTPOINTS
nvme0n1             disk             476.9G
├─nvme0n1p1         part  vfat        512M /boot/efi
├─nvme0n1p2         part  ext4          1G /boot
└─nvme0n1p3         part  crypto_LUKS 475.4G
  └─cryptroot       crypt LVM2_member 475.4G
    ├─vgkali-root   lvm   ext4         60G /
    ├─vgkali-home   lvm   ext4        380G /home
    └─vgkali-swap   lvm   swap         35G [SWAP]

Ce que ça signifie : Root et /home sont à l’intérieur de LUKS. ESP et /boot sont séparés et lisibles. Voilà à quoi ressemble un chiffrement portable « raisonnable ».

Décision : Si vous voyez votre filesystem racine monté directement depuis /dev/nvme0n1pX sans crypto_LUKS, vous n’êtes pas chiffré. Réparez-le plutôt tôt que « plus tard ».

Tâche 16 : Vérifier que l’initramfs connaît le chiffrement

cr0x@server:~$ grep -E 'cryptroot|crypt' /etc/crypttab
cryptroot UUID=11111111-2222-3333-4444-555555555555 none luks,discard

Ce que ça signifie : /etc/crypttab définit le volume chiffré. Si c’est manquant ou incorrect, vous serez lâché dans un shell initramfs au démarrage.

Décision : Si vous avez changé des partitions après l’installation, mettez à jour les UUID et rebuild l’initramfs.

Durcissement post-installation et contrôles de sanity

Kali est une boîte à outils. Votre portable est une station de travail. Mariez-les de façon responsable.

Tâche 17 : Mettre à jour les paquets et confirmer la santé des dépôts

cr0x@server:~$ sudo apt update
Hit:1 http://http.kali.org/kali kali-rolling InRelease
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.

Ce que ça signifie : Le dépôt est joignable, les métadonnées sont valides. Si vous voyez des erreurs de signature, des noms de release incorrects ou des 404, ne procédez pas aux upgrades.

Décision : Corrigez la configuration des dépôts avant apt full-upgrade.

Tâche 18 : Mettre à jour prudemment et surveiller la sortie noyau/initramfs

cr0x@server:~$ sudo apt full-upgrade -y
...
update-initramfs: Generating /boot/initrd.img-6.6.0-kali1-amd64
...
done

Ce que ça signifie : Si la génération d’initramfs échoue, vous pouvez encore démarrer aujourd’hui, mais vous êtes à un reboot d’un mauvais moment.

Décision : Toute erreur d’initramfs : arrêtez-vous, lisez les logs, corrigez et relancez.

Tâche 19 : Confirmer les entrées du menu GRUB (surtout en dual-boot)

cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.6.0-kali1-amd64
Found initrd image: /boot/initrd.img-6.6.0-kali1-amd64
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
done

Ce que ça signifie : GRUB voit Windows Boot Manager. Si ce n’est pas le cas, le dual-boot se limitera au menu firmware.

Décision : Si Windows n’est pas trouvé, vérifiez le montage de l’ESP, puis relancez.

Tâche 20 : Vérifier les firmwares manquants (le Wi‑Fi est le suspect habituel)

cr0x@server:~$ dmesg -T | grep -i firmware | tail -n 10
[Wed Feb  5 10:44:12 2026] iwlwifi 0000:00:14.3: loaded firmware version 89.202a2f7b.0

Ce que ça signifie : Le firmware s’est chargé avec succès. Si vous voyez « failed to load firmware », ne vous attendez pas à avoir du Wi‑Fi avant d’installer les paquets firmware ou d’utiliser Ethernet.

Décision : Si le firmware échoue, prévoyez d’abord une mise à jour filaire. Ne déboguez pas le Wi‑Fi sans logs.

Tâche 21 : Confirmer les bases réseau (DNS et route par défaut)

cr0x@server:~$ ip route
default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.50 metric 600
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.50 metric 600

Ce que ça signifie : Une route par défaut existe. Sans elle, la navigation et les installations de paquets échoueront même si le Wi‑Fi « se connecte ».

Décision : Pas de route par défaut : corrigez DHCP ou NetworkManager avant de blâmer apt.

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

Ce que ça signifie : La configuration du résolveur DNS est présente. Si le DNS est incorrect, apt échouera avec « Temporary failure resolving ».

Décision : Si le DNS pointe nulle part d’utile, corrigez les paramètres réseau ou votre routeur.

Tâche 22 : Confirmer la synchronisation horaire (TLS déteste les horloges erronées)

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

Ce que ça signifie : L’horloge est synchronisée. Une heure incorrecte provoque des échecs de validation TLS qui ressemblent à un « dépôt cassé ».

Décision : Si non synchronisé, corrigez NTP avant de déboguer les signatures apt.

Tâche 23 : Confirmer l’utilisation du disque et la marge d’inodes

cr0x@server:~$ df -hT / /boot /boot/efi
Filesystem           Type  Size  Used Avail Use% Mounted on
/dev/mapper/vgkali-root ext4   60G   12G   45G  22% /
/dev/nvme0n1p2        ext4 1020M  220M  730M  24% /boot
/dev/nvme0n1p1        vfat  511M   18M  494M   4% /boot/efi

Ce que ça signifie : Assez d’espace libre. Si /boot est minuscule et se remplit, les mises à jour du noyau échouent et votre prochain reboot peut casser.

Décision : Si /boot est sous ~500 MiB, augmentez-le ou nettoyez agressivement les anciens noyaux.

Tâche 24 : Confirmer le support TRIM (longévité et performances SSD)

cr0x@server:~$ systemctl status fstrim.timer | sed -n '1,20p'
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; preset: enabled)
     Active: active (waiting) since Wed 2026-02-05 10:52:03 UTC; 1min ago

Ce que ça signifie : TRIM hebdomadaire est activé. Sur SSDs/NVMe, cela aide à maintenir les performances.

Décision : Si désactivé, activez-le sauf si vous avez une configuration de stockage niche qui entre en conflit.

Trois mini-histoires en entreprise (la douleur, en trois saveurs)

1) L’incident causé par une mauvaise hypothèse

Dans une entreprise de taille moyenne, un ingénieur sécurité voulait un portable Kali portable pour des évaluations sur site. Il avait un nouveau portable avec un NVMe interne et une station d’accueil USB-C « utile » qui incluait un petit SSD SATA pour les sauvegardes.

Dans l’installateur, la sélection des disques montrait deux disques de tailles similaires. L’ingénieur a supposé que le NVMe serait toujours /dev/nvme0n1 et que la station serait /dev/sda. Sur ce modèle, la station s’est énumérée plus tôt et les noms ont été inversés. L’installateur a fait exactement ce qu’on lui a dit. Le disque interne a survécu. La station n’a pas survécu. Ce disque de station contenait la seule copie des notes d’engagement et des captures de paquets de la semaine.

Le mode de défaillance n’était pas « Kali a mangé mes données ». C’était « les noms de périphériques ne sont pas stables ». Les nœuds de périphériques Linux sont une couche de commodité, pas une identité. La correction était ennuyeuse : confirmer toujours par modèle/serial via /dev/disk/by-id, et déconnecter physiquement tout stockage non essentiel lors de l’installation. Aussi : ne stockez pas la seule copie de données critiques sur un disque de station que vous reformatez facilement.

Après cela, l’équipe a adopté une norme : retirer tous les stockages externes avant les installations, garder les données d’engagement dans un emplacement distant versionné, et étiqueter les disques internes dans le suivi d’actifs avec modèle et taille pour que les humains puissent faire correspondre ce qu’ils voient à l’écran.

2) L’optimisation qui s’est retournée contre eux

Une autre organisation voulait un démarrage plus rapide et une meilleure endurance SSD sur une flotte de portables Linux. Quelqu’un a proposé d’activer des options de montage agressives, incluant discard partout et un ensemble de paramètres noyau « performance » empruntés à un post de forum. C’était de bonne intention. Cela a aussi introduit une nouvelle classe de délais intermittents au démarrage.

Sur certains NVMe, le discard continu sous de lourds patterns d’écriture causait des pics de latence. Ces pics étaient invisibles au quotidien — jusqu’à ce que initramfs doive déverrouiller LUKS rapidement lors du boot. Parfois ça marchait. Parfois c’était assez long pour que des utilisateurs impatients coupent l’alimentation, ce qui conduisait de façon prévisible à des vérifications de système de fichiers et à de la corruption occasionnelle au reboot suivant.

L’équipe a appris la leçon durement : les optimisations qui touchent à la latence du stockage peuvent devenir des problèmes de fiabilité de boot, pas seulement des réglages de performance. Ils ont rollbacké vers un fstrim.timer hebdomadaire, retiré les paramètres noyau douteux, et standardisé un petit ensemble de réglages connus bons.

Le résultat final était peu glamour : un peu moins d’optimisation théorique SSD, beaucoup moins de tickets « mon portable est coincé au démarrage », et une équipe qui a arrêté d’envoyer la sagesse de forum en images de production.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société de conseil devait supporter des consultants en déplacement avec des portables dual-boot. Ils n’avaient pas le droit de perdre l’accès Windows car les outils VPN et le contrôle endpoint vivaient là. Le côté Linux servait à des tests contrôlés dans des environnements isolés.

La firme a imposé une pratique simple : avant tout changement d’OS, prendre une photo des entrées EFI (efibootmgr -v), exporter les clés de récupération BitLocker, et garder une clé USB de secours bootable avec un toolkit connu bon. Ils exigeaient aussi que l’ESP ne soit jamais reformaté sauf si la machine était reimagée complètement.

Un jour, une mise à jour firmware a réinitialisé l’ordre de démarrage et effacé une entrée EFI non-Microsoft. Le portable a démarré directement sur Windows et la panique « Linux a disparu » a commencé. Mais il n’avait pas disparu. Les partitions disques étaient intactes. En utilisant les données d’entrée sauvegardées, l’ingénieur support a recréé l’entrée manquante et restauré GRUB en moins d’une heure, guidant l’utilisateur à distance via le menu firmware et une courte session de réparation.

Pas d’héroïsme. Pas de « récupération forensique ». Juste une habitude ennuyeuse : capturer l’état avant les changements, et garder le chemin de récupération testé. Le type de pratique qui semble inutile jusqu’à ce que ce soit la seule raison pour laquelle vous prenez votre vol.

Blague #2 : Le meilleur plan de reprise après sinistre est celui que vous testez avant le sinistre. Le deuxième meilleur est celui que vous retrouvez encore dans votre dossier Téléchargements.

Playbook de diagnostic rapide

Quand quelque chose échoue après l’installation, ne thrash pas. Vous voulez localiser rapidement le goulot : firmware/démarrage, disque/chiffrement, noyau/modules, ou réseau/dépôts. Voici l’ordre qui gagne la plupart du temps.

Première étape : le firmware voit-il une entrée bootable ?

• Si la machine n’atteint jamais GRUB : ouvrez le menu de démarrage firmware et vérifiez si Windows Boot Manager et une entrée Linux existent.
• Si l’entrée Linux manque : démarrez l’USB installateur en mode « live/rescue » et lancez efibootmgr -v pour inspecter les entrées.

Deuxième étape : l’ESP est-elle montée et peuplée ?

• Démarrez dans l’environnement de secours, montez le filesystem root, puis confirmez que /boot/efi/EFI contient les bons répertoires.
• Les problèmes de montage d’ESP causent des « ça marchait hier, maintenant non » après des mises à jour.

Troisième étape : le chiffrement se déverrouille-t-il correctement ?

• Si vous atterrissez dans initramfs avec « cannot find cryptroot » : vérifiez /etc/crypttab et les UUID, puis rebuild initramfs.
• Si on demande la phrase de passe mais que ça échoue : suspectez un changement de disposition de clavier ou un header endommagé (rare mais réel).

Quatrième étape : est-ce un problème noyau/modules ?

• Essayez de démarrer un ancien noyau depuis le menu avancé GRUB.
• Si le graphique échoue, démarrez avec un mode basique (nomodeset) temporairement et installez les pilotes GPU correctement ensuite.

Cinquième étape : le problème est-il en réalité réseau/DNS/heure ?

• Les échecs apt viennent souvent du DNS ou de la dérive horaire.
• Vérifiez ip route, resolvectl status, timedatectl.

Bundle de commandes de triage rapide

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0001
Boot0001* Windows Boot Manager  HD(1,GPT,...)File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0002* kali  HD(1,GPT,...)File(\EFI\kali\grubx64.efi)

Décision : Si l’entrée Kali est manquante, vous réparez le boot. Si elle existe, vous descendez la pile.

cr0x@server:~$ lsblk -f
NAME        FSTYPE      FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat        FAT32       AAAA-BBBB                            494.2M     4% /boot/efi
├─nvme0n1p2 ext4        1.0         1111-2222-3333-4444                    730M    24% /boot
└─nvme0n1p3 crypto_LUKS 2           5555-6666-7777-8888
  └─cryptroot LVM2_member LVM2       9999-aaaa-bbbb-cccc

Décision : Si crypto_LUKS n’est pas présent là où vous l’attendez, vous êtes dans le mauvais environnement de boot ou la table de partitions a changé.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom : « Aucun périphérique bootable » après l’installation

Cause racine : Installé en mode legacy sur un disque UEFI, ou l’entrée EFI n’a pas été créée, ou l’ordre de boot firmware a changé.

Correction : Démarrez l’USB installateur en mode UEFI. En rescue, assurez-vous que l’ESP est monté sur /boot/efi, réinstallez GRUB pour UEFI, et recréez l’entrée EFI si nécessaire.

2) Symptom : Démarre seulement quand la clé USB est insérée

Cause racine : GRUB a été installé sur l’ESP de la clé USB ou sur un chemin média amovible, pas sur l’ESP interne.

Correction : Démarrez sans la clé USB dans le menu firmware ; si aucune entrée Linux n’apparaît, utilisez l’environnement rescue pour installer GRUB sur l’ESP interne et exécutez efibootmgr pour l’enregistrer.

3) Symptom : Tombé dans initramfs avec « cannot find /dev/mapper/cryptroot »

Cause racine : UUID erroné dans /etc/crypttab ou /etc/fstab, ou initramfs non reconstruit après changements.

Correction : En rescue, trouvez l’UUID correct via blkid, mettez à jour les fichiers, puis lancez update-initramfs -u et update-grub.

4) Symptom : Kali démarre, mais Windows manque dans le menu GRUB

Cause racine : ESP non monté pendant update-grub, os-prober désactivé, ou fichiers de démarrage Windows absents de l’ESP que vous utilisez.

Correction : Montez l’ESP, vérifiez que /boot/efi/EFI/Microsoft existe, activez os-prober si approprié, relancez update-grub. Autrement, utilisez le menu firmware comme solution temporaire.

5) Symptom : Le Wi‑Fi existe mais ne se connecte pas ; ou périphérique Wi‑Fi manquant

Cause racine : Firmware manquant, rfkill soft/hard block, ou module driver incompatible après mise à jour du noyau.

Correction : Vérifiez dmesg pour les erreurs de firmware, lancez rfkill list, installez les paquets firmware adéquats via Ethernet, puis redémarrez.

6) Symptom : Apt échoue avec erreurs de certificat ou signature

Cause racine : Heure système incorrecte ou DNS/route cassés.

Correction : Confirmez timedatectl sync, vérifiez ip route et resolvectl status. Corrigez le réseau et NTP d’abord, puis relancez apt update.

7) Symptom : Les mises à jour du noyau échouent avec « No space left on device »

Cause racine : Partition /boot trop petite remplie par d’anciens noyaux.

Correction : Supprimez les noyaux anciens, augmentez la taille de /boot si possible, et surveillez-la avec df -h.

8) Symptom : Windows demande la clé de récupération BitLocker après l’installation

Cause racine : Changements dans la chaîne de démarrage (GRUB, ordre EFI) qui ont déclenché la protection BitLocker.

Correction : Utilisez la clé de récupération (vous l’avez sauvegardée, n’est-ce pas ?), puis sous Windows suspendez et réactivez BitLocker après avoir stabilisé la configuration de démarrage.

Tâche 25 : Vérifier l’état rfkill (test rapide Wi‑Fi)

cr0x@server:~$ rfkill list
0: wlan: Wireless LAN
	Soft blocked: no
	Hard blocked: no

Ce que ça signifie : Pas bloqué. Si hard blocked est yes, vous avez probablement un interrupteur physique ou un réglage firmware qui désactive la radio.

Décision : Hard blocked = arrêtez de déboguer les pilotes et cherchez un interrupteur matériel/option firmware.

Tâche 26 : Confirmer les modules noyau chargés pour le Wi‑Fi (exemple)

cr0x@server:~$ lsmod | grep -E '^iwlwifi|^ath9k|^brcmfmac' | head
iwlwifi               438272  1
cfg80211             1122304  2 iwlwifi,mac80211

Ce que ça signifie : Le driver est chargé. Si rien n’apparaît, le périphérique peut ne pas être détecté ou le firmware manquant.

Décision : Module chargé mais pas de connectivité : regardez les logs NetworkManager et le domaine réglementaire ; pas de module : identifiez le périphérique PCI et le driver.

Checklists / plan pas-à-pas

Plan A (meilleur pour la plupart) : Kali dans une VM

1. Installez un hyperviseur sur votre OS hôte stable.
2. Allouez des ressources réalistes (2–4 cœurs, 4–8 GiB RAM au départ, 40–80 GiB disque).
3. Utilisez NAT pour le réseau sauf si vous avez besoin d’un mode bridge pour le réalisme lab.
4. Prenez un snapshot juste après la configuration initiale et les mises à jour.
5. Gardez vos outils offensifs dans la VM, pas sur l’hôte.

Pourquoi c’est sûr : snapshots et séparation. Si vous cassez Kali, vous ne cassez pas votre portable.

Plan B : Dual-boot Kali + Windows (la méthode plutôt sûre)

1. Sauvegarde : Copiez les données critiques hors du portable. Validez la sauvegarde en ouvrant les fichiers sur une autre machine.
2. BitLocker : Exportez les clés de récupération et stockez-les hors du portable.
3. Préparation Windows : Désactivez Fast Startup et réduisez la partition Windows depuis Windows.
4. Firmware : Confirmez le mode UEFI ; décidez de la politique Secure Boot.
5. USB : Vérifiez la somme de contrôle ISO, écrivez la clé, validez par spot-check.
6. Installation : Partitionnement manuel ; conservez l’ESP existant ; créez /boot + racine chiffrée dans l’espace libre.
7. Chargeur : Installez GRUB sur l’ESP interne ; vérifiez que /boot/efi/EFI contient les deux entrées OS.
8. Post-install : Mettez à jour les paquets ; lancez update-grub ; confirmez que Windows est détecté.
9. Récupération : Gardez l’USB à portée ; stockez la sortie de efibootmgr -v dans vos notes.

Plan C : Kali seul sur le bare metal (machine dédiée)

1. Sauvegardez tout. Puis faites comme si vous ne l’aviez pas fait et sauvegardez encore.
2. Déconnectez tout stockage externe.
3. Utilisez UEFI + GPT.
4. Créez ESP (si nécessaire), /boot, et racine chiffrée.
5. Après l’installation, vérifiez le timer TRIM et la santé du disque, puis mettez à jour les paquets.

Checklist de récupération (quand ça ne boote pas)

1. Essayez le menu firmware : pouvez-vous démarrer Windows ? voyez-vous une entrée Kali ?
2. Démarrez l’USB installateur en mode UEFI.
3. Vérifiez la carte des disques avec lsblk et confirmez le chiffrement via lsblk -f.
4. Montez correctement root + boot + ESP.
5. Réinstallez GRUB et régénérez la configuration.
6. Rebuild initramfs si le chiffrement ou les UUID ont changé.

Tâche 27 : Trouver les périphériques PCI (utile pour les pilotes)

cr0x@server:~$ lspci -nn | sed -n '1,25p'
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:9a14]
00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:9a49]
00:14.3 Network controller [0280]: Intel Corporation Wi-Fi 6 AX201 [8086:06f0]

Ce que ça signifie : Vous pouvez identifier le matériel par vendor/device IDs. Cela vous dit quelle famille de driver/firmware concerne le périphérique.

Décision : Si vous ne voyez pas le périphérique du tout, c’est un toggle firmware/BIOS ou une panne matérielle — pas un paquet manquant.

Tâche 28 : Monter correctement les partitions en mode rescue (séquence exemple)

cr0x@server:~$ sudo mount /dev/mapper/vgkali-root /mnt
cr0x@server:~$ sudo mount /dev/nvme0n1p2 /mnt/boot
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
cr0x@server:~$ findmnt /mnt/boot/efi
TARGET          SOURCE         FSTYPE OPTIONS
/mnt/boot/efi   /dev/nvme0n1p1 vfat   rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro

Ce que ça signifie : Root, /boot et l’ESP sont montés aux bons emplacements sous /mnt. C’est requis avant de réparer GRUB depuis chroot.

Décision : Si vous montez l’ESP ailleurs (ou pas du tout), la réparation GRUB « réussira » mais ne tiendra pas.

Tâche 29 : Chroot et réparation GRUB (UEFI)

cr0x@server:~$ sudo mount --bind /dev /mnt/dev
cr0x@server:~$ sudo mount --bind /proc /mnt/proc
cr0x@server:~$ sudo mount --bind /sys /mnt/sys
cr0x@server:~$ sudo chroot /mnt /bin/bash
cr0x@server:~$ grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=kali
Installing for x86_64-efi platform.
Installation finished. No error reported.
cr0x@server:~$ update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.6.0-kali1-amd64
Found initrd image: /boot/initrd.img-6.6.0-kali1-amd64
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
done

Ce que ça signifie : GRUB installé sur l’ESP et la config régénérée. Si Windows est trouvé, le dual-boot devrait revenir.

Décision : Si grub-install renvoie une erreur, vérifiez que l’ESP est FAT32 et monté, et que vous avez booté l’USB en mode UEFI.

Tâche 30 : Rebuild initramfs après modifications de crypt

cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.6.0-kali1-amd64

Ce que ça signifie : Initramfs reconstruit pour les noyaux installés. C’est ce qui rend disponibles l’encryption et les modules de stockage pendant le boot précoce.

Décision : Si ça échoue, corrigez avant de redémarrer. Redémarrer n’est pas un outil de diagnostic ; c’est une conséquence.

Tâche 31 : Recréer une entrée EFI manquante (si le firmware l’a « oubliée »)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "kali" -l '\EFI\kali\grubx64.efi'
BootCurrent: 0002
BootOrder: 0004,0001,0002
Boot0004* kali

Ce que ça signifie : Vous avez créé une nouvelle entrée EFI pointant sur le binaire GRUB de Kali sur la partition 1 (ESP).

Décision : Si le chemin est erroné, le boot échouera silencieusement. Vérifiez que le fichier existe sous /boot/efi/EFI/kali/.

FAQ

1) Dois-je installer Kali comme OS quotidien ?

Si vous aimez la stabilité, non. Kali est optimisé pour les outils de sécurité et les mises à jour rapides, pas pour être une station de travail conservatrice. Utilisez une VM ou un système stable et gardez Kali contenu sauf raison spécifique.

2) Ai-je besoin d’activer Secure Boot ?

Pas pour l’apprentissage ou la plupart des usages personnels. Secure Boot ajoute de la complexité quand vous installez des modules tiers. Si votre environnement l’exige, prévoyez la signature des modules et des changements noyau plus prudents.

3) Quelle est l’approche la plus sûre pour un dual-boot avec Windows ?

Réduisez Windows depuis Windows. Gardez l’ESP existant. Installez Kali dans l’espace libre avec partitionnement manuel. Vérifiez que Windows Boot Manager reste sur l’ESP et que GRUB le détecte.

4) Pourquoi Windows demande-t-il la clé de récupération BitLocker après l’installation de Kali ?

Parce que la chaîne de démarrage a changé. BitLocker utilise ces signaux pour détecter une altération. Il fait son travail. Utilisez la clé de récupération, puis stabilisez la configuration de démarrage et réactivez BitLocker.

5) ext4 ou btrfs pour Kali ?

Ext4 sauf si vous êtes à l’aise pour déboguer des problèmes de boot impliquant snapshots, sous-volumes et sémantiques de rollback. Btrfs va bien, mais n’ajoutez pas de couches que vous ne pouvez pas dépanner à 1 h du matin.

6) Ai-je besoin d’une partition /boot séparée ?

Pour une racine chiffrée, une /boot non chiffrée séparée est la configuration la plus simple et fiable. Elle réduit les surprises lors des mises à jour du noyau et du boot précoce.

7) Mon Wi‑Fi ne fonctionne pas après l’installation. Kali est-il cassé ?

Probablement firmware manquant ou radio bloquée. Vérifiez dmesg pour les erreurs de firmware et rfkill pour les blocks. Prévoyez d’utiliser Ethernet temporairement pour installer les paquets firmware.

8) L’installateur ne voit pas mon NVMe. Que faire ?

Vérifiez les paramètres du firmware : mode de stockage (AHCI vs RAID/RST), et assurez-vous que l’installateur est booté en mode UEFI. Certains portables sont livrés avec Intel RST/RAID activé, ce qui peut masquer les disques aux installateurs Linux.

9) J’ai installé Kali et maintenant mon portable affiche un écran noir au boot.

Souvent des problèmes de pilote graphique. Essayez de démarrer en mode basique ou ajoutez un paramètre noyau temporaire comme nomodeset pour atteindre une GUI, puis installez les bons pilotes GPU avec précaution.

10) Puis-je installer Kali sur un SSD USB externe et booter depuis là ?

Oui, et cela peut être un bon compromis. Le mode de défaillance est des entrées UEFI pointant vers le disque externe, puis échouant quand il est débranché. Gardez le démarrage interne intact et soyez explicite sur où GRUB est installé.

Prochaines étapes que vous ferez réellement

Si vous voulez le résultat le plus sûr, faites ceci dans l’ordre :

1. Décidez la voie d’installation : VM à moins que vous puissiez justifier le bare metal.
2. Sauvegardez et vérifiez la sauvegarde : validation signifie ouvrir les fichiers ailleurs, pas juste regarder une barre de progression.
3. Enregistrez l’état de démarrage : sauvegardez la sortie de efibootmgr -v et confirmez si Secure Boot est activé.
4. Vérifiez l’ISO et la clé USB : checksum de l’ISO, écriture soigneuse, et spot-check du résultat.
5. Partitionnez avec intention : partitionnement manuel pour le dual-boot ; conservez l’ESP ; chiffrez la racine.
6. Après l’installation : montez correctement l’ESP, mettez à jour, régénérez GRUB, confirmez la détection de Windows, et testez un reboot avant de déclarer « terminé ».

Puis faites l’étape la plus sous-estimée du travail systèmes : redémarrez encore une fois pendant que vous avez encore l’installateur USB sur votre bureau. Si quelque chose casse, vous le réparerez en quelques minutes. Si vous attendez d’être en déplacement, vous le réparerez en heures.