Hotplug sata sous Squeeze

Bonjour,
Précédemment sous Lenny j’avais écrit des règles udev pour intercepter l’insertion/retrait d’un disque sata à chaud et faire quelques opérations sympa dessus. Par exemple gérer l’arrachage et retirer du raid le volume absent physiquement, ou à l’insertion si le disque est de taille supérieure ou égale au raid, alors le formater et l’ajouter comme surnuméraire au raid déjà présent, c’est très pratique et cela permet une gestion du raid extrêmement simplifiée : le remplacement d’un disque défectueux peut-être fait sans taper une commande, une manipulation physique des disques suffit.

J’ai besoin de passer sous Squeeze pour différentes raisons, et je voudrais y reproduire le même comportement. Le problème c’est qu’avant même de chercher à adapter mes règles, je me rend compte que tout simplement l’ajout de disque sata à chaud n’est pas intercepté !
Lorsque je branche une clé usb, le dmesg et le /var/log/messages s’agitent, udev s’agite, et j’ai une (des) nouvelles entrées dans dev.
Lorsque j’insère un disque sata, le dmesg et messages restent muet, alors que je devrais au moins avoir l’évènement d’ajout de disque (et la création d’une entrée /dev/sd? dans /dev, à minima).
Aucune règle que je pourrais écrire ne peut gérer l’insertion de disque puisque udev ne voit pas cette insertion !

Mais peut-être n’est ce pas un bug et y a t’il quelque chose que je ne sais …? un module à charger ou je ne sais quoi…
Quelqu’un a t’il une idée ?

Merci.

Première chose à vérifier : les disques SATA sont-ils bien reconnus ? Si oui, comment le sais-tu ?

C’est la même machine qui était sous Lenny (et les mêmes disques).

Ce n’est pas parce que ça fonctionnait avant que ça fonctionne encore aujourd’hui. Il se peut qu’une chose ait changé (bien que ce soit très probable).

Assure toi d’abord d’identifier précisément tes disques d’une façon ou d’une autre, car si “udev” ne les voit pas on peut se demander si le système les voit.

S’ils sont reconnus, comment sont-ils identifiés par le système ? En “hdX” ou “sdX” ?
Sont-ils reconnus seulement lorsqu’ils ont été branchés avant de démarrer la machine, ou sont-ils aussi reconnus après un branchement à chaud ?

J’ai plusieurs disques qui ont tous été testés sous lenny :
je démarre sur deux, j’enlève un , j’en met un autre à la place
je démarre sur deux, j’en met un troisième, j’enlève le deuxième
je démarre sur un, j’en ajoute un deuxième, puis un troisième, puis j’enlève le premier, puis j’enlève le deuxième… etc.

À chaque fois sous Lenny j’ai un évènement lorsque je branche/débranche un disque :
j’ajoute, évènement disque ajouté
j’enlève, évènement disque enlevé
À partir de ça j’ai écrit mes rêgles pour gérer la reconstruction du raid, la désactivation d’un volume absent, la mise à disposition d’un disque surnuméraire etc.
Mais mes règles ne sevent à rien si je n’ai pas d’évènement “disque ajouté” et “disque enlevé”

Déjà udev tout nu sorti des paquets debian et sans mes rêgles devrait intercepter l’évènement “disque ajouté” et interpréter la table des partitions pour me mettre tout les sdXN en conséquence. Il le fait pour les disques usb, pas pour les disques sata.

Mes disques sont vus s’ils sont présents au démarrage, pas s’ils sont branchés à chaud.
Quand ils sont présents au démarrage, ils sont vus comme sdX, c’est du sata on ne peut plus classique. Dans le bios le contrôleur sata est configuré en AHCI.
Si j’ajoute après un démarrage un disque qui n’était pas présent au démarrage, rien ne se passe, dmesg est muet, et rien dans /var/log/messages.
Les leds du contrôleur de disque s’allume, le disque est alimenté et tout, mais Squeeze ne sait rien.

Tout ce matériel fonctionne sous Lenny sans incantations :confused:

