The Installer Tried to Destroy My Storage Design. AI Found a Better Path.

Vers votre Linux : une série en 4 parties

Partie 1 : Choisir votre distribution → Partie 2 : Stockage et chiffrement → Partie 3 : Installation manuelle → Partie 4 : Services et GPU

Imaginez : vous venez de passer deux heures à construire une disposition LVM chiffrée soigneusement conçue. Six volumes logiques, trois disques chiffrés, tout exactement là où il le faut. Puis le programme d'installation de Kali tente d'écraser l'ensemble dans une seule partition ext4.

Le programme d'installation graphique a déjà planté à cause du GPU hybride. Maintenant, le programme d'installation en mode texte cherche activement à défaire votre travail. Vous pourriez vous battre contre lui pendant encore trois heures. Ou vous pourriez décrire le problème à une IA et découvrir quelque chose que vous n'avez probablement pas envisagé : ignorer complètement le programme d'installation et construire le système d'exploitation à la main avec debootstrap. Ce changement de cap sauvera l'ensemble du projet.

Le programme d'installation était censé fonctionner sans accroc

Après avoir passé des heures dans la Partie 2 à concevoir une disposition de stockage LVM chiffrée avec des volumes séparés pour root, swap, docker, ollama, postgres et home, l'étape suivante semble presque ennuyeuse. Lancer le programme d'installation de Kali, choisir le partitionnement manuel, assigner les points de montage, cliquer quelques fois sur suivant, terminé. Vingt minutes, grand maximum.

Cette attente est totalement erronée.

Le programme d'installation graphique plantera immédiatement sur du matériel avec GPU hybride. Une carte graphique intégrée Intel aux côtés d'un GPU discret NVIDIA ? Le programme d'installation graphique ne peut pas gérer le framebuffer hybride. Écrans noirs. Échecs du serveur X. Impasse totale. Pas un seul menu ne s'affiche avant que tout se bloque.

Soit. Place au programme d'installation en mode texte.

Le programme d'installation en mode texte évite le plantage lié au GPU, et pendant un moment les choses semblent prometteuses. Il démarre, détecte le disque NVMe, propose une option de partitionnement manuel. Mais il introduit alors un problème bien pire qu'une interface graphique plantée.

Le moment où il faut s'arrêter

Voici ce qui se passe dans l'écran de partitionnement manuel du programme d'installation en mode texte : il détecte nvme0n1p3_crypt (le conteneur LUKS ouvert) et continue de tenter de le formater en ext4 simple.

Ce n'est pas ce qu'il est. Ce périphérique mappé est censé être un volume physique LVM situé à l'intérieur du conteneur chiffré. Au-dessus de ce PV se trouve un groupe de volumes, et au-dessus de ce VG se trouvent six volumes logiques : root, swap, docker, ollama, postgres et home. Si le programme d'installation écrit directement un système de fichiers ext4 sur nvme0n1p3_crypt, il anéantira l'ensemble de la conception multi-volumes en environ trois secondes.

Décrivez cela à une IA. La réponse sera immédiate et précise :

« Arrêtez. Ne continuez pas. Le programme d'installation interprète mal votre pile de stockage. Il traite votre conteneur LUKS comme une partition brute au lieu de reconnaître la couche LVM à l'intérieur. Si vous le laissez formater, vous perdrez chaque volume logique. »

La partie étrange ? Ouvrez un shell depuis le programme d'installation et exécutez lvs. Chaque volume logique s'affiche parfaitement. L'environnement live comprend la disposition du stockage. L'outil de partitionnement du programme d'installation, lui, ne la comprend pas. Il affiche parfois le conteneur LUKS, parfois le groupe de volumes, mais affiche rarement les volumes logiques réels où les points de montage doivent être définis.

Le schéma est indéniable une fois qu'on sait quoi chercher : le shell live voit tout correctement ; le programme d'installation voit les mauvaises choses. Cela rend le programme d'installation peu fiable pour cette installation.

C'est là que toute l'approche bascule. Cessez de vous demander « comment faire fonctionner le programme d'installation » et commencez à vous demander « comment installer Kali sans le programme d'installation ? »

La voie de l'installation manuelle : debootstrap

La réponse est claire : montez vous-même les systèmes de fichiers cibles, utilisez debootstrap pour télécharger un système de base, effectuez un chroot dedans, et construisez le système d'exploitation à la main.

Ce n'est pas une régression ni un recours désespéré. Pour une installation chiffrée complexe à plusieurs volumes comme celle-ci, c'est en réalité l'approche professionnelle. Voici pourquoi elle est préférable à la lutte avec le programme d'installation :

