インストーラーは読み取り専用の場所から開始されました
AdventureLogのシェルインストーラーは正常に開始しましたが、次の作成を試みた際に失敗しました ./adventurelog。ZimaOSでは、ベースシステムはアプライアンスのような読み取り専用構成になっているため、接続されたストレージ自体に問題がなくても、現在のディレクトリが書き込み可能であることを前提とするスクリプトは失敗する場合があります。
別のユーザーが異なる依存関係チェックに遭遇
別の参加者は、インストーラーが見つけられないため直ちに停止したと報告しました docker-compose。これは元の失敗と同じではありませんでした mkdir というエラーが発生しましたが、ZimaOSホスト向けの汎用的なパッケージインストールコマンドはスレッド内で確立されませんでした。
実演された修正方法は /DATA 配下で作業することでした
IceWhaleのチームメンバーはまず、CLIでの作業は、誘導付きの調査の一環である場合を除き、一般的には推奨されないと注意しました。このデモはテストマシンで実施され、本番システムで実験する場合は、コンピューターとデータのセキュリティリスクを理解しているオペレーターに限るよう明確に推奨されました。
経験豊富なユーザー向けに、次の手順が示されました。
sudo -i
cd /DATA
mkdir 10-16test2
cd 10-16test2/
curl -sSL https://get.adventurelog.app | bash主な変更点は作業ディレクトリです。/DATA は書き込み可能なデータ用で、読み取り専用のシステム層とは異なります。インストーラーのURLはAdventureLogのインストールエンドポイントから利用できます。
インストールに成功しても、アプリが正常に動作するとは限らない
元の投稿者は後に、書き込み可能なパスに関する手順に従ったところ、インストール自体は完了したと確認しました。しかし、AdventureLogのバックエンドは起動せず、ログにはPostgreSQLが利用できないという報告が繰り返し記録されました。ZimaOS App Storeから別のPostgreSQLアプリをインストールしても、AdventureLogのスタックに自動的に接続されることはありませんでした。
スレッドは、データベースの修正が確認されないまま終了しています。スタンドアロンのPostgreSQLコンテナが、別のComposeプロジェクトで宣言されたデータベースになるとは限りません。ネットワーク名、認証情報、サービス検出、ボリューム、想定されるデータベースの初期化をすべて一致させる必要があります。
よくある質問
ZimaOSに空きストレージがあったのに、なぜmkdirは失敗したのですか？
インストーラーは書き込み可能なデータディレクトリではなく、システム内の読み取り専用部分で動作していました。他の場所に空き容量があっても、現在のシステムパスが書き込み可能になるわけではありません。
/DATAでインストーラーを実行すると、AdventureLogの問題は完全に解決しましたか？
インストール先ディレクトリのエラーが解消され、スタックをインストールできるようになりました。後に発生したPostgreSQLの利用不可の問題は、スレッド内では未解決のままでした。
