souvent disque varie, bien fol est qui s'y fie [Résolu]

Christophe C · Le 05/10/2019, à 17:45

J'ai un NUC intel avec un SSD de 250Go, et un DD de 2To en sata dans un logement externe, connecté en USB sur le NUC.

J'ai paramétré le boot pour ne pas démarrer sur un USB, et j'ai défini le SSD comme "primary boot".

Donc j’attends que le SSD soit en /dev/sda, et le DD de 2 To soit en /dev/sdb

Pas de problème, je boot bien sur le SSD.
PAR CONTRE, le SSD est parfois sda, et parfois sdb. Cela semble aléatoire. Pas de problème pour une utilisation courante, par contre j'ai des scripts qui se retrouvent à patauger. Et en plus je ne comprends pas.

Une idée de la façon de régler cela ?

Dernière modification par Christophe C (Le 10/10/2019, à 08:37)

Nuliel · Le 05/10/2019, à 17:47

Salut,
Oui, il faut utiliser des noms qui ne bougent pas, tu devrais trouver ce qu'il faut dans le retour de

ls -l /dev/disk/by-id

cela devrait t'indiquer par quoi remplacer /dev/sdX

Dernière modification par Nuliel (Le 05/10/2019, à 17:47)

inbox · Le 05/10/2019, à 18:13

Salut,

[HS] Peux-tu corriger le titre de ton sujet car il s'agit du verbe fier et non faire.

Merci.[/HS]

A+

Dernière modification par inbox (Le 05/10/2019, à 18:16)

Christophe C · Le 05/10/2019, à 18:15

ca me donne cela. mais concrètement j'en fais quoi ?

[sudo] Mot de passe de chris : 
(chris - 5.0.0-27-generic) ~ : ls -l /dev/disk/by-id
total 0
lrwxrwxrwx 1 root root  9 oct.   5 18:06 ata-Samsung_SSD_860_EVO_250GB_S3YJNB1K201155X -> ../../sda
lrwxrwxrwx 1 root root 10 oct.   5 18:06 ata-Samsung_SSD_860_EVO_250GB_S3YJNB1K201155X-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 oct.   5 18:06 ata-Samsung_SSD_860_EVO_250GB_S3YJNB1K201155X-part2 -> ../../sda2
lrwxrwxrwx 1 root root  9 oct.   5 18:06 ata-ST2000DM001-9YN164_Z1E0S317 -> ../../sdb
lrwxrwxrwx 1 root root 10 oct.   5 18:06 ata-ST2000DM001-9YN164_Z1E0S317-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  9 oct.   5 18:06 wwn-0x5000c5004d441ad9 -> ../../sdb
lrwxrwxrwx 1 root root 10 oct.   5 18:06 wwn-0x5000c5004d441ad9-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  9 oct.   5 18:06 wwn-0x5002538e4018692f -> ../../sda
lrwxrwxrwx 1 root root 10 oct.   5 18:06 wwn-0x5002538e4018692f-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 oct.   5 18:06 wwn-0x5002538e4018692f-part2 -> ../../sda2

Nuliel · Le 05/10/2019, à 18:31

A la place d'utiliser /dev/sda dans tes scripts pour le ssd, tu peux remplacer par /dev/disk/by-id/ata-Samsung_SSD_860_EVO_250GB_S3YJNB1K201155X
De même, à la place de /dev/sdb (pour le disque dur), tu peux remplacer par /dev/disk/by-id/ata-ST2000DM001-9YN164_Z1E0S317
De même, à la place de /dev/sda1, tu peux remplacer par /dev/disk/by-id/ata-Samsung_SSD_860_EVO_250GB_S3YJNB1K201155X-part1
...

Et ces noms là sont persistants, ils ne vont jamais changer

geole · Le 05/10/2019, à 19:12

Bonjour
Tu peux aussi utiliser des noms moins barbares que tu peux imposer avec gparted. Vérification avec la commande

ls -ls /dev/disk/by-label

Le montage se faisant alors avec la commande

mount  -L NomDuLabel   PointdeMontage

Dernière modification par geole (Le 05/10/2019, à 19:12)

