[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Serveur dédié injoignable - erreur de boot



Bonjour,

As-tu essayé d'utiliser la console IPMI pour avoir l'équivalent d'un accès physique au serveur. Tu pourras voir les messages affichés à l'écran.

ManagerV6 -> ton serveur -> onglet IPMI -> Depuis une applet Java  et hop, console comme si tu étais sur la machine physique

Bruno


On 05/09/2015 17:08, Vinc Teteve wrote:
Bonjour à tous,

Je commence par un petit historique de mes manip jusqu'aux problèmes actuels :
J'ai un serveur dédié chez OVH sur lequel est installé Proxmox 3.0, avec en gros une VM par service (toutes sous Debian dans des CT OpenVZ).
La semaine dernière, j'ai fait une mise à jour de la VM DNS. En fin de semaine, j'ai voulu ajouter un NDD sur cette VM. Impossible de m'y connecter en SSH (de mémoire, le message était : pas de pty disponible). Je me suis dit que les mises à jour ne devaient pas être terminée, et qu'elles devaient attendre un retour de ma part. J'ai redémarré la VM via l'interface Proxmox : VM up, mais impossible de m'y connecter en SSH (network error : Connection timed out). N'étant pas en état de chercher une solution intelligente, j'ai redémarré tout le serveur (sic...). Et depuis, impossible de me reconnecter sur l'hôte.
Là, intervention d'OVH :

"Cette opération a été achevée le 2015-09-04 03:10:46
Voici les détails de cette opération : 
Boot sur interface diagnostique (rescue)
Date 2015-09-04 03:07:47, yoann P a fait Boot sur interface diagnostique (rescue):
 Voici le detail de l'intervention realisee:
Le serveur lance un memtest lors du boot sur disque.
Actions entreprises: 
Redemarrage du serveur sur mode 'rescue' (Linux)
Resultat: 
Boot OK. Systeme 'rescue' accessible.
Recommandations:
Configuration/erreur a corriger par le client"

J'ai effectué les tests via le manager en mode rescue : tous OK. Je l'ai démarré en mode rescue, accès SSH OK. J'ai déplacé le répertoire /etc/grub.d/20_memtest86+ pour éviter qu'il lance un memtest au boot, mais toujours aucun accès SSH après reboot sur HD. Donc retour en mode rescue, et histoire de cumuler, j'ai eu la merveilleuse idée de me dire : "Une mise à jour du système va tout résoudre..." Donc apt-get update && apt-get upgrade en chroot sur ma partition principale /dev/md1.
Et là, c'est le drame :
"Errors were encountered while processing:
  bind9
  pve-cluster
  qemu-server
  pve-manager
 E: Sub-process /usr/bin/dpkg returned an error code (1)"
Donc bien évidemment, ça n'a rien résolu du tout !! Je me suis enfin dit qu'il valait mieux aller se coucher que de continuer à tout casser...
Donc au final, j'ai un serveur partiellement mis à jour en mode rescue, qui à priori démarre en HD, mais impossible de s'y connecter. Déjà, je voudrais commencer par résoudre ce problème de boot. Mais à distance, je ne sais pas où s'arrête la séquence de boot, dans quel état est le serveur...
Et je vous avoue ne pas trop savoir quoi chercher et par où commencer...

Si quelqu'un aurait une piste/idée, je suis preneur. De même, je n'ai pas envie de faire un pavé encore plus gros qu'actuellement avec des infos inutiles, mais n'hésitez pas si vous voulez plus d'infos techniques...
Je vais même aller plus loin : si quelqu'un se sent l'âme de me faire un devis pour une prestation de sauvetage de serveur, je suis également intéressé. Je ne veux absolument pas perdre les données sur le serveur...

Bon w-e à tous.


Reply to: