Je ne sais par quelle op=E9ration,
les noms des partitions de mon serveur sont
pass=E9s de /dev/sdaX =E0 /dev/sdcX,
soit 8 partitions /dev/sda1 =E0 8 =3D> /dev/sdc1 =E0 8.
Comment r=E9tablir leur nom en /dev/sda1 =E0 8 ?
On m'a dit que c'=E9tait impossible, sauf en recompilant le noyau.
On ne peut pas le garantir, et ce n'est désormais plus important. Ce qu'il faut, c'est utiliser les device réels (pour l'instant /dev/sdcX) pour changer les labels en fonction d'un rôle de la partition (à cet égard, s'il n'y a qu'un seul swap, swap est le seul label plutôt bien choisi).
Je recommande de préfixer ou suffixer les étiquettes (LABEL et PARTLABEL) avec un identifiant représentatif de la machine ou du système. Ainsi en cas de branchement du disque pour maintenance ou récupération sur une autre machine qui adopte la même convention, il n'y aurait pas de conflit d'étiquettes ni de risque de confusion entre les partitions des différents disques.
Et ensuite utiliser les labels pour le montage, afin que les montages ne soient plus dépendants de l'ordre de détection des disques.
Dans ce cas ma recommandation est encore plus valable.
Le 21/12/2017 à 00:09, Eric Degenetais a écrit :
On ne peut pas le garantir, et ce n'est désormais plus important. Ce qu'il
faut, c'est utiliser les device réels (pour l'instant /dev/sdcX) pour
changer les labels en fonction d'un rôle de la partition (à cet égard, s'il
n'y a qu'un seul swap, swap est le seul label plutôt bien choisi).
Je recommande de préfixer ou suffixer les étiquettes (LABEL et
PARTLABEL) avec un identifiant représentatif de la machine ou du
système. Ainsi en cas de branchement du disque pour maintenance ou
récupération sur une autre machine qui adopte la même convention, il n'y
aurait pas de conflit d'étiquettes ni de risque de confusion entre les
partitions des différents disques.
Et ensuite utiliser les labels pour le montage, afin que les montages ne
soient plus dépendants de l'ordre de détection des disques.
Dans ce cas ma recommandation est encore plus valable.
On ne peut pas le garantir, et ce n'est désormais plus important. Ce qu'il faut, c'est utiliser les device réels (pour l'instant /dev/sdcX) pour changer les labels en fonction d'un rôle de la partition (à cet égard, s'il n'y a qu'un seul swap, swap est le seul label plutôt bien choisi).
Je recommande de préfixer ou suffixer les étiquettes (LABEL et PARTLABEL) avec un identifiant représentatif de la machine ou du système. Ainsi en cas de branchement du disque pour maintenance ou récupération sur une autre machine qui adopte la même convention, il n'y aurait pas de conflit d'étiquettes ni de risque de confusion entre les partitions des différents disques.
Et ensuite utiliser les labels pour le montage, afin que les montages ne soient plus dépendants de l'ordre de détection des disques.
Dans ce cas ma recommandation est encore plus valable.
Stephane Ascoet
Le 20/12/2017 à 16:25, Sébastien NOBILI a écrit :
Bonjour, Le mardi 19 décembre 2017 à 17:45, a écrit :
Je ne sais par quelle opération, les noms des partitions de mon serveur sont passés de /dev/sdaX à /dev/sdcX, soit 8 partitions /dev/sda1 à 8 => /dev/sdc1 à 8.
Bonjour, belle trouvaille, en fait les choses sont ainsi depuis cet ete, ce disque dur n'a jamais ete /dev/sda. Andre a du bidouille les etiquettes mais comme on l'a tous dit dans ce dialogue de sourd qui tourne en boucle, ce ne sont que des etiquettes, ce disque a toujours ete et sera toujours /dev/sdc. Visiblement Andre confond nom de bloc, etiquette et dossier de montage depuis le debut(etonnant pour un membre historique de la liste comme lui)... -- Cordialement, Stephane Ascoet
Le 20/12/2017 à 16:25, Sébastien NOBILI a écrit :
Bonjour,
Le mardi 19 décembre 2017 à 17:45, andre_debian@numericable.fr a écrit :
Je ne sais par quelle opération,
les noms des partitions de mon serveur sont
passés de /dev/sdaX à /dev/sdcX,
soit 8 partitions /dev/sda1 à 8 => /dev/sdc1 à 8.
Bonjour, belle trouvaille, en fait les choses sont ainsi depuis cet ete,
ce disque dur n'a jamais ete /dev/sda. Andre a du bidouille les
etiquettes mais comme on l'a tous dit dans ce dialogue de sourd qui
tourne en boucle, ce ne sont que des etiquettes, ce disque a toujours
ete et sera toujours /dev/sdc. Visiblement Andre confond nom de bloc,
etiquette et dossier de montage depuis le debut(etonnant pour un membre
historique de la liste comme lui)...
Bonjour, Le mardi 19 décembre 2017 à 17:45, a écrit :
Je ne sais par quelle opération, les noms des partitions de mon serveur sont passés de /dev/sdaX à /dev/sdcX, soit 8 partitions /dev/sda1 à 8 => /dev/sdc1 à 8.
Bonjour, belle trouvaille, en fait les choses sont ainsi depuis cet ete, ce disque dur n'a jamais ete /dev/sda. Andre a du bidouille les etiquettes mais comme on l'a tous dit dans ce dialogue de sourd qui tourne en boucle, ce ne sont que des etiquettes, ce disque a toujours ete et sera toujours /dev/sdc. Visiblement Andre confond nom de bloc, etiquette et dossier de montage depuis le debut(etonnant pour un membre historique de la liste comme lui)... -- Cordialement, Stephane Ascoet
Daniel Caillibaud
Le 19/12/17 à 17:45, a écrit : AF> Bonjour, AF> AF> Je ne sais par quelle opération, AF> les noms des partitions de mon serveur sont AF> passés de /dev/sdaX à /dev/sdcX, AF> soit 8 partitions /dev/sda1 à 8 => /dev/sdc1 à 8. Juste une remarque pour compléter toutes les autres déjà fai tes (mettre des uuid ou des labels dans le fstab), lvm permet aussi de s'affranchir de ces pbs (outre le fait de pouvoir redimensionner ses partitions ou les changer de disque sans rien avoir à modifier dans /etc) Avec lvm les partitions restent toujours /dev/nomVG/nomLV Attention, avec lvm si on redimensionne une partition il me semble que le uuid change (mais pas si sûr, juste un doute) -- Daniel Toute technique est mise au point, utilisée, importante, obsolète, standardisée puis comprise.
Le 19/12/17 à 17:45, andre_debian@numericable.fr a écrit :
AF> Bonjour,
AF>
AF> Je ne sais par quelle opération,
AF> les noms des partitions de mon serveur sont
AF> passés de /dev/sdaX à /dev/sdcX,
AF> soit 8 partitions /dev/sda1 à 8 => /dev/sdc1 à 8.
Juste une remarque pour compléter toutes les autres déjà fai tes (mettre des
uuid ou des labels dans le fstab), lvm permet aussi de s'affranchir de ces
pbs (outre le fait de pouvoir redimensionner ses partitions ou les changer
de disque sans rien avoir à modifier dans /etc)
Avec lvm les partitions restent toujours /dev/nomVG/nomLV
Attention, avec lvm si on redimensionne une partition il me semble que le
uuid change (mais pas si sûr, juste un doute)
--
Daniel
Toute technique est mise au point, utilisée, importante, obsolète,
standardisée puis comprise.
Le 19/12/17 à 17:45, a écrit : AF> Bonjour, AF> AF> Je ne sais par quelle opération, AF> les noms des partitions de mon serveur sont AF> passés de /dev/sdaX à /dev/sdcX, AF> soit 8 partitions /dev/sda1 à 8 => /dev/sdc1 à 8. Juste une remarque pour compléter toutes les autres déjà fai tes (mettre des uuid ou des labels dans le fstab), lvm permet aussi de s'affranchir de ces pbs (outre le fait de pouvoir redimensionner ses partitions ou les changer de disque sans rien avoir à modifier dans /etc) Avec lvm les partitions restent toujours /dev/nomVG/nomLV Attention, avec lvm si on redimensionne une partition il me semble que le uuid change (mais pas si sûr, juste un doute) -- Daniel Toute technique est mise au point, utilisée, importante, obsolète, standardisée puis comprise.
Pascal Hambourg
Le 23/12/2017 à 12:23, Daniel Caillibaud a écrit :
Juste une remarque pour compléter toutes les autres déjà faites (mettre des uuid ou des labels dans le fstab), lvm permet aussi de s'affranchir de ces pbs (outre le fait de pouvoir redimensionner ses partitions ou les changer de disque sans rien avoir à modifier dans /etc)
Je ne peux que recommander LVM aussi, mais pas pour les mauvaises raisons. On peut aussi bien redimensionner ou déplacer une partition classique sans modifier /etc/fstab si celle-ci y est identifiée par son UUID ou LABEL.
Avec lvm les partitions restent toujours /dev/nomVG/nomLV
Volumes logiques, pas partitions. Attention, il y a en parallèle un autre schéma de nommage : /dev/mapper/nomVG-nomLV (les éventuels tirets dans les noms de VG et LV sont doublés, il vaut donc mieux les éviter). Cette forme est celle utilisée par l'installateur pour identifier les volumes logiques dans /etc/fstab, et par l'initramfs pour détecter qu'il s'agit d'un volume logique afin de l'activer. A noter que ces deux formes sont en fait des liens symboliques qui pointent vers le "vrai" nom (canonique) de périphérique /dev/dm-N, comme tous les périphériques créés par le device mapper. Ce nom canonique peut être visible par exemple dans /proc/partitions et /proc/mounts.
Attention, avec lvm si on redimensionne une partition il me semble que le uuid change (mais pas si sûr, juste un doute)
Non. Aucune raison pour que ce soit le cas. L'UUID est un attribut du contenant, pas du contenu.
Le 23/12/2017 à 12:23, Daniel Caillibaud a écrit :
Juste une remarque pour compléter toutes les autres déjà faites (mettre des
uuid ou des labels dans le fstab), lvm permet aussi de s'affranchir de ces
pbs (outre le fait de pouvoir redimensionner ses partitions ou les changer
de disque sans rien avoir à modifier dans /etc)
Je ne peux que recommander LVM aussi, mais pas pour les mauvaises
raisons. On peut aussi bien redimensionner ou déplacer une partition
classique sans modifier /etc/fstab si celle-ci y est identifiée par son
UUID ou LABEL.
Avec lvm les partitions restent toujours /dev/nomVG/nomLV
Volumes logiques, pas partitions.
Attention, il y a en parallèle un autre schéma de nommage :
/dev/mapper/nomVG-nomLV (les éventuels tirets dans les noms de VG et LV
sont doublés, il vaut donc mieux les éviter). Cette forme est celle
utilisée par l'installateur pour identifier les volumes logiques dans
/etc/fstab, et par l'initramfs pour détecter qu'il s'agit d'un volume
logique afin de l'activer. A noter que ces deux formes sont en fait des
liens symboliques qui pointent vers le "vrai" nom (canonique) de
périphérique /dev/dm-N, comme tous les périphériques créés par le device
mapper. Ce nom canonique peut être visible par exemple dans
/proc/partitions et /proc/mounts.
Attention, avec lvm si on redimensionne une partition il me semble que le
uuid change (mais pas si sûr, juste un doute)
Non. Aucune raison pour que ce soit le cas. L'UUID est un attribut du
contenant, pas du contenu.
Le 23/12/2017 à 12:23, Daniel Caillibaud a écrit :
Juste une remarque pour compléter toutes les autres déjà faites (mettre des uuid ou des labels dans le fstab), lvm permet aussi de s'affranchir de ces pbs (outre le fait de pouvoir redimensionner ses partitions ou les changer de disque sans rien avoir à modifier dans /etc)
Je ne peux que recommander LVM aussi, mais pas pour les mauvaises raisons. On peut aussi bien redimensionner ou déplacer une partition classique sans modifier /etc/fstab si celle-ci y est identifiée par son UUID ou LABEL.
Avec lvm les partitions restent toujours /dev/nomVG/nomLV
Volumes logiques, pas partitions. Attention, il y a en parallèle un autre schéma de nommage : /dev/mapper/nomVG-nomLV (les éventuels tirets dans les noms de VG et LV sont doublés, il vaut donc mieux les éviter). Cette forme est celle utilisée par l'installateur pour identifier les volumes logiques dans /etc/fstab, et par l'initramfs pour détecter qu'il s'agit d'un volume logique afin de l'activer. A noter que ces deux formes sont en fait des liens symboliques qui pointent vers le "vrai" nom (canonique) de périphérique /dev/dm-N, comme tous les périphériques créés par le device mapper. Ce nom canonique peut être visible par exemple dans /proc/partitions et /proc/mounts.
Attention, avec lvm si on redimensionne une partition il me semble que le uuid change (mais pas si sûr, juste un doute)
Non. Aucune raison pour que ce soit le cas. L'UUID est un attribut du contenant, pas du contenu.
andre_debian
On Saturday 23 December 2017 05:56:34 Comendatore wrote:
Si ta machine est une machine hébergée par un prestataire, n'y aurait-il pas du RAID ? En principe, tout bon hébergeur met d'office du RAID actue llement. Pour le savoir, dans le cas d'un RAID hardware : lspci -vv | grep -i raid , pour un RAID software : cat /proc/mdstat et pour avoir des info completes : mdadm -D /dev/md[X] De mémoire, il m'est déjà arrivé un truc du genre, o ù le RAID était complètement inactif suite à des pannes sur des disques. Ça vaut peut-être le coup de checker ça ;-) Rooty
Merci, c'était une bonne piste : # lspci -vv | grep -i raid , ne donne pas de réponse. # cat /proc/mdstat , idem # /sbin/./mdadm -D /dev/md0 , "/dev/mda: No such file" Pas de RAID installé, semble t-il... Au risque d'un tsunami, tant que je n'aurais pas dans le rép /dev, sda1 à sda8, je peux pas faire grand chose. André
On Saturday 23 December 2017 05:56:34 Comendatore wrote:
Si ta machine est une machine hébergée par un prestataire, n'y aurait-il pas
du RAID ? En principe, tout bon hébergeur met d'office du RAID actue llement.
Pour le savoir, dans le cas d'un RAID hardware : lspci -vv | grep -i raid ,
pour un RAID software : cat /proc/mdstat et pour avoir des info completes :
mdadm -D /dev/md[X]
De mémoire, il m'est déjà arrivé un truc du genre, o ù le RAID était
complètement inactif suite à des pannes sur des disques.
Ça vaut peut-être le coup de checker ça ;-)
Rooty
Merci, c'était une bonne piste :
# lspci -vv | grep -i raid , ne donne pas de réponse.
# cat /proc/mdstat , idem
# /sbin/./mdadm -D /dev/md0 , "/dev/mda: No such file"
Pas de RAID installé, semble t-il...
Au risque d'un tsunami, tant que je n'aurais pas dans le rép /dev,
sda1 à sda8, je peux pas faire grand chose.
On Saturday 23 December 2017 05:56:34 Comendatore wrote:
Si ta machine est une machine hébergée par un prestataire, n'y aurait-il pas du RAID ? En principe, tout bon hébergeur met d'office du RAID actue llement. Pour le savoir, dans le cas d'un RAID hardware : lspci -vv | grep -i raid , pour un RAID software : cat /proc/mdstat et pour avoir des info completes : mdadm -D /dev/md[X] De mémoire, il m'est déjà arrivé un truc du genre, o ù le RAID était complètement inactif suite à des pannes sur des disques. Ça vaut peut-être le coup de checker ça ;-) Rooty
Merci, c'était une bonne piste : # lspci -vv | grep -i raid , ne donne pas de réponse. # cat /proc/mdstat , idem # /sbin/./mdadm -D /dev/md0 , "/dev/mda: No such file" Pas de RAID installé, semble t-il... Au risque d'un tsunami, tant que je n'aurais pas dans le rép /dev, sda1 à sda8, je peux pas faire grand chose. André
Pascal Hambourg
Le 23/12/2017 à 16:10, a écrit :
Au risque d'un tsunami, tant que je n'aurais pas dans le rép /dev, sda1 à sda8, je peux pas faire grand chose.
Tu peux faire tout ce que tu veux quel que soit le nom du disque. C'est juste que tu ne veux pas.
Le 23/12/2017 à 16:10, andre_debian@numericable.fr a écrit :
Au risque d'un tsunami, tant que je n'aurais pas dans le rép /dev,
sda1 à sda8, je peux pas faire grand chose.
Tu peux faire tout ce que tu veux quel que soit le nom du disque. C'est
juste que tu ne veux pas.
On Saturday 23 December 2017 19:17:05 Pascal Hambourg wrote:
Le 23/12/2017 à 16:10, a écrit :
Au risque d'un tsunami, tant que je n'aurais pas dans le rép /dev, sda1 à sda8, je peux pas faire grand chose.
Tu peux faire tout ce que tu veux quelquesoit le nom du disque :
Et comment donc ?
En utilisant /dev/sdc au lieu de /dev/sda.
J'ai peut-être trouvé la solution par cette simple commande : # mv sdc1 à 8 sda1 à 8
/dev étant un devtmpfs peuplé dynamiquement, cela ne persistera pas au reboot.
L'UUID est préservé (blkid /dev/sdaX). Ensuite, modifier sdcX en sdaX dans les rép de /dev/disk/ : by-id by-label by-path by-uuid.
Etc. etc. Il aurait été plus simple de créer des liens symboliques /dev/sda* pointant vers /dev/sdc*.
hamster
Le 23/12/2017 à 23:28, Pascal Hambourg a écrit :
J'ai peut-être trouvé la solution par cette simple commande : # mv sdc1 à 8 sda1 à 8
/dev étant un devtmpfs peuplé dynamiquement, cela ne persistera pas au reboot.
+1, tu peux trifouiller tant que tu veux dans /dev, le noyau effacera tout et recommancera a zero comme bon lui chante au prochain reboot. Et il n'y a meme pas besoin d'attendre le prochain reboot. Il suffit de débrancher le disque et le rebrancher. Quand on débranche, le fichier bloc est détruit, quand on rebranche le noyau refait un autre fichier bloc comme bon lui chante. Il est courant qu'après débranchage / rebranchage le fichier bloc n'ait plus le meme nom. Par exemple un disque qui etait nommé sda, on débranche / rebranche et pouf, il est nommé sdc. On n'a aucune maitrise sur la facon dont le noyau nomme les fichiers bloc.
Le 23/12/2017 à 23:28, Pascal Hambourg a écrit :
J'ai peut-être trouvé la solution par cette simple commande :
# mv sdc1 à 8 sda1 à 8
/dev étant un devtmpfs peuplé dynamiquement, cela ne persistera pas au
reboot.
+1, tu peux trifouiller tant que tu veux dans /dev, le noyau effacera
tout et recommancera a zero comme bon lui chante au prochain reboot.
Et il n'y a meme pas besoin d'attendre le prochain reboot. Il suffit de
débrancher le disque et le rebrancher. Quand on débranche, le fichier
bloc est détruit, quand on rebranche le noyau refait un autre fichier
bloc comme bon lui chante. Il est courant qu'après débranchage /
rebranchage le fichier bloc n'ait plus le meme nom. Par exemple un
disque qui etait nommé sda, on débranche / rebranche et pouf, il est
nommé sdc. On n'a aucune maitrise sur la facon dont le noyau nomme les
fichiers bloc.
J'ai peut-être trouvé la solution par cette simple commande : # mv sdc1 à 8 sda1 à 8
/dev étant un devtmpfs peuplé dynamiquement, cela ne persistera pas au reboot.
+1, tu peux trifouiller tant que tu veux dans /dev, le noyau effacera tout et recommancera a zero comme bon lui chante au prochain reboot. Et il n'y a meme pas besoin d'attendre le prochain reboot. Il suffit de débrancher le disque et le rebrancher. Quand on débranche, le fichier bloc est détruit, quand on rebranche le noyau refait un autre fichier bloc comme bon lui chante. Il est courant qu'après débranchage / rebranchage le fichier bloc n'ait plus le meme nom. Par exemple un disque qui etait nommé sda, on débranche / rebranche et pouf, il est nommé sdc. On n'a aucune maitrise sur la facon dont le noyau nomme les fichiers bloc.
hamster
Le 23/12/2017 à 16:10, a écrit :
tant que je n'aurais pas dans le rép /dev, sda1 à sda8, je peux pas faire grand chose.
Je pense que c'est la la source de l'incompréhension. On arrive pas a se faire une idée de ce qui te bloque, de ce qui t'oblige a avoir tes partoches nomées sda, de ce qui t'empeche de faire quoi que ce soit tant qu'elles sont pas nommées comme ca. Et tu ne nous donne aucun indice. Nous, de notre coté, on ne connait pas de cas ou c'est bloquant, mais sans doute est-tu dans un cas particulier qu'on connait pas… et qu'on arrivera pas a deviner tant que tu nous en dira pas plus.
Le 23/12/2017 à 16:10, andre_debian@numericable.fr a écrit :
tant que je n'aurais pas dans le rép /dev,
sda1 à sda8, je peux pas faire grand chose.
Je pense que c'est la la source de l'incompréhension. On arrive pas a se
faire une idée de ce qui te bloque, de ce qui t'oblige a avoir tes
partoches nomées sda, de ce qui t'empeche de faire quoi que ce soit tant
qu'elles sont pas nommées comme ca. Et tu ne nous donne aucun indice.
Nous, de notre coté, on ne connait pas de cas ou c'est bloquant, mais
sans doute est-tu dans un cas particulier qu'on connait pas… et qu'on
arrivera pas a deviner tant que tu nous en dira pas plus.
tant que je n'aurais pas dans le rép /dev, sda1 à sda8, je peux pas faire grand chose.
Je pense que c'est la la source de l'incompréhension. On arrive pas a se faire une idée de ce qui te bloque, de ce qui t'oblige a avoir tes partoches nomées sda, de ce qui t'empeche de faire quoi que ce soit tant qu'elles sont pas nommées comme ca. Et tu ne nous donne aucun indice. Nous, de notre coté, on ne connait pas de cas ou c'est bloquant, mais sans doute est-tu dans un cas particulier qu'on connait pas… et qu'on arrivera pas a deviner tant que tu nous en dira pas plus.
daniel huhardeaux
Le 23/12/2017 à 23:06, a écrit :
On Saturday 23 December 2017 19:17:05 Pascal Hambourg wrote:
Le 23/12/2017 à 16:10, a écrit :
Au risque d'un tsunami, tant que je n'aurais pas dans le rép /dev, sda1 à sda8, je peux pas faire grand chose.
Tu peux faire tout ce que tu veux quelquesoit le nom du disque :
Et comment donc ?
C'est juste que tu ne veux pas :
Remarque acerbe, surtout après ce que j'ai écrit :
"tant que je n'aurais pas dans /dev, sda1 à sda8, je peux pas faire grand
Je suis comme tout le monde, incapable de comprendre ce qui ne va pas dans ta logique. Quelqu'un t'avais demandé de voir dans dmesg quels extaient les logs qui concernaient les disques, je n'ai pas souvenir d'avoir vu passer l'information. ~$ dmesg|grep sd -- Daniel
Le 23/12/2017 à 23:06, andre_debian@numericable.fr a écrit :
On Saturday 23 December 2017 19:17:05 Pascal Hambourg wrote:
Le 23/12/2017 à 16:10, andre_debian@numericable.fr a écrit :
Au risque d'un tsunami, tant que je n'aurais pas dans le rép /dev,
sda1 à sda8, je peux pas faire grand chose.
Tu peux faire tout ce que tu veux quelquesoit le nom du disque :
Et comment donc ?
C'est juste que tu ne veux pas :
Remarque acerbe, surtout après ce que j'ai écrit :
"tant que je n'aurais pas dans /dev, sda1 à sda8, je peux pas faire grand
Je suis comme tout le monde, incapable de comprendre ce qui ne va pas
dans ta logique. Quelqu'un t'avais demandé de voir dans dmesg quels
extaient les logs qui concernaient les disques, je n'ai pas souvenir
d'avoir vu passer l'information.
On Saturday 23 December 2017 19:17:05 Pascal Hambourg wrote:
Le 23/12/2017 à 16:10, a écrit :
Au risque d'un tsunami, tant que je n'aurais pas dans le rép /dev, sda1 à sda8, je peux pas faire grand chose.
Tu peux faire tout ce que tu veux quelquesoit le nom du disque :
Et comment donc ?
C'est juste que tu ne veux pas :
Remarque acerbe, surtout après ce que j'ai écrit :
"tant que je n'aurais pas dans /dev, sda1 à sda8, je peux pas faire grand
Je suis comme tout le monde, incapable de comprendre ce qui ne va pas dans ta logique. Quelqu'un t'avais demandé de voir dans dmesg quels extaient les logs qui concernaient les disques, je n'ai pas souvenir d'avoir vu passer l'information. ~$ dmesg|grep sd -- Daniel