vu que j’ai plusieurs disque j’ai pu expérimenter cela :

disque 1 (lenny)
disque 2 (squeeze)
disque 3 (peu-importe)

je boote sur le disque 1 (lenny), j’ajoute le disque 3 (peu importe), il est vu.
je boote sur le disque 2 (squeeze), j’ajoute le disque 3 (peu importe), il n’est pas vu.

Alors, on va procéder par étapes.
Je pars du principe que tu as cherché tout ce que tu pouvais avec un moteur de recherche :wink:

Tu m’aurais dit l’inverse j’aurais pu comprendre en me disant que ça aurait pu venir d’une mauvaise gestion de l’économie d’énergie, mais là :open_mouth:

Donc ça laisse présager soit d’une option qui désactive l’ajout automatique des périphériques SATA dans “udev”, soit d’un gros bug.
On peut exclure le fait que “udev” ne soit pas lancé ou ne fonctionne pas du tout étant donné qu’il réagit lorsque tu branches de l’USB.

Il se pourrait que ça vienne de là (l’AHCI n’est pas toujours bien supporté s’il s’agit d’un matériel récent).
Tu as essayé en le mettant en mode Compatible ?

Tu peux améliorer le niveau de verbosité de “udevd” en rajoutant l’option “–debug” à la ligne qui permet de le lancer.

je vais voir ça, merci du tuyau :slight_smile:

Je n’ai pas la bécane sous les yeux à cette heure-ci mais j’ai trois options dans le bios, de mémoire J’ai le choix entre Raid, AHCI et un troisième, je crois intitulé tout simplement IDE (certainement le mode compatible).

La machine n’est pas toute récente, de la génération P4 HT. Je ne connais pas le lspci par cœur mais le contrôleur comme le reste est du très classique intel ICH-quelquechose.

Je pourrais donner plus de détails quand je serai de nouveau devant la machine, mais vu qu’elle n’est pas toute neuve, et que ça marchait déjà sous Lenny avec le noyau par défaut je crains que ce ne soit pas à cause du trop jeune âge du matériel…

Dans le BIOS j’ai trois options pour le sata, IDE, RAID et AHCI.
J’ai essayé IDE, RAID et AHCI (il semble que le mode RAID fonctionne en mode AHCI lorsque les fonctionalités raid ne sont pas utilisées)

lspci (contrôleur en mode IDE)
00:1f.2 IDE interface: Intel Corporation 82801FR/FRW (ICH6R/ICH6RW) SATA Controller (rev 03)
lspci (contrôleur en mode RAID)
00:1f.2 RAID bus controller: Intel Corporation 82801FR/FRW (ICH6R/ICH6RW) SATA Controller (rev 03)
lspci (contrôleur en mode SATA)
00:1f.2 SATA controller: Intel Corporation 82801FR/FRW (ICH6R/ICH6RW) SATA Controller (rev 03)

Dans les trois cas, sous squeeze avec le noyau 2.6.32.5-686,
avec udevd --debug dans /etc/init.d/udev et udev_log=“debug” dans /etc/udev/udev.conf
Le système ne détecte pas le branchement à chaud de mes disques sata, udev reste muet et ne fait rien.
Rien dans dmesg, syslog, messages. Je peut confirmer qu’udev fonctionne pour des clés usb.

J’ai essayé de débrancher à chaud un disque présent au démarrage (et donc reconnu), le système ne remarque pas non plus son absence (et j’ai eu un panic un peu plus tard).

[quote]Dans les trois cas, sous squeeze avec le noyau 2.6.32.5-686,
avec udevd --debug dans /etc/init.d/udev et udev_log=“debug” dans /etc/udev/udev.conf
Le système ne détecte pas le branchement à chaud de mes disques sata, udev reste muet et ne fait rien.
Rien dans dmesg, syslog, messages. Je peut confirmer qu’udev fonctionne pour des clés usb.

