# Erreur openssh-server après upgrade **URL:** \ **Category:** Support Debian\ **Created:** [Mars 21, 2016, 1:31 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781 "2016-03-21T13:31:07Z")\ **Posts on this page:** 1\ **Showing post:** 91
**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:** [Août 25, 2019, 2:22 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/91 "2019-08-25T14:22:47Z")
> [@Vinz](#): > > Beaucoup de choses obscures pour moi Même cela ? > [@Vinz](#): > > ```auto > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE > ... > 194 Temperature_Celsius 0x0022 118 098 000 Old_age Always - 29 > > ``` Il faut dire qu’une valeur de 118° cela fait peur, a priori, mais une valeur brute de 29° tout en fin de ligne, c’est beaucoup plus sympathique. Reprenons, d’abord remarquez que le numéro de série dans la sortie de ```plaintext sudo smartctl -d 'cciss,1' --info /dev/sda ``` n’est pas le même que celui affiché avec `èd cciss,0`. On a bien accès à des disques physiques différents. Je vous conseille donc de lancer ```plaintext sudo smartctl -d cciss,$D --info /dev/sda ``` pour des valeurs $D égales à 2,3,.. jusqu’à ce que le disque ne soit plus trouvé ( erreur ou numéro de série affiché inchangé ) Il est grand temps de lancer des tests SMART ```plaintext sudo smartctl -d cciss,0 -t short /dev/sda sudo smartctl -d cciss,1 -t short /dev/sda ``` et ainsi de suite pour $D = 2,3, … Notez l’heure à laquelle vous pourrez consulter les résultats (option `-a` ) Une remarque sur le partitionnement > [@Vinz](#): > > En mode rescue apres chroot: > > ```plaintext > turman@195-154-216-106:~$ sudo chroot /mnt /bin/bash > root@195-154-216-106:/$df -hTx tmpfs > Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur > /dev/sda2 ext4 916G 705G 165G 82% / > udev devtmpfs 1,9G 0 1,9G 0% /dev > root@195-154-216-106:/$lsblk --fs > NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT > loop0 squashfs > sda > ├─sda1 ext4 /boot 54e0bfeb-4c89-4f26-a0eb-e0afde40706c > ├─sda2 ext4 / a8ac874e-2e31-4ae7-9ca2-4d62bd54ed75 164,1G 77% / > └─sda3 swap b989aa61-cf22-4287-98e9-e7a1bef031ef [SWAP] > root@195-154-216-106:/$ip address show > > ``` On voit que vous avez attribué tout l’espace disponible à un seul système de fichiers racine (ext4) directement sur une partition `sda2`. Cela présente de nombreux inconvénients pour un serveur - vous mélangez la partie système et la partie applicative - si il y a un problème avec une application qui remplit les journaux, ( `/var/log`) vous risquez de remplir à terme la racine. - Les écritures sur la partie système ( / /usr /etc /boot /lib /usr ) sont nettement moins fréquentes que sur la partie applicative, si on prend soin d’avoir `/var` comme système de fichiers séparé. - il en résulte que la probabilité d’avoir des ennuis en mettant tout dans un seul FS comme vous l’avez fait est augmentée d’au moins deux ordres de grandeur par rapport à un partitionnement plus adapté. Si vous reconstruisez le serveur , je ne peux que vous conseiller d’utiliser LVM ce qui vous permettra d’avoir la possibilité d’agrandir après coup les systèmes de fichiers ( même la racine ou le swap peuvent être dans un volume logique, donc extensible ) 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) --- _[View the full topic](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781)._