Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
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.
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é.
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], 
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
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.
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 :
Et après insertion j'ai bien :
Ç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 :
où la valeur de ID_SERIAL peut être récupérée avec
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
Dernière modification par raleur (05-08-2021 20:45:35)
Il vaut mieux montrer que raconter.
Hors ligne
/EDIT
Un point me chagrine :
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 07:00:29)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
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.
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.
Hors ligne
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é :
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 :
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 09:48:41)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
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 :
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, 
EDIT :
PS : quand je regarde dans /dev/disk/by-id il y a tout (sortie écourtée) :
Dernière modification par jpt (02-08-2021 12:03:38)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
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.
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 ?
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.
Hors ligne