L'installatore è stato avviato da una posizione in sola lettura
L'installatore shell di AdventureLog si è avviato normalmente, ma ha avuto esito negativo quando ha tentato di creare ./adventurelogSu ZimaOS, il sistema di base è simile a un'appliance ed è di sola lettura, quindi uno script che presuppone che la directory corrente sia scrivibile può non riuscire anche quando lo spazio di archiviazione collegato è integro.
Un secondo utente ha riscontrato un controllo delle dipendenze diverso
Un altro partecipante ha riferito che l'installatore si è arrestato immediatamente perché non riusciva a trovare docker-compose. Non si trattava dello stesso errore del problema originale mkdir errore, e la discussione non ha stabilito un comando universale per installare pacchetti sull'host ZimaOS.
La soluzione illustrata consisteva nell'operare sotto /DATA
Un membro del team IceWhale ha innanzitutto avvertito che l'uso della CLI non è generalmente consigliato, a meno che non faccia parte di un'indagine guidata. La dimostrazione è stata eseguita su una macchina di test, con la raccomandazione esplicita di evitare esperimenti su un sistema di produzione, a meno che l'operatore non comprenda i rischi per il computer e la sicurezza dei dati.
Per un utente esperto, la sequenza mostrata era:
sudo -i
cd /DATA
mkdir 10-16test2
cd 10-16test2/
curl -sSL https://get.adventurelog.app | bashLa modifica fondamentale riguardava la directory di lavoro: /DATA è destinata ai dati scrivibili, a differenza del livello di sistema in sola lettura. L'URL dell'installatore è disponibile presso l'endpoint di installazione di AdventureLog.
Installazione riuscita non significa che l’app sia operativa
L’autore originale ha successivamente confermato che l’installazione è stata completata dopo aver seguito le istruzioni relative a un percorso scrivibile. Tuttavia, il backend di AdventureLog non si è avviato e i suoi log hanno segnalato ripetutamente che PostgreSQL non era disponibile. Installare un’app PostgreSQL separata dall’App Store di ZimaOS non ha collegato automaticamente il database allo stack di AdventureLog.
La discussione termina senza una soluzione confermata al problema del database. Un container PostgreSQL autonomo non diventa automaticamente il database dichiarato da un altro progetto Compose; devono corrispondere nomi di rete, credenziali, rilevamento del servizio, volumi e inizializzazione prevista del database.
Domande frequenti
Perché mkdir non è riuscito anche se ZimaOS disponeva di spazio libero?
L’installer operava in una parte del sistema di sola lettura, non in una directory dati scrivibile. La capacità libera altrove non rende scrivibile il percorso di sistema corrente.
Eseguire l’installer in /DATA ha risolto completamente il problema di AdventureLog?
Ha risolto l’errore della directory di installazione e ha consentito di installare lo stack. Il successivo problema di disponibilità di PostgreSQL è rimasto irrisolto nella discussione.
