trekfan1 ha scritto: ↑sabato 14 maggio 2022, 6:58
@LucaZeta non fare risposte consecutive se non ci sono risposte ma clicca sulla matita e aggiungi il nuovo testo eventualmente preceduto da EDIT, grazie
Corretto come suggerito. La rimozione dei "consecutivi" non è permessa all'utente.
Ubuntello ha scritto: ↑sabato 14 maggio 2022, 14:04
Considera anche che “tornare indietro” può significare solo rimandare l'inevitabile
* (ovvero capire come porre rimedio a un determinato problema), che chiaramente può avere senso se al momento non si ha sufficiente tempo per approfondire.
* È probabile che sia così quando un programma rifiuta di avviarsi e indica esattamente cosa c'è che non va per l'attuale versione, e quindi ciò dovrebbe essere previsto dai suoi sviluppatori; sempre che non ci siano cambiamenti nelle versioni successive.
A meno di disporre di una finestra di disservizio illimitata, il roll-back quale estrema ratio permette di rimanere nei tempi previsti.
Evidente che dopo il roll-back deve seguire una fase di analisi in ambiente adeguato atta a risolvere il problema, oppure come in questo caso, attendere con la speranza che il problema venga risolto dagli amministratori Ubuntu.
Ho iniziato con Ubuntu 16.04, la migrazione in 18.04 l'ho dovuta fare a partire dall'istallazione ed è stata impegnativa, invece per quella 20.04 è bastata la procedura do-release-upgrade.
sono uno pari, quindi. Speriamo bene.
[AGGIORNAMENTO]
Rilasciata ufficialmente, come previsto ad Agosto, la procedura do-release-upgrade, ho verificato su un muletto la sua corretta esecuzione:
tramite CLONEZILLA (si tratta di una utility che consente la clonazione di dischi e/o partizioni da un sorgente ad un target) ho riportato l'esatta configurazione del server Ubuntu 20.04.4 LTS sul muletto e su quello ho testato do-release-upgrade.
Premesso che Focal Fossa utilizza php7.4 e Jammy Jellyfish utilizza php8.1 è lecito aspettarsi: 1) che l'utente abbia già verificato la compatibilità di tutte le sue web application prima di iniziare la procedura di upgrade 2) che la procedura di upgrade termini con un ambiente php8.1 funzionante
Così non è, perché ad un certo punto la procedura di upgrade segnala un errore che impedisce ai servizi HTML e mysql di partire.
Codice: Seleziona tutto
apache2_reload: apache2: Syntax error on line 146 of /etc/apache2/apache2.conf: Syntax error on line 3 of /etc/apache2/mods-enabled/php7.4.load: Cannot load /usr/lib/apache2/modules/libphp7.4.so into server: /usr/lib/apache2/modules/libphp7.4.so: cannot open shared object file: No such file or directory
Tra le ricerche effettuate ho notato che la stessa anomalia era già stata riscontrata durante l'upgrade di release da
21.04 a 21.10
CONCLUSIONE: Il problema segnalato costituisce una piccola imperfezione nel processo di aggiornamento che non è difficile risolvere con pochi interventi manuali. La retro compatibilità php7.4 non viene assicurata da Canonical, ma è disponibile su PPA di ondrej.
Considero il test un successo e mi ripropongo di riflettere sull'opportunità di eseguire l'aggiornamento per poi perfezionarlo aggiungendo una compatibilità non prevista, dall'ambiente standard, a php7.4 a cui non posso ancora rinunciare.