# Erreur openssh-server après upgrade

**URL:** <https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781>\
**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:** 20\
**Page:** 5

<div class="post-metadata">

**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\
**Post date:** [Août 25, 2019, 11:08 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/82 "2019-08-25T11:08:06Z")

</div>

Effectivement j’avais pris l’option RAID à 5€/mois sur ce serveur.

Voici sur la sortie de smartctl sur cciss,0:

> ```
> turman@195-154-216-106:~$ sudo smartctl -d 'cciss,0' --info /dev/sda
> smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.15.0-22-generic] (local build)
> Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
> 
> === START OF INFORMATION SECTION ===
> Device Model: MB1000EBNCF
> Serial Number: WCAW32333375
> LU WWN Device Id: 5 0014ee 2b0acc1fe
> Firmware Version: HPG0
> User Capacity: 1 000 204 886 016 bytes [1,00 TB]
> Sector Size: 512 bytes logical/physical
> Rotation Rate: 7200 rpm
> Form Factor: 3.5 inches
> Device is: Not in smartctl database [for details use: -P showall]
> ATA Version is: ATA8-ACS T13/1699-D revision 6
> SATA Version is: SATA 2.6, 3.0 Gb/s
> Local Time is: Sun Aug 25 12:53:59 2019 CEST
> SMART support is: Available - device has SMART capability.
> SMART support is: Enabled
> 
> ```

Et voici celle sur cciss,1:

> ```
> turman@195-154-216-106:~$ sudo smartctl -d 'cciss,1' --info /dev/sda
> smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.15.0-22-generic] (local build)
> Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
> 
> === START OF INFORMATION SECTION ===
> Device Model: MB1000EBNCF
> Serial Number: WCAW32355604
> LU WWN Device Id: 5 0014ee 25b57274e
> Firmware Version: HPG0
> User Capacity: 1 000 204 886 016 bytes [1,00 TB]
> Sector Size: 512 bytes logical/physical
> Rotation Rate: 7200 rpm
> Form Factor: 3.5 inches
> Device is: Not in smartctl database [for details use: -P showall]
> ATA Version is: ATA8-ACS T13/1699-D revision 6
> SATA Version is: SATA 2.6, 3.0 Gb/s
> Local Time is: Sun Aug 25 12:56:12 2019 CEST
> SMART support is: Available - device has SMART capability.
> SMART support is: Enabled
> 
> ```

Je n’ai pas bien compris ce quelle commande je devais taper après pour avoir les détails.

Mais peut-être que le RAID serait une piste, avec par ex un mauvais support dans Debian 10 pour ma configuration ?

J’aimerais bien aussi comprendre pourquoi mon syslog ne contient aucun événement depuis mon premier boot en mode rescue il y a 2 jours.. alors que c’est justement là où on devrait voir concrètement le problème !

---

<div class="post-metadata">

**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\
**Post date:** [Août 25, 2019, 11:25 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/83 "2019-08-25T11:25:49Z")

</div>

Avec l’option **-a** à la place de **–info**

Le _syslog_ c’est celui du serveur fonctionnant en mode _normal_. Regarde aussi /var/log/messages.

---

<div class="post-metadata">

**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\
**Post date:** [Août 25, 2019, 11:42 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/84 "2019-08-25T11:42:43Z")

</div>

Voici les sorties avec les détails (sur 0 et 1):

