El instalador se inició desde una ubicación de solo lectura
El instalador de shell de AdventureLog se inició normalmente, pero falló al intentar crear ./adventurelog. En ZimaOS, el sistema base funciona como un dispositivo integrado y es de solo lectura, por lo que un script que presupone que el directorio actual permite escritura puede fallar incluso cuando el almacenamiento conectado funciona correctamente.
Un segundo usuario se encontró con una comprobación de dependencias diferente
Otro participante informó que el instalador se detuvo inmediatamente porque no pudo encontrar docker-compose. Ese no era el mismo fallo que el original mkdir y el hilo no estableció un comando universal para instalar paquetes en el host de ZimaOS.
La solución demostrada fue trabajar en /DATA
Primero, un miembro del equipo de IceWhale advirtió que, por lo general, no se recomienda trabajar con la CLI a menos que forme parte de una investigación guiada. La demostración se realizó en una máquina de prueba, con la recomendación explícita de evitar experimentar en un sistema de producción a menos que el operador comprenda los riesgos informáticos y de seguridad de los datos.
Para un usuario experimentado, la secuencia demostrada fue:
sudo -i
cd /DATA
mkdir 10-16test2
cd 10-16test2/
curl -sSL https://get.adventurelog.app | bashEl cambio clave fue el directorio de trabajo: /DATA está destinado a datos con permisos de escritura, a diferencia de la capa del sistema, que es de solo lectura. La URL del instalador está disponible en el punto de acceso de instalación de AdventureLog.
Una instalación correcta no significaba que la aplicación funcionara correctamente
El autor original confirmó más tarde que la instalación se completó después de seguir las instrucciones sobre la ruta con permisos de escritura. Sin embargo, el backend de AdventureLog no se inició y sus registros indicaban repetidamente que PostgreSQL no estaba disponible. Instalar una aplicación independiente de PostgreSQL desde la tienda de aplicaciones de ZimaOS no la conectó automáticamente con el stack de AdventureLog.
El hilo termina sin una solución confirmada para la base de datos. Un contenedor independiente de PostgreSQL no se convierte automáticamente en la base de datos declarada por otro proyecto de Compose; los nombres de red, las credenciales, el descubrimiento del servicio, los volúmenes y la inicialización esperada de la base de datos deben coincidir.
Preguntas frecuentes
¿Por qué falló mkdir aunque ZimaOS tenía almacenamiento libre?
El instalador se estaba ejecutando en una parte del sistema de solo lectura, no en un directorio de datos con permisos de escritura. Tener espacio libre en otra ubicación no hace que la ruta actual del sistema tenga permisos de escritura.
¿Ejecutar el instalador desde /DATA resolvió completamente el problema de AdventureLog?
Resolvió el error del directorio de instalación y permitió instalar el stack. El problema posterior de disponibilidad de PostgreSQL quedó sin resolver en el hilo.
