Det gamla ZimaOS-betaproblemet, där större delen av installationsdisken förblev oanvänd, åtgärdades för länge sedan. Samma användare som rapporterade det i versionerna 1.1.0 och 1.2.2 återkom i februari 2025 och bekräftade att ZimaOS 1.3.1 automatiskt utökade den åttonde datapartitionen korrekt vid första uppstarten.
Det avslutet är viktigare än trådens gamla manuella resize2fs lösning. Aktuella användare bör inte ändra storleken på ZimaOS-systempartitioner manuellt om de inte först har bevisat att automatisk expansion misslyckades i en aktuell version och har en säkerhetskopia.
Så såg den tidiga betainstallationen ut
Den fysiska installationen från 2024 skapade partitioner för ZimaOS start- och systemplatser samt en liten datapartition, samtidigt som större delen av den fysiska disken lämnades oanvänd. Därför såg det ut som att instrumentpanelen hade ”förlorat” terabyte, trots att själva disken var felfri.
Varför de tidiga manuella försöken att ändra storlek var riskfyllda
Tråden växlade mellan exempel med Proxmox och fysisk installation och gick sedan över till manuell storleksändring av partitioner och filsystem. Det skapar en viktig åtskillnad: att utöka en virtuell disk, att utöka en partition och att utöka filsystemet inuti den partitionen är tre separata åtgärder.
Kör resize2fs mot fel partition eller ett filsystem vars tillhörande partition inte har utökats kan inte skapa det saknade diskutrymmet. Att redigera ZimaOS systemlayout innebär dessutom en risk för designen med återställning via två platser.
Lösningen med ttydBridge är historisk bakgrund
Skärmbilderna dokumenterar hur användare fick åtkomst till en terminal och försökte ändra storleken manuellt under felsökningen 2024. De bör inte betraktas som den aktuella installationsproceduren.
Tråden har en verifierad lösning
I februari 2025 testade den ursprungliga användaren igen med ZimaOS 1.3.1 och rapporterade att den åttonde partitionen utökades korrekt vid den första uppstarten. Det innebär att det ursprungliga felet i den automatiska utökningen redan hade åtgärdats i den versionen.
Det aktuella ZimaOS-installationsprogrammet förväntar sig nu minst 25 GB lagringsutrymme på målenheten och hanterar det normala installationsflödet automatiskt.
Om en aktuell installation fortfarande visar fel kapacitet
Jämför först den fysiska diskens storlek, partitionstabellen och det monterade filsystemet med lsblk eller lagringsgränssnittet. Ta reda på om den saknade kapaciteten faktiskt är oallokerad, tillhör en annan partition eller helt enkelt inte ingår i det lagringsutrymme du visar.
checklistan för kapacitetslager använder samma lagerindelade metod. den aktuella installationschecklistan bör användas innan någon destruktiv storleksändring görs.
Slutsats
Rapporten ”ZimaOS använder inte hela disken” var ett tidigt betafel, inte en aktuell designregel. ZimaOS 1.3.1 hade redan åtgärdat den automatiska utökningen i den ursprungliga rapportörens test. I en modern version bör du först fastställa exakt vilket kapacitetslager som berörs och spara manuell partitionsredigering som sista utväg.
