souci imprimante usb (fdisk -l , hddtemp )

Le
alain-buster
bonjour , je rencontre un souci avec mon imprimante usb HP ENVY 5536 .

je ne sais à quel(s) paquet se rapporte le souci :

description :

1) j'allume l'imprimante

2) j'allume le pc

3) arrivé sous testing , les disques sont tous mélangés .

certains ne sont plus reconnus et d'autres décalés d'une lettre .

fdisk -l se mélange les pinceaux.

deuxième cas de figure :

1) j'allume le pc

2) j'allume l'imprimante

3) pas de souci . tout fonctionne parfaitement .

aucun disque ne disparait , tous sont reconnus dans l'ordre.

je me suis bien exprimé ? besoin d' éclaircissements ?

je me tiens à votre disposition .

je ne sais ni quand , ni où , ni comment poster ???

merci

alain

alain_bellec@bbox.fr
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
steve
Le #26501810
Le 17-12-2018, à 15:01:42 +0100, infos SX a écrit :
On Monday 17 December 2018 14:47:03 Eric Degenetais wrote:
certains ne sont plus reconnus et d'autres décalés d'une lettre .


ça vient peut-être d'un certain manque de robustesse de la configuration :
si je comprends bien la configuration utilise des device names du type
/dev/sda1, dev/sda2, /dev/sdb ...
Or ces lettres dépendent de l'ordre dans lequel les périphériques répondent
lors de leur énumération, ordre dont la stabilité n'est pas (n'a jamais
été) garantie.
Il est aujourd'hui recommandé de référencer les périphériques
- soit par l'UUID de la partition (ce que font normalement les
installeurs, mais il faut le faire soi-même si c'est une migration)
soit par un 'label' descriptif (/dev/disk/by-label/my_data_part) créé
avec les outils de gestion de FS (un peu plus de travail, mais a
l'avantage d'être immédiatement lisible)

C'est ce que j'ai fait sur un serveur avec un seul disque dur.
UUID et /dev/disk/by-label/my_data_part,
Lorsque je fais un reboot, une fois sur deux il devient /dev/sdc
et l'autre fois, /dev/sda.

Difficile de croire que ça soit possible vu qu'il n'y a qu'un seul
disque. Et même si c'était bien le cas, ce ne serait pas grave vu que
tu as utilisé le UUID et que le nom (aléatoire) du disque n'est pas
utilisé pour monter la partition.
/dev/disk/by-label/my_data_part :
je n'ai pas ce fichier "my_data_part".

Sauf erreur, il n'y a pas de fichier nommé ainsi. Ici par exemple, j'ai
lrwxrwxrwx 1 root root 10 déc 14 21:40 BOOT -> ../../sda1
et
lrwxrwxrwx 1 root root 10 déc 14 21:40 3148652c-4040-4348-9022-22250d497fcd -> ../../sda1
où BOOT est le nom de l'étiquette de /dev/sda1 et 3148652c-4040-4348-9022-22250d497fcd son uuid.
ajh-valmer
Le #26501818
Le 17-12-2018, à 15:01:42 +0100, A. Valmer a écrit :
C'est ce que j'ai fait sur un serveur avec un seul disque dur.
UUID et /dev/disk/by-label/my_data_part,
Lorsque je fais un reboot, une fois sur deux il devient /dev/sdc
et l'autre fois, /dev/sda.


On Monday 17 December 2018 15:47:45 steve wrote:
Difficile de croire que ça soit possible vu qu'il n'y a qu'un seul
disque. Et même si c'était bien le cas, ce ne serait pas grave vu que
tu as utilisé le UUID et que le nom (aléatoire) du disque n'est pas
utilisé pour monter la partition.

