Debian Debian-France Debian-Facile Debian-fr.org Debian-fr.xyz Debian ? Communautés

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#76 11-07-2021 14:53:21

jpt
Banni(e)
Distrib. : Debian 10.8
Noyau : Linux 5.7.10 (backports)
(G)UI : LXDE
Inscription : 12-09-2020

Re : [Résolu] Ordre aléatoire de reconnaissance des disques au démarrage

Bonjour,

Des nouvelles, au bout de presque un mois et demi avec le nouveau noyau : en trois mots, plus aucun problème. cool

raleur a écrit :

Il pourrait suffire de pré-charger ce module dans l'initramfs (via /etc/initramfs-tools/modules) pour obtenir un ordre plus prévisible plutôt que recompiler un noyau.

Dommage que cette information soit arrivée après la modif puis recompil du noyau, et j'avoue que je n'ai pas trop envie de risquer de tout casser juste pour tester la validité de cette hypothèse qui, pourtant, me plait bien.

raleur a écrit :

1) Les supports de stockage USB. Personne ne s'émeut que leurs noms soient variables.

C'est vrai, mais en général on accède à ces supports par une petite fenêtre nous disant "Nouveau périphérique détecté, voulez-vous afficher son contenu" et si on répond "oui", c'est le système qui va se charger de nous ouvrir un explorateur vers le support, nous masquant les sous-couches, et donc on zappe la difficulté.

raleur a écrit :

2) […] Rien ne t'empêche de créer des règles udev pour en faire autant avec tes disques, ainsi tu pourras utiliser par exemple /dev/ssd, /dev/data et /dev/backup qui pointeront toujours vers le bon disque quel que soit son nom /dev/sd*.

J'ai regardé un peu, au début de mes soucis, et ça m'a eu l'air bien compliqué, d'autant plus que je ne suis pas sûr de ne pas avoir de problèmes quand même quand il sera question d'accéder à la partoche par /dev/sdxy (tutos internet, pages de man, etc.) avec tous les risques que ça comporte, une erreur d'inattention c'est si vite arrivé…

Bon, en attendant je vais pouvoir remettre [Résolu], yes.gif


AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War

Hors ligne

#77 11-07-2021 17:33:17

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Ordre aléatoire de reconnaissance des disques au démarrage

jpt a écrit :

Dommage que cette information soit arrivée après la modif puis recompil du noyau, et j'avoue que je n'ai pas trop envie de risquer de tout casser juste pour tester la validité de cette hypothèse qui, pourtant, me plait bien.


Pas grave, ce sera pour la prochaine mise à jour du noyau. Il se passe rarement plus d'un mois sans qu'il y en ait une.

jpt a écrit :

je ne suis pas sûr de ne pas avoir de problèmes quand même quand il sera question d'accéder à la partoche par /dev/sdxy


Le but est de ne plus utiliser /dev/sd* du tout mais seulement les alias persistants.
Effectivement, il faut donc créer des alias pour les partitions aussi, à l'instar de ce qu'il y a dans /dev/disk/by-id et /dev/disk/by-path.

Je viens de bricoler un fichier /etc/udev/rules.d/usb contenant ceci pour tester avec une clé USB :

SUBSYSTEM=="block", ACTION=="add", KERNEL=="sd*", SUBSYSTEMS=="usb", ATTRS{serial}=="5B745A003FF", SYMLINK+="kingston%n"


Et après insertion j'ai bien :

lrwxrwxrwx 1 root root 3 juil. 11 17:09 /dev/kingston -> sdb
lrwxrwxrwx 1 root root 4 juil. 11 17:09 /dev/kingston1 -> sdb1
lrwxrwxrwx 1 root root 4 juil. 11 17:09 /dev/kingston2 -> sdb2



Ça doit pouvoir s'adapter aux disques SATA. Apparemment ATTRS{serial} n'est pas défini pour les disques SATA, on peut utiliser ENV{ID_SERIAL} à la place.
[EDIT]
Par exemple pour un SSD SATA, on peut utiliser cette règle :

SUBSYSTEM=="block", ACTION=="add", KERNEL=="sd*", ENV{ID_SERIAL}=="XXXXX", SYMLINK+="ssd%n"


où la valeur de ID_SERIAL peut être récupérée avec

udevadm info /dev/sdX | grep SERIAL=


Le nom du symlink ne doit pas entrer en conflit avec un nom de périphérique du noyau comme sd*.

