Het oude ZimaOS-bètaprobleem waarbij het grootste deel van de installatieschijf ongebruikt bleef, is lang geleden opgelost. Dezelfde gebruiker die het probleem in 1.1.0 en 1.2.2 meldde, keerde in februari 2025 terug en bevestigde dat ZimaOS 1.3.1 de achtste gegevenspartitie bij de eerste keer opstarten automatisch correct uitbreidde.
Die afsluiting is belangrijker dan de oude handmatige resize2fs workaround. Huidige gebruikers zouden ZimaOS-systeempartities niet handmatig moeten vergroten, tenzij ze eerst hebben vastgesteld dat automatische uitbreiding in een recente release is mislukt en ze een back-up hebben.
Hoe de vroege bètainstallatie eruitzag
De bare-metalinstallatie uit 2024 maakte de ZimaOS-opstart-/systeemslotpartities en een kleine gegevenspartitie aan, terwijl het grootste deel van de fysieke schijf ongebruikt bleef. Daardoor leek het dashboard terabytes te verliezen, hoewel de schijf zelf gezond was.
Waarom de vroege handmatige pogingen om de grootte aan te passen riskant waren
De thread verschoof van Proxmox- en bare-metalvoorbeelden naar het handmatig vergroten van partities en bestandssystemen. Dat maakt een belangrijk onderscheid duidelijk: een virtuele schijf vergroten, een partitie vergroten en het bestandssysteem binnen die partitie vergroten zijn drie afzonderlijke bewerkingen.
Uitvoeren resize2fs tegen de verkeerde partitie of een bestandssysteem waarvan de omvattende partitie niet is vergroot, kan geen ontbrekende schijfruimte worden aangemaakt. Het aanpassen van de systeemindeling van ZimaOS brengt ook het ontwerp voor herstel met twee slots in gevaar.
De ttydBridge-workaround behoort tot de historische context
Die schermafbeeldingen documenteren hoe gebruikers in 2024 een terminal openden en handmatig de grootte probeerden te wijzigen. Ze moeten niet worden beschouwd als de huidige installatieprocedure.
De thread heeft een geverifieerde oplossing
In februari 2025 testte de oorspronkelijke gebruiker ZimaOS 1.3.1 opnieuw en meldde dat de achtste partitie bij de eerste keer opstarten correct was uitgebreid. Dat betekent dat het oorspronkelijke probleem met automatische uitbreiding in die release al was opgelost.
De huidige huidige ZimaOS-installatieprogramma verwacht nu ten minste 25 GB opslagruimte op de doellocatie en handelt de normale installatie automatisch af.
Als een huidige installatie nog steeds de verkeerde capaciteit toont
Vergelijk eerst de grootte van de fysieke schijf, de partitietabel en het aangekoppelde bestandssysteem met lsblk of de opslaginterface. Bepaal of de ontbrekende capaciteit daadwerkelijk niet is toegewezen, bij een andere partitie hoort of simpelweg geen onderdeel is van de opslagruimte die je bekijkt.
De controlelijst voor capaciteitslagen gebruikt dezelfde gelaagde methode. De huidige installatiecontrolelijst moet worden gevolgd voordat je een destructieve wijziging van de partitiegrootte uitvoert.
Kort samengevat
De melding dat “ZimaOS niet de volledige schijf gebruikt” was een bug in een vroege bèta, geen actuele ontwerpregel. ZimaOS 1.3.1 had de automatische uitbreiding al opgelost in de test van de oorspronkelijke melder. Diagnoseer in een moderne release eerst de exacte capaciteitslaag en beschouw handmatige partitiebewerkingen als laatste redmiddel.
