# Plantage serveur Kimsufi, plus accès à rien

**URL:** <https://www.debian-fr.org/t/plantage-serveur-kimsufi-plus-acces-a-rien/80134>\
**Category:** Support Debian\
**Created:** [Septembre 11, 2019, 10:15 UTC](https://www.debian-fr.org/t/plantage-serveur-kimsufi-plus-acces-a-rien/80134 "2019-09-11T10:15:51Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![Brigadou](https://www.debian-fr.org/user_avatar/www.debian-fr.org/brigadou/32/8390_2.png) [@Brigadou](https://www.debian-fr.org/u/Brigadou)\
**Post date:** [Septembre 11, 2019, 10:15 UTC](https://www.debian-fr.org/t/plantage-serveur-kimsufi-plus-acces-a-rien/80134/1 "2019-09-11T10:15:51Z")

</div>

Bonjour à tous,

J’ai un serveur kimsufi sous Debian 8.10 (Jessie) (oldstable) (64bits) que je souhaitais upgrader puisque certains paquets de mises à jour dans webmin échouaient.  
J’ai rencontré des erreurs dès le départ, suivi ce tuto [https://phoenixnap.com/kb/how-to-upgrade-debian-8-jessie-to-debian-9-stretch](https://phoenixnap.com/kb/how-to-upgrade-debian-8-jessie-to-debian-9-stretch).  
J’ai eu des soucis avec libre office common et d’autres a supprimés (apparemment) puis avec ma sources list . J’ai quelques screen si besoin.

Bref en tentant de passer à buster hier, tout à planté, plus d’accés a winscp, rutorrent, ni rien. il me semble avoir vu dans putty une erreur avec MySQL aussi.  
Je ne sais pas quoi faire, ça dépasse mes maigres compétences pour le coup.  
A part tout réinstaller mais franchement ça m’embête, d’une parce que c’est un serveur multicomptes bien spécial qui a été monté par une personne, donc je serai incapable de tout refaire. De deux ce serait perdre tout le contenu, ça fait ch\*\*\* (disque de 2To plein à environ 70%)

Si un pro, une âme charitable dans le coin se sent capable de checker le problème, je lui passe volontiers la main.  
C’est ça ou la résiliation et après 4 ans ben c’est triste.

Un grand merci d’avance  
Briga

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Septembre 11, 2019, 12:02 UTC](https://www.debian-fr.org/t/plantage-serveur-kimsufi-plus-acces-a-rien/80134/2 "2019-09-11T12:02:47Z")

</div>

> [@Brigadou](#):
>
> Je ne sais pas quoi faire, ça dépasse mes maigres compétences pour le coup.

Je ne connais pas trop OVH (si si) mais tu as une option sous la main pour [rebooter le serveur en mode recovery](https://docs.ovh.com/fr/dedicated/ovh-rescue/), sur la même machine mais avec une distrib live. Tu as peut être aussi un accés genre KVM qui te permet de voir le boot de ta machine comme si tu étais devant.  
En tous cas en recovery, tu peux monter les disques, regarder dans les logs ce qui coince, réinstaller grub, faire des install comme si tu étais sur ta machine normal (en chroot).  
Mais je n’ai pas le temps de te dépanner là maintenant. Et je suis trés cher. 😃

---

<div class="post-metadata">

**Author:** ![Brigadou](https://www.debian-fr.org/user_avatar/www.debian-fr.org/brigadou/32/8390_2.png) [@Brigadou](https://www.debian-fr.org/u/Brigadou)\
**Post date:** [Septembre 11, 2019, 12:14 UTC](https://www.debian-fr.org/t/plantage-serveur-kimsufi-plus-acces-a-rien/80134/3 "2019-09-11T12:14:40Z")

</div>

Oui donc c’est pas pour moi. Je n’ai pas monté le serveur à l’époque mais une personne qui s’y connait bien. Mes compétences s’arrêtent aux mises à jour et pannes simples, de quoi entretenir le serveur quoi. je suis plutôt branché hardware que software, chacun son truc.  
Mais merci quand même 😉

---

<div class="post-metadata">

**Author:** ![nestor](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/e495f1/32.png) [@nestor](https://www.debian-fr.org/u/nestor)\
**Post date:** [Septembre 11, 2019, 12:27 UTC](https://www.debian-fr.org/t/plantage-serveur-kimsufi-plus-acces-a-rien/80134/4 "2019-09-11T12:27:34Z")

</div>

Bonjour,

Upgrader de jessie à stretch puis ensuite à buster avec des erreurs au premier upgrade, c’est suicidaire ?

Même en mode recovery, ça risque de pas être la joie…

Bon courage.

---

<div class="post-metadata">

**Author:** ![Brigadou](https://www.debian-fr.org/user_avatar/www.debian-fr.org/brigadou/32/8390_2.png) [@Brigadou](https://www.debian-fr.org/u/Brigadou)\
**Post date:** [Septembre 11, 2019, 1:24 UTC](https://www.debian-fr.org/t/plantage-serveur-kimsufi-plus-acces-a-rien/80134/5 "2019-09-11T13:24:37Z")

</div>

Il n’y a pas eu d’upgrade sous strech. il y a eu des conflits avec plusieurs paquets, mais j’avais encore accès à tout. c’est pendant l’up à buster que ça a coincé.  
Même en voulant mettre le rtmv2 à jour ça coincait déjà.

---

<div class="post-metadata">

**Author:** ![nestor](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/e495f1/32.png) [@nestor](https://www.debian-fr.org/u/nestor)\
**Post date:** [Septembre 11, 2019, 1:38 UTC](https://www.debian-fr.org/t/plantage-serveur-kimsufi-plus-acces-a-rien/80134/6 "2019-09-11T13:38:42Z")

</div>

> Il n’y a pas eu d’upgrade sous strech.

J’ai un serveur kimsufi sous **Debian 8.10 (Jessie) (oldstable) (64bits)** que je souhaitais upgrader puisque certains paquets de mises à jour dans webmin échouaient.  
J’ai rencontré des erreurs dès le départ, suivi ce tuto **[How to Upgrade Debian 8 Jessie to Debian Linux 9 Stretch {safely}](https://phoenixnap.com/kb/how-to-upgrade-debian-8-jessie-to-debian-9-stretch.)**  
J’ai eu des soucis avec libre office common et d’autres a supprimés (apparemment) puis avec ma sources list . J’ai quelques screen si besoin.

Bref **en tentant de passer à buster hier** , tout à planté, plus d’accés a winscp, rutorrent, ni rien. il me semble avoir vu dans putty une erreur avec MySQL aussi.

Là je ne suis pas…

---

<div class="post-metadata">

**Author:** ![Brigadou](https://www.debian-fr.org/user_avatar/www.debian-fr.org/brigadou/32/8390_2.png) [@Brigadou](https://www.debian-fr.org/u/Brigadou)\
**Post date:** [Septembre 11, 2019, 1:42 UTC](https://www.debian-fr.org/t/plantage-serveur-kimsufi-plus-acces-a-rien/80134/7 "2019-09-11T13:42:47Z")

</div>

Je me suis inspiré du tuto mais pour buster

---

<div class="post-metadata">

**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\
**Post date:** [Septembre 11, 2019, 2:00 UTC](https://www.debian-fr.org/t/plantage-serveur-kimsufi-plus-acces-a-rien/80134/8 "2019-09-11T14:00:29Z")

</div>

> [@Brigadou](#):
>
> J’ai eu des soucis avec libre office common et

On peut se poser la question : pourquoi diantre avoir des paquets `libreoffice*` sur un _serveur_ ?  
Sur un poste client

```plaintext
fp2@debpacha:~$ aptitude why libreoffice
i task-xfce-desktop Recommande libreoffice
fp2@debpacha:~$ 

```

Autant je comprend la présence de paquets `texlive*` ou `latex*` installés comme dépendance de `r-base*` (GNU R) ou de `pandoc`, autant je ne vois pas comment des paquets `libreoffice` pourraient être présents sur un serveur, vu l’aspect interaction avec l’utilisateur de ce genre de logiciel.

> [@Brigadou](#):
>
> Bref en tentant de passer à buster hier, tout à planté, plus d’accés a winscp, rutorrent, ni rien.

Non le système n’a pas planté, il a tout simplement perdu l’accès au réseau. Avant de faire la migration de stretch vers buster, vous n’avez pas prêté l’attention nécessaire au problème des noms d’interfaces de réseau persistantes.  
Par exemple, sur un HP microserver, j’étais arrivé ç la conclusion que les interfaces seraient renommées

```plaintext
   eth1 -> enp3s0f1
   eth0 -> enp3s0f0

```

et en fait elles ont été renommées `eno1` et `eno2`.  
Si c’est bien un problème réseau, la seule solution envisageable est la réparation via le mode rescue selon la page indiquée par mattotop mais comme je vois le prérequis suivant

```plaintext
    Avoir un accès en SSH (root) à votre serveur dédié

```

je ne sais que penser. (Pour ma part, j’ai dû me déplacer pour régler le problème ).  
La page [du mode rescue (OVH)](https://docs.ovh.com/fr/dedicated/ovh-rescue/) n’est pas d’une clarté limpide, car après avoir parlé de prérequis, on a le paragraphe

```plaintext
 Utiliser le SSH (lignes de commande)

```

où vous avez l’IP du serveur.

Peut-être faut-il comprendre _prérequis_ savoir utiliser la ligne de commandes via SSH ?

Bon courage,  
Cordialement,  
Regards,  
Mit freundlichen Grüßen,  
مع تحياتي الخالصة

* * *

F. Petitjean  
Ingénieur civil du Génie Maritime.

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »  
Pierre Dac

---

<div class="post-metadata">

**Author:** ![Brigadou](https://www.debian-fr.org/user_avatar/www.debian-fr.org/brigadou/32/8390_2.png) [@Brigadou](https://www.debian-fr.org/u/Brigadou)\
**Post date:** [Septembre 11, 2019, 2:19 UTC](https://www.debian-fr.org/t/plantage-serveur-kimsufi-plus-acces-a-rien/80134/9 "2019-09-11T14:19:48Z")

</div>

Le serveur n’a pas été monté par moi-même. Il est assez spécifique, c’est un multicompte (j’ai décrit ce que je souhaitais, la personne en a fait l’arborescence)  
Rutorrent, plex, pydio, webmin etc.  
Un admin (moi) 2 utilisateurs rutorrent, pour les autres (famille, amis) ils n’ont accès qu’au sftp en mode restreint ou plex.  
Si tel ou tel paquets qui doivent ou pas être présents ce n’est pas à moi de le dire.

Quand je dis planté c’est une façon de parler, plus d’accès = plantage, panne ce que voulez…  
j’ai bien compris qu’il fallait l’accès ssh (j’ai les bases quand même) mais c’est là que ça coince… Connection refused  
Ou alors je m’y prend mal ahaha en même temps suis pompier pas dev ça se saurait 😉

---

<div class="post-metadata">

**Author:** ![nestor](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/e495f1/32.png) [@nestor](https://www.debian-fr.org/u/nestor)\
**Post date:** [Septembre 11, 2019, 3:48 UTC](https://www.debian-fr.org/t/plantage-serveur-kimsufi-plus-acces-a-rien/80134/10 "2019-09-11T15:48:15Z")

</div>

Mode rescue kimsufi:

1: Créer une paire de clefs ssh  
2: Se connecter au manager kimsufi  
3: En haut à gauche (onglet: votre nom), choisir SSH  
4: Y coller votre clef publique:

 ![](https://www.debian-fr.org/uploads/default/original/2X/6/608da3714e9c021c1390608d56e5df5fd97fa12b.png)

5:Retour au tableau de bord, onglet netboot, choisir «&nbsp;Rescue: rescue64pro&nbsp;»:

 ![](https://www.debian-fr.org/uploads/default/original/2X/0/02db094cd2c368500e774d95a8265ec1b3c1ecb4.png)

6:Redémarrer  
7: Se connecter en SSH en utilisant la clef privée générée précédemment (ip du serveur sur port 22).  
8:Dans la console saisir «&nbsp;fdisk -l&nbsp;» pour identifier le disque du serveur (/dev/sdxx)  
9:Monter ce disque sur mnt «&nbsp;mount /dev/sdxx /mnt&nbsp;»  
10: saisir «&nbsp;chroot /mnt&nbsp;»  
11: à partir de là tu peux regarder tes logs et ton sources.list etc.., corriger, relancer un update, un upgrade,…  
12: Une fois fait, retour au manager kimsufi à l’onglet netboot et choisir disque dur et redémarrer.

---

<div class="post-metadata">

**Author:** ![Brigadou](https://www.debian-fr.org/user_avatar/www.debian-fr.org/brigadou/32/8390_2.png) [@Brigadou](https://www.debian-fr.org/u/Brigadou)\
**Post date:** [Septembre 11, 2019, 9:27 UTC](https://www.debian-fr.org/t/plantage-serveur-kimsufi-plus-acces-a-rien/80134/11 "2019-09-11T21:27:14Z")

</div>

> [@nestor](#):
>
> chroot /mnt

Je suis arrivé à l’étape 11 sans problème, mais j’avoue qu’après j’hésite à aller plus loin, suis presque devenu parano et pas trop l’envie de faire une connerie 😅

---

<div class="post-metadata">

**Author:** ![Brigadou](https://www.debian-fr.org/user_avatar/www.debian-fr.org/brigadou/32/8390_2.png) [@Brigadou](https://www.debian-fr.org/u/Brigadou)\
**Post date:** [Septembre 12, 2019, 11:32 UTC](https://www.debian-fr.org/t/plantage-serveur-kimsufi-plus-acces-a-rien/80134/12 "2019-09-12T11:32:20Z")

</div>

Bonjour,

Quelqu’un a une idée de la marche à suivre ? J’ai édité le fichier sources.list pour corriger les erreurs, enfin tenter de corriger et je rencontre ça. A chaque étape c’est une galère

[![](https://www.debian-fr.org/uploads/default/original/2X/c/c7139ef39a72e293cfd4a50c1c01ade79deb335d.png) ](https://www.zupimages.net/up/19/37/ohl7.png)

---

<div class="post-metadata">

**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\
**Post date:** [Septembre 12, 2019, 2:08 UTC](https://www.debian-fr.org/t/plantage-serveur-kimsufi-plus-acces-a-rien/80134/13 "2019-09-12T14:08:45Z")

</div>

> [@Brigadou](#):
>
> ’ai édité le fichier sources.list pour corriger les erreurs,

Quelles erreurs ? Pourrait-on avoir le contenu du fichier ?

> [@Brigadou](#):
>
> A chaque étape c’est une galère

Ce qui est galère, c’est de deviner ce que vous faites et si la fenêtre texte dont vous donnez une image peu lisible a été prise dans un environnement netboot avant ou après un chroot éventuel.

> [@Brigadou](#):
>
> Quelqu’un a une idée de la marche à suivre ?

Le message de nestor en 12 points me semble un très bon point de départ. On pourrait ajouter  
0 Se munir de papier, crayon et prévoir une large plage horaire au calme.  
7 a Charger la clé avec la commande `ssh-add` (si ce n’est pas déjà fait )  
7 b se connecter en SSH depuis un terminal avec un tampon d’historique largement dimensionné  
7 c dans le shell obtenu, déterminer si les commandes suivantes sont disponibles

```plaintext
which script
which tmux

```

9 b Après le montage de la racine sur `/mnt` vous pouvez chercher comment ont été nommées les interfaces réseau

```plaintext
less /mnt/var/log/messages

```

et vous cherchez `renamed from eth`  
et vous comparer avec ce qui se trouve dans `/mnt/etc/network/interfaces` ( à éditer si besoin est )  
10 a Avant de procéder au `chroot` il y a un certain nombre de systèmes de fichiers à monter en mode bind

```plaintext
for d in $(basename -a /dev /proc /sys )
do  
 mkdir /mnt/$d
 mount --bind /$d /mnt/$d
done

```

Cette liste est peu-être incomplète 😥

Avant le chroot les fichiers de configuration sont dans `/mnt/etc` par exemple `/mnt/etc/apt/sources.list`

1. Je suppose que la fenêtre que vous avez collée a lieu après le chroot lors d’un `apt update` ou `apt upgrade`.  
Je suis au regret de vous annoncer que le paquet `phpmyadmin` n’est [pas disponible dans buster](https://packages.debian.org/search?suite=all&searchon=names&keywords=phpmyadmin) et donc de la même manière que Cahuzac était une source inépuisable d’ennuis pour le Parti Socialiste, il vaudrait mieux mettre `phpmyadmin` de côté.

Je pense qu’il faut d’abord vérifier si c’est un problème de noms d’interfaces réseau et régler ce problème avant de s’attaquer au reste de la mise à jour. Autrement dit, d’abord s’assurer une connexion SSH sur le Kimsufi pour administrer tranquillement sans passer par le mode rescue.

Cordialement,  
Regards,  
Mit freundlichen Grüßen,  
مع تحياتي الخالصة

* * *

F. Petitjean  
Ingénieur civil du Génie Maritime.

« On ne perd pas son temps en aiguisant ses outils. »  
Proverbe français

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

---

<div class="post-metadata">

**Author:** ![Brigadou](https://www.debian-fr.org/user_avatar/www.debian-fr.org/brigadou/32/8390_2.png) [@Brigadou](https://www.debian-fr.org/u/Brigadou)\
**Post date:** [Septembre 12, 2019, 2:17 UTC](https://www.debian-fr.org/t/plantage-serveur-kimsufi-plus-acces-a-rien/80134/14 "2019-09-12T14:17:44Z")

</div>

J’entends bien tout ce que vous me dites, sauf que là on a largement dépasser mon stade de compétences. Donc je crois que le mieux pour moi, au lieu d’accumuler erreurs sur erreurs, et de ne pas comprendre la moitié de ce que je fais c’est d’arrêter les frais.  
En tout cas merci beaucoup 😉