Christophe C · Le 05/10/2019, à 22:42

Quel rapport avec la montage ?

geole · Le 06/10/2019, à 15:00

Bonjour.
Je pense que pour accéder au contenu d'un disque dans 99,99% des cas, on utilise une partition qu'il faut monter.

diesel · Le 06/10/2019, à 15:54

Ce qui change le moins pour un disque dur ou une de ses partitions, ce sont les UUID.

Chez moi, ça donne ça :

jean-marie@jean-marie:~$ ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 oct.   6 15:34 0f25cd42-acfb-4cf7-8cd2-f88ca2864840 -> ../../sdb1
lrwxrwxrwx 1 root root  9 oct.   6 15:55 19DA-F2FA -> ../../sdc
lrwxrwxrwx 1 root root 15 oct.   6 15:34 3105-0CC7 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 10 oct.   6 15:34 384d8720-f90f-427d-995a-d7773016a3ff -> ../../sdb3
lrwxrwxrwx 1 root root 10 oct.   6 15:34 4318b53e-ae2a-4fb0-9059-c440a12f21a6 -> ../../sdb2
lrwxrwxrwx 1 root root 10 oct.   6 15:34 7a776d67-d77d-4896-803e-95ae76609511 -> ../../sda1
lrwxrwxrwx 1 root root 15 oct.   6 15:34 93f157ec-dad1-4669-8603-3bb6c9514d85 -> ../../nvme0n1p4
lrwxrwxrwx 1 root root 15 oct.   6 15:34 a9da4361-66a1-4a09-9a8f-526e4f10412e -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 15 oct.   6 15:34 e585a780-4f4c-44d3-9d4f-95eaf501ac08 -> ../../nvme0n1p3
jean-marie@jean-marie:~$

Donc, si je veux m'adresser à la partition 2 de mon disque sdb, j'utilise "/dev/disk/by-uuid/4318b53e-ae2a-4fb0-9059-c440a12f21a6"

Et là, je suis certain que ça ne changera jamais (sauf peut-être repartitionnement du disque).

Amicalement.

Jean-Marie

Dernière modification par diesel (Le 06/10/2019, à 15:58)

jamesbad000 · Le 06/10/2019, à 16:16

Bonjour,

Ce qui change le moins pour un disque dur ou une de ses partitions, ce sont les UUID.

Pour la partition oui.
En fait plus précisément l'uuid est dans le système de fichier et ne change qu'en cas de reformatage (certains outils peuvent aussi la modifier en cas de copie / déplacement de la partition sur un autre disque), ou demande explicite.

A noter qu'avec gpt il y a aussi l'uuid qui se trouve dans la table de partition (/dev/disk/by-partuuid). Mais ce n'est pas celle là qui est utilisée par grub ou fstab pour identifier les partitions)

Le disque dur lui n'a pas d'uuid et ce qui est indiqué par /dev/disk/by-id étant basé sur les infos constructeurs (modèle, n° de série) ne risque pas de bouger.

edit:
En revanche, le n° de partition (-partX) indiqué dans /dev/disk/by-id peut changer en cas de modif du partitionnement.

Dernière modification par jamesbad000 (Le 06/10/2019, à 16:18)

diesel · Le 06/10/2019, à 16:20

Oui, ce que tu dis est plus juste.

Amicalement.

Jean-Marie

Christophe C · Le 09/10/2019, à 19:09

Ok, ca me semble clair. j'utilise couremment les UUID pour les montages, mais j'ignorais qu'on opuvait faire un adressage avec dans un script. Merci.

Et sinon, quelqu'un voit-il la raison de ce comportement irrégulier : le même disque un coup SDA, un coup SDB ?

kamaris · Le 09/10/2019, à 19:41

C'est parce que c'est udev qui gère le chargement des modules du noyau pour la reconnaissance matérielle, et cela de manière parallèlisée.
L'ordre dans lequel ils sont chargés n'est donc pas déterministe.
Cf. par exemple https://wiki.archlinux.org/index.php/Udev :

https://wiki.archlinux.org/index.php/Udev a écrit :

