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.
