コミュニティソリューション

ZimaOSでaptとyumが動作しない理由:Buildroot、zpkgモジュール、コンテナ、WebDAV

A November 2024-July 2025 thread where apt, apt-get, and yum failed because ZimaOS is Buildroot-based rather than Debian/Ubuntu. A later user wanted davfs2 for a host-level WebDAV mount so it would appear in Files. IceWhale did not provide an apt-style package-manager solution and instead explored container alternatives.

apt install, apt installapt-get update 、および yum install

ZimaOSはDebian、Ubuntu、Fedora、RHEL形式の汎用ディストリビューションではないため、ZimaOS上で失敗します。ZimaOSはBuildrootを基盤とするアプライアンスOSとして構築され、ほとんどのシステムフォルダーを読み取り専用にしています。

現在のZimaOSには、特定の用途向けのパッケージに似た仕組みがあります。特にzpkgモジュールや、一部の開発者向けドキュメントで専用ツール用に使用されているEntware/opkgなどです。ただし、これらによってベースOSが通常の変更可能なLinuxディストリビューションになり、Debianパッケージのように任意のホストパッケージをインストールして統合できるようになるわけではありません

元のユーザーはapt、apt-get、yumを試しました

元の2024年の投稿では、SSH経由で3つすべてのパッケージマネージャー方式が失敗したと報告されていました。コミュニティの返信では、ZimaOSはBuildrootを基盤とし、Linux、glibc、systemd、Docker、仮想化コンポーネントを、Debian形式のパッケージデータベースなしで組み合わせていると説明されていました。

このアーキテクチャに関する説明は、現在も正確です。

現在のZimaOSでは、ほとんどのシステムパスが読み取り専用です /DATA.

IceWhaleの現在のCLIガイダンスでは、rootであってもほとんどのシステムフォルダーは読み取り専用のままであると明記されています。ユーザーデータとアプリデータは、次の場所に置く必要があります。

現在のZimaOS CLIファイルシステムモデルを参照してください。

アプリケーションではDockerが主要な拡張モデルです

ソフトウェアが保守されているDockerイメージまたはComposeスタックとして存在する場合、それが通常、ZimaOSに最も適したデプロイ方法です。依存関係はコンテナ内に留まり、ベースオペレーティングシステムを変更しません。 davfs2 このため、IceWhaleが後のWebDAVリクエストへの対応で、ユーザーにインストールを指示するのではなく、Dockerベースのアプリケーションを検討しました

APTを使用します。

zpkgはaptではなく、ZimaOSのモジュールマネージャーです 現在のZimaOSでは zpkg

これは、AI/検索拡張機能やコミュニティ/公式モジュールなど、任意のDebianパッケージ名をインストール可能なシステムモジュールの代替として一般的に使用できるものではありません。モジュールはZimaOSの拡張機構向けに構築され、独自のサービスポリシーを含めることができます。 davfs2 インストールできます。

IceWhaleは、専用の開発環境向けにopkgについても文書化しています

現在のIceWhaleのPython/開発者向けガイダンスでは、Entwareのインストール先として /opt そして使用する opkg 次のような開発者向けユーティリティ用の git-http.

これは、その特定のガイドにおける高度なサポート対象パターンであり、EntwareからインストールしたすべてのLinuxデーモンが、ZimaOSの起動、Files、ネットワーク、ストレージサービスと安全に統合できると考えてよいという意味ではありません。

現在のEntware/opkg開発ワークフローは、想定される用途に合致する場合にのみ使用してください。

後の WebDAV リクエストではホストレベルの統合が必要だった

2025 年のユーザーは、WebDAV クラウドドライブを OS レベルでマウントし、ZimaOS Files の利用環境と他のアプリからアクセスできるようにしたいと考えていました。別個の AList 型アプリでは同等にならないと明確に述べていました。

この要件は「WebDAV クライアントコンテナを実行する」よりも難しいものです。コンテナ内のマウントが、Files や他のすべてのコンテナから見えるネイティブなホストマウントになるとは限らないためです。

コンテナでも一部の WebDAV ワークフローは解決できる

本当の目的が WebDAV プロバイダー上のデータを閲覧、同期、またはコピーすることであれば、ホストを変更するより、コンテナ化されたツールのほうが安全な場合があります。例として、WebDAV を直接サポートする同期クライアント、ファイルマネージャー、バックアップツールなどがあります。

コンテナが必要とする ZimaOS フォルダーだけをマッピングし、プロバイダーの認証情報は保護されたアプリ設定に保存してください。

ソフトウェアに通常の変更可能な Linux ホストが必要な場合は VM を使用する

ワークフローで本当に apt install davfs2、システムパッケージ、FUSE/カーネルの動作、またはカスタム起動サービスが必要な場合は、Debian/Ubuntu VM をより明確な境界として利用できます。ゲスト内では、実際に Debian/Ubuntu であるため、通常のパッケージ管理がサポートされます。

必要に応じて、意図したネットワーク/ストレージプロトコルを通じて、マウントしたデータを ZimaOS または他のクライアントに公開します。

ホストの変更は不変のライフサイクルを乗り越えて維持される必要がある

高度な回避策によってバイナリを /opt または /DATA、次を確認してください:

  • 再起動後にサービスが起動すること。
  • OTA アップデート後も維持されること。
  • 認証情報が安全に保持されること。
  • 依存するアプリの起動前にマウントが存在すること。
  • 障害が発生しても、アプリが空のローカルマウントポイントに書き込む状態にならないこと。

ホストマウントは自動的に Files との統合にはならない

ZimaOS Files は独自のストレージおよびネットワークロケーションモデルを持つネイティブサービスです。シェルからカスタム FUSE/WebDAV マウントを作成しても、それが Files の正式なロケーションとして表示されたり、同じ権限およびライフサイクル管理を受けたりするとは限りません。

ZimaOS パッケージマネージャー FAQ

ZimaOS ではなぜ apt が動作しないのですか?

ZimaOS は Buildroot ベースであり、Debian/Ubuntu の APT パッケージ管理アーキテクチャは使用していません。

zpkg は apt の汎用的な代替になりますか?

いいえ。zpkg は、プラットフォームのモジュールシステム向けに構築された ZimaOS モジュールをインストールします。

IceWhale が opkg を文書化したことはありますか?

Entware を使った特殊な開発者向け/Python 環境では、 /opt。だからといって、ベース OS が通常の変更可能なディストリビューションになるわけではありません。

davfs2 や別のホストデーモンがどうしても必要な場合はどうすればよいですか?

利用可能な場合はサポート対象のコンテナ/モジュールを優先し、ワークフローが通常のパッケージ管理とホストサービスに本当に依存する場合は、汎用 Linux VM を実行してください。