udev loads kernel modules by utilizing coding parallelism to provide a potential performance advantage versus loading these modules serially. The modules are therefore loaded asynchronously. The inherent disadvantage of this method is that udev does not always load modules in the same order on each boot. If the machine has multiple block devices, this may manifest itself in the form of device nodes changing designations randomly. For example, if the machine has two hard drives, /dev/sda may randomly become /dev/sdb.

Christophe C · Le 13/10/2019, à 10:09

Merci de l'info

C'est vraiment un truc de demeuré. Tout cela pour gagner quelques fractions de secondes.

Ceci dit j'ai toujours eu plusieurs disques et jamais de problème, alors que UDEV n'est pas récent.

Mon actuel problème est tout nouveau, sur une nouvelle machine, mais j'utilisais déjà certain des disques sur l'ancienne. Je ne comprends pas pourquoi le pb apparaît maintenant.

Dernière modification par Christophe C (Le 13/10/2019, à 10:28)

jamesbad000 · Le 13/10/2019, à 13:42

L'explication données par Archlinux me parrait assez approximative. D'ailleurs elle est sourcée sur une page wikipedia ou l'extrait en question n'existe plus...

udev détecte l'apparition ou la disparition de périphérique notamment. Et leur assigne un fichier de type périphérique dans /dev, les divers raccourcis dans /dev/disk... Possible que cela entraine en plus le chargement d'un module si ça n'a pas déjà eu lieu pour un autre matériel déjà pris en charge par le même module. Mais c'est toute la chaine de traitement de l'événement qui est parallélisée avec le traitement d'un autre événement, pas juste le chargement d'un module

Sachant que d'un événement initial comme l'apparition d'un disque, il découle en plus de ce qui est dit ci dessus l'analyse du contenu du périphérique de bloc pour savoir ce qu'il contient.
Si une table de partition est détectée, cela va déclencher autant d'événement que de partitions. Si chaque nouveau périphérique de bloc contiennent du lvm par exemple, il va y avoir encore l'apparition de nouveau périphériques de bloc. Au final le gain de la parallélisation peut se compter facilement en dizaines de secondes...

Par ailleurs pour diverses raisons que je ne m'avancerais pas à tenter d'expliquer, certaines cartes mère ne détectent pas le matériel systématiquement dans le même ordre. (c'est un constat)

Dernière modification par jamesbad000 (Le 13/10/2019, à 13:47)

Nuliel · Le 13/10/2019, à 13:55

D'ailleurs sais tu ce qui analyse le contenu du périphérique de bloc? Raison: lorsqu'on démarre sur un live usb et qu'un disque dur défectueux est branché, on voit apparaître "secteur ...." défectueux, beaucoup, beaucoup de fois (là où j'aimerais que la lecture de ce secteur défectueux n'arrive qu'une fois)

jamesbad000 · Le 13/10/2019, à 14:35

Naziel a écrit :

D'ailleurs sais tu ce qui analyse le contenu du périphérique de bloc

Pas avec certitude. Mais j'imagine que ça doit être autour de blkid, libblkid.

Nuliel · Le 13/10/2019, à 14:46

Ok, merci

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 05/10/2019, à 17:45

souvent disque varie, bien fol est qui s'y fie [Résolu]

#2 Le 05/10/2019, à 17:47

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

#3 Le 05/10/2019, à 18:13

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

#4 Le 05/10/2019, à 18:15

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

#5 Le 05/10/2019, à 18:31

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

#6 Le 05/10/2019, à 19:12

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

#7 Le 05/10/2019, à 22:42

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

#8 Le 06/10/2019, à 15:00

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

#9 Le 06/10/2019, à 15:54

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

#10 Le 06/10/2019, à 16:16

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

#11 Le 06/10/2019, à 16:20

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

#12 Le 09/10/2019, à 19:09

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

#13 Le 09/10/2019, à 19:41

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

#14 Le 13/10/2019, à 10:09

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

#15 Le 13/10/2019, à 13:42

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

#16 Le 13/10/2019, à 13:55

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

#17 Le 13/10/2019, à 14:35

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

#18 Le 13/10/2019, à 14:46

Re : souvent disque varie, bien fol est qui s'y fie [Résolu]

Pied de page des forums