Kimsufi en mode normal : pas de ssh, pas de http,

Bonjour,
plus d'accès ssh après reboot.

J'ai mis à jour mon système (debian) et le noyau a été mis à jour. J'ai fait un reboot. Mais au reboot, je n'ai plus d'accès au serveur. Plus d'accès ssh, plus de http,…

J'ai rebooté plusieurs fois en mode rescue, revenant sur un noyau précédent, en désactivant le firewall, fail2ban. J'ai regardé les logs mais je n'ai rien trouvé de pertinant.

Quelqu'un aurait une idée lumineuse pour quel que chose auquel je n'aurai pas pensé ?
Merci d'avance

Bonjour,

vous aviez attendu après reboot (pas qu'il était en fsck) ?
Avez-vous attendu une intervention de OVH pour avoir plus d'infos ?

Cordialement, janus57

Oui j'ai attendu après reboot.
Non je n'ai pas attendu d'intervention d'OVH.

Bonjour @NicolasR87,
Est-ce que vous avez des logs du boot sur la machine ? Est-ce qu'elle pinge ?
Pouvez-vous m'envoyer le nom du serveur par MP s'il vous plaît ?

J'ai cherché dans les logs quelque chose d'exploitable sans succès. J'ai abandonné depuis et j'en ai profité pour mettre à jour vers une nouvelle offre kimsufi plus récente, avec plus de disque, plus de mémoire, plus de cpu et pour moins cher.

Je comprends, merci pour l'info. Est-ce que vous pourriez tout de même me donner le nom du serveur car j'ai une suspicion au cas où ce serait une machine avec un CPU Atom située à Roubaix ? Dans ce cas-là, le serveur n'aurait pas du tout pingé au boot sur disque.

EDIT: vu par MP, ça semblait bien être un problème purement logiciel au niveau de l'OS installé. Difficile d'en savoir plus a posteriori mais j'ai l'impression que le serveur pingait bien une fois booté sur disque.

De mémoire, le serveur répondait bien au ping mais étant donné que je ne pouvais pas y accéder en ssh, il était difficile de comprendre ce qui posait problème.
En mode rescue, j'ai remonté un environnement chrooté mais pas réussi non plus à trouver le souci.

Ma recette (sûrement proche de ce que vous aviez fait), si ça peut être utile à quelqu'un pour plus tard, c'est :
```bash
# Sur nos installations récentes, la racine a le label root
mount LABEL=root /mnt
mount --types proc /proc /mnt/proc
mount --rbind /sys /mnt/sys
mount --make-rslave /mnt/sys
mount --rbind /dev /mnt/dev
mount --make-rslave /mnt/dev
chroot /mnt
```

Une fois dans le chroot :
```bash
# Pour les autres partitions du genre /var/log, /boot, etc.
mount -a
# Pour regarder les logs du dernier jour et chercher les lignes en rouge
journalctl -S -1d
```

Ma recette était presque la même. Je dois avouer que j'ai agit comme un débutant alors que c'est un système d'exploitation que je connais vraiment très bien. Je n'ai pas tout perdu dans l'histoire.

Faut-il que je mette résolu dans le sujet ou quelque chose pour signifier que le problème a été résolu ?

Je crois que vous pouvez utiliser cette icône sur l'une des réponses :