Si, c'est la réalité.
/dev/disk# ls -l by-label/
lrwxrwxrwx 1 root root 10 déc. 15 00:45 sda1 -> ../../sda1
lrwxrwxrwx 1 root root 10 déc. 15 00:45 sda2 -> ../../sda2
lrwxrwxrwx 1 root root 10 déc. 15 00:45 sda5 -> ../../sda5
lrwxrwxrwx 1 root root 10 déc. 15 00:45 sda6 -> ../../sda6
lrwxrwxrwx 1 root root 10 déc. 15 00:45 sda7 -> ../../sda7
lrwxrwxrwx 1 root root 10 déc. 15 00:45 swap -> ../../sda3
Ici, impeccable et au prochain reboot, j'aurai ces lignes,
mais, avec ../../sdc.
D'accord, l'UUID ne change pas, donc pas bien grave,
ça n'empêche pas le système de bien fonctionner,
mais je préférerais que le DD = /dev/sda et s'y tienne.
C'est juste pour comprendre pourquoi ce changement ? :
sans doute la console KVM qui peut prendre le nommage
/dev/sda lorsqu'elle est lancée. Je ferai un test pour voir.
Bonne soirée.
steve
Le #26501817
Le 17-12-2018, à 17:16:35 +0100, ajh-valmer a écrit :
Le 17-12-2018, à 15:01:42 +0100, A. Valmer a écrit :
C'est ce que j'ai fait sur un serveur avec un seul disque dur.
UUID et /dev/disk/by-label/my_data_part,
Lorsque je fais un reboot, une fois sur deux il devient /dev/sdc
et l'autre fois, /dev/sda.


On Monday 17 December 2018 15:47:45 steve wrote:
Difficile de croire que ça soit possible vu qu'il n'y a qu'un seul
disque. Et même si c'était bien le cas, ce ne serait pas grave vu que
tu as utilisé le UUID et que le nom (aléatoire) du disque n'est pas
utilisé pour monter la partition.

Si, c'est la réalité.
/dev/disk# ls -l by-label/
lrwxrwxrwx 1 root root 10 déc. 15 00:45 sda1 -> ../../sda1
lrwxrwxrwx 1 root root 10 déc. 15 00:45 sda2 -> ../../sda2
lrwxrwxrwx 1 root root 10 déc. 15 00:45 sda5 -> ../../sda5
lrwxrwxrwx 1 root root 10 déc. 15 00:45 sda6 -> ../../sda6
lrwxrwxrwx 1 root root 10 déc. 15 00:45 sda7 -> ../../sda7
lrwxrwxrwx 1 root root 10 déc. 15 00:45 swap -> ../../sda3
Ici, impeccable et au prochain reboot, j'aurai ces lignes,
mais, avec ../../sdc.

Si c'est vraiment le cas, je serais vraiment intéressé d'en connaître la
raison. Et pourquoi sdc et pas sdb ou sdk par exemple ?
D'accord, l'UUID ne change pas, donc pas bien grave,
ça n'empêche pas le système de bien fonctionner,
mais je préférerais que le DD = /dev/sda et s'y tienne.

Pas sûr que ça soit possible, mais clairement non recommendable.
Peut-être qu'avec une règle udev tu pourrais y parvenir. J'ai
personnellement laissé tomber après avoir lu et relu que c'était perdu
d'avance (by design).
Bonne soirée.

De même.
steve
Le #26501820
Le 17-12-2018, à 17:55:45 +0100, ajh-valmer a écrit :
Je posterai le résultat dès le prochaine reboot,
il y a la console KVM et l'USB,

Quand on aura tout dit :)
qui peuvent prendre respectivement le nommage /dev/sda et /dev/sdb,
donc disque dur = /dev/sdc.
Ceci doit dépendre si KVM est lancé ou pas.
KVM a besoin de l'USB.
Reboot :
KVM pas lancé : DD = /dev/sda
KVM lancé : DD = /dev/sdc

Alors c'est parfait, on a retrouvé nos petits.
Haricophile
Le #26501830
Le Mon, 17 Dec 2018 15:47:45 +0100,
steve
Difficile de croire que ça soit possible vu qu'il n'y a qu'un seul
disque.

Moi je le crois très bien pour une imprimante connectée en USB qu i se ferait
passer pour un stockage de masse.
Tant qu'on était avec une connexion parallèle fixe (PATA), l'ordr e des disques
était fixes donc une config /dev/sda est robuste.
Dès qu'on passe a du série (SATA) et SURTOUT quand ça devien t plug'n play
comme USB, là c'est une autre paire de manche...
D'où l'intérêt dans du matériel moderne d'utiliser touj ours l'UUID ou le label
(attention aux doublons pour le label).
Pascal Hambourg
Le #26501850
Le 17/12/2018 à 15:47, steve a écrit :
Le 17-12-2018, à 15:01:42 +0100, infos SX a écrit :
Lorsque je fais un reboot, une fois sur deux il devient /dev/sdc
et l'autre fois, /dev/sda.

Difficile de croire que ça soit possible vu qu'il n'y a qu'un seul
disque.

Certains périphériques comme les lecteurs de carte mémoire peuvent aussi
être nommés /dev/sd*. Ou un problème lors de l'initialisation d'un
disque peut le faire détecter plusieurs fois, avec un nom différent
chaque fois.
Pascal Hambourg
Le #26501853
Le 17/12/2018 à 16:01, Haricophile a écrit :
Tant qu'on était avec une connexion parallèle fixe (PATA), l'ordre des disques
était fixes donc une config /dev/sda est robuste.

Même pas. Le nommage /dev/sd* utilisé par les pilotes PATA et SATA basés
sur libata est basé sur l'ordre d'énumération. Pour retrouver un nommage
déterministe, il faut remonter aux pilotes IDE qui les ont précédés (qui
ne sont plus activés dans les noyaux Debian depuis belle lurette) avec
un nommage /dev/hd* basé sur la position physique :
- hda maître primaire
- hdb esclave primaire
- hdc maître secondaire
- hdd esclabe secondaire
Dès qu'on passe a du série (SATA) et SURTOUT quand ça devient plug'n play
comme USB, là c'est une autre paire de manche...

Le passage au bus série n'a strictement rien à voir là-dedans.
Pascal Hambourg
Le #26501852
Le 17/12/2018 à 17:25, steve a écrit :
Le 17-12-2018, à 17:16:35 +0100, ajh-valmer a écrit :
/dev/disk# ls -l by-label/
lrwxrwxrwx 1 root root 10 déc.  15 00:45 sda1 -> ../../sda1
lrwxrwxrwx 1 root root 10 déc.  15 00:45 sda2 -> ../../sda2
lrwxrwxrwx 1 root root 10 déc.  15 00:45 sda5 -> ../../sda5
lrwxrwxrwx 1 root root 10 déc.  15 00:45 sda6 -> ../../sda6
lrwxrwxrwx 1 root root 10 déc.  15 00:45 sda7 -> ../../sda7
lrwxrwxrwx 1 root root 10 déc.  15 00:45 swap -> ../../sda3


C'est une très mauvaise idée de donner des noms de périphériques non
persistants comme étiquettes de système de fichiers. Quand ça ne se
passe pas comme tu veux, l'étiquette "sda1" se retrouve sur /dev/sdc1.
Pas génial pour la clarté. Une étiquette devrait être représentative du
contenu, pas de la position du contenant. Comme le titre d'un livre :
aurait-on l'idée de nommer un livre à partir de sa position sur
l'étagère et de la position de l'étagère dans la bibliothèque ?
D'accord, l'UUID ne change pas, donc pas bien grave,
ça n'empêche pas le système de bien fonctionner,
mais je préférerais que le DD = /dev/sda et s'y tienne.

Pas sûr que ça soit possible, mais clairement non recommendable.
Peut-être qu'avec une règle udev tu pourrais y parvenir.

