Linux : vue d'ensemble

L'essentiel

• La Box tourne sous Linux (ADR-001) : c'est le seul système où la pile d'inférence AMD (ROCm, Vulkan/RADV), Docker et l'administration distante sont natifs.
• Framework supporte officiellement Fedora 43, Ubuntu 25.10 et Bazzite ¹ ; la matrice ROCm 10.0 ne liste que Ubuntu 26.04 et 24.04.4 ². Aucune distribution n'est « officielle » des deux côtés : c'est la question Q-007.
• Noyau : 6.11 minimum selon Framework, 6.18.4 ou plus récent selon AMD pour ROCm ³. Le dossier retient 6.18.4.
• Le pilote GPU est amdgpu (noyau) avec Mesa (RADV pour Vulkan) ; AMDVLK est abandonné ⁵.
• Les sous-pages traitent ROCm et Vulkan, la mémoire GPU allouable, l'installation reproductible et la stabilité.

Rôle du système

Le système d'exploitation de la Box a quatre fonctions : exposer le GPU à la pile d'inférence, isoler les services (LLM, RAG, interface, base vectorielle, identité) dans des conteneurs, garantir la reprise après incident (snapshots, sauvegardes, redémarrage automatique) et permettre l'administration à distance sécurisée. Il n'a pas d'interface graphique : pas de session utilisateur locale, pas d'écran en fonctionnement normal.

Choix de distribution

Noyau et firmware

Le firmware GPU (linux-firmware) compte autant que le noyau : la version 2026010 ou supérieure est citée comme condition de stabilité. Sur Ubuntu 24.04, cela impose le noyau OEM ou HWE ; sur Fedora 43 et Ubuntu 26.04, le noyau livré convient.

Pilotes GPU

• amdgpu : pilote noyau, in-tree. Sur Ubuntu supporté, ROCm 10.0 utilise le pilote « inbox » ² ; la pile DKMS d'AMD (amdgpu-dkms) n'est pas nécessaire et change le nom des paramètres TTM (voir Mémoire GPU).
• Mesa : fournit RADV (Vulkan) et RadeonSI (OpenGL). RADV est le seul pilote Vulkan AMD d'avenir depuis l'abandon d'AMDVLK ⁵. Ne pas installer AMDVLK.
• ROCm : pile de calcul (HIP, rocBLAS…) nécessaire au backend HIP de llama.cpp, à PyTorch et à vLLM ; optionnelle si Vulkan est retenu. Détail : ROCm.

Conteneurs

Les services de la Box tournent dans des conteneurs (Docker ou Podman). L'accès GPU passe par les périphériques /dev/kfd (ROCm) et /dev/dri (Vulkan et ROCm) exposés au conteneur ; aucune couche propriétaire équivalente au NVIDIA Container Toolkit n'est nécessaire, mais les groupes video et render doivent être accessibles. Les toolboxes kyuz0 ⁶ montrent que llama.cpp Vulkan et ROCm fonctionnent en conteneur sur Strix Halo. Les détails (images, compose, volumes) sont dans la section Architecture.

Mises à jour et rollback

Un serveur d'inférence dépend d'un triplet noyau / firmware / pilotes dont chaque mise à jour peut casser la stabilité. Principes retenus (hypothèses à valider) Hypothèse :

Règle : les mises à jour de sécurité sont automatiques ; les mises à jour de noyau, firmware, Mesa et ROCm sont manuelles, précédées d'un snapshot et suivies du test de charge court (voir Stabilité). Le choix ZFS ou Btrfs, et le miroir des deux SSD, relèvent de Q-006 et de la section Sauvegardes.

Administration distante

• SSH avec clés uniquement (mots de passe désactivés), port exposé sur le réseau local ou via VPN (WireGuard ou Tailscale), jamais directement sur Internet. Voir Réseau.
• Cockpit (console web d'administration) : pratique pour la supervision de base et les mises à jour ; à évaluer, son exposition ajoutant une surface d'attaque. Non décidé.
• Journalisation centralisée et alertes : voir Monitoring.
• Comptes : un compte d'administration nominatif par intervenant, sudo journalisé, pas de connexion root.

Durcissement

Le détail est dans la section Sécurité et sa checklist d'installation. Pour le système : chiffrement au repos (LUKS) des volumes de données, pare-feu par défaut fermé (seuls les ports du reverse proxy et de SSH), Secure Boot à évaluer (compatibilité avec les modules et le firmware GPU non vérifiée), mises à jour de sécurité automatiques, fail2ban ou équivalent sur SSH.

Monitoring

Métriques système, GPU (amdgpu via sysfs, rocm-smi si ROCm), température, consommation et journaux dmesg remontés vers Prometheus et Grafana : voir Monitoring. Les motifs à surveiller en priorité sont listés dans Stabilité.

Questions ouvertes

• Q-007Quelle distribution Linux pour la Box ?MoyenneOuverte
• Q-011Combien de mémoire GPU peut-on réellement allouer sur 128 Go ?HauteOuverte
• Q-012La plateforme Strix Halo est-elle assez stable pour un serveur 24 h/24 ?HauteOuverte

Ce qu'il reste à tester

• Mesurer la mémoire GPU allouable sur le Framework DesktopAvec BIOS 3.06, UMA à 512 Mo, noyau 6.18.4+ et ttm.pages_limit fixé via amd-ttm, le GPU peut allouer au moins 100 Go de façon stable ; gpt-oss-120b MXFP4 se charge avec 32k tokens de contexte pour 4 slots.À tester
• Redémarrage à distance avec disque chiffré LUKS2 et TPM2Avec systemd-cryptenroll et un enrôlement TPM2 lié aux PCR du démarrage sécurisé, la Box redémarre sans saisie de mot de passe après un redémarrage ordinaire, refuse le déverrouillage automatique après une modification du chargeur ou de la désactivation de Secure Boot, et redevient déverrouillable avec la clé de récupération.À tester
• Stabilité sous charge continue pendant 24 heuresAvec BIOS 3.06, noyau 6.18.4+, firmware 2026010+, veille désactivée, amdgpu.gpu_recovery=1 et 100 Go de GTT, llama-server (backend retenu) sert 4 utilisateurs simulés en continu pendant 24 h sans reset GPU, sans erreur amdgpu dans dmesg et sans redémarrage du service.À tester
• Valider l'installation reproductibleUne personne compétente en administration Linux mais sans connaissance préalable du projet réinstalle la Box en moins d'une demi-journée à partir de la page Installation et du dépôt de configuration, et obtient le même résultat à la checklist de validation que l'installation initiale.À tester