gratifiant > linux.debian.user.french

alain-buster (17/12/2018, 14h50)
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
Eric Degenetais (17/12/2018, 15h50)
infos SX (17/12/2018, 16h30)
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 .


[..]
> 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.

/dev/disk/by-label/my_data_part :
je n'ai pas ce fichier "my_data_part".

A. V.
steve (17/12/2018, 16h50)
Le 17-12-2018, à 15:01:42 +0100, infos SX a écrit :

>On Monday 17 December 2018 14:47:03 Eric Degenetais wrote:
>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.
Eric Degenetais (17/12/2018, 16h50)
Le lun. 17 déc. 2018 à 15:27, infos SX <info> a écrit :
> On Monday 17 December 2018 14:47:03 Eric Degenetais wrote:
> C'est ce que j'ai fait sur un serveur avec un seul disque dur.
> UUID et /dev/disk/by-label/my_data_part,

Identifier par UUDI n'empêche pas que la lettre change. Simplement,
comme on n'utilise pas la lettre pour référencer la partition,
on se fiche qu'elle change.
> Lorsque je fais un reboot, une fois sur deux il devient /dev/sdc
> et l'autre fois, /dev/sda. l'identificatio
> /dev/disk/by-label/my_data_part :
> je n'ai pas ce fichier "my_data_part". Ce n'est peut-être pas évident dans mon message précédent, mais :
> A. V.

Cordialement.
______________
Éric Dégenètais
Henix


Eric Degenetais (17/12/2018, 17h00)
Le lun. 17 déc. 2018 à 15:48, steve <dlist> a écrit :

> Le 17-12-2018, à 15:01:42 +0100, infos SX a écrit :
> configuration :
> répondent
> 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'estpas
> utilisé pour monter la partition.
> Sauf erreur, il n'y a pas de fichier nommé ainsi. Ici par exemple, j'ai
> Coquille de ma part, j'avais l'intention d'écrire (EXEMPLE :

/dev/disk/by-label/my_data_part). L'outil d'installation peut créer des
labels, ou bien on peut les créer manuellement.
Il n'y a pas de contenu standard à /dev/disk/by-label à ma connaissance, ce
sont des étiquettes descriptives créées à la demande del'utilisateur
(qu'on peut aussi ajouter a posteriori avec les outils de manipulation de
filesystem).

> 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.
> ______________

Éric Dégenètais
Henix


ajh-valmer (17/12/2018, 18h20)
> 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'estpas
> 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 (17/12/2018, 18h30)
Le 17-12-2018, à 17:16:35 +0100, ajh-valmer a écrit :

[..]
>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.
Eric Degenetais (17/12/2018, 18h50)
Le lun. 17 déc. 2018 à 17:26, steve <dlist> a écrit :
> Le 17-12-2018, à 17:16:35 +0100, ajh-valmer a écrit :
> 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.

J'ai eu ce cas sur un desktop à cause d'un lecteur de carte devenu capricieux :
=> s'il marchait bien, il enfonçait les HDD en termes de temps
d'initialisation, donc les 4 devices correspondant aux lecteurs de
carte étaient énumérés /dev/sda ... /dev/sdd, et les HDD /dev/sde et
/dev/sdf
=> s'il "ratait" au démarrage, les HDD se retrouvaient premiers
énumérés et donc reconnus comme /dev/sda et /dev/sdb
Les clefs USB peuvent éventuellement avoir cet effet aussi...

Pour savoir pourquoi il suffit peut-être de lister les /dev/sd* et de
voir /dev/disk/by-label et /dev/disk/by-uuid pour voir qui "est
devant" ...

Quoi qu'il en soit, compter sur ces noms de device bruts n'a jamais
été vraiment fiable (sachant que le matériel ou le bios introduisent
dans certains cas de l'aléa dans les temps de réponse pour éviter les
collisions entre périphériques sur un bus...), et les distributions
ont donc cessé de compter dessus.

Cordialement
______________
Éric Dégenètais
Henix


ajh-valmer (17/12/2018, 19h00)
> Le 17-12-2018, à 17:16:35 +0100, ajh-valmer a écrit :
> 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).


Je posterai le résultat dès le prochaine reboot,
il y a la console KVM et l'USB,
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

A. Valmer
steve (17/12/2018, 19h10)
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 (17/12/2018, 20h10)
Le Mon, 17 Dec 2018 15:47:45 +0100,
steve <dlist> a écrit :

> 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 qui se ferait
passer pour un stockage de masse.

Tant qu'on était avec une connexion parallèle fixe (PATA), l'ordre 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 devient 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 toujours l'UUID ou le label
(attention aux doublons pour le label).
Pascal Hambourg (17/12/2018, 22h40)
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 (17/12/2018, 22h50)
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 (17/12/2018, 23h00)
Le 17/12/2018 à 17:25, steve a écrit :
> Le 17-12-2018, à 17:16:35 +0100, ajh-valmer a écrit :


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.

Discussions similaires