L’ancien problème de ZimaOS Beta, où la majeure partie du disque d’installation restait inutilisée, a été résolu il y a longtemps. Le même utilisateur qui l’avait signalé sur les versions 1.1.0 et 1.2.2 est revenu en février 2025 et a confirmé que ZimaOS 1.3.1 étendait automatiquement et correctement la huitième partition de données au premier démarrage.
Cette conclusion est plus importante que l’ancienne solution manuelle du fil resize2fs solution de contournement. Les utilisateurs actuels ne devraient pas redimensionner manuellement les partitions système de ZimaOS, sauf après avoir vérifié que l’extension automatique a échoué sur une version récente et disposé d’une sauvegarde.
À quoi ressemblait l’installation bêta initiale
L’installation bare metal de 2024 créait les partitions d’emplacement de démarrage/système de ZimaOS ainsi qu’une petite partition de données, tout en laissant inutilisée la majeure partie du disque physique. Le tableau de bord semblait ainsi « perdre » des téraoctets, même si le disque lui-même était sain.
Pourquoi les premières tentatives manuelles de redimensionnement étaient risquées
Le fil est passé d’exemples Proxmox à des exemples sur matériel physique, puis au redimensionnement manuel des partitions et des systèmes de fichiers. Cela crée une distinction importante : augmenter la taille d’un disque virtuel, augmenter la taille d’une partition et augmenter la taille du système de fichiers à l’intérieur de cette partition sont trois opérations distinctes.
Exécution resize2fs contre la mauvaise partition ou un système de fichiers dont la partition conteneur n’a pas été agrandie ne peut pas créer d’espace disque supplémentaire. Modifier la structure système de ZimaOS comporte également un risque pour la conception de récupération à double emplacement.
La solution de contournement ttydBridge relève du contexte historique
Ces captures d’écran montrent comment les utilisateurs ont obtenu un terminal et tenté une modification manuelle de la taille en 2024. Elles ne doivent pas être considérées comme la procédure d’installation actuelle.
Le fil de discussion a une résolution vérifiée
En février 2025, l’utilisateur initial a effectué un nouveau test avec ZimaOS 1.3.1 et signalé que la huitième partition s’était correctement étendue au premier démarrage. Cela signifie que le défaut d’extension automatique initial avait déjà été corrigé dans cette version.
L’installateur ZimaOS actuel attend désormais au moins 25 Go d’espace de stockage de destination et gère automatiquement le déroulement normal de l’installation.
Si une installation actuelle affiche toujours une capacité incorrecte
Comparez d’abord la taille du disque physique, la table de partitions et le système de fichiers monté avec lsblk ou dans l’interface de stockage. Déterminez si la capacité manquante est réellement non allouée, appartient à une autre partition ou ne fait simplement pas partie de l’espace de stockage que vous consultez.
La liste de vérification des couches de capacité utilise la même méthode par couches. La liste de vérification de l’installation actuelle doit être consultée avant toute modification destructive de la taille.
En bref
Le signalement « ZimaOS n’utilise pas tout le disque » concernait un bug des premières versions bêta, et non une règle de conception actuelle. ZimaOS 1.3.1 avait déjà corrigé l’extension automatique lors du test de l’auteur initial. Avec une version récente, commencez par diagnostiquer la couche de capacité exacte et ne recourez à la modification manuelle des partitions qu’en dernier ressort.
