Migration Buster / Serveur Hs

Mon serveur YunoHost

Matériel: Serveur Kimsufi KS-4C
**Version de YunoHost: 4 ?
**J’ai accès à mon serveur : Mode rescue Ovh (Je n’ai plus de ssh, ni webmin)
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : Je viens de faire la migration vers Buster

Description du problème

Bonjour à vous,

J’ai fait hier soir une migration vers Buster via l’interface web d’administration Yunohost. La mise à jour semblait s’être bien déroulé mais après redémarrage je n’ai plus rien de fonctionnel. Mon serveur est un dédié Kimsufi donc je ne peux pas voir à quel moment ça bloque. En mode rescue les fichiers du dossier var/log reste à la date d’hier donc pas plus de pistes sur ce qui peux bloquer. Lorsque je fait un redémarrage Ovh semble indiquer que le ping est ok ce que je n’arrive pas à reproduire.

Auriez-vous une piste sachant que je suis donc dans un mode ou le disque est monté dans un dossier comme si je l’avais branché sur un autre Pc pour voir les fichiers.

Si vous avez besoin d’information supplémentaire n’hésitez pas à me demander.

Merci

Tu veux dire que OVH t’affiche clairement une info qui sous-entends que ton serveur devrait répondre au ping, mais lorsque tu ping l’IP correspondante, ça ne réponds pas ?

Oui c’est ça je reçois ce mail après redémarrage.

Bonjour,

Vous avez fait la demande d’un reboot hardware à distance sur
votre serveur ns329316.ip-X-X-X.eu. Nous venons d’exécuter votre
demande et votre serveur répond à nouveau au ping.
Vous pouvez vous connecter à votre serveur.

Pour votre information:

  • date de votre demande de reboot: 2020-10-17 11:28:53
  • date d’exécution du reboot hard: 2020-10-17 11:29:03
  • date de détection de ping : 2020-10-17 11:30:00

Cordialement,
L’équipe Kimsufi

Mais de mon côté ça ne ping pas et je ne comprends pas qu’il n’y ai absolument aucun mouvement dans /var/log

Sinon dans le résumé du serveur côté interface web Kimsufi je constate qu’il voit ceci: YunoHost 9.13 stretch 4.19-ovh-xxxx-std-ipv6-64

Si je monte la partition de boot en mode rescue j’ai ces fichiers:

config-4.19-ovh-xxxx-std-ipv6-64
grub
initrd.img-4.19-ovh-xxxx-std-ipv6-64
System.map-4.19-ovh-xxxx-std-ipv6-64
vmlinuz-4.19-ovh-xxxx-std-ipv6-64

Je vais creuser du côté de la mise à jours manuelle du kernel ce qu’il est possible de faire. Si certains d’entre vous sont sur Buster avec un serveur Ovh je serai curieux de savoir quel fichiers se trouvent dans votre dossier /boot.

Re:

Le problème semble donc bien provenir du Kernel. Dans l’interface Kimsufi j’ai un menu qui permet de faire si je comprend bien un boot sur un kernel réseau Ovh. Avec cette option j’accède maintenant au ssh et mon serveur est fonctionnel. Je vais faire un backup total avant de continuer (Je n’avais pas intégré Nextcloud avant de monter de version)

En attendant vous avez une idée de la manière dont je pourrais réparer mon système ensuite?

La première chose qui me viens à l’esprit, si c’est un problème de kernel, c’est que grub permet normalement de passer sur un ancien kernel au démarrage …

Salut,

J’ai un Kimsufi KS-1 sous Buster.

Kernel: 4.19.62-mod-std-ipv6-64-rescue

Et voici ce que j’ai sous /boot :

config-4.19.0-10-amd64  initrd.img-4.19.0-10-amd64  System.map-4.19.0-11-amd64
config-4.19.0-11-amd64  initrd.img-4.19.0-11-amd64  vmlinuz-4.19.0-10-amd64
grub                    System.map-4.19.0-10-amd64  vmlinuz-4.19.0-11-amd64