Hai qualche altro dettaglio? Sto riscontrando lo stesso problema.
1 Mi Piace
Per chi sta riscontrando lo stesso problema, ecco il riepilogo (generato dall’IA) di quello che ho fatto:
Avvia temporaneamente PG15 → Esegui il dump del database → Usa PG18 → Ripristina il dump
1 Mi Piace
Quindi sì, questo aggiornamento è basato su immagini.
Quindi anche se scegli di installare una vecchia versione di Discourse, l’immagineforcerà comunque un aggiornamento alla versione 18?
Capito.
1 Mi Piace
Vedo che l’hai risolto, ma il metodo suggerito da ChatGPT, sebbene abbia corretto l’errore, ha comunque cancellato il mio database, quindi essenzialmente nessun account, nessuna discussione o messaggio.
Fortunatamente si trattava di un forum di sviluppo relativamente nuovo, quindi non è stata persa troppa roba.
2 Mi Piace
Si è prestata grande attenzione per assicurarsi che ciò non accadesse oggi. Dopo ogni passaggio, mi confermava che non sarebbe stato cancellato nulla, e avevo l’impressione che avessimo verificato tre volte che tutti i dati fossero stati migrati prima di concordare la cancellazione delle cose che non ci servivano più.
Ma se fosse andato tutto storto, l’unico dato che mi sarebbe mancato sarebbe stata la configurazione del componente del tema.
1 Mi Piace
Ciao, io ho un forum con database piuttosto grande (circa 80 GB), per il passaggio da 13 a 15, ho cambiato server, fatto nuova installazione e ripristinato.
Consigliate lo stesso passaggio? (ho provato l’upgrade ma ho errori di collation)
Più indietro nella discussione lo staff ha dichiarato:
Quindi, sì, è un’opzione
Hai già detto:
Errori di ordinamento? Che versione è l’attuale Discourse?
Forse pubblica gli errori che hai incontrato / l’output della console
ma non sei rimasto senza spazio (raccomandato 2 x dimensione del database esistente) ?
Ciao, spazio ne ho (250 gb liberi) errore era “collation mismatch” ma mi sa che non ho le stringhe utf nel file app.yml
1 Mi Piace
Cerciamo di fornire impostazioni predefinite ragionevoli nelle immagini discourse_docker, ma non è possibile prevedere ogni possibile caso d’uso. Sentiti libero di personalizzare le tue immagini per mantenere versioni precedenti, se lo preferisci.
In una certa misura, le versioni delle dipendenze riflettono i nostri requisiti di hosting: utilizziamo l’immagine di base internamente. Ciò significa che non dovrebbe diventare troppo obsoleta, ma implica anche che possiamo mantenere solo un numero limitato di combinazioni.
È un metodo perfettamente valido se ti senti più a tuo agio con esso.
Se l’avviso viene generato durante la preparazione del dump del vecchio DB, non c’è motivo di preoccuparsi. Stiamo eseguendo il server solo contro la vecchia directory dei dati allo scopo di eseguire pg_dump. Quando il dump viene ripristinato nel nuovo server, gli indici vengono ricreati.
Il motivo per cui vedi questo è che negli ultimi giorni abbiamo rilasciato una nuova versione dell’immagine di base che aggiorna da Debian Bookworm a Trixie, cambiando la versione di glibc. Le impostazioni locali basate sul provider libc (che probabilmente stavi usando) non sono stabili tra gli aggiornamenti di glibc, quindi quando lo script di aggiornamento avvia un server Postgres per eseguire il dump dei tuoi vecchi dati, visualizza avvisi di disallineamento dell’ordinamento.
Il disallineamento dell’ordinamento è l’unico motivo per cui stiamo eseguendo il dump e il ripristino invece di eseguire pg_upgrade. Una volta che il tuo DB utilizza C.UTF-8 con il provider builtin, gli aggiornamenti a glibc non influenzeranno più gli ordinamenti.
2 Mi Piace
Ho eseguito l’aggiornamento stasera ed è andato secondo i piani. Ho ricevuto gli stessi avvisi sulla collation del database, ma sembra che dovremmo ignorarli. Grazie.
2 Mi Piace
Ho provato a inserire in app.yml
app.yml
templates:
- “templates/postgres.15.template.yml”
- “templates/redis.template.yml”
- “templates/web.template.yml”
- “templates/web.ratelimited.template.yml”
Per posticipare l’upgrade, ma ho questo errore
Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
replace failed with the params {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
Sembra che il contenitore base sia sbagliato, credo. Hai eseguito un ./launcher rebuild? Dovrebbe fare un git pull, ma potresti provare a eseguire un git pull per vedere se cambia qualcosa.
1 Mi Piace
Stesso errore
Digest: sha256:837e8ed4b5916baa36856b842ad84fe262b6b1b5550701f8844b13cc7acad7a5
Stato: Scaricata immagine più recente per discourse/base:2.0.20260812-0036
docker.io/discourse/base:2.0.20260812-0036
Verifica che il launcher sia aggiornato
Il launcher è aggiornato
Arresto del vecchio container
- /usr/bin/docker stop -t 600 app
app
2.0.20260812-0036: Pulling from discourse/base
Digest: sha256:837e8ed4b5916baa36856b842ad84fe262b6b1b5550701f8844b13cc7acad7a5
Stato: L’immagine è aggiornata per discourse/base:2.0.20260812-0036
docker.io/discourse/base:2.0.20260812-0036
/usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups.rb
/usr/local/bin/pups --stdin
I, [2026-08-25T06:22:16.249062 #1] INFO – : Lettura da stdin
I, [2026-08-25T06:22:16.274434 #1] INFO – : File > /etc/service/postgres/run chmod: +x chown:
I, [2026-08-25T06:22:16.281650 #1] INFO – : File > /etc/service/postgres/log/run chmod: +x chown:
I, [2026-08-25T06:22:16.287846 #1] INFO – : File > /etc/runit/3.d/99-postgres chmod: +x chown:
I, [2026-08-25T06:22:16.293208 #1] INFO – : File > /root/install_postgres chmod: +x chown:
I, [2026-08-25T06:22:16.299851 #1] INFO – : File > /root/upgrade_postgres chmod: +x chown:
FALLITO
Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
Posizione del fallimento: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
La sostituzione è fallita con i parametri {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
Il bootstrap è fallito con codice di uscita 1
** BOOTSTRAP FALLITO ** si prega di scorrere verso l’alto e cercare messaggi di errore precedenti, potrebbe essercene più di uno.
./discourse-doctor può aiutare a diagnosticare il problema.
2d15a756bfd82ed45debfbb4936784721293a3aeecabe8ba9b58c64d4bbe16e1
1 Mi Piace
Penso di aver trovato la causa.
L’immagine base corrente installa il server PostgreSQL 18, ma postgres.15.template.yml presuppone ancora che i pacchetti del server PostgreSQL 15 siano già presenti. Di conseguenza, tenta di accedere a:
/etc/postgresql/15/main/postgresql.conf
prima che questo file esista, generando l’errore ENOENT sopra menzionato.
Ho aperto una piccola PR che fa in modo che il template di blocco (holdback) per PostgreSQL 15 rimuova i pacchetti del server PostgreSQL 18 e installi i pacchetti del server PostgreSQL 15 prima di configurare PostgreSQL:
Questo dovrebbe ripristinare il percorso previsto, in cui la modifica di postgres.template.yml in postgres.15.template.yml rinvia l’aggiornamento a PostgreSQL 18.
4 Mi Piace
E’ stato rilasciato l’aggiornamento?
Quando potrò riprovare? (solo per informazione)
Ho unito la correzione (grazie @Ethsim2!), quindi dovresti riuscire a riprovare.
2 Mi Piace
Funziona, grazie mille!
2 Mi Piace
L’aggiornamento è andato bene per chi ha più container sullo stesso server? Se ho tempo questo fine settimana, potrei aggiornare il nostro - ho solo pensato di chiedere qui prima, nel caso in cui fosse meglio aspettare.
sì, ho fatto gli aggiornamenti su due container su un unico server un paio di settimane fa (anche su un server russo). Nessun problema, ma assicurati prima di avere abbastanza spazio su disco.
3 Mi Piace
Consiglio per chi esegue aggiornamenti di PostgreSQL al di fuori di Docker. Puoi usare --link con pg_upgrade in modo da non dover copiare i dati. È possibile creare hard link dei dati. Rispar spazio su disco.
2 Mi Piace