J’ai essayé de débrancher à chaud un disque présent au démarrage (et donc reconnu), le système ne remarque pas non plus son absence (et j’ai eu un panic un peu plus tard).[/quote]
Comme tu n’as pas ce problème avec les autres versions du kernel, il ça semble venir du noyau lui-même.
Ce qui est bizarre c’est que si le disque SATA est branché avant de démarrer, il est reconnu ; c’est le branchement/débranchement à chaud qui buggue.

Je dirais que soit c’est le SATA qui est mal géré par le noyau, soit “udev” qui est buggué et qui n’arrive pas à établir de lien avec le noyau quand un périphérique est ajouté/enlevé. Tu as essayé de regarder dans les listes de bugs si tu retrouvais quelque chose de similaire ?

ce matin j’ai trouvé un bug similaire bugs.debian.org/cgi-bin/bugreport.cgi?bug=570821
Mais lui il l’a avec Lenny, et le bug est marqué non reproductible :confused:

Sous Lenny (noyau 2.6.26-2) j’ai tout ce qui suit qui s’affiche lorsque je branche/débranche un disque à chaud…

=== HotPlug ===

– udevadm monitor :

UEVENT[1282554575.789002] add /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi) UEVENT[1282554575.789220] add /class/scsi_disk/1:0:0:0 (scsi_disk) UDEV [1282554575.811741] add /class/bdi/8:16 (bdi) UEVENT[1282554575.811892] add /block/sdb/sdb1 (block) UEVENT[1282554575.812001] add /block/sdb/sdb2 (block) UEVENT[1282554575.812117] add /class/bdi/8:16 (bdi) UEVENT[1282554575.812616] add /class/scsi_device/1:0:0:0 (scsi_device) UEVENT[1282554575.812705] add /class/bsg/1:0:0:0 (bsg) UDEV [1282554575.827441] add /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi) UDEV [1282554575.828592] add /class/scsi_disk/1:0:0:0 (scsi_disk) UDEV [1282554575.833661] add /class/bsg/1:0:0:0 (bsg) UDEV [1282554575.839596] add /class/scsi_device/1:0:0:0 (scsi_device) UDEV [1282554575.928786] add /block/sdb (block) UDEV [1282554575.973361] add /block/sdb/sdb2 (block) UDEV [1282554576.002254] add /block/sdb/sdb1 (block)

– dmesg :

[ 237.071496] ata2: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0xe frozen [ 237.071666] ata2: irq_stat 0x00400040, connection status changed [ 237.071810] ata2: SError: { PHYRdyChg CommWake DevExch } [ 237.071960] ata2: hard resetting link [ 242.834769] ata2: link is slow to respond, please be patient (ready=0) [ 244.906742] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 244.909173] ata2.00: ATA-8: MAXTOR STM3500320AS, MX1A, max UDMA/133 [ 244.909173] ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 244.936822] ata2.00: configured for UDMA/133 [ 244.936968] ata2: EH complete [ 244.937223] scsi 1:0:0:0: Direct-Access ATA MAXTOR STM350032 MX1A PQ: 0 ANSI: 5 [ 244.937529] sd 1:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB) [ 244.937692] sd 1:0:0:0: [sdb] Write Protect is off [ 244.937832] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 244.937867] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 244.938105] sd 1:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB) [ 244.938267] sd 1:0:0:0: [sdb] Write Protect is off [ 244.938406] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 244.938441] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 244.938505] sdb: sdb1 sdb2 [ 244.963229] sd 1:0:0:0: [sdb] Attached SCSI disk

=== HotUnPlug ===

– udevadm monitor :

UDEV [1282554740.633724] remove /class/bsg/1:0:0:0 (bsg) UDEV [1282554740.633796] remove /class/scsi_device/1:0:0:0 (scsi_device) UDEV [1282554740.633824] remove /class/scsi_disk/1:0:0:0 (scsi_disk) UDEV [1282554740.633848] remove /class/bdi/8:16 (bdi) UDEV [1282554740.633868] remove /block/sdb/sdb2 (block) UDEV [1282554740.633886] remove /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi) UDEV [1282554740.633903] remove /block/sdb/sdb1 (block) UEVENT[1282554740.633921] remove /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi) UDEV [1282554740.635766] remove /block/sdb (block)

