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.
That closure is more important than the thread’s old manual resize2fs workaround. Current users should not resize ZimaOS system partitions by hand unless they have first proved automatic expansion failed on a current release and have a backup.
What the Early Beta Installation Looked Like
The 2024 bare-metal install created the ZimaOS boot/system slot partitions and a small data partition while leaving most of the physical disk unused. That made the dashboard appear to “lose” terabytes even though the disk itself was healthy.
Why the Early Manual Resize Attempts Were Risky
The thread moved between Proxmox and bare-metal examples, then into manual partition/filesystem resizing. That creates an important distinction: growing a virtual disk, growing a partition and growing the filesystem inside that partition are three separate operations.
Running resize2fs against the wrong partition or a filesystem that has not had its containing partition enlarged cannot create missing disk space. Editing the ZimaOS system layout also risks the dual-slot recovery design.
The ttydBridge Workaround Is Historical Context
Those screenshots document how users obtained a terminal and tried manual resizing in 2024. They should not be treated as the current installation procedure.
The Thread Has a Verified Resolution
In February 2025, the original user tested again on ZimaOS 1.3.1 and reported that the eighth partition expanded correctly on first boot. That means the original auto-expansion defect had already been resolved by that release.
The current current ZimaOS installer now expects at least 25GB of destination storage and handles the normal installation flow automatically.
If a Current Install Still Shows the Wrong Capacity
First compare the physical disk size, partition table and mounted filesystem with lsblk or the storage UI. Determine whether the missing capacity is actually unallocated, belongs to another partition, or is simply not part of the storage space you are viewing.
The capacity-layer checklist uses the same layered method. The current installation checklist should come before any destructive resize.
Bottom Line
The “ZimaOS does not use the full disk” report was an early Beta bug, not a current design rule. ZimaOS 1.3.1 already fixed automatic expansion in the original reporter’s test. On a modern release, diagnose the exact capacity layer first and keep manual partition surgery as a last resort.
