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.
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
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 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.
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.
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.
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 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 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.
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.
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).
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 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 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.
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
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 Mon, 17 Dec 2018 15:47:45 +0100, steve 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 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).
Le Mon, 17 Dec 2018 15:47:45 +0100,
steve <dlist@bluewin.ch> 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 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).
Le Mon, 17 Dec 2018 15:47:45 +0100, steve 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 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 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.
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.
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 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.
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.
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 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.
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.
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 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.
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.
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 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 :
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.
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 :
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.
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.
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.