– dmesg :

[ 397.907968] ata2: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe frozen [ 397.908139] ata2: irq_stat 0x00400000, PHY RDY changed [ 397.908280] ata2: SError: { PHYRdyChg } [ 397.908427] ata2: hard resetting link [ 398.633045] ata2: SATA link down (SStatus 0 SControl 300) [ 398.633195] ata2: failed to recover some devices, retrying in 5 secs [ 403.639120] ata2: hard resetting link [ 403.959153] ata2: SATA link down (SStatus 0 SControl 300) [ 403.959305] ata2: failed to recover some devices, retrying in 5 secs [ 408.963251] ata2: hard resetting link [ 409.283723] ata2: SATA link down (SStatus 0 SControl 300) [ 409.283870] ata2.00: disabled [ 409.787746] ata2: EH complete [ 409.787904] ata2.00: detaching (SCSI 1:0:0:0) [ 409.788386] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [ 409.790493] sd 1:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 409.790777] sd 1:0:0:0: [sdb] Stopping disk [ 409.790927] sd 1:0:0:0: [sdb] START_STOP FAILED [ 409.791065] sd 1:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK

et rien sous Squeeze, c’est très étrange !

Et si tu utilises la commande suivante qui a été utilisée dans le rapport de bug que tu as donné :

grep sdd /var/log/messages
ça donne quoi ?

Dans mon cas présent je n’ai qu’un disque (sda), celui ajouté devrait être sdb, mais de toute manière je n’ai pas d’autre sd* que sda.

J’ai tout lu du rapport, et il ne m’apporte rien à part savoir que quelqu’un a eu un problème similaire. Mais ce n’est pas le même problème, la personne qui a rapporté le bug avait plus de chance que moi, il avait bien dans /var/log/messages l’information comme quoi son disque était présent, mais c’était l’entrée /dev qui n’était pas faite (et qu’il devait faire à la main). Moi je n’ai rien du tout, donc même pas de quoi faire un mknod à priori.

C’est ce qui me fait penser que c’est le kernel qui foire.

En effet, si c’était “udev”, tu aurais au moins une entrée dans les logs du kernel. Là ça ne semble pas être le cas, donc on dirait que le kernel lui-même ne voit pas l’ajout du périphérique.

Dans l’idéal, il faudrait essayer avec un kernel compilé depuis les sources vanilla pour voir si le bug vient du kernel d’origine ou du kernel retouché par Debian. A ce moment là on saurait au moins à qui remonter le bug.

Autrement je ne vois pas pour l’instant :confused:

Chose étrange, dans les multiples disques que j’ai sous la main, j’en ai un qui est un clone de ma lenny qui fonctionne (pas un clone raid, mais installé en suivant scrupuleusement la même procédure). Depuis cette Lenny, je n’ai rien non plus, alors que j’ai exactement la même configuration logicielle. Tout cela est très étrange.

Avec les mêmes mises à jour ?

très juste, j’ai une petite variation sur le noyau :slight_smile:

Sur la lenny qui fonctionne

Sur la lenny qui ne fonctionne pas

[code]$ diff lenny-ok lenny-ko
27,28d26
< ii bzip2 1.0.5-1 high-quality block-sorting file compressor - utilities
< ii chkconfig 11.0-79.1-1 system tool to enable or disable system services
40d37
< ii ddrescue 1.13-3 copies data from one file or block device to another
92d88
< ii insserv 1.12.0-4 boot sequence organizer using LSB init.d script dependencies
116,118c112,114
< ii libc6 2.7-18lenny2 GNU C Library: Shared libraries
< ii libc6-i686 2.7-18lenny2 GNU C Library: Shared libraries [i686 optimized]
< ii libc6-xen 2.7-18lenny2 GNU C Library: Shared libraries [Xen version]

