60 votes

Junfeng avatar

Comment faire en sorte que Linux reconnaisse un nouveau disque SATA /dev/sda que j'ai inséré à chaud sans redémarrer ?

Demandé el 6 de Mai, 2009
Quand la question a-t-elle été
215555 affichage
Nombre de visites la question a
5 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

L'échange à chaud d'un disque SATA /dev/sda défaillant a bien fonctionné, mais lorsque j'ai voulu insérer un nouveau disque, il n'a pas été reconnu :

[root@fs-2 ~]# tail -18 /var/log/messages
May 5 16:54:35 fs-2 kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xe frozen
May 5 16:54:35 fs-2 kernel: ata1: SError: { PHYRdyChg CommWake }
May 5 16:54:40 fs-2 kernel: ata1: link is slow to respond, please be patient (ready=0)
May 5 16:54:45 fs-2 kernel: ata1: device not ready (errno=-16), forcing hardreset
May 5 16:54:45 fs-2 kernel: ata1: soft resetting link
May 5 16:54:50 fs-2 kernel: ata1: link is slow to respond, please be patient (ready=0)
May 5 16:54:55 fs-2 kernel: ata1: SRST failed (errno=-16)
May 5 16:54:55 fs-2 kernel: ata1: soft resetting link
May 5 16:55:00 fs-2 kernel: ata1: link is slow to respond, please be patient (ready=0)
May 5 16:55:05 fs-2 kernel: ata1: SRST failed (errno=-16)
May 5 16:55:05 fs-2 kernel: ata1: soft resetting link
May 5 16:55:10 fs-2 kernel: ata1: link is slow to respond, please be patient (ready=0)
May 5 16:55:40 fs-2 kernel: ata1: SRST failed (errno=-16)
May 5 16:55:40 fs-2 kernel: ata1: limiting SATA link speed to 1.5 Gbps
May 5 16:55:40 fs-2 kernel: ata1: soft resetting link
May 5 16:55:45 fs-2 kernel: ata1: SRST failed (errno=-16)
May 5 16:55:45 fs-2 kernel: ata1: reset failed, giving up
May 5 16:55:45 fs-2 kernel: ata1: EH complete

J'ai essayé plusieurs choses pour que le serveur trouve le nouveau /dev/sda, comme par exemple rescan-scsi-bus.sh mais ils n'ont pas fonctionné :

[root@fs-2 ~]# echo "---" > /sys/class/scsi_host/host0/scan
-bash: echo: write error: Invalid argument
[root@fs-2 ~]#
[root@fs-2 ~]# /root/rescan-scsi-bus.sh -l
[snip]
0 new device(s) found.
0 device(s) removed.
[root@fs-2 ~]#
[root@fs-2 ~]# ls /dev/sda
ls: /dev/sda: No such file or directory

J'ai fini par redémarrer le serveur. /dev/sda a été reconnu, j'ai réparé le RAID logiciel et tout va bien maintenant. Mais pour la prochaine fois, Comment faire pour que Linux reconnaisse un nouveau disque SATA que j'ai inséré à chaud sans redémarrer ?

Le système d'exploitation en question est RHEL5.3 :

[root@fs-2 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.3 (Tikanga)

Le disque dur est un Seagate Barracuda ES.2 SATA 3.0-Gb/s 500-GB, modèle ST3500320NS.

Voici la sortie de lscpi :

[root@fs-2 ~]# lspci
00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2)
00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a3)
00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2)
00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)
00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
00:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2)
00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3)
00:09.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3)
00:0a.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0b.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0c.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02)
04:00.0 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06)
04:00.1 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06)

Mise à jour : Dans une douzaine de cas, nous avons été contraints de redémarrer les serveurs parce que la permutation à chaud ne fonctionnait pas. Merci pour les réponses qui m'ont incité à me pencher davantage sur le contrôleur SATA. J'ai inclus la sortie lspci pour le système problématique ci-dessus (nom d'hôte : fs-2). J'aurais encore besoin d'aide pour comprendre ce qui n'est pas pris en charge au niveau matériel en termes d'échange à chaud pour ce système. N'hésitez pas à me faire part de tout autre résultat que lspci qui pourrait être utile.

La bonne nouvelle est que la permutation à chaud a "fonctionné" aujourd'hui sur l'un de nos serveurs (nom d'hôte : www-1), ce qui est très rare pour nous. Voici la sortie de lspci :

[root@www-1 ~]# lspci
00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2)
00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a3)
00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2)
00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)
00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
00:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2)
00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3)
00:09.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3)
00:0b.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0c.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control
00:19.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration
00:19.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map
00:19.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller
00:19.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control
00:19.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control
03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02)
04:00.0 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06)
04:00.1 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06)
09:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS (rev 04)
Demandé el 6 de Mai, 2009 par Junfeng

Réponses

Trop de publicités?

3voto

IMB avatar
IMB Points 777

Dans certains cas, l'échange à chaud doit être activé dans le BIOS de la carte mère et/ou du contrôleur SATA. Cela dépend entièrement de la marque et du modèle des deux, mais si vous avez des contrôleurs SATA embarqués qui devrait supporte le hotswap, cela vaut la peine de passer le BIOS de la carte mère au peigne fin. Les cartes SATA peuvent ou non avoir leurs propres paramètres BIOS, beaucoup de cartes bas de gamme n'en ont pas, mais les cartes de niveau serveur en ont généralement.