Cette règle doit être placée dans un fichier /etc/udev/rules.d/*.rules, et ensuite il faut l'inclure dans l'initramfs en exécutant

update-initramfs -u

Dernière modification par raleur (05-08-2021 21:45:35)


Il vaut mieux montrer que raconter.

En ligne

#78 12-07-2021 07:49:34

jpt
Banni(e)
Distrib. : Debian 10.8
Noyau : Linux 5.7.10 (backports)
(G)UI : LXDE
Inscription : 12-09-2020

Re : [Résolu] Ordre aléatoire de reconnaissance des disques au démarrage

Bonjour,

et merci pour ce post bien détaillé.
J'en prends bonne note, juste que je ne sais pas encore quand et comment je vais pouvoir jouer avec (= tester dans une mv) et non, je ne dirai pas que j'ai d'autres choses à faire sinon je vais encore me faire démonter et pourtant c'est vrai.

EDIT
Une blague (sans doute liée à la tentative d'exécution dans Wheezy ?) :

$ udevadm info /dev/sdb | grep SERIAL=
missing option
$ man udevadm
$ udevadm info --name=/dev/sdb | grep SERIAL=
missing option
$ udevadm info --path=/dev/sdb | grep SERIAL=
device path not found

/EDIT

Un point me chagrine :

raleur a écrit :

Pas grave, ce sera pour la prochaine mise à jour du noyau. Il se passe rarement plus d'un mois sans qu'il y en ait une.

J'ai bien installé unattended upgrades, ce n'est pas pour autant que je vois ma version 5.7.10 évoluer.
Ceci pourrait faire l'objet d'une discussions séparée.

Dernière modification par jpt (12-07-2021 08:00:29)


AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War

Hors ligne

#79 12-07-2021 20:12:12

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Ordre aléatoire de reconnaissance des disques au démarrage

jpt a écrit :

Une blague (sans doute liée à la tentative d'exécution dans Wheezy ?)


Possible.
Avec --name, essaie de mettre le nom seul sans /dev, comme "sdb".
Il me semble que --path attend le chemin dans /sys, comme /block/sdb.

jpt a écrit :

J'ai bien installé unattended upgrades, ce n'est pas pour autant que je vois ma version 5.7.10 évoluer.


Il me semble que tu utilises un noyau compilé par tes soins. Dans ce cas il ne va pas se recompiler tout seul.


Il vaut mieux montrer que raconter.

En ligne

#80 13-07-2021 10:47:52

jpt
Banni(e)
Distrib. : Debian 10.8
Noyau : Linux 5.7.10 (backports)
(G)UI : LXDE
Inscription : 12-09-2020

Re : [Résolu] Ordre aléatoire de reconnaissance des disques au démarrage

raleur a écrit :

Avec --name, essaie de mettre le nom seul sans /dev, comme "sdb".
Il me semble que --path attend le chemin dans /sys, comme /block/sdb

C'est pas gagné :

$ udevadm info --name=sdb | grep SERIAL=
missing option
$ udevadm info --name=/sdb | grep SERIAL=
missing option
$
$ udevadm info --path=/block/sdb | grep SERIAL=
missing option
$ udevadm info --path=/sys/block/sdb | grep SERIAL=
missing option
$ udevadm info --path=sys/block/sdb | grep SERIAL=
device path not found
$ udevadm info --path=block/sdb | grep SERIAL=
device path not found
$ udevadm info --path=/sdb | grep SERIAL=
device path not found
$ udevadm info --path=sdb | grep SERIAL=
device path not found

Bon, de toute façon c'est sur la vieille 32 bits, appelée à n'être plus utilisée, à terme, qu'en secours, alors c'est pas bien grave si ça ne fonctionne pas.
Par contre dans la nouvelle (hier elle était éteinte) c'est tout bon :

$ udevadm info /dev/sdb | grep SERIAL=
E: ID_SERIAL=ST2000DM008-2FR102_WFL1V0FK


raleur a écrit :

Il me semble que tu utilises un noyau compilé par tes soins. Dans ce cas il ne va pas se recompiler tout seul.

Tutafait.
Pour la bonne et simple raison que j'ai besoin d'un pilote bien spécial pour mon imprimante, et dont le code n'a pas été écrit en mode "module" -- si un jour j'ai 24 h à ne rien faire que ça, c'est à tenter.
Pour l'instant, je récupère les sources (quand je n'ai pas trop la flemme) et je recompile.
De toute façon, tout ça est plus ou moins provisoire, j'attends la v11 pour définir des choses bien stables.

Dernière modification par jpt (13-07-2021 10:48:41)


AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War

Hors ligne

#81 02-08-2021 12:58:21

jpt
Banni(e)
Distrib. : Debian 10.8
Noyau : Linux 5.7.10 (backports)
(G)UI : LXDE
Inscription : 12-09-2020

Re : [Résolu] Ordre aléatoire de reconnaissance des disques au démarrage

Question à raleur :

salustre, hombre !

je suis tombé sur cette page où il est question de ce qui me préoccupe et, si les solutions proposées sont sympathiques quoique mystérieuses (comment les mettre en œuvre dans fstab ?), je trouve également la sortie des commandes un peu bizarre…

Bon, j'ai testé dans la vieille machine (sans bidouillages particuliers) mais cela ne devrait pas avoir d'incidence, non ?
Alors regardons ensemble comment sont vues les 4 partoches de sda et les 2 de sdb :

# cd /dev/disk/by-path
# ls -l | grep /s
lrwxrwxrwx 1 root root  9 août   2 10:59 pci-0000:00:1f.2-scsi-0:0:0:0 -> ../../sda
lrwxrwxrwx 1 root root 10 août   2 10:59 pci-0000:00:1f.2-scsi-0:0:0:0-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 août   2 10:59 pci-0000:00:1f.2-scsi-0:0:0:0-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 10 août   2 10:59 pci-0000:00:1f.2-scsi-0:0:0:0-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 août   2 10:59 pci-0000:00:1f.2-scsi-0:0:0:0-part4 -> ../../sda4


Où sont sda1 et sda2 ? Que font sdb1 et sdb2 dans cette sortie ?
Pourquoi n'y a-t-il pas une ligne "courte" avec sdb ?
Et le résultat est identique sans le grep de la fin de la ldc.

Si je regarde autrement c'est plus correct :

# cd /sys/class/scsi_device/
# ls -ld */device/block/sda/sd*
drwxr-xr-x 5 root root 0 août   2 10:59 0:0:0:0/device/block/sda/sda1
drwxr-xr-x 5 root root 0 août   2 10:59 0:0:0:0/device/block/sda/sda2
drwxr-xr-x 5 root root 0 août   2 10:59 0:0:0:0/device/block/sda/sda3
drwxr-xr-x 5 root root 0 août   2 10:59 0:0:0:0/device/block/sda/sda4
# ls -ld */device/block/sdb/sd*
drwxr-xr-x 5 root root 0 août   2 10:59 2:0:0:0/device/block/sdb/sdb1
drwxr-xr-x 5 root root 0 août   2 10:59 2:0:0:0/device/block/sdb/sdb2