ii libc6 2.7-18lenny4 GNU C Library: Shared libraries
ii libc6-i686 2.7-18lenny4 GNU C Library: Shared libraries [i686 optimized]
ii libc6-xen 2.7-18lenny4 GNU C Library: Shared libraries [Xen version]
120d115
< ii libcap1 1:1.10-14 support for getting/setting POSIX.1e capabilities
136d130
< rc libdrm2 2.3.1-2 Userspace interface to kernel DRM services – runtime
150d143
< rc libgl1-mesa-glx 7.0.3-7 A free implementation of the OpenGL API – GLX runtime
153d145
< rc libgmp3c2 2:4.2.2+dfsg-3 Multiprecision arithmetic library
166d157
< rc libice6 2:1.0.4-1 X11 Inter-Client Exchange library
178c169
< ii libkrb53 1.6.dfsg.4~beta1-5lenny2 MIT Kerberos runtime libraries


ii libkrb53 1.6.dfsg.4~beta1-5lenny4 MIT Kerberos runtime libraries
185d175
< rc libmpfr1ldbl 2.3.1.dfsg.1-2 multiple precision floating-point computation
199c189
< ii libpng12-0 1.2.27-2+lenny2 PNG library - runtime


ii libpng12-0 1.2.27-2+lenny3 PNG library - runtime
211d200
< rc libsm6 2:1.0.3-2 X11 Session Management library
242d230
< rc libxaw7 2:1.0.4-2 X11 Athena Widget library
259d246
< rc libxmu6 2:1.0.4-1 X11 miscellaneous utility library
261d247
< rc libxpm4 1:3.5.7-1 X11 pixmap library
264,269d249
< rc libxt6 1:1.0.5-3 X11 toolkit intrinsics library
< rc libxtst6 2:1.0.3-1 X11 Testing – Resource extension library
< rc libxv1 2:1.0.4-1 X11 Video extension library
< rc libxxf86dga1 2:1.0.2-1 X11 Direct Graphics Access extension library
< rc libxxf86vm1 1:1.0.2-1 X11 XFree86 video mode extension library
< ii links 2.1pre37-1.1 Web browser running in text mode
271,275c251,254
< ii linux-image-2.6.26-2-686 2.6.26-21lenny4 Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4
< ii linux-image-2.6.26-2-xen-686 2.6.26-21lenny4 Linux 2.6.26 image on i686, oldstyle Xen support
< ii linux-modules-2.6.26-2-xen-686 2.6.26-21lenny4 Linux 2.6.26 modules on i686
< ii locales 2.7-18lenny2 GNU C Library: National Language (locale) data [support]
< ii lockfile-progs 0.1.11-0.1 Programs for locking and unlocking files and mailboxes


ii linux-image-2.6.26-2-686 2.6.26-22lenny1 Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4
ii linux-image-2.6.26-2-xen-686 2.6.26-22lenny1 Linux 2.6.26 image on i686, oldstyle Xen support
ii linux-modules-2.6.26-2-xen-686 2.6.26-22lenny1 Linux 2.6.26 modules on i686
ii locales 2.7-18lenny4 GNU C Library: National Language (locale) data [support]
281,282d259
< ii lynx 2.8.7dev9-2.1 Text-mode WWW Browser (transitional package)
< ii lynx-cur 2.8.7dev9-2.1 Text-mode WWW Browser with NLS support (development version)
306,307d282
< ii ntp 1:4.2.4p4+dfsg-8lenny3 Network Time Protocol daemon and utility programs
< ii ntpdate 1:4.2.4p4+dfsg-8lenny3 client for setting system time from NTP servers
335,336c310
< ii smartmontools 5.38-2+lenny1 control and monitor storage systems using S.M.A.R.T.
< ii sudo 1.6.9p17-2+lenny1 Provide limited super user privileges to specific users


ii sudo 1.6.9p17-3 Provide limited super user privileges to specific users
360a335
rc vim-tiny 1:7.1.314-3+lenny2 Vi IMproved - enhanced vi editor - compact version
370d344
< rc x11-utils 7.3+2+nmu1 X11 utilities
373c347
< ii xen-linux-system-2.6.26-2-xen-686 2.6.26-21lenny4 XEN system with Linux 2.6.26 image on i686


