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.]]>
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) :
]]>
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.]]>
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.]]>
/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.]]>
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
]]>
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], ]]>
je n'ai pas les compétences et les connaissances pour savoir qui fait quoi et quand dans le noyau
Grosso modo, la gestion des disques SATA fait intervenir trois couches de pilotes :
- le pilote du contrôleur SATA (ahci, ata_piix) qui émule un contrôleur SCSI et émet les messages préfixés par "ata"
- la gestion de base du SCSI (scsi_mod) qui émet les messages préfixés par "scsi"
- le pilote de disque SCSI (sd_mod) qui émet les messages préfixés par "sd"
ata1, ata2... désignent des ports SATA. ata1.00 désigne un périphérique ATA connecté au port ata1.
0.0.0.0, 1.0.0.0... désignent des périphériques SCSI. Je suppose que les 4 nombres représentent le contrôleur, le bus, le périphérique et l'unité logique ou quelque chose dans le genre.
Il y a un lien entre les identifiants de ports et de périphériques ATA et les identifiants de périphériques SCSI, mais il n'est pas toujours aussi trivial que dans ton cas. Sans compter que d'autres périphériques sont aussi gérés comme des périphériques SCSI comme les supports de stockage USB. Quand au nommage /dev/sd* des disques, il n'a aucun lien avec les précédents et dépend uniquement de l'ordre de prise en compte par le pilote sd_mod.
je pars juste de l'idée qu'en supprimant des modules chargés en mode random et en les incluant en dur dans le noyau pour avoir un comportement plus "statique" et séquentiel et reproductible
En fait je vois une grande différence entre les précédents logs et les derniers : dans les précédents, on distingue deux phases :
- une première phase où les disques sont détectés les uns après les autres par les pilotes libata et scsi_mod
- une seconde phase qui arrive bien plus tard où les disques sont tous énumérés en même temps par le pilote sd_mod
Alors que dans les derniers logs, les disques sont toujours détectés les uns après les autres mais chaque disque est énuméré immédiatement après avoir été détecté.
Une explication possible est que dans le premier cas le module sd_mod n'est pas encore chargé au moment où les disques sont détectés. Lorsqu'il est chargé, tous les disques ont déjà été détectés et l'ordre de prise en compte n'est pas assuré. 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.
tout est dans l'ordre, dans le bon ordre
Il n'y a pas de bon ordre, ni de mauvais. Il y a plusieurs ordres, plus ou moins reproductibles, plus ou moins fréquents.
En quoi cet ordre est-il meilleur qu'un autre ? Et qu'est-ce qui te dis que si tu changes ou ajoutes un disque ce bel ordre ne va pas être totalement chamboulé ? Et même sans rien changer, qu'est-ce qui te dit que de temps en temps, selon la température, la tension d'alimentation... le temps d'initialisation des disques ne va pas changer et avec lui l'ordre de détection ?
Je voudrais terminer avec un réflexion sur le nommage variable des périphériques qui te gêne tant. Pourtant ce nommage variable est courant dans deux autres cas et cela ne semble gêner personne :
1) Les supports de stockage USB. Personne ne s'émeut que leurs noms soient variables.
2) Les périphériques /dev/dm-* créés par le device mapper comme les volumes logiques LVM et les volumes chiffrés. Oui, ils peuvent varier mais ça ne gêne personne parce que personne ne les utilise directement : on utilise les liens symboliques /dev/mapper/* ou /dev/vg/lv créés par udev qui pointent toujours vers le bon périphérique. 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*.]]>
Tu as plusieurs disques.
Oui.
Tu as un souci au démarrage, tu regardes les UUID, avec blkid par exemple.
Pas toujours, mais oui.
Tu fais des scripts ou des réglages, tu passes par les UUID.
Non pour les scripts, oui pour les réglages (les fameux point_de_montage.mount de systemd).
Tu t'interroges sur la variation de sdX, tu changes le fonctionnement de ton OS par rapport au matériel.
Oui, en m'inspirant de la remarque de raleur
les pilotes de disque n'ont plus été compilés en dur dans le noyau (et initialisés dans un ordre constant) mais en tant que modules inclus dans un initrd puis initramfs et chargés à la demande dans un ordre variable.
et de la constatation du changement d'identification dans /var/log/messages. Malheureusement je n'ai pas les compétences et les connaissances pour savoir qui fait quoi et quand dans le noyau, je pars juste de l'idée qu'en supprimant des modules chargés en mode random et en les incluant en dur dans le noyau pour avoir un comportement plus "statique" et séquentiel et reproductible, je devrais avoir un comportement plus stable.
Et c'est ce que je constate ce matin :
1-) démarrage plus rapide, hé ouais !
2-) les disques correctement détectés et d'une manière plus propre.
Quand je compare le bout de /val/log/messages donné hier avec celui de ce matin, il n'y a pas photo, regardez bien : tout est dans l'ordre, dans le bon ordre (j'ai enlevé quelques lignes pour alléger, elles sont inutiles à la compréhension du problème, et j'ai rajouté deux sauts de ligne pour la clarté -- je n'ai rien regroupé, contrairement aux sorties précédentes) !
Voilà, là c'est parfait : plus de micmacs, ata1 définit scsi 0:0:0:0: qui définit sd 0:0:0:0: comme sda et pareil pour les deux autres, c'est impec !
La seule chose qui manque dans ce listing (dans ces messages), c'est le numéro de série des disques car là, il est impossible de distinguer les deux gros disques l'un de l'autre, dommage. Plus qu'à faire confiance au système, encore que, à terme, avant de passer en prod', j'envisage de n'avoir qu'une seule partoche sur le disque des sauvegardes, je pourrai donc les distinguer par cette astuce.
À suivre…
le problème semble très difficilement solutionnable.
Pas sûr, pas sûr : j'ai un bon espoir, en regardant les lignes précédentes et la phrase de raleur, qu'on bon noyau en dur pourrait arranger les choses.
même si ce petit script s'est avéré utile, il ne m'a pas fourni la solution.
savoir l'assignation absolue du nom des disques.
Si tu parles de mon script, il n'a pas été écrit pour ça, je voulais juste un outil qui me remonte les informations au plus proche du cœur de la machine, et il le fait. Pas plus.
Et comme un imbécile j'ai oublié d'y inclure une sortie de df, pour qu'on se rende bien compte, en cas d'erreur de nommage au boot, que les sorties de df seront en vrac et donc ingérables (chose déjà signalée il y a longtemps).
Bonne journée,]]>
Sinon, le fait qu'Alain ait eu le problème prouve simplement que je n'ai pas tort, donc que j'ai raison, soyons binaires,
non , cela montre la concomitance d'un phénomène analogue chez deux personnes au moins .
ni l'une ni l'autre n'a raison ou tort .
cela prouve simplement qu'une investigation en profondeur sur les statistiques d'erreurs , les causes et le fonctionnement est nécessaire .
l'analyse a été faite par râleur .
le problème semble très difficilement solutionnable .
dont acte .
pour ma part . mes lignes n'ont apporté aucune solution .
simplement un pis - aller qui permet de savoir qui est qui afin d'éviter des erreurs éventuelles .
mme si ce petit script s'est avéré utile , il ne m'a pas fourni la solution .
savoir l' assignation absolue du nom des disques .
amicalement ,
alain.
]]>
]]>
Pourquoi ? Tu sais que le nommage des disques /dev/sd* n'est pas stable et c'est pour cela qu'on utilise des UUID ou LABEL, non ?
alors du coup ou est le soucis quand tu connais l'info?
Je suis d'accord sur le fait qui il a sûrement des trucs a améliorer, à commencer par l'installateur qui met sdx en commentaire , le fstab peut ,ne plus correspondre avec se qu'il y a en commentaire
enfin n'importe qui qui débarque sur le poste est noyé par un flot de nom d'oiseau et au final on ne sait pas comment on peu d'aider?
Je sais pas peut être revoir tes scripts , il me semble ce que tu fais avec ton script il y a un utilitaire sympa duf-utility]]>
And tbh, I have a potential similar hazard. I use CloneZilla, and if a program asks: Would you like to backup /dev/sda to /dev/sdb or /dev/sdb to /dev/sda ?, guess how nervous I get knowing that linux seems to randomly assign disk orders. I haven't overwritten my data with my own backup yet, but this is just waiting to happen.
of=FICHIER
écrire dans le FICHIER plutôt que sur la sortie standard
dd: impossible d'ouvrir '/media/disk3p1/': est un dossier]]>