Non, pas possible. On ne peut renommer que les interfaces réseau. Si les
labels et UUID ne conviennent pas, au mieux on peut créer des liens
symboliques (alias) persistants qui pointent vers les noms de
périphériques canoniques. C'est ce que fait implicitement LVM avec les
noms de volumes logiques.
Pascal Hambourg
Le #26502081
Le 19/12/2018 à 07:03, steve a écrit :
Le 17-12-2018, à 21:34:02 +0100, Pascal Hambourg a écrit :
Certains périphériques comme les lecteurs de carte mémoire peuvent
aussi être nommés /dev/sd*. Ou un problème lors de l'initialisation
d'un disque peut le faire détecter plusieurs fois, avec un nom
différent chaque fois.

Oui, tout à fait d'accord. Mais comme il ne parlait que d'un seul disque
(sans préciser l'existence d'autres types de cartes mémoire), je ne
voyais pas vraiment comment c'était possible.

Pas besoin qu'une carte mémoire soit insérée, il suffit que le lecteur
soit présent, comme les lecteurs intégrés aux ordinateurs connectés via
un port USB interne.
steve
Le #26502082
Le 17-12-2018, à 21:53:19 +0100, Pascal Hambourg a écrit :
Le 17/12/2018 à 17:25, steve a écrit :
Le 17-12-2018, à 17:16:35 +0100, ajh-valmer a écrit :
/dev/disk# ls -l by-label/
lrwxrwxrwx 1 root root 10 déc.  15 00:45 sda1 -> ../../sda1
lrwxrwxrwx 1 root root 10 déc.  15 00:45 sda2 -> ../../sda2
lrwxrwxrwx 1 root root 10 déc.  15 00:45 sda5 -> ../../sda5
lrwxrwxrwx 1 root root 10 déc.  15 00:45 sda6 -> ../../sda6
lrwxrwxrwx 1 root root 10 déc.  15 00:45 sda7 -> ../../sda7
lrwxrwxrwx 1 root root 10 déc.  15 00:45 swap -> ../../sda3


C'est une très mauvaise idée de donner des noms de périphériques non
persistants comme étiquettes de système de fichiers. Quand ça ne se
passe pas comme tu veux, l'étiquette "sda1" se retrouve sur /dev/sdc1.
Pas génial pour la clarté. Une étiquette devrait être représentative
du contenu, pas de la position du contenant. Comme le titre d'un livre
: aurait-on l'idée de nommer un livre à partir de sa position sur
l'étagère et de la position de l'étagère dans la bibliothèque ?

Tout à fait d'accord. J'ai fait un mauvais copié-collé dans ce message.
Correct est:
$ pwd
/dev/disk/by-label
$ ll -l
total 0
lrwxrwxrwx 1 root root 10 déc 14 21:40 BOOT -> ../../sda1
lrwxrwxrwx 1 root root 9 déc 14 21:40 HOME -> ../../md1
lrwxrwxrwx 1 root root 10 déc 14 21:40 RACINE -> ../../sda5
lrwxrwxrwx 1 root root 10 déc 14 21:40 TMP -> ../../sda7
lrwxrwxrwx 1 root root 10 déc 14 21:40 USR -> ../../sda6
lrwxrwxrwx 1 root root 9 déc 14 21:40 VAR -> ../../md0
D'accord, l'UUID ne change pas, donc pas bien grave,
ça n'empêche pas le système de bien fonctionner,
mais je préférerais que le DD = /dev/sda et s'y tienne.

Pas sûr que ça soit possible, mais clairement non recommendable.
Peut-être qu'avec une règle udev tu pourrais y parvenir.

Non, pas possible. On ne peut renommer que les interfaces réseau. Si
les labels et UUID ne conviennent pas, au mieux on peut créer des
liens symboliques (alias) persistants qui pointent vers les noms de
périphériques canoniques. C'est ce que fait implicitement LVM avec les
noms de volumes logiques.

Merci pour la précision.
Publicité
Poster une réponse
Anonyme