Debian Rescue Mode

Support Debian
#1

Bonjour à tous,

J’ai un problème sur mon serveur hébergé chez OVH.

Debian 8
5 disques de 6To en RAID1 (2 disques)et RAID5 (3 disques) logiciel.

Après l’intervention OVH a redémarré le serveur et depuis je n’arrive pas à démarrer normalement le serveur.
OVH me dit que après redémarrage le système a lancé fsck et tounait en boucle.

J’ai démarré le serveur en mode rescue et j’ai pas grand chose dans les logs.
le RAID semble bien fonctionné:

root@rescue:~# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md2 : active raid1 sda2[0] sdb2[1]
20478912 blocks [2/2] [UU]

md4 : active raid1 sda4[0] sdb4[1]
5823522624 blocks super 1.2 [2/2] [UU]

md127 : active raid5 sdc1[0] sde1[3] sdd1[1]
11720779776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
bitmap: 0/44 pages [0KB], 65536KB chunk

unused devices:

OVH me dit corriger la configuration de votre GRUB afin que votre système démarre normalement.

qqn pourrait m’aider pour corriger/reparer GRUB?

Merci bcp

#2

Quel rapport avec le mode rescue de Debian ?

“Après l’intervention” : quelle intervention ?

Je ne vois pas le rapport entre fsck qui tourne en boucle et la configuration de GRUB.
Je commencerais par vérifier tous les systèmes de fichiers avec fsck.

#3

Peut être je n’ai pas bien choisi le titre de sujet.
Le rapport avec Rescue mode est que OVH propose de démarrer le serveur en mode rescue mode et diagnostiquer/réparer le système.

OVH dit:
"D’après ce que vous m’avez indiqué par téléphone, le serveur tente de démarrer sur le disque mais ne lance pas le système.
Ceci semble provenir de la configuration de votre GRUB.
Comme indiqué par téléphone, suite à l’intervention de nos techniciens pour le remplacement du système de refroidissement de votre serveur, celui-ci démarrer normalement.
Une vérification du système de fichiers s’est lancé sur le serveur, mais ne s’est pas terminé normalement.
Nos techniciens sont intervenue afin de mettre votre serveur en mode rescue car celui-ci redémarrer en boucle.
Merci de corriger la configuration de votre GRUB afin que votre système démarre normalement. "

#4

C’est le mode rescue d’OVH, pas de Debian. Le mode rescue de Debian suppose que Debian démarre (mais sans démarrer les services dont SSH, donc pas très utile si on n’ a pas accès à une console).

As-tu fait la vérification de tous les systèmes de fichiers ?

#5

J’ai ça quand je verifié .

root@rescue:~# df -h
Filesystem Size Used Avail Use% Mounted on
aufs 16G 1.1M 16G 1% /
devtmpfs 16G 0 16G 0% /dev
91.121.126.137:/home/pub/rescue.v8 2.0T 280G 1.6T 15% /nfs
tmpfs 16G 1.1M 16G 1% /rw
91.121.126.137:/home/pub/pro-power 2.0T 280G 1.6T 15% /power
91.121.126.137:/home/pub/commonnfs 2.0T 280G 1.6T 15% /common
tmpfs 16G 0 16G 0% /dev/shm
tmpfs 16G 9.9M 16G 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 16G 0 16G 0% /sys/fs/cgroup
tmpfs 16G 580K 16G 1% /tmp
root@rescue:~# fdisk -l
root@rescue:~# mkdir /tmp/chroot
root@rescue:~# mount /dev/md2 /tmp/chroot/
mount: /dev/md2: can’t read superblock
root@rescue:~# mount /dev/md2
mount: can’t find /dev/md2 in /etc/fstab
root@rescue:~# dumpe2fs /dev/md2 | grep superblock
dumpe2fs 1.42.12 (29-Aug-2014)
dumpe2fs: Attempt to read block from filesystem resulted in short read while trying to open /dev/md2
Couldn’t find valid filesystem superblock.
root@rescue:~#
root@rescue:~# fsck /dev/md2
fsck from util-linux 2.25.2
e2fsck 1.42.12 (29-Aug-2014)
fsck.ext2: Attempt to read block from filesystem resulted in short read while trying to open /dev/md2
Could this be a zero-length partition?
root@rescue:~# df -h
Filesystem Size Used Avail Use% Mounted on
aufs 16G 1.2M 16G 1% /
devtmpfs 16G 0 16G 0% /dev
91.121.126.137:/home/pub/rescue.v8 2.0T 280G 1.6T 15% /nfs
tmpfs 16G 1.2M 16G 1% /rw
91.121.126.137:/home/pub/pro-power 2.0T 280G 1.6T 15% /power
91.121.126.137:/home/pub/commonnfs 2.0T 280G 1.6T 15% /common
tmpfs 16G 0 16G 0% /dev/shm
tmpfs 16G 9.9M 16G 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 16G 0 16G 0% /sys/fs/cgroup
tmpfs 16G 580K 16G 1% /tmp
root@rescue:~# df -hT /dev/md2
Filesystem Type Size Used Avail Use% Mounted on
devtmpfs devtmpfs 16G 0 16G 0% /dev