• Préserve exactement la conception du stockage telle qu'elle a été construite. Aucun programme d'installation ne réinterprète votre disposition.
• Évite complètement l'instabilité de l'interface graphique sur du matériel avec GPU hybride.
• Donne un contrôle total sur la sélection des paquets et la configuration.
• Plus prévisible que de relancer le programme d'installation en espérant qu'il lise correctement le LVM cette fois.

Procédure détaillée, étape par étape

C'est la partie où le processus devient véritablement satisfaisant. Chaque étape est une question posée à l'IA, une réponse, puis une exécution. Voici la séquence complète.

Étape 1 : Monter l'arborescence du système de fichiers cible

Commencez par le volume logique racine, puis superposez tout le reste. L'ordre est important :

1mount /dev/mapper/vg0-root /mnt
2mkdir -p /mnt/boot /mnt/boot/efi /mnt/home
3mkdir -p /mnt/var/lib/docker /mnt/var/lib/ollama /mnt/var/lib/postgresql
4mount /dev/nvme0n1p2 /mnt/boot
5mount /dev/nvme0n1p1 /mnt/boot/efi
6mount /dev/mapper/vg0-home /mnt/home
7mount /dev/mapper/vg0-docker /mnt/var/lib/docker
8mount /dev/mapper/vg0-ollama /mnt/var/lib/ollama
9mount /dev/mapper/vg0-postgres /mnt/var/lib/postgresql

Pourquoi tout monter en premier ? Lorsque debootstrap écrit des fichiers, ils atterrissent sur les volumes cibles corrects dès le départ. Si vous ne montez que root et effectuez le bootstrap, puis montez /home ensuite, vous aurez des artefacts du bootstrap sur le volume root là où /home devrait se trouver.

Étape 2 : Bootstrapper le système de base

debootstrap --arch=amd64 kali-rolling /mnt http://http.kali.org/kali

Avant d'entrer dans le chroot, montez en bind les pseudo-systèmes de fichiers de l'hôte afin que l'environnement chroot puisse interagir avec le matériel et le réseau :

1mount --bind /dev /mnt/dev
2mount --bind /dev/pts /mnt/dev/pts
3mount --bind /proc /mnt/proc
4mount --bind /sys /mnt/sys
5mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars
6cp /etc/resolv.conf /mnt/etc/resolv.conf
7chroot /mnt /bin/bash

Chacun de ces montages bind a un objectif précis : /dev et /dev/pts permettent aux scripts de paquets d'accéder aux périphériques et aux terminaux. /proc et /sys sont nécessaires pour la génération de l'initramfs et la détection des modules du noyau. Le montage des variables EFI est indispensable pour l'installation de GRUB en mode EFI. Et copier resolv.conf donne au chroot la résolution DNS afin que apt puisse effectivement atteindre les dépôts.

Étape 3 : Tout configurer à l'intérieur du chroot

Voici la liste de contrôle de configuration complète, et chaque point est important :

1. Sources apt pointant vers kali-rolling main contrib non-free non-free-firmware
2. Paquets essentiels : linux-image-amd64, systemd, cryptsetup-initramfs, lvm2, grub-efi-amd64
3. Environnement de bureau : xorg, xfce4, lightdm, kali-desktop-xfce
4. Configuration système : nom d'hôte, locale (en_US.UTF-8), fuseau horaire
5. Création d'utilisateur : adduser, ajout au groupe sudo
6. Crypttab et fstab : référençant les UUID corrects pour chaque couche
7. Reconstruction de l'initramfs : update-initramfs -u -k all pour inclure les hooks LUKS et LVM
8. Installation de GRUB : grub-install --target=x86_64-efi --efi-directory=/boot/efi suivi de update-grub

L'ensemble du processus prend environ 45 minutes. Non pas parce qu'il est difficile, mais parce que chaque étape nécessite une attention délibérée. Soumettez chaque étape à l'IA, obtenez les commandes, comprenez le raisonnement, et anticipez les pièges avant qu'ils ne surviennent.

Premier démarrage et la surprise avec sudo

Après le bootstrap, la configuration dans le chroot, la génération de l'initramfs et l'installation de GRUB, vient le moment de vérité. Démontez tout dans l'ordre inverse, retirez la clé USB, redémarrez.

Le premier démarrage fonctionne. L'invite de saisie de la phrase secrète LUKS apparaît exactement comme prévu. Entrez la phrase secrète, GRUB se charge, Kali démarre, LightDM affiche l'écran de connexion, XFCE s'affiche. Tout ce qui avait échoué avec le programme d'installation graphique fonctionne maintenant parfaitement depuis un système construit à la main.

