Aggiornamento della versione del kernel richiesto durante l'aggiornamento manuale di discourse

Installazione
22

Se si esegue rsync di /var/discourse tra droplet nello stesso data center, i tempi di inattività possono essere minimi e il fallback consiste semplicemente in una reversione del DNS.
Il nuovo VPS necessita solo di docker e potenzialmente di swap.

2 Mi Piace
23

Ciao,

Ricevo anch’io questo errore eseguendo Red Hat Enterprise Linux 7, con kernel 3.10.0. RHEL8 non esegue molto più recente.

1 Mi Piace
24

Uguale qui, 3.1.0.beta1 funziona bene su CentOS7 (3.10.0-1160.76.1.el7.x86_64)

Ovviamente i kernel delle distribuzioni ricevono un sacco di backport. Controllare la versione del kernel vanilla in questo modo ha causato problemi anche in altri progetti. C’è un modo per aggirare questo controllo dalla riga di comando?

—AGGIORNAMENTO—
Ho modificato lo script del launcher per aggirare il controllo - diverse installazioni di CentOS7 sono state aggiornate senza problemi.

5 Mi Piace
25

Questa questione riceverà maggiore attenzione? I requisiti di sistema non richiedono alcuna versione del kernel e Centos 7/RHEL 7 non è ancora in EOL. Anche Docker non richiede un kernel più recente. Non credo che aggirare manualmente il controllo sia la soluzione adeguata a lungo termine.

2 Mi Piace
26

Stavo per aggiornare un forum più vecchio e ho riscontrato lo stesso errore. Centos7 non ha ancora raggiunto la fine del suo ciclo di vita, potresti trovare una soluzione alternativa per Ubuntu 14.04?

27

Se ritieni di utilizzare il kernel più aggiornato dal tuo fornitore del sistema operativo (con correzioni backported), potresti voler provare a bypassare il controllo. So che lo farei! Questo è il problema in cui è stato aggiunto il controllo. Credo che potresti semplicemente rimuovere o commentare il comando exit nel tuo script ./launcher, in questo paragrafo:

  # Almeno versione minima
  if compare_version "${kernel_min_version}" "${test}"; then
    echo "ERRORE: Versione del kernel ${test} non supportata, aggiornare ad almeno ${kernel_min_version}"
    exit 1
  fi

Se, di conseguenza, l’aggiornamento fallisce ancora, dovrai trovare un modo per eseguire la tua installazione di Discourse su un kernel più recente.

(È abbastanza possibile che questo consiglio venga ritenuto fuori tema, ma penso che ciò che è successo sia che abbiamo un controllo per un numero di versione piuttosto che un controllo per una funzionalità (urandom), e quell’approccio può dare falsi positivi.)

4 Mi Piace
28

Sto riscontrando questo problema in questo momento e il nostro forum è inattivo a causa di questo. Come posso modificare lo script di avvio e commentare il controllo del kernel (almeno fino a quando Centos7 non riceverà questo aggiornamento o proveremo a spostare il forum su un altro server)?

AGGIORNAMENTO:
Sono riuscito (per tentativi ed errori) ad aggiornare Launcher e invece di commentare il kernel, ho semplicemente impostato una versione inferiore come requisito. Ha funzionato bene.

Forse questa non è una buona soluzione a lungo termine, ma la nostra società di hosting ci ha già informato che Centos7 non riceverà la versione del kernel 4.4… qualcuno può spiegare cosa significa in termini pratici?

1 Mi Piace
29

Sembra che Centos 7 riceverà aggiornamenti fino a metà 2024.

A un certo punto - possibilmente prima della fine del supporto - il Discourse in continua evoluzione avrà bisogno di qualcosa che Centos 7 non ha, e dovrai aggiornare il tuo sistema operativo (o migrare a una nuova istanza con una versione del sistema operativo adatta). Sembra che quel momento non sia ancora arrivato.

Come sempre, prima di provare ad aggiornare Discourse, ora o in futuro, esegui un backup dei tuoi forum e fai una copia di sicurezza di quel backup, oltre a una copia di sicurezza del tuo file app.yml.

1 Mi Piace
30

Qual kernel stai eseguendo che funziona con la ricostruzione che hai appena fatto?

Se è inferiore a 4.4 e funziona, allora sembra che @falco debba ridurre nuovamente la versione richiesta.

31

(Poiché le distribuzioni avranno back-port di funzionalità e correzioni da kernel successivi, il controllo della versione del kernel è uno strumento molto rozzo. Comprendo l’idea di ridurre il carico di supporto, ma c’è anche un effetto opposto quando il controllo di sicurezza ha un falso positivo. E con la crescente popolarità di Discourse, questo problema diventa più grande. È molto meglio controllare una funzionalità che una versione.)

2 Mi Piace
32

Il nostro sistema sta eseguendo quanto segue:

  • CentOS Linux release 7.9.2009 (Core)
  • Kernel 3.10.0-1160.88.1.el7.x86_64
1 Mi Piace
Change attachment size limit without rebuilding?
33

Aggiornamento di questo:\nAnche se il nostro forum ora funziona, vediamo questo errore sempre più spesso:\n\u003e # Oops\n\u003e \n\u003e Il software che alimenta questo forum di discussione ha riscontrato un problema imprevisto. Ci scusiamo per l’inconveniente.\n\u003e \n\u003e Informazioni dettagliate sull’errore sono state registrate e è stata generata una notifica automatica. Ci daremo un’occhiata.\n\u003e \n\u003e Non è necessaria alcuna ulteriore azione. Tuttavia, se la condizione di errore persiste, è possibile fornire dettagli aggiuntivi, inclusi i passaggi per riprodurre l’errore, pubblicando un argomento di discussione nella categoria di feedback del sito.\n\nPuò essere correlato in qualche modo al problema con i requisiti minimi del kernel? Questa "instabilità" (chiamiamola così) è diventata più evidente negli ultimi giorni/settimane. Sembra andare e venire, a volte il forum va bene, a volte no.\n\nEDIT: Lascia perdere, penso che fosse correlato a un problema di postgresql (avere troppi processi in corso associati a immagini senza un container, cosa che una pulizia del launcher ha risolto).

1 Mi Piace
34

Sarei propenso a concordare. Pensi che sia una buona idea @Falco?

1 Mi Piace
35

Sì, PR ben accetti per il feature detection corretto.

2 Mi Piace
36

Ciao Falco,

Ho riscontrato questo problema durante l’aggiornamento di Discourse da 3.1.0.beta2 a 3.1.0.beta4.

Sembrava un aggiornamento minore, ma a causa del controllo del kernel l’aggiornamento è stato piuttosto complesso su CentOS7. Forse la prossima volta un numero di versione diverso può riflettere meglio l’impatto relativamente elevato delle modifiche.

Leggendo la discussione non riesco a capire quale controllo delle funzionalità sia effettivamente necessario, forse se puoi elaborare su questo qualcuno è in grado di inviare una PR.

1 Mi Piace
37

È nel post di @Ed_S:

Su Ruby 3.1 si verifica una RuntimeException quando si chiama Random.urandom su piattaforme in cui non è implementato correttamente, il che include persone che eseguono Ubuntu 14.04 con kernel 3.13.

Kernel needs upgrading but that's not an option right now