ZimaOSのディスク容量を完全に使えない：古いリサイズ不具合を解説

インストールディスクの大部分が未使用のまま残るという、旧ZimaOS Betaの問題はずっと前に修正されています。1.1.0および1.2.2でこの問題を報告した同じユーザーが、2025年2月に再び確認し、ZimaOS 1.3.1では初回起動時に8番目のデータパーティションが正しく自動拡張されたと報告しました。

この結論は、スレッドに記載された以前の手動 resize2fs 回避策。現在のユーザーは、現行リリースで自動拡張が失敗したことをまず確認し、バックアップを取っていない限り、ZimaOSのシステムパーティションを手動でリサイズしないでください。

初期のBetaインストールの状態

4TBのZimaOSディスクの大部分が未割り当て領域として表示されているGParted — 元のBeta 1.1.0のインストールでは、4TBディスクの大部分が未割り当てのまま残されていました。出典：IceWhaleコミュニティフォーラム。

ストレージ割り当てが非常に小さく表示されているZimaOSダッシュボード — ダッシュボードには、物理ディスク全体ではなく、小さなシステム／データパーティションだけが反映されていました。出典：IceWhaleコミュニティフォーラム。

2024年のベアメタルインストールでは、ZimaOSのブート／システムスロットパーティションと小さなデータパーティションが作成され、物理ディスクの大部分は未使用のまま残されました。そのため、ディスク自体は正常であるにもかかわらず、ダッシュボードではテラバイト単位の容量が「失われた」ように表示されました。

初期の手動リサイズの試みが危険だった理由

ZimaOS仮想ディスクのProxmoxディスク拡張ダイアログ — ある返信ではProxmoxのディスク拡張が説明されましたが、元のシステムは後にベアメタルであることが明らかになりました。出典：IceWhaleコミュニティフォーラム。

ZimaOSのデータファイルシステムの拡張に失敗するGParted — その後、ユーザーは手動でGPartedの拡張を試みたものの、ファイルシステムのリサイズ段階で失敗したことを示しました。出典：IceWhaleコミュニティフォーラム。

このスレッドでは、Proxmoxとベアメタルの例を行き来した後、パーティションとファイルシステムの手動リサイズへと話が進みました。ここで重要な区別が生じます。仮想ディスクの拡張、パーティションの拡張、そしてそのパーティション内のファイルシステムの拡張は、それぞれ別の操作です。

実行 resize2fs 対象を誤ったパーティションにしている場合や、所属するパーティションの拡張が済んでいないファイルシステムに対しては、不足しているディスク領域を作成できません。ZimaOSのシステムレイアウトを編集すると、デュアルスロットのリカバリ設計にも影響するおそれがあります。

ttydBridgeの回避策は歴史的な経緯を示すものです

ttydBridgeのZimaOS App Store検索結果 — 以前の回避策では、ターミナルにアクセスするためにttydBridgeを使用していました。出典：IceWhaleコミュニティフォーラム。

インポートボタンが強調表示されたZimaOSのカスタムアプリ画面 — このスレッドでは、ストアから利用できなかったttydBridgeを手動でインポートする方法を記録しています。出典：IceWhaleコミュニティフォーラム。

初期のZimaOSにおけるDocker Composeのインポートダイアログ — 以前のカスタムアプリのワークフローでは、Composeファイルをアップロードしていました。出典：IceWhaleコミュニティフォーラム。

ZimaOS上のttydBridgeアプリタイル — ttydBridgeは、手動でサイズ変更を試みるためのブラウザベースのターミナルを提供しました。出典：IceWhaleコミュニティフォーラム。

ZimaOSディスク上でresize2fsとlsblkを実行したターミナル出力 — 手動ターミナルテストでは、トラブルシューティング中のパーティションとファイルシステムの状態が表示されました。出典：IceWhaleコミュニティフォーラム。

これらのスクリーンショットは、2024年にユーザーがターミナルを取得し、手動でサイズ変更を試みた方法を記録したものです。現在のインストール手順として扱わないでください。

スレッドでは解決が確認されています

2025年2月、元のユーザーはZimaOS 1.3.1で再度テストし、初回起動時に8番目のパーティションが正しく拡張されたと報告しました。つまり、元の自動拡張の不具合はそのリリースまでにすでに解消されていました。

現在のZimaOSインストーラーは、インストール先のストレージとして最低25GBを要求し、通常のインストール手順を自動的に処理します。

現在のインストールでも容量が正しく表示されない場合

まず、物理ディスクのサイズ、パーティションテーブル、マウントされたファイルシステムを比較します。 lsblk またはストレージUIを確認してください。不足している容量が実際に未割り当てなのか、別のパーティションに属しているのか、あるいは表示中のストレージ領域に含まれていないだけなのかを判断します。

容量レイヤーのチェックリストでは、同じ階層化された方法を使用します。現在のインストールチェックリストを、破壊的なサイズ変更より先に確認してください。

要点

「ZimaOSがディスク全体を使用しない」という報告は初期ベータ版のバグであり、現在の設計ルールではありません。ZimaOS 1.3.1では、元の報告者のテスト環境ですでに自動拡張が修正されています。最新のリリースでは、まず正確な容量レイヤーを診断し、手動でのパーティション操作は最後の手段にしてください。