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
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
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.
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.
On Monday 17 December 2018 15:47:45 steve wrote:
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.
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 ?
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).
De même.
Quand on aura tout dit :)
Alors c'est parfait, on a retrouvé nos petits.
steve
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).
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.
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
Le passage au bus série n'a strictement rien à voir là-dedans.
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 ?
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.
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.
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
Merci pour la précision.