Si je me souviens bien, j'ai dû faire cela avec un certain nombre de cartes mères Gigabyte, et peut-être d'autres marques. J'en avais besoin pour faire fonctionner un plateau SATA remplaçable à chaud ; si la fonction était désactivée, le retrait du disque ne posait pas de problème, mais le nouveau disque ne s'enregistrait pas avant le redémarrage. L'activation du paramètre a fonctionné comme prévu, les disques placés dans le plateau ont été immédiatement mis en marche et disponibles pour le système d'exploitation.

Répondu el 30 de Décembre, 2014 par IMB (777 Points )

2voto

Jiri Klouda avatar
Jiri Klouda Points 902

Voici pourquoi j'ai dû redémarrer l'ordinateur...

Je viens de remplacer à chaud mon /dev/sdc. J'ai utilisé scsiadd -r 3 0 0 pour éteindre l'ancien disque avant de le retirer. Ensuite, après avoir installé le nouveau disque, celui-ci n'apparaissait pas comme /dev/sdc mais plutôt comme /dev/sdd. Après un redémarrage, le disque réapparaissait en tant que /dev/sdc.

Il semble donc que le hotswap fonctionne correctement, il se peut simplement que le /dev/sd* ne soit plus le même.

Cela pourrait-il être une réponse à votre problème ?

Répondu el 4 de Mars, 2011 par Jiri Klouda (902 Points )

1voto

Mark R avatar
Mark R Points 81

Pour que le hotplug fonctionne, le module acpiphp doit être chargé.

[root@example ~]# modprobe acpiphp

évidemment, si vous voulez que cela fonctionne au démarrage, vous devrez configurer

modprobe acpiphp

r

Répondu el 24 de Février, 2012 par Mark R (81 Points )

1voto

DawTaylor avatar
DawTaylor Points 1

Le contrôleur Fusion-MPT SAS dont vous disposez est un contrôleur RAID bas de gamme. Si vous ne l'utilisez pas pour le RAID, il peut encore fournir une couche d'obstruction/abstraction inutile.

Il se peut que vous deviez interroger le contrôleur RAID avec mpt-status ou lsiutil pour qu'il analyse effectivement le bus.

http://hwraid.le-vert.net/wiki/LSIFusionMPT dispose d'une bonne documentation, mais je ne peux pas dire que je l'ai vérifiée.

Répondu el 21 de Janvier, 2014 par DawTaylor (1 Points )

1voto

Ben Scott avatar
Ben Scott Points 350

Je sais que cette question est ancienne, mais j'ai eu quelques succès que je n'ai pas vus ailleurs. J'ai eu des problèmes similaires sur un Dell Precision 380 aujourd'hui. J'ai finalement réussi à le faire fonctionner en faisant une combinaison des opérations suivantes :

echo "- - -" > /sys/class/scsi_host/host2/scan
echo 1 > /sys/class/scsi_device/2:0:0:0/device/reset
echo 1 > /sys/devices/pci0000:00/0000:00:1f.2/rescan
echo 1 > /sys/devices/pci0000:00/0000:00:1f.2/reset

AVERTISSEMENT : Cela peut également perturber d'autres dispositifs ATA sur le système. Si vous avez monté des systèmes de fichiers sur ces périphériques, cela risque de mal se terminer. Ma situation n'a pas eu d'incidence, mais la vôtre pourrait en avoir.

Je ne sais pas encore exactement quelles commandes sont nécessaires, ni dans quel ordre. Il se peut que certaines commandes doivent être répétées. Si je devais deviner, je dirais qu'il faut procéder dans l'ordre indiqué ci-dessus, puis refaire un scan scsi_host à la fin. J'en ai fait beaucoup d'autres au cours de mes explorations.

La première commande (scsi_host scan) indique à la couche intermédiaire SCSI de rechercher sur tous les bus les périphériques nouveaux ou modifiés. La deuxième commande tente de réinitialiser la cible SCSI (périphérique disque). Les deux dernières commandes fonctionnent avec le pilote du contrôleur AHCI lui-même.

J'ai trouvé les éléments en question principalement par un examen détaillé et une expérimentation audacieuse.

Vous pouvez faire correspondre les nœuds scsi_device à la marque et au modèle du périphérique avec (en utilisant grep pour imprimer les noms de fichiers avant le contenu) :

grep . /sys/class/scsi_device/*/device/model

Le premier chiffre de l'ID du périphérique SCSI doit être le numéro scsi_host. Vous pouvez ensuite faire correspondre les nœuds scsi_host à leurs nœuds de périphériques avec :

ls -l /sys/class/scsi_host

Je pense que je n'aurai jamais l'occasion de l'affiner davantage, c'est pourquoi j'ai voulu partager cette information dans l'espoir d'en rapprocher d'autres. Si j'obtiens plus d'informations, je modifierai cette réponse en conséquence.

J'espère que cela vous aidera.

Répondu el 27 de Novembre, 2017 par Ben Scott (350 Points )

Questions connexes

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X