ii xen-linux-system-2.6.26-2-xen-686 2.6.26-22lenny1 XEN system with Linux 2.6.26 image on i686
384d357
< rc xterm[/code]

ceci est très intéressant :

[code]$ diff lenny-ok lenny-ko | grep linux
< ii linux-image-2.6.26-2-686 2.6.26-21lenny4 Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4
< ii linux-image-2.6.26-2-xen-686 2.6.26-21lenny4 Linux 2.6.26 image on i686, oldstyle Xen support
< ii linux-modules-2.6.26-2-xen-686 2.6.26-21lenny4 Linux 2.6.26 modules on i686

ii linux-image-2.6.26-2-686 2.6.26-22lenny1 Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4
ii linux-image-2.6.26-2-xen-686 2.6.26-22lenny1 Linux 2.6.26 image on i686, oldstyle Xen support
ii linux-modules-2.6.26-2-xen-686 2.6.26-22lenny1 Linux 2.6.26 modules on i686
< ii xen-linux-system-2.6.26-2-xen-686 2.6.26-21lenny4 XEN system with Linux 2.6.26 image on i686
ii xen-linux-system-2.6.26-2-xen-686 2.6.26-22lenny1 XEN system with Linux 2.6.26 image on i686[/code]

L’hotplug fonctionne avec le noyau 2.6.26-2-686 fournit par le paquet 2.6.26-21lenny4, et pas celui fournit par le paquet 2.6.26-22lenny1

Juste pour prévenir, on voit des noyaux xen, mais tout les tests que j’ai relatés ont été fait avec Xen et sans Xen, avec les mêmes résultats donc Xen n’est pas responsable du dysfonctionnement.

Sur ma lenny qui ne fonctionne pas j’ai mit à jour à nouveau

[code]$ diff lenny-ok lenny-ko2 | grep linux
< ii linux-image-2.6.26-2-686 2.6.26-21lenny4 Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4
< ii linux-image-2.6.26-2-xen-686 2.6.26-21lenny4 Linux 2.6.26 image on i686, oldstyle Xen support
< ii linux-modules-2.6.26-2-xen-686 2.6.26-21lenny4 Linux 2.6.26 modules on i686

ii linux-image-2.6.26-2-686 2.6.26-24lenny1 Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4
ii linux-image-2.6.26-2-xen-686 2.6.26-24lenny1 Linux 2.6.26 image on i686, oldstyle Xen support
ii linux-modules-2.6.26-2-xen-686 2.6.26-24lenny1 Linux 2.6.26 modules on i686
< ii xen-linux-system-2.6.26-2-xen-686 2.6.26-21lenny4 XEN system with Linux 2.6.26 image on i686
ii xen-linux-system-2.6.26-2-xen-686 2.6.26-24lenny1 XEN system with Linux 2.6.26 image on i686[/code]

J’ai donc la version du paquet 2.6.26-24lenny1, cela ne fonctionne toujours pas.
On peut supposer une régression entre le paquet 2.6.26-21lenny4 et le 2.6.26-22lenny1

je vais faire un clone (dd) de mon installation qui fonctionne, vérifier que le clone fonctionne, et faire une màj…

La réponse est ailleurs :slight_smile: On le vois dans le diff de dpkg -l plus haut…

Je ne sais pour quelle raison, ce qui fait la différence en fait entre
mes différentes installations, ce n’est pas la version du noyau, mais
la présence du paquet smartmontooles, l’hotplug fonctionne une fois que
l’on a installé ce paquet dans toutes les configurations.

Debian linux-image¹ smartmontools sata-hotplug ======= =============== ================ ============ Lenny 2.6.26-21lenny4 - - Lenny 2.6.26-21lenny4 5.38-2+lenny1 Oui Lenny 2.6.26-22lenny1 - - Lenny 2.6.26-22lenny1 5.38-2+lenny1 Oui Lenny 2.6.26-24 - - Lenny 2.6.26-24 5.38-2+lenny1 Oui Lenny 2.6.26-24lenny1 - - Lenny 2.6.26-24lenny1 5.38-2+lenny1 Oui Squeeze 2.6.32-18 - - Squeeze 2.6.32-18 5.39.1+svn3124-1 Oui

