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

[Daniel Caillibaud]

Le 05/09/15 à 17:08, Vinc Teteve  a écrit :
VT>  Je ne veux absolument pas perdre les données sur le serveur...

Ça va pas résoudre ton problème mais peut-être te permettre d'essayer plus 
sereinement,
sauvegarde d'abord tes données
- boot en rescue et se connecter en ssh
- si elle n'y est pas ajouter ta clé ssh (dans /root/.ssh/authorized_keys
  ou /root/.ssh/authorized_keys2) pour éviter de retaper le mot de passe tout 
le temps
- mkdir /mnt/data 
- si tu sais pas quelle est la partition de data "parted -l" (ou lvdisplay si 
c'est du lvm)
- mount /dev/sdX /mnt/data

Et ensuite sur ton pc 
rsync -av root@serveur:/mnt/data/ /un/dossier/avec/assez/d/espace/libre
(tu peux aussi sauvegarder tout /etc, c'est pas énorme, et éventuellement des 
trucs de /var/lib
si tu as des datas perso dedans)

Sinon, pour travailler sur ton serveur en rescue, avant le chroot faut monter 
dedans les
dossiers spéciaux et tout ce qu'il faut pour que le système puisse tourner (par 
ex sans /var
apt-get marche moins bien…)

Si /dev/sdX est /boot, /dev/sdX la racine et /dev/sdZ /home, tu dois tout 
monter avant le chroot

# un dossier pour le chroot
mkdir /mnt/foo

# les partitions
mount /dev/sdY /mnt/foo
mount /dev/sdX /mnt/foo/boot
mount /dev/sdX /mnt/foo/home

# et les répertoires spéciaux
mount -o bind /proc /mnt/foo/proc
mount -o bind /sys /mnt/foo/sys/
mount -o bind /dev /mnt/foo/dev/
mount -o bind /dev/pts /mnt/foo/dev/pts/

# tu peux chroot
chroot /mnt/foo


-- 
Daniel

Pourquoi lave-t-on une injure alors qu'on essuie un affront ?
Alphonse Allais

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

[Grégory Bulot]

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


Je réponds, sachant que je ne suis pas l'auteur du post :

Y'a pas ipmi sur les kimsuffi

:-/

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

[bruno.debian]

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.

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

[bruno.debian]

Oui je m'en doute mais il n'a pas précisé quelle gamme il utilisait : 
kimsufi, soyoustart ou OVH.




On 08/09/2015 10:35, Grégory Bulot wrote:

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


Je réponds, sachant que je ne suis pas l'auteur du post :

Y'a pas ipmi sur les kimsuffi

:-/

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

[Vinc Teteve]

Bonsoir,