> ```
> turman@195-154-216-106:~$ sudo smartctl -d 'cciss,0' -a /dev/sda    
> smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.15.0-22-generic] (local build)
> Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
> 
> === START OF INFORMATION SECTION ===
> Device Model: MB1000EBNCF
> Serial Number: WCAW32333375
> LU WWN Device Id: 5 0014ee 2b0acc1fe
> Firmware Version: HPG0
> User Capacity: 1 000 204 886 016 bytes [1,00 TB]
> Sector Size: 512 bytes logical/physical
> Rotation Rate: 7200 rpm
> Form Factor: 3.5 inches
> Device is: Not in smartctl database [for details use: -P showall]
> ATA Version is: ATA8-ACS T13/1699-D revision 6
> SATA Version is: SATA 2.6, 3.0 Gb/s
> Local Time is: Sun Aug 25 13:33:30 2019 CEST
> SMART support is: Available - device has SMART capability.
> SMART support is: Enabled
> 
> === START OF READ SMART DATA SECTION ===
> SMART Status not supported: Incomplete response, ATA output registers missing
> SMART overall-health self-assessment test result: PASSED
> Warning: This result is based on an Attribute check.
> 
> General SMART Values:
> Offline data collection status: (0x84) Offline data collection activity
> was suspended by an interrupting command from host.
> Auto Offline Data Collection: Enabled.
> Self-test execution status: ( 0) The previous self-test routine completed
> without error or no self-test has ever 
> been run.
> Total time to complete Offline 
> data collection: (16860) seconds.
> Offline data collection
> capabilities: (0x7b) SMART execute Offline immediate.
> Auto Offline data collection on/off support.
> Suspend Offline collection upon new
> command.
> Offline surface scan supported.
> Self-test supported.
> Conveyance Self-test supported.
> Selective Self-test supported.
> SMART capabilities: (0x0003) Saves SMART data before entering
> power-saving mode.
> Supports SMART auto save timer.
> Error logging capability: (0x01) Error logging supported.
> General Purpose Logging supported.
> Short self-test routine 
> recommended polling time: ( 2) minutes.
> Extended self-test routine
> recommended polling time: ( 174) minutes.
> Conveyance self-test routine
> recommended polling time: ( 5) minutes.
> SCT capabilities: (0x303d) SCT Status supported.
> SCT Error Recovery Control supported.
> SCT Feature Control supported.
> SCT Data Table supported.
> 
> SMART Attributes Data Structure revision number: 16
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
> 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 129
> 3 Spin_Up_Time 0x0027 172 172 021 Pre-fail Always - 4366
> 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 56
> 5 Reallocated_Sector_Ct 0x0033 184 184 140 Pre-fail Always - 350
> 7 Seek_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
> 9 Power_On_Hours 0x0032 008 008 000 Old_age Always - 67547
> 10 Spin_Retry_Count 0x0033 100 253 051 Pre-fail Always - 0
> 11 Calibration_Retry_Count 0x0033 100 253 051 Pre-fail Always - 0
> 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 54
> 180 Unknown_HDD_Attribute 0x002f 200 200 100 Pre-fail Always - 0
> 184 End-to-End_Error 0x0033 100 100 097 Pre-fail Always - 0
> 187 Reported_Uncorrect 0x0032 100 097 000 Old_age Always - 3
> 188 Command_Timeout 0x0032 100 088 000 Old_age Always - 21
> 190 Airflow_Temperature_Cel 0x0022 070 051 045 Old_age Always - 30
> 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 53
> 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 2
> 194 Temperature_Celsius 0x0022 117 098 000 Old_age Always - 30
> 195 Hardware_ECC_Recovered 0x0036 200 200 000 Old_age Always - 0
> 196 Reallocated_Event_Count 0x0032 193 193 000 Old_age Always - 7
> 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
> 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
> 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
> 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
> 
> SMART Error Log Version: 1
> No Errors Logged
> 
> SMART Self-test log structure revision number 1
> No self-tests have been logged. [To run self-tests, use: smartctl -t]
> 
> SMART Selective self-test log data structure revision number 1
> SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
> 1 0 0 Not_testing
> 2 0 0 Not_testing
> 3 0 0 Not_testing
> 4 0 0 Not_testing
> 5 0 0 Not_testing
> Selective self-test flags (0x0):
> After scanning selected spans, do NOT read-scan remainder of disk.
> If Selective self-test is pending on power-up, resume after 0 minute delay.
> 
> turman@195-154-216-106:~$ sudo smartctl -d 'cciss,1' -a /dev/sda     
> smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.15.0-22-generic] (local build)
> Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
> 
> === START OF INFORMATION SECTION ===
> Device Model: MB1000EBNCF
> Serial Number: WCAW32355604
> LU WWN Device Id: 5 0014ee 25b57274e
> Firmware Version: HPG0
> User Capacity: 1 000 204 886 016 bytes [1,00 TB]
> Sector Size: 512 bytes logical/physical
> Rotation Rate: 7200 rpm
> Form Factor: 3.5 inches
> Device is: Not in smartctl database [for details use: -P showall]
> ATA Version is: ATA8-ACS T13/1699-D revision 6
> SATA Version is: SATA 2.6, 3.0 Gb/s
> Local Time is: Sun Aug 25 13:34:10 2019 CEST
> SMART support is: Available - device has SMART capability.
> SMART support is: Enabled
> 
> === START OF READ SMART DATA SECTION ===
> SMART Status not supported: Incomplete response, ATA output registers missing
> SMART overall-health self-assessment test result: PASSED
> Warning: This result is based on an Attribute check.
> 
> General SMART Values:
> Offline data collection status: (0x84) Offline data collection activity
> was suspended by an interrupting command from host.
> Auto Offline Data Collection: Enabled.
> Self-test execution status: ( 0) The previous self-test routine completed
> without error or no self-test has ever 
> been run.
> Total time to complete Offline 
> data collection: (16560) seconds.
> Offline data collection
> capabilities: (0x7b) SMART execute Offline immediate.
> Auto Offline data collection on/off support.
> Suspend Offline collection upon new
> command.
> Offline surface scan supported.
> Self-test supported.
> Conveyance Self-test supported.
> Selective Self-test supported.
> SMART capabilities: (0x0003) Saves SMART data before entering
> power-saving mode.
> Supports SMART auto save timer.
> Error logging capability: (0x01) Error logging supported.
> General Purpose Logging supported.
> Short self-test routine 
> recommended polling time: ( 2) minutes.
> Extended self-test routine
> recommended polling time: ( 171) minutes.
> Conveyance self-test routine
> recommended polling time: ( 5) minutes.
> SCT capabilities: (0x303d) SCT Status supported.
> SCT Error Recovery Control supported.
> SCT Feature Control supported.
> SCT Data Table supported.
> 
> SMART Attributes Data Structure revision number: 16
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
> 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 3
> 3 Spin_Up_Time 0x0027 175 174 021 Pre-fail Always - 4233
> 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 56
> 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
> 7 Seek_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
> 9 Power_On_Hours 0x0032 015 015 000 Old_age Always - 62087
> 10 Spin_Retry_Count 0x0033 100 253 051 Pre-fail Always - 0
> 11 Calibration_Retry_Count 0x0033 100 253 051 Pre-fail Always - 0
> 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 54
> 180 Unknown_HDD_Attribute 0x002f 200 200 100 Pre-fail Always - 0
> 184 End-to-End_Error 0x0033 100 100 097 Pre-fail Always - 0
> 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
> 188 Command_Timeout 0x0032 100 095 000 Old_age Always - 10
> 190 Airflow_Temperature_Cel 0x0022 071 051 045 Old_age Always - 29
> 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 53
> 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 2
> 194 Temperature_Celsius 0x0022 118 098 000 Old_age Always - 29
> 195 Hardware_ECC_Recovered 0x0036 200 200 000 Old_age Always - 0
> 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
> 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
> 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
> 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
> 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
> 
> SMART Error Log Version: 1
> No Errors Logged
> 
> SMART Self-test log structure revision number 1
> No self-tests have been logged. [To run self-tests, use: smartctl -t]
> 
> SMART Selective self-test log data structure revision number 1
> SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
> 1 0 0 Not_testing
> 2 0 0 Not_testing
> 3 0 0 Not_testing
> 4 0 0 Not_testing
> 5 0 0 Not_testing
> Selective self-test flags (0x0):
> After scanning selected spans, do NOT read-scan remainder of disk.
> If Selective self-test is pending on power-up, resume after 0 minute delay.
> 
> ```

