O instalador foi iniciado a partir de uma localização só de leitura
O instalador de shell do AdventureLog iniciou-se normalmente, mas falhou quando tentou criar ./adventurelog. No ZimaOS, o sistema base funciona como um dispositivo e é só de leitura, pelo que um script que assume que o diretório atual é gravável pode falhar, mesmo quando o armazenamento ligado está saudável.
Outro utilizador deparou-se com uma verificação de dependências diferente
Outro participante comunicou que o instalador parou imediatamente porque não conseguiu encontrar docker-compose. Esse não era o mesmo erro que o original mkdir erro, e o tópico não estabeleceu um comando universal para instalar pacotes no anfitrião ZimaOS.
A solução demonstrada consistia em trabalhar em /DATA
Um membro da equipa IceWhale começou por avisar que, em geral, não é recomendável trabalhar através da CLI, a menos que isso faça parte de uma investigação orientada. A demonstração foi realizada numa máquina de teste, com a recomendação explícita de evitar experiências num sistema de produção, a menos que o operador compreenda os riscos informáticos e de segurança dos dados.
Para um utilizador experiente, a sequência demonstrada foi:
sudo -i
cd /DATA
mkdir 10-16test2
cd 10-16test2/
curl -sSL https://get.adventurelog.app | bashA principal alteração foi o diretório de trabalho: /DATA destina-se a dados graváveis, ao contrário da camada de sistema só de leitura. O URL do instalador está disponível em ponto de instalação do AdventureLog.
Uma instalação bem-sucedida não significava que a aplicação estivesse funcional
O autor original confirmou mais tarde que a instalação foi concluída depois de seguir as instruções relativas ao caminho com permissões de escrita. No entanto, o backend do AdventureLog não arrancou e os respetivos registos indicavam repetidamente que o PostgreSQL estava indisponível. Instalar uma aplicação PostgreSQL separada a partir da App Store do ZimaOS não a ligou automaticamente à stack do AdventureLog.
O tópico termina sem uma solução confirmada para a base de dados. Um contentor PostgreSQL autónomo não é automaticamente a base de dados declarada por outro projeto Compose; os nomes de rede, as credenciais, a deteção do serviço, os volumes e a inicialização esperada da base de dados têm todos de corresponder.
Perguntas frequentes
Porque é que o mkdir falhou, apesar de o ZimaOS ter armazenamento livre?
O instalador estava a operar numa parte do sistema só de leitura, e não num diretório de dados com permissões de escrita. Ter espaço livre noutra localização não torna gravável o caminho atual do sistema.
Executar o instalador em /DATA resolveu completamente o problema do AdventureLog?
Resolveu o erro do diretório de instalação e permitiu instalar a stack. O problema posterior de disponibilidade do PostgreSQL permaneceu por resolver no tópico.
