Purtroppo non ha funzionato, l’URL non è cambiato dopo aver ricostruito l’HTML e porta ancora a \n\u003e Ops! Questa pagina non esiste o è privata.\n\n\nAltre idee o pensieri?
La ricostruzione dall’UX ha funzionato o no?
Fare clic sul pulsante “Ricostruisci HTML” non ha funzionato. Il link non è cambiato e porta ancora alla pagina di errore.
C’è un secondo problema che ho notato dopo il ripristino. Ho dato un’occhiata ai log degli errori e ho notato questo. Il link non è lo stesso di quello nel post che ho ricostruito:
Failed to process hijacked response correctly : Errno::ENOENT : No such file or directory @ rb_sysopen - /XXXXX.s3.dualstack.us-east-1.amazonaws.com/optimized/1X/46728e07f9819907d1b18387bf02ea7fc25c7981_2_32x32.ico
La cosa strana è che quando inserisco l’URL sopra nel browser, in realtà serve l’icona.
Ecco il backtrace
Messaggio (5 copie segnalate)
Errore nell’elaborazione della risposta dirottata : Errno::ENOENT : No such file or directory @ rb_sysopen - /XXXXX.s3.dualstack.us-east-1.amazonaws.com/optimized/1X/46728e07f9819907d1b18387bf02ea7fc25c7981_2_32x32.ico
Backtrace
/var/www/discourse/app/controllers/static_controller.rb:160:in
read' /var/www/discourse/app/controllers/static_controller.rb:160:inblock (2 levels) in favicon’
/var/www/discourse/lib/distributed_memoizer.rb:16:inblock in memoize' /var/www/discourse/lib/distributed_mutex.rb:33:inblock in synchronize’
/var/www/discourse/lib/distributed_mutex.rb:29:insynchronize' /var/www/discourse/lib/distributed_mutex.rb:29:insynchronize’
/var/www/discourse/lib/distributed_mutex.rb:14:insynchronize' /var/www/discourse/lib/distributed_memoizer.rb:12:inmemoize’
/var/www/discourse/app/controllers/static_controller.rb:138:inblock in favicon' /var/www/discourse/lib/hijack.rb:56:ininstance_eval’
Allora non avevi bisogno di capire come ricostruire dalla riga di comando.
Non sono sicuro, ma sembra che lo stia trattando come un nome di file anziché come un bucket, ma dovrei guardare il codice sorgente per esserne certo.
Qualche altra idea/pensiero su come correggere i collegamenti interrotti di /short-url?
È successo anche a me, su un server Oracle Cloud. Il kernel è andato in panico, e così anch’io. Pensavo di essere fritto. Ma dopo circa sei o otto riavvii dalla console cloud, alcuni dei quali erano riavvii “stacca la spina”, e dopo circa mezz’ora di attesa, il server si è avviato abbastanza a lungo da permettermi di modificare grub.cfg e tornare al kernel precedente.
Sono riuscito così a salvare la mia istanza. Un giorno dopo, è stato offerto un altro aggiornamento del kernel, ed è stato allora che sono diventato più certo che la mia teoria sui problemi del kernel fosse vera. E ho trovato la descrizione del bug per confermarlo. Sì, piuttosto brutto.
Ho ideato uno “Stupid Grub Trick”, come lo chiamo io, che cercherò di trovare il tempo di pubblicare anonimamente, in modo che si possa evitare una tale calamità in futuro.
Buona fortuna con il tuo ripristino, @RBoy. Devo dire che questo thread mi dà un senso di nausea dopo il mio quasi disastro la scorsa – quando è stato, mercoledì?
A proposito, hai detto di aver riacquistato l’accesso al tuo vecchio server. Se lo hai ancora o puoi accedervi di nuovo – per me ci sono voluti alcuni riavvii forzati e un po’ di attesa – beh, entra e aggiorna ancora una volta, poiché c’è un altro nuovo kernel che non ha il bug. O torna al kernel precedente.