J'en suis là de mes interrogations existentielles et c'est dommage car (touchons du bois), depuis mon "forçage" dans le noyau, je n'ai plus ce souci des noms en vrac.
Seulement, je vois venir bullseye et sa palanquée de soucis, et je me méfie (merci à Croutons pour son pdf, qui fait un peu peur, soyons honnête).

Et comme un homme averti en vaut deux, c'est ma chérie qui va être contente, big_smile lol big_smile lol

EDIT :
PS : quand je regarde dans /dev/disk/by-id il y a tout (sortie écourtée) :

# cd /dev/disk/by-id
# ls -lGg
lrwxrwxrwx 1  9 août   2 10:59 scsi-SATA_SAMSUNG_HD103SJS27EJ9BZ300246 -> ../../sda
lrwxrwxrwx 1 10 août   2 10:59 scsi-SATA_SAMSUNG_HD103SJS27EJ9BZ300246-part1 -> ../../sda1
lrwxrwxrwx 1 10 août   2 10:59 scsi-SATA_SAMSUNG_HD103SJS27EJ9BZ300246-part2 -> ../../sda2
lrwxrwxrwx 1 10 août   2 10:59 scsi-SATA_SAMSUNG_HD103SJS27EJ9BZ300246-part3 -> ../../sda3
lrwxrwxrwx 1 10 août   2 10:59 scsi-SATA_SAMSUNG_HD103SJS27EJ9BZ300246-part4 -> ../../sda4
lrwxrwxrwx 1  9 août   2 10:59 scsi-SATA_ST31000528AS_9VPA4LYV -> ../../sdb
lrwxrwxrwx 1 10 août   2 10:59 scsi-SATA_ST31000528AS_9VPA4LYV-part1 -> ../../sdb1
lrwxrwxrwx 1 10 août   2 10:59 scsi-SATA_ST31000528AS_9VPA4LYV-part2 -> ../../sdb2

Dernière modification par jpt (02-08-2021 13:03:38)


AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War

Hors ligne

#82 05-08-2021 21:52:50

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Ordre aléatoire de reconnaissance des disques au démarrage

jpt a écrit :

je suis tombé sur cette page où il est question de ce qui me préoccupe et, si les solutions proposées sont sympathiques quoique mystérieuses (comment les mettre en œuvre dans fstab ?)


Rien de nouveau par rapport à ce qui déjà été évoqué dans cette discussion : utilisation d'un lien symbolique persistant présent par défaut dans /dev/disk ou créé par une règle udev personnalisée. Une fois le lien choisi ou créé, on peut l'utiliser dans /etc/fstab à la place du nom de périphérique.

jpt a écrit :

Où sont sda1 et sda2 ? Que font sdb1 et sdb2 dans cette sortie ?
Pourquoi n'y a-t-il pas une ligne "courte" avec sdb ?


Udev a dû s'emmêler les pinceaux entre sda et sdb lors de la création de ces liens. Je n'ai pas d'explication, c'est très étonnant et c'est la première fois que je vois ça. Est-ce reproductible sur plusieurs démarrages ?

jpt a écrit :

Si je regarde autrement c'est plus correct


Normal, /sys est une vue du noyau. Pas d'intervention d'udev.


Il vaut mieux montrer que raconter.

En ligne

Pied de page des forums