[RÉSOLU] 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

Bonjour,

Je crois que j’ai résolu mon problème. Ca venait peut-être plutôt de grub… La commande qui a fini par me dépanner et me permettre demarrer depuis le disque dur du serveur est

grub-install /dev/sda

Je ne sais pas si ça pourras en dépanner d’autres j’ai tenté plein de trucs avant de le faire repartir (Dont l’installation de différents kernel).

Merci Kit pour les informations contenu dans le dossier boot ça m’a permis de voir les différences avec mon serveur. Et merci Aleks de m’avoir mis sur la piste de Kernel et Grub.

1 Like

Avec plaisir. Pense à mettre le topic en “Résolu”

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.