In sintesi: controlla la route predefinita prima di reinstallare i container
Nel caso reale della versione 1.6.2, Jellyfin, Vaultwarden e altre app sembravano non avviarsi, le impostazioni non si aprivano, i servizi dipendenti dal DNS non funzionavano e alcuni container comparivano solo dopo un lungo ritardo. La prova decisiva non indicava una corruzione di Docker: la route predefinita con la metrica più bassa puntava a 192.168.1.0 invece che al gateway reale 192.168.1.1. Una volta corretto il gateway nella GUI, la connettività esterna e lo stack delle app sono tornati operativi.
Per prima cosa, verifica se i container sono davvero inattivi
docker ps -a
docker info | grep -iE 'Docker Root Dir|Storage Driver'
docker stats --no-streamSe i container sono nello stato Created, Restarting o Exited, controlla i relativi log. Se sono in esecuzione, ma le loro interfacce web dipendono da DNS, Cloudflare o API remote, il problema potrebbe riguardare la raggiungibilità della rete anziché l'avvio del container.
Controlla quindi le route predefinite dell'host
ip route show default
ip route
Il caso analizzato mostrava diverse route predefinite e quella non valida aveva la metrica più bassa, quindi Linux la preferiva. Le metriche delle route Linux spiegano questa regola di instradamento.
Verifica separatamente l'IP diretto e il DNS
ping -c 3 1.1.1.1
getent hosts cloudflare.com
curl -I https://example.comSe 1.1.1.1 non risponde, correggi l'instradamento prima del DNS. Se l'IP diretto funziona ma i nomi non vengono risolti, controlla il DNS. In questo modo eviterai di diagnosticare erroneamente un gateway non funzionante come un problema di Pi-hole, Cloudflare o DNS di Docker.
Correggi l'interfaccia di rete in ZimaOS
Apri Impostazioni → Rete, seleziona l'interfaccia che gestisce la route predefinita e verifica IP statico, subnet, gateway e DNS. Le versioni attuali di ZimaOS mostrano ogni porta Ethernet fisica separatamente. Le impostazioni di rete di ZimaOS rappresentano il modello di configurazione attuale.
Il documento rete delle app di ZimaOS riguarda il livello delle app.
Perché un gateway errato può far sembrare guaste metà delle app
Le app con sole dipendenze locali possono avviarsi immediatamente. Altre attendono i registri delle immagini, il DNS, database remoti, servizi di certificazione o API cloud. Un host con connettività di rete parziale produce quindi una combinazione di sintomi che sembra casuale. Correggere ogni container singolarmente fa perdere tempo quando la dipendenza condivisa è la route dell'host.
La versione 1.6.2 era un aggiornamento di sicurezza e compatibilità
Le note ufficiali della versione 1.6.2 si concentrano sulla sicurezza di account, file e messaggistica, sul rafforzamento di SSH, sulle modifiche a kernel e driver, sulle correzioni USB e RAID; non documentano alcuna modifica intenzionale al gateway. Il caso analizzato va considerato una possibile regressione nella migrazione della configurazione di rete, non un comportamento progettato. Le modifiche di ZimaOS 1.6.2 forniscono il riferimento ufficiale.
Aggiorna alla versione stabile attuale prima di inseguire vecchi bug della 1.6.2
La versione 1.7.1 di ZimaOS ha successivamente migliorato l'efficienza di avvio di Docker, la rete di Docker durante l'installazione, la gestione dinamica degli URL e il comportamento dell'App Store. Se il sistema utilizza ancora la versione 1.6.2, esegui il backup dei dati importanti e passa al ramo stabile attuale prima di presumere che il vecchio bug sia ancora presente.
Il backup di ZimaOS costituisce il livello di sicurezza.
Il rollback consiste nell'avviare lo slot A/B alternativo, non nel fare un downgrade arbitrario
La documentazione pubblica attuale sul ripristino descrive l'avvio dello slot di sistema alternativo quando quello corrente non funziona. Non garantisce un downgrade supportato con un clic a una versione storica qualsiasi. Il ripristino del sistema ZimaOS è l'attuale procedura di recupero simile a un rollback.
Se l'instradamento è corretto ma la risoluzione dei nomi continua a non funzionare, confronta il server DNS configurato con un resolver indipendente. Il test DNS di Cloudflare può aiutare a dimostrare se il problema residuo riguarda il resolver anziché l'avvio di Docker.
Domande frequenti
Perché dopo la versione 1.6.2 hanno smesso di funzionare solo alcune app?
Le app con dipendenze da DNS o rete esterni possono non funzionare, mentre i container esclusivamente locali continuano a essere operativi.
Come faccio a capire se il gateway predefinito è errato?
Usa ip route e verifica che la route predefinita con la metrica più bassa punti all'indirizzo effettivo del router.
Devo reinstallare prima Jellyfin o Vaultwarden?
Non prima di aver verificato l'instradamento dell'host, il DNS e lo stato dei container.
Posso eseguire il rollback di ZimaOS a qualsiasi versione precedente?
Il ripristino pubblico attuale si concentra sull'avvio dello slot A/B alternativo, non su un downgrade arbitrario a una versione storica.
Devo rimanere alla versione 1.6.2?
Se possibile, esegui un backup e passa alla versione stabile attuale, quindi verifica nuovamente gli eventuali problemi residui.