Beaucoup de choses obscures pour moi mais j’ai pas l’impression que ça permette de mettre en avant un éventuel problème de disque, n’est ce pas ?

Sinon pour /mnt/var/log/messages c’est exactement pareil que pour syslog: les logs sont corrompus (mots/caractères bizarres) et il n’y a plus rien à partir du 23/08 11h39 c’est à dire mon premier reboot en mode rescue suite à mon dist-upgrade.

---

<div class="post-metadata">

**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\
**Post date:** [Août 25, 2019, 1:13 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/85 "2019-08-25T13:13:54Z")

</div>

Non pas d’erreurs visibles sur la sortie de _smartctl_  
Désolé, mais je ne peux pas t’aider davantage. Je soupçonne un problème matériel avec le contrôleur RAID (ou son pilote incompatible avec Debian 10) mais sans en être sûr du tout.  
Il faut peut-être insister auprès de l’assistance technique pour savoir ce qu’il en est.

Concernant ce type de serveur avec Raid matériel, je ne peux qu’approuver l’avis de [Clochette](https://www.debian-fr.org/u/Clochette).  
Pour le même prix tu peux trouver un serveur dédié tout aussi performant avec du Raid logiciel beaucoup plus facile à administrer et à dépanner, et souvent plus performant.

---

<div class="post-metadata">

**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\
**Post date:** [Août 25, 2019, 1:24 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/86 "2019-08-25T13:24:30Z")

</div>

Bon je crois que je vais abandonner et commander un nouveau serveur.

Cela m’embête énormément de savoir qu’une mise à jour de Debian ait pu rendre mon serveur inutilisable, et sans avoir l’explication exacte en plus, c’est assez déprimant…

Je vais essayer de relancer le support d’Online mais sans trop d’espoir.

J’ai regardé les offres de Gandi mais je suis déçu. [Chez Online](https://www.online.net/fr/serveur-dedie) pour à peu près le même prix (36€ HT par mois) je peux avoir du lourd comparé à Gandi:  
Xeon 4 cœurs à 3.3 GHz avec 32 Go de RAM et 2x1To en SATA de disque (par contre je vois la différence entre le Pro-2-M-SATA et le Pro-3-S). Je sais pas encore si je vais prendre l’option RAID qui semble compliquer un peu les choses (d’autant que je ne suis pas sûr que je puisse choisir un RAID logiciel).

---

<div class="post-metadata">

**Author:** ![anon44391915](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/958977/32.png) [@anon44391915](https://www.debian-fr.org/u/anon44391915)\
**Post date:** [Août 25, 2019, 1:32 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/87 "2019-08-25T13:32:37Z")

</div>

> [@Vinz](#):
>
> Cela m’embête énormément de savoir qu’une mise à jour de Debian ait pu rendre mon serveur inutilisable, et sans avoir l’explication exacte en plus, c’est assez déprimant…

**Édition :** c’est un peu plus compliqué à faire que ce qui suit (voir `man journalctl`)  
Il faut préciser quel journal d’amorçage on souhaite voir ; par défaut, c’est celui en cours.

Utiliser :

```plaintext
sudo journalctl --list-boots

```

Pour se faire une idée.  
Il faut avoir la fonctionnalité _persistent journal_ pour accéder à un autre journal que celui en cours.

**Ce qui suit n’est donc pas valable.**

Depuis l’environnement «&nbsp;chrooté&nbsp;» tu peux utiliser la commande :

```plaintext
sudo journalctl -b

```

qui te donnera le journal du dernier amorçage normal  
et probablement des indices sur l’erreur qui bloque ton serveur.

Ce journal peut être long.

Tu peux utiliser aussi :

```plaintext
sudo journalctl -b > journalctl-b.txt

```

pour disposer de ce journal d’amorçage normal dans un fichier texte `journalctl-b.txt`

Ce fichier serait à déposer sur [paste.debian.net](http://paste.debian.net) pour que nous puissions le consulter.  
Nous pourrons le consulter si tu nous donnes le lien de ton «&nbsp;paste&nbsp;»

---

<div class="post-metadata">

**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\
**Post date:** [Août 25, 2019, 2:05 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/88 "2019-08-25T14:05:56Z")

</div>

J’ai l’impression qu’il y a plein de choses intéressantes là !

Avant de le copier quelque part voici déjà quelques lignes (je met en gras celle qui sont en rouge dans la console):  
août 25 10:26:52 ea71cbeb6893 kernel: DMAR: Host address width 39  
août 25 10:26:52 ea71cbeb6893 kernel: DMAR: DRHD base: 0x000000fed90000 flags: 0x1  
**août 25 10:26:52 ea71cbeb6893 kernel: DMAR: Failed to map dmar0**  
août 25 10:26:52 ea71cbeb6893 kernel: DMAR: Parse DMAR table failure.  
août 25 10:26:52 ea71cbeb6893 kernel: Switched APIC routing to physical flat.

Ou encore:  
août 25 10:26:52 ea71cbeb6893 kernel: smpboot: CPU0: Intel(R) Core™ i3-2100 CPU @ 3.10GHz (family: 0x6, model: 0x2a, stepping: 0x7)  
août 25 10:26:52 ea71cbeb6893 kernel: Performance Events: PEBS fmt1+, SandyBridge events, 16-deep LBR, full-width counters, Broken BIOS detected, complain to your hardware vendor.  
**août 25 10:26:52 ea71cbeb6893 kernel: [Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR 38d is 330)**  
août 25 10:26:52 ea71cbeb6893 kernel: Intel PMU driver.  
août 25 10:26:52 ea71cbeb6893 kernel: … version: 3  
août 25 10:26:52 ea71cbeb6893 kernel: … bit width: 48  
août 25 10:26:52 ea71cbeb6893 kernel: … generic registers: 4  
août 25 10:26:52 ea71cbeb6893 kernel: … value mask: 0000ffffffffffff  
août 25 10:26:52 ea71cbeb6893 kernel: … max period: 00007fffffffffff  
août 25 10:26:52 ea71cbeb6893 kernel: … fixed-purpose events: 3  
août 25 10:26:52 ea71cbeb6893 kernel: … event mask: 000000070000000f

Il y aussi cette partie qui parle des disques et du réseau:

> ```
> août 25 10:26:53 ea71cbeb6893 kernel: HP HPSA Driver (v 3.4.20-125)
> août 25 10:26:53 ea71cbeb6893 kernel: hpsa 0000:04:00.0: can't disable ASPM; OS doesn't have ASPM control
> août 25 10:26:53 ea71cbeb6893 kernel: hpsa 0000:04:00.0: Logical aborts not supported
> août 25 10:26:53 ea71cbeb6893 kernel: hpsa 0000:04:00.0: HP SSD Smart Path aborts not supported
> août 25 10:26:53 ea71cbeb6893 kernel: hidraw: raw HID events driver (C) Jiri Kosina
> août 25 10:26:53 ea71cbeb6893 kernel: usbcore: registered new interface driver usbhid
> août 25 10:26:53 ea71cbeb6893 kernel: usbhid: USB HID core driver
> août 25 10:26:53 ea71cbeb6893 kernel: e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
> août 25 10:26:53 ea71cbeb6893 kernel: e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
> août 25 10:26:53 ea71cbeb6893 kernel: e1000e 0000:02:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
> août 25 10:26:53 ea71cbeb6893 kernel: input: HP Virtual Keyboard as /devices/pci0000:00/0000:00:1c.7/0000:01:00.4/usb3/3-1/3-1:1.0/0003:03F0:7029.0001/input/input4
> août 25 10:26:53 ea71cbeb6893 kernel: scsi host0: hpsa
> août 25 10:26:53 ea71cbeb6893 kernel: hpsa can't handle SMP requests
> août 25 10:26:53 ea71cbeb6893 kernel: hpsa 0000:04:00.0: scsi 0:0:0:0: added RAID HP P410 controller SSDSmartPathCap- En- Exp=1
> août 25 10:26:53 ea71cbeb6893 kernel: hpsa 0000:04:00.0: scsi 0:0:1:0: masked Direct-Access ATA MB1000EBNCF PHYS DRV SSDSmartPathCap- En- Exp=0
> août 25 10:26:53 ea71cbeb6893 kernel: hpsa 0000:04:00.0: scsi 0:0:2:0: masked Direct-Access ATA MB1000EBNCF PHYS DRV SSDSmartPathCap- En- Exp=0
> août 25 10:26:53 ea71cbeb6893 kernel: hpsa 0000:04:00.0: scsi 0:1:0:0: added Direct-Access HP LOGICAL VOLUME RAID-1(+0) SSDSmartPathCap- En- Exp=1
> août 25 10:26:53 ea71cbeb6893 kernel: hpsa can't handle SMP requests
> août 25 10:26:53 ea71cbeb6893 kernel: scsi 0:0:0:0: RAID HP P410 5.12 PQ: 0 ANSI: 5
> août 25 10:26:53 ea71cbeb6893 kernel: scsi 0:1:0:0: Direct-Access HP LOGICAL VOLUME 5.12 PQ: 0 ANSI: 5
> août 25 10:26:53 ea71cbeb6893 kernel: scsi 0:0:0:0: Attached scsi generic sg0 type 12
> août 25 10:26:53 ea71cbeb6893 kernel: sd 0:1:0:0: Attached scsi generic sg1 type 0
> août 25 10:26:53 ea71cbeb6893 kernel: sd 0:1:0:0: [sda] 1953459632 512-byte logical blocks: (1.00 TB/931 GiB)
> août 25 10:26:53 ea71cbeb6893 kernel: sd 0:1:0:0: [sda] Write Protect is off
> août 25 10:26:53 ea71cbeb6893 kernel: sd 0:1:0:0: [sda] Mode Sense: 6b 00 00 08
> août 25 10:26:53 ea71cbeb6893 kernel: sd 0:1:0:0: [sda] Write cache: disabled, read cache: disabled, doesn't support DPO or FUA
> août 25 10:26:53 ea71cbeb6893 kernel: [TTM] Zone kernel: Available graphics memory: 1995756 kiB
> août 25 10:26:53 ea71cbeb6893 kernel: [TTM] Initializing pool allocator
> août 25 10:26:53 ea71cbeb6893 kernel: [TTM] Initializing DMA pool allocator
> août 25 10:26:53 ea71cbeb6893 kernel: e1000e 0000:02:00.0 0000:02:00.0 (uninitialized): registered PHC clock
> août 25 10:26:53 ea71cbeb6893 kernel: sda: sda1 sda2 sda3
> août 25 10:26:53 ea71cbeb6893 kernel: sd 0:1:0:0: [sda] Attached SCSI disk
> août 25 10:26:53 ea71cbeb6893 kernel: fbcon: mgadrmfb (fb0) is primary device
> août 25 10:26:53 ea71cbeb6893 kernel: hid-generic 0003:03F0:7029.0001: input,hidraw0: USB HID v1.01 Keyboard [HP Virtual Keyboard] on usb-0000:01:00.4-1/input0
> août 25 10:26:53 ea71cbeb6893 kernel: input: HP Virtual Keyboard as /devices/pci0000:00/0000:00:1c.7/0000:01:00.4/usb3/3-1/3-1:1.1/0003:03F0:7029.0002/input/input5
> août 25 10:26:53 ea71cbeb6893 kernel: hid-generic 0003:03F0:7029.0002: input,hidraw1: USB HID v1.01 Mouse [HP Virtual Keyboard] on usb-0000:01:00.4-1/input1
> août 25 10:26:53 ea71cbeb6893 kernel: e1000e 0000:02:00.0 eth0: (PCI Express:2.5GT/s:Width x1) 44:1e:a1:3b:21:f6
> août 25 10:26:53 ea71cbeb6893 kernel: e1000e 0000:02:00.0 eth0: Intel(R) PRO/1000 Network Connection
> août 25 10:26:53 ea71cbeb6893 kernel: e1000e 0000:02:00.0 eth0: MAC: 3, PHY: 8, PBA No: FFFFFF-0FF
> août 25 10:26:53 ea71cbeb6893 kernel: e1000e 0000:03:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
> août 25 10:26:53 ea71cbeb6893 kernel: e1000e 0000:03:00.0 0000:03:00.0 (uninitialized): registered PHC clock
> août 25 10:26:53 ea71cbeb6893 kernel: e1000e 0000:03:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 44:1e:a1:3b:21:f7
> août 25 10:26:53 ea71cbeb6893 kernel: e1000e 0000:03:00.0 eth1: Intel(R) PRO/1000 Network Connection
> août 25 10:26:53 ea71cbeb6893 kernel: e1000e 0000:03:00.0 eth1: MAC: 3, PHY: 8, PBA No: FFFFFF-0FF
> août 25 10:26:53 ea71cbeb6893 kernel: e1000e 0000:02:00.0 enp2s0: renamed from eth0
> 
> ```

---

<div class="post-metadata">

**Author:** ![anon44391915](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/958977/32.png) [@anon44391915](https://www.debian-fr.org/u/anon44391915)\
**Post date:** [Août 25, 2019, 2:15 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/89 "2019-08-25T14:15:31Z")

</div>

C’est le journal d’amorçage d’urgence que nous avons là et pas celui du dernier amorçage normal.  
Regarde l’horodatage.

Par contre le fichier `/mnt/var/log/kern.log` (environnement non chrooté)  
ou `/var/log/kern.log` (environnement chrooté) peut comporter quelque chose éventuellement.

Tout comme `/var/log/messages` (chrooté)

---

<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:** [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")

</div>

> [@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)

---

<div class="post-metadata">

**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\
**Post date:** [Août 25, 2019, 2:39 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/92 "2019-08-25T14:39:23Z")

</div>

J’essayerai les commandes littlejohn ce soir en espérant trouver le temps nécessaire.

En attendant je vois que /mnt/var/log/kern.log est comme les autres logs (syslog et messages): le texte est corrompu et il n’y a rien depuis le 23/08 !

Et effectivement journalctl ne renvoie rien une fois chrooté:

> root@195-154-216-106:/$journalctl -b  
> No journal files were found.  
> – No entries –  
> root@195-154-216-106:/$journalctl --list-boots  
> No journal files were found.

Lorsque je ne suis pas chrooté mais j’ai toujours les erreurs postées plus haut, et aussi celle ci:

> ```
> août 25 16:24:20 ea71cbeb6893 kernel: ------------[cut here]------------
> août 25 16:24:20 ea71cbeb6893 kernel: Your BIOS is broken; DMAR reported at address fed90000 returns all ones!
> BIOS vendor: HP; Ver: J01; Product Version: 
> août 25 16:24:20 ea71cbeb6893 kernel: WARNING: CPU: 0 PID: 0 at /build/linux-lZKWha/linux-4.15.0/drivers/iommu/dmar.c:848 warn_invalid_dmar.part.11+0x5c/0x70
> août 25 16:24:20 ea71cbeb6893 kernel: Modules linked in:
> août 25 16:24:20 ea71cbeb6893 kernel: CPU: 0 PID: 0 Comm: swapper Not tainted 4.15.0-22-generic #24-Ubuntu
> août 25 16:24:20 ea71cbeb6893 kernel: Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
> août 25 16:24:20 ea71cbeb6893 kernel: RIP: 0010:warn_invalid_dmar.part.11+0x5c/0x70
> août 25 16:24:20 ea71cbeb6893 kernel: RSP: 0000:ffffffffb6e03da0 EFLAGS: 00010086
> août 25 16:24:20 ea71cbeb6893 kernel: RAX: 0000000000000000 RBX: 00000000fed90000 RCX: ffffffffb6e628a8
> août 25 16:24:20 ea71cbeb6893 kernel: RDX: 0000000000000001 RSI: 0000000000000082 RDI: 0000000000000046
> août 25 16:24:20 ea71cbeb6893 kernel: RBP: ffffffffb6e03dc0 R08: 6e657620534f4942 R09: 000000000000009a
> août 25 16:24:20 ea71cbeb6893 kernel: R10: ffffffffb6e03d80 R11: 726556203b504820 R12: ffffffffb6b4b381
> août 25 16:24:20 ea71cbeb6893 kernel: R13: ffffffffb753d004 R14: ffffffffb753d02c R15: ffffffffff200a30
> août 25 16:24:20 ea71cbeb6893 kernel: FS: 0000000000000000(0000) GS:ffff92aa46200000(0000) knlGS:0000000000000000
> août 25 16:24:20 ea71cbeb6893 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> août 25 16:24:20 ea71cbeb6893 kernel: CR2: ffff92aa4bdff000 CR3: 000000002b40a001 CR4: 00000000000606b0
> août 25 16:24:20 ea71cbeb6893 kernel: Call Trace:
> août 25 16:24:20 ea71cbeb6893 kernel: dmar_validate_one_drhd+0x84/0xe0
> août 25 16:24:20 ea71cbeb6893 kernel: dmar_walk_remapping_entries+0xa6/0x1d0
> août 25 16:24:20 ea71cbeb6893 kernel: detect_intel_iommu+0x66/0xef
> août 25 16:24:20 ea71cbeb6893 kernel: ? xen_swiotlb_init+0x4e0/0x4e0
> août 25 16:24:20 ea71cbeb6893 kernel: pci_iommu_alloc+0x55/0x71
> août 25 16:24:20 ea71cbeb6893 kernel: mem_init+0x1c/0xa9
> août 25 16:24:20 ea71cbeb6893 kernel: start_kernel+0x2ce/0x4fd
> août 25 16:24:20 ea71cbeb6893 kernel: x86_64_start_reservations+0x24/0x26
> août 25 16:24:20 ea71cbeb6893 kernel: x86_64_start_kernel+0x74/0x77
> août 25 16:24:20 ea71cbeb6893 kernel: secondary_startup_64+0xa5/0xb0
> août 25 16:24:20 ea71cbeb6893 kernel: Code: 7e 1c 00 bf 01 00 00 00 49 89 c5 e8 2f 7e 1c 00 4d 89 f1 4d 89 e8 48 89 c1 4c 89 e2 48 89 de 48 c7 c7 60 aa b4 b6 e8 b4 8a a5 ff <0f> 0b 5b 41 5c 41 5d 41 5e 5d c3 66 0f 1f 84 00 00 00 00 00 e8 
> août 25 16:24:20 ea71cbeb6893 kernel: ---[end trace e522152bd8c158c3]---
> 
> ```

Je sais pas si ce problème de BIOS est pertinent ou pas mais il doit être aussi présent à priori lorsque le serveur démarre en mode normal…

---

<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:** [Août 25, 2019, 2:59 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/93 "2019-08-25T14:59:53Z")

</div>

> [@Vinz](#):
>
> Il y aussi cette partie qui parle des disques et du réseau:

On y voit que c’est le pilote `hpsa` pour le contrôleur disque et `e1000e`pour les interfaces réseau.  
La dernière ligne est très claire

```plaintext
août 25 10:26:53 ea71cbeb6893 kernel: e1000e 0000:02:00.0 enp2s0: renamed from eth0

```

c’est bien `enp2s0` qui _doit_ apparaître dans `/etc/network/interfaces`.  
J’ai déjà eu des renommages d’interfaces réseau avec Debian 7 ou 8 je ne sais plus, du genre eth1 est renommé eth3 ou autre bizarreries ( sur les Proliant avec une carte additionnelle 2 ports , combiner les 4 ethX pour de l’agrégation de lien etc ) Je n’ai pas encore passé aux noms persistants et à Buster sur ces systèmes.

J’ai l’impression que le système actuel est sain, qu’il démarre bien mais que la configuration réseau n’est plus bonne.

Les outils HP (hpacucli ou autre) sont en général installés dans /opt

```plaintext
ls -l /mnt/opt

```

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

* * *

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

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

---

<div class="post-metadata">

**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\
**Post date:** [Août 25, 2019, 3:13 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/94 "2019-08-25T15:13:12Z")

</div>

Alors déjà “sudo smartctl -d cciss,$D --info /dev/sda” ne fonctionne qu’avec 0 et 1 (au delà j’ai du “No such device or address”). Ensuite si je lance les tests (“sudo smartctl -d cciss,$D --info /dev/sda”) il me dit que le résultat sera prêt 2 minutes plus tard et basta (il y a peut-être un fichier créé mais je sais pas où).

Sinon dans /mnt/opt je n’ai rien mis à part des veilles versions de Groovy que j’avais essayé il y a longtemps…

Mais donc il faudrait revenir au nommage eth0 ? Ok je vais remettre eth0 dans /etc/network/interfaces mais dois je aussi décommenter les lignes que j’avais commenté dans 70-persistent-net.rules ?  
Au final la seule chose qui aura été faite sera le nettoyage par fsck.

Edit: sinon le support d’Online me proposait d’effacer complètement /etc/network/interfaces, j’essayerai après…

---

<div class="post-metadata">

**Author:** ![anon44391915](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/958977/32.png) [@anon44391915](https://www.debian-fr.org/u/anon44391915)\
**Post date:** [Août 25, 2019, 3:20 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/95 "2019-08-25T15:20:20Z")

</div>

Tu as mal lu ou lu trop vite @Vinz

> [@littlejohn75](#):
>
> La dernière ligne est très claire
> 
> ```auto
> août 25 10:26:53 ea71cbeb6893 kernel: e1000e 0000:02:00.0 enp2s0: renamed from eth0
> 
> ```
> 
> c’est bien `enp2s0` qui _doit_ apparaître dans `/etc/network/interfaces` .

Si tu souhaites essayer d’effacer (mettre en commentaire) le contenu de `/etc/network/interfaces`

Laisse au minimum ceci dedans :

```plaintext
# The loopback network interface
auto lo
iface lo inet loopback

```

Tout en sachant que tu peux perdre l’accès d’urgence.

---

<div class="post-metadata">

**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\
**Post date:** [Août 25, 2019, 3:24 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/96 "2019-08-25T15:24:34Z")

</div>

Arf j’ai effectivement lu à l’envers, désolé ! Je commence un peu à saturer…

Là je viens de tenter la suppression de /etc/network/interfaces mais c’est toujours unpingable en mode normal…

De toutes les manières, il y a forcément un problème au niveau des disques (en plus d’un probleme réseau éventuel) puisque tous mes logs sont corrompus et inexistants à partir de vendredi, on est bien d’accord ?

---

<div class="post-metadata">

**Author:** ![anon44391915](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/958977/32.png) [@anon44391915](https://www.debian-fr.org/u/anon44391915)\
**Post date:** [Août 25, 2019, 3:52 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/97 "2019-08-25T15:52:30Z")

</div>

> [@Vinz](#):
>
> désolé ! Je commence un peu à saturer…

T’en fais pas, on a avancé quand même et à chaque jour suffit sa peine 😉  
J’aimerais pas non plus avoir des logs corrompus.

---

<div class="post-metadata">

**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\
**Post date:** [Août 25, 2019, 4:11 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/98 "2019-08-25T16:11:10Z")

</div>

Ba justement non je trouve qu’on a malheureusement pas vraiment avancé, malgré toute votre aide et 90 posts en 2 jours !

Je pense que ce soir je vais louer [ce serveur](https://www.online.net/fr/serveurs-dedies/pro-3-s) car le RAID est logiciel contrairement à l’autre au même prix. Je reposerai certainement des questions pour faire une bonne installation avec un partitionnement moins rudimentaire que celui que j’ai actuellement.

---

<div class="post-metadata">

**Author:** ![anon44391915](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/958977/32.png) [@anon44391915](https://www.debian-fr.org/u/anon44391915)\
**Post date:** [Août 25, 2019, 4:15 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/99 "2019-08-25T16:15:30Z")

</div>

Personnellement, j’ai appris quelques trucs.  
Tu n’as pas été dépanné, certes.

C’est une belle bête que tu envisages de louer !

---

<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:** [Août 25, 2019, 4:38 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/100 "2019-08-25T16:38:53Z")

</div>

> [@anon44391915](#):
>
> Tu n’as pas été dépanné, certes.

Ben le problème était sur l’accès ssh, et il me semble que c’est bon, non ? 😃

> [@Vinz](#):
>
> Je pense que ce soir je vais louer [ce serveur](https://www.online.net/fr/serveurs-dedies/pro-3-s)

J’ai des pro3s et des pro4s, rien à dire, ça marche.

> [@Vinz](#):
>
> Ba justement non je trouve qu’on a malheureusement pas vraiment avancé, malgré toute votre aide et 90 posts en 2 jours !

Concrètement, à part:

- le probléme de ssh résolu,
- logs corrompus pê par une manip genre sortie abrupte du mode rescue, mais en tous cas pas du à une défaillance materielle,
- logs qui ne sont plus à jour depuis 2j que tu fais des reboots incessants essentiellement pour revenir dans un chroot qui ne logue rien, c’est toujours le cas aprés un ultime reboot ou bien le syslog se remplit de nouveau ?
- les warnings de boots (sans avoir vérifié) me semblent anodins et pas inhabituels.  
En gros, tu as quoi qui ne marche pas maintenant ?

---

<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:** [Août 25, 2019, 4:40 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/101 "2019-08-25T16:40:58Z")

</div>

> [@anon44391915](#):
>
> c’est bien `enp2s0` qui _doit_ apparaître dans `/etc/network/interfaces` .

En mode pas à pas, car on fatigue.  
Préparer le chroot (mount --bind)

```auto
sudo chroot /mnt /bin/bash

```

éditer `/etc/network/interfaces` pour avoir ce contenu

```auto
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
# was eth0 now enp2s0

auto enp2s0 
iface enp2s0 inet static 
  address 195.154.216.106
  netmask 255.255.255.0 
  gateway 195.154.216.1 

```

Et faire

```plaintext
ifup enp2s0
ip address show enp2s0

```

Ceci vérifiera la syntaxe du fichier `/etc/network/interfaces`  
Avant redémarrage, je préconise

```plaintext
mv /etc/udev/rules.d/70-persistent-net.rules $HOME
ping -c 2 linuxfr.org

```

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

* * *

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

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

---

<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:** [Août 25, 2019, 5:31 UTC](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781/102 "2019-08-25T17:31:33Z")

</div>

> [@anon70622873](#):
>
> Le fichier a été modifié, par Vinz ou une autre personne avec une IP qui n’a rien à y faire. Vu la similarité des deux adresses on peut penser que la seconde ( 8.190.34.106 ⇒Singapour) résulte d’une faute de frappe en voulant recopier la première (88.190.34.106⇒freebox fibre optique). la stupidité et l’inutilité de la chose ne suggère pas une attaque mais bien une erreur de manipulation de quelqu’un qui à les droits root sur ce serveur.

Alors ça, déjà, c’est ça qu’on peut retenir, que ce n’est pas un hack, pour ce qui est du contenu de interfaces.

> [@littlejohn75](#):
>
> c’est bien `enp2s0` qui _doit_ apparaître dans `/etc/network/interfaces` .

Et ça, on s’en balance complètement chez online, vu qu’en ipv4, le dhcp a pris le relais sur l’interface quel que soit son nom en lui attribuant la même ip, sans doute depuis longtemps, sur la config faite pour eth0 dans interfaces.  
La seule raison qu’on peut avoir pour mettre en dur une config chez online, c’est quand on veut configurer l’ipv6 (il faut un pre-up et lancer le dhclient sur un fichier dhcp dédié à l’ipv6 indiquant le client id pour l’autoconf).  
Donc ça pose peut être des problémes, ce nommage en enp2s0, mais ce sont des problémes qui existaient sans doute avant l’upgrade.

[Page précédente](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781.md?page=4)

[Page suivante](https://www.debian-fr.org/t/erreur-openssh-server-apres-upgrade/68781.md?page=6)