Avant mes montages ressemblait à ça .


/dev/md2 / ext4 errors=remount-ro,relatime 0 1
/dev/vg/backup /backup ext4 defaults,relatime 1 2
/dev/vg/pgsql /var/lib/postgresql ext4 defaults,relatime 1 2
/dev/sda3 swap swap defaults 0 0
/dev/sdb3 swap swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts defaults 0 0
cgroup /sys/fs/cgroup cgroup defaults 0 0

#6

Pas facile de se faire une idée sans être devant le terminal…
Que disent blkid et lsblk ?

Remarque : le swap sans RAID, c’est un peu bête. Le système risque d’en souffrir si un disque tombe en panne en cours de fonctionnement.

#7

Je suis d’accord c’est difficile ne pas avoir l’accès direct…
C’est different, si je suis connecté en KVM j’ai ça .

#8

Et si je suis connecté en mode rescue OVH j’ai ça .

#9

En fait avant, dans l’état normal, j’avais ça.

root@4dnackup:/# df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev 10M 0 10M 0% /dev
tmpfs 6,3G 649M 5,7G 11% /run
/dev/md2 20G 3,0G 16G 17% /
tmpfs 16G 4,0K 16G 1% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 16G 0 16G 0% /sys/fs/cgroup
/dev/mapper/vg-pgsql 9,8G 4,8G 4,5G 52% /var/lib/postgresql
/dev/mapper/vg-backup 7,4T 5,6T 1,5T 80% /backup

En mode Rescue OVH, j’ai créé le répertoire /tmp/chroot et monté /dev/md2 .

root@rescue:/# mkdir /tmp/chroot
root@rescue:/# mount /dev/md2 /tmp/chroot/

root@rescue:/tmp/chroot/var# mount --bind /sys /tmp/chroot/sys
root@rescue:/tmp/chroot/var# mount --bind /proc /tmp/chroot/proc
root@rescue:/tmp/chroot/var# mount --bind /dev /tmp/chroot/dev

root@rescue:/tmp/chroot/var/log# df -h
Filesystem Size Used Avail Use% Mounted on
aufs 16G 1.2M 16G 1% /
devtmpfs 16G 0 16G 0% /dev
91.121.126.137:/home/pub/rescue.v8 2.0T 280G 1.6T 15% /nfs
tmpfs 16G 1.2M 16G 1% /rw
91.121.126.137:/home/pub/pro-power 2.0T 280G 1.6T 15% /power
91.121.126.137:/home/pub/commonnfs 2.0T 280G 1.6T 15% /common
tmpfs 16G 0 16G 0% /dev/shm
tmpfs 16G 10M 16G 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 16G 0 16G 0% /sys/fs/cgroup
tmpfs 16G 556K 16G 1% /tmp
/dev/md2 20G 3.0G 16G 17% /tmp/chroot

Je me demande si je ferai #chroot /tmp/chroot et demarrer le serveur sur le disque dur, ça va fonctionner ou j’ai oublié de monter qqch?

#10

Quel est le système actif quand tu es connecté en KVM ? Comment en es-tu arrivé là ?

blkid identifie /dev/md2 comme un système de fichiers ext4, et lsblk indique que sa taille et non nulle et qu’il est monté en tant que racine.

Pourtant, dans ton message précédent, toutes les commandes sur ce périphérique échouaient, je ne comprends plus rien…

Une différence avec le mode rescue OVH est que les autres ensembles RAID, et donc les volumes logiques LVM qu’ils contiennent, ne sont pas activés.

#11

OVH, à travers espace client, te permet de connecter à ton serveur avec KVM.

#12

là je suis perdu aussi…
Si je recommence, quand j’ai démarré ce matin mon serveur sr DD et connecté en KVM, il me demande de me connecter et j’arrive à me connecter…

#13

#14

Et si je démarre en mode rescue OVH, je peux me connecter en SSH avec MDP envoyé par OVH et aussi faire la diagnostique sur le serveur web. Voilà à quoi ça ressemble…

root@rescue:~# lspci | grep -i lsi | grep -v megaraid
04:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)

#15

#16

Peux-tu remonter dans l’historique du terminal KVM pour voir l’erreur qui provoque le lancement du shell d’urgence? Sinon, exécuter journalctl -xb comme suggéré ?