Infelizmente, isso não funcionou, o URL não mudou após a reconstrução do HTML e ainda leva a um\n> Oops! Essa página não existe ou é privada.\n\n\nAlguma outra ideia ou pensamento?
A reconstrução a partir da UX funcionou ou não?
Clicar no botão “Reconstruir HTML” não funcionou. O link não mudou e ainda leva à página de erro.
Há um segundo problema que notei após a restauração. Dei uma olhada nos logs de erro e notei isto. O link não é o mesmo que o do post que reconstruí:
Falha ao processar a resposta sequestrada corretamente : Errno::ENOENT : No such file or directory @ rb_sysopen - /XXXXX.s3.dualstack.us-east-1.amazonaws.com/optimized/1X/46728e07f9819907d1b18387bf02ea7fc25c7981_2_32x32.ico
O estranho é que quando coloco o URL acima no navegador, ele realmente serve o ícone.
Aqui está o backtrace
Mensagem (5 cópias relatadas)
Falha ao processar a resposta sequestrada corretamente : 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’
Então você não precisou descobrir como reconstruir a partir da linha de comando.
Não tenho certeza, mas parece que ele está tratando isso como um nome de arquivo em vez de um bucket, mas eu precisaria olhar o código-fonte para ter certeza.
Alguma outra ideia/pensamento sobre como corrigir os links quebrados de /short-url?
Isso também aconteceu comigo, em um servidor Oracle Cloud. O kernel entrou em pânico, e eu também. Pensei que estava perdido. Mas após cerca de seis ou oito reinicializações do console da nuvem, algumas das quais foram reinicializações de “puxar o plugue”, e após cerca de meia hora de espera, o servidor subiu tempo suficiente para eu editar o grub.cfg e reverter para o kernel anterior.
Consegui salvar minha instância com isso. Um dia depois, outra atualização de kernel foi oferecida, e foi quando fiquei mais certo de que minha teoria sobre problemas de kernel era verdadeira. E encontrei a descrição do bug para confirmá-lo. Sim, muito desagradável.
Criei um Truque Estúpido do Grub, como eu chamo, que tentarei encontrar tempo para postar em breve, para que se possa evitar tal calamidade no futuro.
Boa sorte com sua restauração, @RBoy. Devo dizer que este tópico me dá um nó no estômago depois do meu próprio quase desastre na semana passada - quando foi, quarta-feira?
A propósito, você disse que recuperou o acesso ao seu antigo servidor. Se você ainda o tem ou pode acessá-lo novamente - para mim, levou algumas reinicializações difíceis e alguma espera - bem, entre e atualize mais uma vez, pois há outro novo kernel que não tem o bug. Ou reverta para o kernel anterior.