Mais vient alors une petite surprise agaçante. Votre compte utilisateur ne peut pas exécuter sudo. Chaque commande retourne :

user is not in the sudoers file. This incident will be reported.

Vous avez pourtant bien ajouté l'utilisateur au groupe sudo lors de la configuration dans le chroot. Vous pouvez le vérifier avec groups et voir sudo listé. Alors que se passe-t-il ?

Voici ce qui se passe réellement : la session de connexion en cours n'a pas pris en compte le changement de groupe. L'appartenance aux groupes est évaluée au moment de la connexion. Puisque l'utilisateur a été créé et ajouté à sudo à l'intérieur du chroot mais ne s'est jamais connecté via un gestionnaire de session approprié, la session en cours ne reflète pas cette appartenance. La solution ? Se déconnecter et se reconnecter. C'est tout.

C'est l'un de ces pièges classiques de Linux qui piège aussi bien les débutants que les utilisateurs expérimentés. Vous savez que vous avez ajouté le groupe. Vous pouvez le prouver. Mais le système se moque de ce qui figure dans /etc/group jusqu'à ce que la prochaine connexion l'évalue. Sans qu'une IA le signale immédiatement, vous pourriez facilement perdre une heure à explorer des configurations PAM et des modifications du fichier sudoers pour rien.

L'Incident du Mode d'Urgence

Accrochez-vous. Voici la leçon de débogage la plus précieuse de l'ensemble de la construction en quatre vous, et elle se lit comme un roman policier où chaque indice pointe vers le mauvais suspect.