Le 7 septembre 2015 20:31, Jean-Michel OLTRA <
jm.oltra.antis...@espinasse.net> a écrit :
> Sur quel noyau tentes tu de démarrer ? Si tu cherches les archives (du
mois d'août, je pense), tu verras que, dans une configuration similaire
> (à part que j'ai md0 sur /boot), et avec un noyau 4.x, je ne pouvais plus
démarrer, suite à un souci sur lvm2. Actuellement, c'est corrigé
> chez Debian. Ça pourrait être ça ?

J'essaye de démarrer avec le noyau par défaut dans Proxmox v3 : le
2.6.32-26-pve
# ls -l /boot/
total 22944
-rw-r--r-- 1 root root  2525801 Oct 14  2013 System.map-2.6.32-26-pve
-rw-r--r-- 1 root root   104818 Oct 14  2013 config-2.6.32-26-pve
drwxr-xr-x 3 root root 4096 Sep  7 18:15 grub
-rw-r--r-- 1 root root 16639161 Sep  7 18:18 initrd.img-2.6.32-26-pve
-rw-r--r-- 1 root root  4207920 Oct 14  2013 vmlinuz-2.6.32-26-pve

Je n'ai pas fait de changement de noyau depuis le dernier reboot qui
fonctionnait...

> Le 8 septembre 2015 10:35, Grégory Bulot  a écrit :
> Je réponds, sachant que je ne suis pas l'auteur du post :
> Y'a pas ipmi sur les kimsuffi

Le serveur est un serveur dédié (gamme "pro") et non un kimsufi. Je
pourrais donc avoir l'option IPMI, sous réserve de souscrire l'option
"Pro", avec la sous-option "vKVM"...etc...
Ce qui ne rentre pas dans mon budget mensuel... :/

Par contre, j'avance un peu. J'ai lancé un reboot "classique" du serveur,
et demandé à OVH ce qu'il y avait sur l'écran :
"Voici le detail de l'intervention realisee:
Le serveur reste bloqué durant la phase de boot sur le message :
(grub)
Actions entreprises:
Redémarrage du serveur sur mode 'rescue' (Linux)
Resultat:
Boot OK. Systeme 'rescue' accessible."

J'ai donc bien un souci de grub...

Je viens de faire les manips indiquées par Daniel pour monter le chroot.
J'avais déjà essayé, mais apparemment le /dev/pts est indispensable...
Il n'était pas indiqué dans les tutos que j'avais trouvés, et ça me
bloquait pour monter mes volumes LVM.
Je lance toutes les sauvegardes ce soir, et tente une réinstall de grub
dans la foulée...

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

[Vinc Teteve]

Merci Jean-Michel pour ta réponse. Le problème est que mon fichier
/var/log/dmesg date de décembre 2014, date du dernier reboot réussi du
serveur.
Donc à priori, je pense que le serveur ne démarre pas du tout, à moins
qu'il ne log rien au démarrage...
J'ai beau retourner ma config dans tous les sens, je ne vois pas où peut se
trouver le problème.
J'ai 2 disques en RAID logiciel, avec /dev/md1 pour le système / et
/dev/md3 avec LVM pour les datas...

~# fdisk -l

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
[...]
Device Boot  Start End  Blocks   Id  System
/dev/sda1   *40962048204810238976+  fd  Linux raid
autodetect
/dev/sda220482049409610238976   82  Linux swap / Solaris
Partition 2 does not start on physical sector boundary.
/dev/sda340960001  1953517568   956278784   fd  Linux raid
autodetect
Partition 3 does not start on physical sector boundary.

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
[...]
Device Boot  Start End  Blocks   Id  System
/dev/sdb140962048204810238976+  fd  Linux raid
autodetect
/dev/sdb220482049409610238976   82  Linux swap / Solaris
Partition 2 does not start on physical sector boundary.
/dev/sdb340960001  1953517568   956278784   fd  Linux raid
autodetect
Partition 3 does not start on physical sector boundary.

Disk /dev/md3: 979.2 GB, 979229409280 bytes
2 heads, 4 sectors/track, 239069680 cylinders, total 1912557440 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Alignment offset: 3584 bytes
Disk identifier: 0x
Disk /dev/md3 doesn't contain a valid partition table

Disk /dev/md1: 10.5 GB, 10484645888 bytes
2 heads, 4 sectors/track, 2559728 cylinders, total 20477824 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x
Disk /dev/md1 doesn't contain a valid partition table

Disk /dev/mapper/vg--vm-lv--vm: 107.4 GB, 107374182400 bytes
255 heads, 63 sectors/track, 13054 cylinders, total 209715200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x
Disk /dev/mapper/vg--vm-lv--vm doesn't contain a valid partition table

Disk /dev/mapper/vg--vm-lv--bck: 32.2 GB, 32212254720 bytes
255 heads, 63 sectors/track, 3916 cylinders, total 62914560 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x
Disk /dev/mapper/vg--vm-lv--bck doesn't contain a valid partition table

Disk /dev/mapper/vg--vm-lv--data: 805.3 GB, 805306368000 bytes
255 heads, 63 sectors/track, 97906 cylinders, total 1572864000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x
Disk /dev/mapper/vg--vm-lv--data doesn't contain a valid partition table

~# dd if=/dev/sda bs=446 count=1
[;;;]GRUB GeomHard DiskRead Error
1+0 records in
1+0 records out
446 bytes (446 B) copied, 3.3286e-05 s, 13.4 MB/s

Je me pose une question bête : GRUB doit bien être installé sur /dev/sda,
et pas sur /dev/md1 ??
Et comment être sûr que le système log bien ce qu'il fait au boot ?

Cdlt

Le 6 septembre 2015 14:26, Jean-Michel OLTRA <
jm.oltra.antis...@espinasse.net> a écrit :

>
> Bonjour,
>
>
> Le samedi 05 septembre 2015, Vinc Teteve a écrit...
>
>
> > 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...
>
> Lorsque tu tentes le boot sur le disque, tu dois avoir des logs que tu
> peux lire en rebootant en rescue juste derrière.
>
> D'autre part, il faudrait voir ce que tu as d'activé en mode rescue, en
> comparaison du mode normal (points de montage, services…).
> Éventuellement tenter des redémarrages manuels, pour voir ce qui
> pourrait bloquer (déjà, ce qui a été mis à jour partiellement), les
> désactiver sur la séquence de boot et tenter des redémarrages en mode
> normal. Par élimination et tâtonnements, tu pourrais trouver une
> séquence de boot valide sur le disque avec ce qui fonctionne encore.
>
> --
> jm
>
>

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

[Jean-Michel OLTRA]

Bonjour,


Le lundi 07 septembre 2015, Vinc Teteve a écrit...


> J'ai 2 disques en RAID logiciel, avec /dev/md1 pour le système / et
> /dev/md3 avec LVM pour les datas...

Sur quel noyau tentes tu de démarrer ? Si tu cherches les archives (du
mois d'août, je pense), tu verras que, dans une configuration similaire
(à part que j'ai md0 sur /boot), et avec un noyau 4.x, je ne pouvais
plus démarrer, suite à un souci sur lvm2. Actuellement, c'est corrigé
chez Debian. Ça pourrait être ça ?

-- 
jm

[HS]Re: Serveur dédié injoignable - erreur de boot

[Grégory Bulot]

Le Sat, 5 Sep 2015 17:08:01 +0200,
Vinc Teteve  a écrit :

> Bonjour à tous, 

Salut, 

Je me permets de répondre limite HS. J'ai eu un problème similaire en
apparence, la solution était de réutiliser le noyau "ovh" au boot
(modification directe de /boot/grub/grub.cfg pour specifier le bon No
correspondant au menuentry, sa commence à 0 ...)

alors certe, c'est un noyau 2.6, mais cela a été salvateur (je ne
retrouve plus la page qui en parle)

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

[Jean-Michel OLTRA]

Bonjour,


Le samedi 05 septembre 2015, Vinc Teteve a écrit...


> 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...

Lorsque tu tentes le boot sur le disque, tu dois avoir des logs que tu
peux lire en rebootant en rescue juste derrière.

D'autre part, il faudrait voir ce que tu as d'activé en mode rescue, en
comparaison du mode normal (points de montage, services…).
Éventuellement tenter des redémarrages manuels, pour voir ce qui
pourrait bloquer (déjà, ce qui a été mis à jour partiellement), les
désactiver sur la séquence de boot et tenter des redémarrages en mode
normal. Par élimination et tâtonnements, tu pourrais trouver une
séquence de boot valide sur le disque avec ce qui fonctionne encore.

-- 
jm

Serveur dédié injoignable - erreur de boot

[Vinc Teteve]

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.