Malheureusement, cela n’a pas fonctionné, l’URL n’a pas changé après la reconstruction du HTML et elle mène toujours à une page \n> Oops ! Cette page n’existe pas ou est privée.\n\nAvez-vous d’autres idées ou suggestions ?
La reconstruction à partir de l’UX a-t-elle fonctionné ou non ?
Cliquer sur le bouton « Reconstruire le HTML » n’a pas fonctionné. Le lien n’a pas changé et mène toujours à la page d’erreur.
Il y a un deuxième problème que j’ai remarqué après la restauration. J’ai consulté les journaux d’erreurs et j’ai remarqué ceci. Le lien n’est pas le même que celui du message que j’ai reconstruit :
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 chose étrange est que lorsque je mets l’URL ci-dessus dans le navigateur, elle affiche bien l’icône.
Voici la trace d’appels :
Message (5 copies signalées)
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
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’
Alors vous n’aviez pas besoin de comprendre comment reconstruire depuis la ligne de commande.
Je ne suis pas sûr, mais il semble qu’il traite cela comme un nom de fichier plutôt qu’un compartiment, mais je devrais examiner le code source pour en être sûr.
D’autres idées/réflexions sur la façon de corriger les liens brisés de /short-url ?
Cela m’est arrivé aussi, sur un serveur Oracle Cloud. Le noyau a paniqué, et moi aussi. Je pensais que j’étais perdu. Mais après environ six ou huit redémarrages depuis la console cloud, dont certains étaient des redémarrages “à la sauvage”, et après environ une demi-heure d’attente, le serveur a démarré assez longtemps pour que je puisse modifier grub.cfg et revenir au noyau précédent.
J’ai ainsi pu sauver mon instance. Un jour plus tard, une autre mise à jour du noyau était proposée, et c’est là que j’ai été plus certain que ma théorie sur les problèmes de noyau était vraie. Et j’ai trouvé la description du bug pour le confirmer. Oui, assez méchant.
J’ai conçu une astuce stupide pour Grub, comme je l’appelle, que j’essaierai de trouver le temps de poster bientôt, afin que l’on puisse éviter une telle calamité à l’avenir.
Bonne chance pour votre restauration, @RBoy. Je dois dire que ce fil me donne la nausée après mon propre quasi-désastre la semaine dernière – quand était-ce, mercredi ?
Au fait, vous avez dit que vous aviez retrouvé l’accès à votre ancien serveur. Si vous l’avez toujours ou si vous pouvez y accéder à nouveau – pour moi, cela a nécessité des redémarrages difficiles et un peu d’attente – eh bien, allez-y et mettez à jour une fois de plus, car il existe un autre nouveau noyau qui n’a pas le bug. Ou revenez au noyau précédent.