Matériel pris en charge

Ce que LFSi supporte, ce qu'elle ne supporte pas, et pourquoi — une distribution souveraine assume ses limites autant que ses capacités.

Le principe : pas de binaire opaque par défaut

LFSi est construite intégralement depuis les sources, vérifiées et tracées. Cette exigence a une conséquence directe sur le matériel : LFSi n'embarque, par défaut, aucun firmware propriétaire (les « blobs » binaires que certains périphériques chargent à l'initialisation, dont le code source n'est pas public et ne peut donc être ni audité, ni reconstruit).

Ce choix est délibéré : embarquer des blobs opaques réintroduirait dans une image auditable exactement ce que LFSi cherche à éliminer — du code non maîtrisé, non traçable, hors chaîne d'approvisionnement. La contrepartie est claire et assumée : certains matériels qui exigent un firmware externe ne fonctionneront pas tant que ce firmware n'a pas été ajouté explicitement (voir plus bas).

En pratique, la grande majorité du matériel serveur fonctionne sans firmware externe : le firmware y est gravé sur la carte (flash/NVRAM).

Matériel pris en charge

Architectures

Stockage

Contrôleurs SATA/AHCI, SCSI, NVMe, VirtIO (machines virtuelles), USB (installation depuis clé). Pilotes intégrés au noyau — aucun firmware requis.

Cartes réseau (sans firmware externe)

Détection automatique et indépendante du constructeur : le noyau identifie chaque carte par son identifiant PCI et charge le pilote correspondant. Un panachage de cartes de constructeurs différents sur une même machine est géré nativement. Familles couvertes :

Ces cartes portent leur firmware sur la puce : elles fonctionnent sans aucun ajout.

Matériel non pris en charge (en l'état)

Cette liste est explicite par conception. Chaque limite découle du principe « pas de binaire opaque par défaut » — elle n'est pas un oubli, et chacune est levable sur demande (voir « Ajouter du firmware »).

1. Cartes réseau exigeant un firmware externe

Certaines cartes ne portent pas leur firmware et le réclament au démarrage. Sans ce blob, la carte n'apparaît pas. Principaux cas :

2. Réseau sans fil (Wi-Fi, cellulaire)

Non pris en charge, et hors périmètre : LFSi est une distribution serveur/appliance filaire. Le Wi-Fi repose presque toujours sur du firmware propriétaire et élargirait la surface d'attaque sans justification pour une appliance.

3. Accélération graphique (GPU)

Non pertinente : LFSi est sans interface graphique et démarre en mode console (nomodeset). Les pilotes GPU accélérés (et leurs firmwares : amdgpu, i915 récents…) ne sont pas embarqués. L'affichage console VGA/série fonctionne partout.

4. Tout périphérique dépendant d'un blob propriétaire

Par extension : accélérateurs, cartes de capture, contrôleurs exotiques… dès lors qu'ils exigent un firmware non libre non embarqué.

Diagnostiquer un matériel non reconnu

Le symptôme est explicite dans le journal noyau. Sur le système installé :

dmesg | grep -i firmware

Un message du type :

bnx2x 0000:01:00.0: Direct firmware load for bnx2x/bnx2x-e2-7.13.21.0.fw failed with error -2

indique précisément quel firmware manque. Pour lister les cartes vues par le noyau :

ip -brief link       # interfaces detectees
lspci -k | grep -A3 -i ethernet   # cartes PCI + pilote associe (ou absence de pilote)

Si une carte physiquement présente n'apparaît pas dans ip link, c'est soit un pilote absent, soit — le plus souvent sur du matériel serveur — un firmware manquant signalé par dmesg.

Ajouter du firmware (sur besoin identifié)

L'absence de firmware est réversible et additive — aucune réinstallation, aucune refonte. Lorsqu'une cible matérielle précise le requiert, un sous-ensemble curé de firmware (uniquement les blobs nécessaires, jamais l'intégralité de linux-firmware) peut être intégré à l'image :

• il est choisi explicitement (par exemple bnx2x/ pour un parc de serveurs Broadcom identifiés) ;
• il est tracé dans la nomenclature (SBOM) et la provenance, au même titre que tout autre composant, avec sa version et son origine ;
• il reste hors du système de base source : son statut de binaire non libre est documenté, jamais dissimulé.

Cette démarche préserve l'auditabilité : on sait exactement quel blob a été ajouté, pourquoi, et pour quel matériel. Contactez l'équipe LFSi avec la référence exacte de vos cartes (lspci -nn) pour une image adaptée à votre parc.

En résumé