L'aggiornamento di Discourse continua a fallire

Questa è probabilmente quella che funzionerà. Puoi avviare quell’immagine con, ad esempio, docker start b5f2a8a39709.

(Potresti anche voler eliminare alcune di quelle immagini più vecchie: c’è potenzialmente una grande quantità di spazio su disco che può essere recuperata!)

2 Mi Piace

Ottenimento: Risposta di errore dal demone: Nessun container: b5f2a8a39709

Grazie. Inoltre, le mie procedure di backup copiano TUTTI i file dal sistema. Ci sono probabilmente immagini più recenti lì se sapessi dove guardare e dove copiarle.

Mi scuso per aver interrotto il workaround, ma migreremo su un altro server, il che è stata una sfida di per sé perché si trattava di un server dedicato e abbiamo appena rinnovato il contratto per un anno intero lo scorso giugno.

Forse sarebbe bello se il team di Discourse emettesse un avviso per le persone che lo gestiscono su server non più supportati. Scoprirlo nel modo in cui l’abbiamo fatto è MOLTO spiacevole. (tre utenti con lo stesso problema, stiamo parlando di server, non vengono rinnovati alla stessa velocità dei laptop.)

1 Mi Piace

Voglio che sia chiaro che questa non è stata una modifica intenzionale.

Inoltre, non abbiamo accesso diretto a hardware così vecchio e dobbiamo fare affidamento sull’assistenza della community qui per determinare esattamente cosa sta andando storto.

Una volta che sapremo con certezza che si tratta di un problema di compilazione con la gemma stessa, potremo agire.

3 Mi Piace

@here

L’aggiunta di una chiave di primo livello nel file app.yml con

base_image: discourse/base:2.0.20220621-0049-slim

dovrebbe risolvere il problema, anche se rallenterà un po’ le ricostruzioni.

3 Mi Piace

È giusto, ma tali server sono ancora offerti da provider in tutto il mondo come server a basso costo.
Per molti progetti open source più piccoli, tali server sono ideali, dal punto di vista del prezzo e spesso non possono permettersi un Intel Xeon o AMD Ryzen con 32 GB di RAM.

Capisco perfettamente che tu non abbia l’hardware su cui testare il software, ma dalla comunicazione in questo thread, è stato stabilito da noi e poi non c’è stata alcuna reazione.
Un semplice mi dispiace, ci daremo un’occhiata sarebbe stato sufficiente in questo caso, invece ci hai lasciati lì ad aspettare.

1 Mi Piace

Sto testando ora con questa modifica.

La build sembra fallire allo stesso modo.

Questo è stato con la modifica a containers/app.yml, aggiungendo:

base_image: discourse/base:2.0.20220621-0049-slim

verso l’alto.

1 Mi Piace

Ciò significa che il problema non è che spediamo una versione precompilata della gemma, ma che la gemma upstream non può compilare su quelle vecchie CPU.

Abbiamo aperto la issue #789 contro la gemma oj.

2 Mi Piace

Capito. Vorrei ripristinare una delle mie recenti immagini docker – dai miei backup rsync. C’è una procedura che puoi indicarmi per individuarle e ripristinarne/avviarne una? Grazie!

Hai provato un ./launcher start app?

1 Mi Piace

Se questo non funziona, prova l’altro metodo che ho descritto per ricostruire dall’ultimo commit funzionante.

3 Mi Piace

Sì. Questo avvia il server web, ma non è possibile accedere a nessun thread, girano a vuoto.

Questo non aiuterà.

Il problema è che la gemma aggiornata non verifica se l’istruzione è supportata dalla CPU prima di utilizzarla.

Aiuterà a ripristinare l’istanza di Discourse, poiché installerà la versione precedente/funzionante della gemma (dimostrato da ciò che ho fatto per ripristinare l’istanza di Bryan), ma sì, qualsiasi ulteriore aggiornamento (tramite admin/upgrade) attiverà nuovamente lo stesso problema.

1 Mi Piace

Non sto avendo fortuna con una nuova build né riesco ancora a far funzionare l’istanza precedente, quindi dato che si avvicina il fine settimana potrei rimandare a settimana prossima nella speranza che la situazione possa essere risolta dal lato del gem…

Quale procedura era? Sono francamente un po’ confuso ora nel cercare di seguire le varie idee su questo thread. Grazie!

La seconda parte di questo post:

1 Mi Piace

Ci proverò. Grazie.

Un altro possibile workaround consiste nell’aggiungere quanto segue ad app.yml

hooks:
  after_code:
    - exec:
        cmd:
          - sed -i -e 's/oj (3.13.*/oj (3.13.14)/' Gemfile.lock
3 Mi Piace

Presumo che gli aggiornamenti sarebbero comunque non sicuri dopo questo, corretto? Sto eseguendo la build sul commit precedente.