The old ZimaOS Beta problem where most of the installation disk remained unused was fixed long ago. The same user who reported it on 1.1.0 and 1.2.2 returned in February 2025 and confirmed that ZimaOS 1.3.1 automatically expanded the eighth data partition correctly on first boot.
Das alte ZimaOS-Beta-Problem, bei dem der größte Teil der Installationsfestplatte ungenutzt blieb, wurde bereits vor langer Zeit behoben. Derselbe Benutzer, der das Problem unter 1.1.0 und 1.2.2 gemeldet hatte, kehrte im Februar 2025 zurück und bestätigte, dass ZimaOS 1.3.1 die achte Datenpartition beim ersten Start automatisch korrekt erweiterte. resize2fs Dieser Abschluss ist wichtiger als die alte manuelle
Übergangslösung. Aktuelle Benutzer sollten ZimaOS-Systempartitionen nicht manuell vergrößern, es sei denn, sie haben zunächst nachgewiesen, dass die automatische Erweiterung in einer aktuellen Version fehlgeschlagen ist, und verfügen über ein Backup.
Das Dashboard zeigte nur die kleine System-/Datenpartition statt der gesamten physischen Festplatte an.
Die Bare-Metal-Installation von 2024 erstellte die ZimaOS-Boot-/System-Slot-Partitionen und eine kleine Datenpartition, während der größte Teil der physischen Festplatte ungenutzt blieb. Dadurch schien das Dashboard Terabytes zu „verlieren“, obwohl die Festplatte selbst einwandfrei war.
Der Benutzer zeigte später, dass ein manueller Vergrößerungsversuch mit GParted während der Phase zur Größenänderung des Dateisystems fehlschlug.
Die Diskussion wechselte zwischen Proxmox- und Bare-Metal-Beispielen und ging anschließend zum manuellen Vergrößern von Partitionen und Dateisystemen über. Das schafft einen wichtigen Unterschied: Das Vergrößern einer virtuellen Festplatte, das Vergrößern einer Partition und das Vergrößern des Dateisystems innerhalb dieser Partition sind drei getrennte Vorgänge. resize2fs gegen die falsche Partition oder ein Dateisystem, dessen enthaltende Partition nicht vergrößert wurde, kann keinen fehlenden Speicherplatz schaffen. Das Bearbeiten des ZimaOS-Systemlayouts birgt außerdem Risiken für das Dual-Slot-Wiederherstellungsdesign.
Die ttydBridge-Übergangslösung ist historischer Kontext
Diese Screenshots dokumentieren, wie Nutzer 2024 ein Terminal öffneten und eine manuelle Größenänderung ausprobierten. Sie sollten nicht als aktuelle Installationsanleitung betrachtet werden.
Der Thread hat eine bestätigte Lösung
Im Februar 2025 testete der ursprüngliche Nutzer ZimaOS 1.3.1 erneut und berichtete, dass sich die achte Partition beim ersten Start korrekt vergrößerte. Das bedeutet, dass der ursprüngliche Fehler bei der automatischen Erweiterung in dieser Version bereits behoben war.
Der aktuelle ZimaOS-Installer erwartet jetzt mindestens 25 GB Speicherplatz auf dem Zieldatenträger und übernimmt den normalen Installationsablauf automatisch.
Wenn eine aktuelle Installation weiterhin die falsche Kapazität anzeigt
Vergleichen Sie zunächst die Größe des physischen Datenträgers, die Partitionstabelle und das eingehängte Dateisystem mit lsblk oder die Speicheroberfläche. Ermitteln Sie, ob die fehlende Kapazität tatsächlich nicht zugewiesen ist, zu einer anderen Partition gehört oder einfach nicht Teil des von Ihnen angezeigten Speicherbereichs ist.
Die Checkliste für Kapazitätsebenen verwendet dieselbe schrittweise Methode. Die aktuelle Installations-Checkliste sollte vor jeder zerstörerischen Größenänderung herangezogen werden.
Kurz gesagt
Der Bericht „ZimaOS verwendet nicht den gesamten Datenträger“ bezog sich auf einen frühen Beta-Fehler und nicht auf eine aktuelle Designregel. ZimaOS 1.3.1 behob die automatische Erweiterung bereits im Test des ursprünglichen Berichterstatters. Bei einer modernen Version sollte zuerst die genaue Kapazitätsebene diagnostiziert und eine manuelle Bearbeitung der Partitionen nur als letztes Mittel eingesetzt werden.