Le paquet smartmontools installe libcap-ng0 en dépendance, mais c’est bien le
paquet smartmontools qui contient ce qui permet l’hotplug.

Debian linux-image¹ smartmontools libcap-ng0 sata-hotplug ======= ============ ================ ========== ============ Squeeze 2.6.32-18 - - - Squeeze 2.6.32-18 - 0.6.4-1 - Squeeze 2.6.32-18 5.39.1+svn3124-1 0.6.4-1 Oui

Il n’est pas nécessaire que le démon smartd fonctionne (start_smartd=no ou
absent dans /etc/default/smartmontools), il suffit que le paquet smartmontools
soit installé, seulement présent. /etc/default/smartmontools peut aussi être
absent.

[code]présence-au-démarrage présence-à-l’insertion sata-hotplug
===================== ====================== ============


  •                  Oui                     -
    

Oui Oui Oui
Oui - Oui[/code]

Il faut que le paquet soit présent lorsque le noyau démarre, et peut être
désinstallé après démarrage, et cela fonctionne encore jusqu’au prochain
redémarrage, donc il y a un lien direct avec le noyau.

mis à part /usr/share/bug/, /usr/share/doc/, /sur/share/man/, le paquet
smartmontools contient :

/etc/default/smartmontools /etc/init.d/smartmontools /etc/smartd.conf /etc/smartmontools/run.d/10mail /etc/smartmontools/run.d/10powersave-notify /usr/sbin/smartctl /usr/sbin/smartd /usr/share/lintian/overrides/smartmontools /usr/share/smartmontools/smartd-runner /var/lib/smartmontools

Qu’y a t’il dans cela qui puisse contrôler le noyau ?

  • Si /usr/sbin/smartctl est supprimé, l’hotplug fonctionne toujours
  • Si /usr/sbin/smartd est supprimé, après redémarrage l’hotplug ne
    fonctionne pas, il faut qu’il soit présent au démarrage.

Smartd n’est pas sensé être lancé lors de l’init, mais à un moment ce
binaire sert tout de même à quelquechose puisqu’il est indispensable à
l’hotplug, il ne sert pas qu’au monitoring !

Dans la description du paquet smartmontools, il est écrit :

[quote]control and monitor storage systems using S.M.A.R.T.
The smartmontools package contains two utility programs (smartctl and smartd)
to control and monitor storage systems using the Self-Monitoring, Analysis and
Reporting Technology System (S.M.A.R.T.) built into most modern ATA and SCSI
hard disks. It is derived from the smartsuite package, and includes support
for ATA/ATAPI-5 disks. It should run on any modern Linux system.[/quote]
Rien à propos de l’hotplug.
Rien non plus à ce propos dans le man de smartctl, smartd ou smartd.conf .
Rien dans smartd.conf ni dans /usr/share/doc/smartmontools/README …

Ce que j’en conclus c’est qu’une installation Debian Lenny ou Debian Squeeze
par défaut ne sait pas gérer l’hotplug SATA parce que smartmontools n’est pas
installé par défaut, et à priori rien dans la doc ne permet de savoir qu’il est
nécessaire et qu’il faut donc l’installer, non pas seulement pour le monitoring,
mais aussi pour l’hotplug !


Mais voilà, dans toutes les configurations, mais pas dans tout les cas…

Parfois quand je redémarre l’hotplug ne fonctionne pas… et après un autre
redémarrage l’hotplug refonctionne à nouveau; là j’ai du mal à voir !

Donc j’ai toujours un problème : il n’est pas garanti que l’hotplug
refonctionne après un redémarrage, ce qui n’est pas du tout pratique, et je
ne vois pas d’autre moyen de le vérifier qu’en insérant un disque (et donc
être sur place).

[1] idem avec linux-image-2.6.??-?-686 ou linux-image-2.6.??-?-xen-686