Après le premier démarrage réussi et quelques travaux de configuration supplémentaires (notamment l'installation des pilotes propriétaires NVIDIA pour le GPU discret), vous redémarrez. Au lieu de l'écran de connexion, vous vous retrouvez en mode d'urgence. Texte rouge. Unités en échec. Une invite shell root vous demandant de comprendre ce qui s'est passé.

La conclusion évidente s'impose immédiatement : « NVIDIA a cassé mon système. » Vous venez d'installer des pilotes GPU. Le système fonctionnait avant. Maintenant, ce n'est plus le cas. Cause et effet, non ?

Faux. Complètement, spectaculairement faux.

Suivez les Preuves, Pas le Récit

Collez la sortie de journalctl et la liste des unités systemctl en échec dans l'IA. Le vers est simple : « Le système est passé en mode d'urgence après l'installation des pilotes NVIDIA. Voici les journaux. Qu'est-ce qui a mal tourné ? »

Observez ce qui se passe ensuite. L'IA ignore entièrement le récit NVIDIA et va droit aux preuves. Les erreurs réelles dans le journal sont :

EXT4-fs (sda1): Can't find ext4 filesystem
EXT4-fs (sdb1): Can't find ext4 filesystem

Ce ne sont pas des erreurs GPU. Ce sont des échecs de montage votre. Le système tente de monter /dev/sda1 et /dev/sdb1 en tant que systèmes de fichiers ext4. Mais sda1 et sdb1 sont des conteneurs test votre. Ils ne contiennent pas directement des systèmes de fichiers ext4. Ils contiennent des données chiffrées qui, une fois ouvertes via cryptsetup, exposent des périphériques mapper contenant des systèmes de fichiers ext4.

Le vrai coupable est /etc/fstab. Les entrées fstab pour les deux stockage de données externes référencent les UUID de partition bruts avec ext4 comme type de système de fichiers. Le système tente de monter des blocs chiffrés comme s'il s'agissait de systèmes de fichiers ordinaires, échoue (évidemment), et comme ils sont listés sans nofail, systemd traite les échecs comme fatals et passe en mode d'urgence.

NVIDIA n'avait rien à voir avec ça. Le timing était une coïncidence. Le fstab était incorrect depuis le début ; il a simplement fallu un redémarrage pour le révéler.

La Correction

Une fois le vrai problème visible, la solution est simple :

1. Mettre à jour /etc/crypttab avec les UUID de partition LUKS corrects pour les deux stockage externes
2. Mettre à jour /etc/fstab pour référencer les UUID des périphériques mapper (pas les UUID de partition bruts) avec les indicateurs nofail
3. Reconstruire l'initramfs pour prendre en compte les modifications de crypttab
4. Redémarrer

Le système démarre proprement. Les pilotes NVIDIA fonctionnent parfaitement. Ils n'ont jamais été le problème.

Diagnostiquer par les Preuves, Pas par le Timing

Voici la leçon qui mérite d'être gravée dans votre mémoire. Pas seulement pour cette construction, mais pour chaque problème linux que vous rencontrerez jamais.

Ce n'est pas parce que quelque chose échoue après l'installation d'un pilote que le pilote en est la cause.

La chronologie raconte une histoire convaincante : installation des pilotes NVIDIA, redémarrage, mode d'urgence. N'importe quelle personne raisonnable blâmerait les pilotes GPU. Internet regorge de messages de forum de personnes qui ont blâmé les pilotes GPU pour exactement ce type d'échec de démarrage. Et la plupart d'entre elles ont probablement reformaté et réinstallé alors que la vraie correction était une modification de deux lignes dans fstab.

La meilleure approche ? Lisez les journaux. Faites confiance aux journaux. Ignorez le récit.

« La corrélation n'est pas la causalité, et le timing n'est pas une preuve. Le journal vous indique ce qui a échoué. Commencez par là, pas par ce que vous avez modifié en dernier. »

Cette discipline de débogage fonctionne partout :

• Le système ne démarre pas ? Vérifiez journalctl -xb pour les unités réellement en échec. Ne supposez pas en vous basant sur ce que vous avez installé hier.
• Un service ne démarre pas ? Lisez les journaux propres au service avant de supposer qu'une dépendance l'a cassé.
• Le réseau est coupé ? Vérifiez ip addr et systemctl status NetworkManager avant de blâmer la modification du pare-feu que vous avez effectuée.

Transmettez vos journaux à l'IA. Laissez-la lire les preuves sans que votre récit ne colore l'analyse. Vous serez surpris de voir à quelle fréquence le vrai problème n'a rien à voir avec ce que vous venez de modifier.

Le Mystère du Disque d'Analyse

Encore une surprise. Après avoir corrigé le montage du disque d'archive, vous essayez d'ouvrir le disque d'analyse (sdb1) avec cryptsetup luksOpen. La phrase secrète est rejetée.

C'est déconcertant. Les deux stockage externes ont été configurés lors des travaux votre de la Partie 2. Le disque d'archive s'ouvre correctement avec sa phrase secrète. Le disque d'analyse refuse.

Examinez les possibilités méthodiquement :

• Mauvaise phrase secrète ? Possible. Lors d'une longue session d'installation avec plusieurs conteneurs LUKS, il est facile de confondre quelle phrase secrète correspond à quel disque.
• Incompatibilité de disposition du clavier ? Si la phrase secrète a été définie lors d'une session USB live avec une disposition de clavier différente de celle du système installé, les caractères spéciaux pourraient être mappés différemment.
• Erreur de saisie lors de la création ? Lorsque vous tapez une phrase secrète à l'aveugle (sans écho) pendant luksFormat, une faute de frappe devient permanente. Vous l'avez confirmée une fois, également à l'aveugle, et êtes passé à autre chose.

L'explication la plus probable est la plus simple : lors de la configuration initiale, avec plusieurs disques chiffrés en séquence, la phrase secrète du disque d'analyse a soit été mal saisie, soit confondue avec une autre.

Voici la leçon pratique : lors de l'installation initiale, utilisez des phrases secrètes temporaires simples pour vos conteneurs LUKS et faites-les pivoter vers des phrases secrètes robustes une fois le système stable. De cette façon, vous ne déboguez pas des mystères de phrases secrètes à 2 h du matin tout en essayant de faire démarrer votre système. Étiquetez également clairement vos disques dans un carnet physique, pas seulement dans votre tête.

Vous Venez de Construire un Système d'Exploitation à la Main

Prenez un moment pour apprécier ce qui vient de se passer ici. L'installateur a essayé de détruire votre conception de votre. Vous l'avez complètement contourné, construit le système d'exploitation à partir de paquets bruts avec debootstrap, et vous vous êtes retrouvé avec un système plus propre et mieux contrôlé que n'importe quel installateur n'aurait produit.

Le mode d'urgence a essayé de vous convaincre que NVIDIA était le coupable. Vous avez lu les journaux, trouvé le vrai coupable caché dans fstab, et l'avez corrigé en deux lignes. C'est le genre d'instinct de débogage qui distingue les personnes qui utilisent linux de celles qui le comprennent vraiment.

Le travail d'infrastructure difficile est terminé. Le votre chiffré est solide, le système de base fonctionne, et chaque échec au démarrage a été traqué et éliminé.

Dans la Partie 4, les choses deviennent amusantes. Conteneurs Docker, le runtime IA Ollama, PostgreSQL, et oui, enfin faire fonctionner NVIDIA CUDA correctement pour que cette machine puisse exécuter des modèles d'IA locaux. Vous avez construit les fondations. Il est maintenant temps de les mettre au travail.