L’installateur a été lancé depuis un emplacement en lecture seule
L’installateur shell d’AdventureLog a démarré normalement, mais a échoué lorsqu’il a tenté de créer ./adventurelog. Sur ZimaOS, le système de base est de type appliance et en lecture seule ; un script qui suppose que le répertoire courant est inscriptible peut donc échouer, même si le stockage connecté fonctionne correctement.
Un deuxième utilisateur a rencontré une vérification de dépendance différente
Un autre participant a indiqué que l’installateur s’était arrêté immédiatement, car il ne trouvait pas docker-compose. Ce n’était pas le même échec que l’échec initial mkdir erreur, et la discussion n’a pas établi de commande universelle d’installation de paquets pour l’hôte ZimaOS.
La correction présentée consistait à travailler sous /DATA
Un membre de l’équipe IceWhale a d’abord averti que le travail en ligne de commande n’est généralement pas recommandé, sauf dans le cadre d’une investigation guidée. La démonstration a été réalisée sur une machine de test, avec la recommandation explicite d’éviter toute expérimentation sur un système de production, à moins de comprendre les risques liés à l’ordinateur et à la sécurité des données.
Pour un utilisateur expérimenté, la séquence présentée était la suivante :
sudo -i
cd /DATA
mkdir 10-16test2
cd 10-16test2/
curl -sSL https://get.adventurelog.app | bashLe changement clé concernait le répertoire de travail : /DATA est destiné aux données inscriptibles, contrairement à la couche système en lecture seule. L’URL d’installation est disponible à l’adresse du point de terminaison d’installation d’AdventureLog.
Une installation réussie ne signifiait pas que l’application était fonctionnelle
L’auteur original a ensuite confirmé que l’installation elle-même s’était terminée après avoir suivi les instructions concernant un chemin accessible en écriture. Cependant, le backend d’AdventureLog ne démarrait pas et ses journaux indiquaient à plusieurs reprises que PostgreSQL était indisponible. L’installation d’une application PostgreSQL distincte depuis l’App Store de ZimaOS n’a pas automatiquement connecté celle-ci à la stack AdventureLog.
Le fil se termine sans correctif confirmé pour la base de données. Un conteneur PostgreSQL autonome n’est pas automatiquement la base de données déclarée par un autre projet Compose ; les noms réseau, les identifiants, la découverte de services, les volumes et l’initialisation attendue de la base de données doivent tous correspondre.
FAQ
Pourquoi mkdir a-t-il échoué alors que ZimaOS disposait d’espace de stockage libre ?
L’installateur fonctionnait dans une partie du système en lecture seule, et non dans un répertoire de données accessible en écriture. L’espace libre disponible ailleurs ne rend pas accessible en écriture le chemin système actuel.
L’exécution de l’installateur sous /DATA a-t-elle entièrement résolu le problème d’AdventureLog ?
Cela a résolu l’erreur de répertoire d’installation et a permis d’installer la stack. Le problème ultérieur de disponibilité de PostgreSQL est resté irrésolu dans le fil.
