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

jpt · 11-10-2020 18:43:52

Bonsoir,

EDIT pour l'accès à une probable solution efficace (non testée), voir le # 75 /EDIT

suite à début de discussion ailleurs (ce post et les quelques qui le précèdent) et pour ne pas polluer le topic, j'en ouvre un autre ici, je sens qu'on n'a pas fini de rigoler.

J'ai donc plié la machine pour aller me promener, après avoir configuré un fstab michto michto sur les conseils de Debian Alain (merci à lui), il ressemble à ça (commentaires allégés pour la lisibilité) :

# <file system>             <mount point>  <type>  <options>  <dump>  <pass>

### disque ssd système

#/dev/sda1 : 240 Go

UUID=99dc8d6c-8674-4c7d-b27f-7cd860bdd63f /              ext4    defaults,noatime 0 1

tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

### premier hd, sdb -- les datas

#/dev/sdb1 : 1,6 To

UUID=83452e91-8384-45c3-b2c7-4315904d03fa /data_large ext4  relatime,rw,auto,users,exec 0 2

#/dev/sdb2 : 195 Go

UUID=ca124013-9812-4eac-8e52-35560d5ac7f4 /data_small ext4  defaults  0 2

# dessous on monte les dossiers /data_small/home /data_small/root et /data_small/var avec leurs données

# sur le système de fichiers / et respectivement dans les dossiers home, root et var où linux s'attend à les trouver

/data_small/home  /home none  bind  0 0

/data_small/root  /root none  bind  0 0

/data_small/var   /var  none  bind  0 0

### second  hd, sdc -- les sauvegardes des datas

#/dev/sdc1 : 1,6 To

UUID=0e65ae8e-d816-4ffc-a210-e616717de2fe /dbck_large ext4  relatime,rw,auto,users,exec 0 2

#/dev/sdc2 : 195 Go

UUID=99fc2adf-d339-4fcc-82fb-82f93db59f2a /dbck_small ext4  relatime,rw,auto,users,exec 0 2

et en rentrant de promenade, j'allume la babasse et que croyez-vous que j'y ai vu ? Cette abomination :

/                                     /dev/sdb1        ext4            rw,noatime

├─/data_large                         /dev/sda1        ext4            rw,nosuid,nodev,relatime

├─/dbck_large                         /dev/sdc1        ext4            rw,nosuid,nodev,relatime

├─/dbck_small                         /dev/sdc2        ext4            rw,nosuid,nodev,relatime

├─/data_small                         /dev/sda2        ext4            rw,relatime

├─/home                               /dev/sda2[/home] ext4            rw,relatime

├─/root                               /dev/sda2[/root] ext4            rw,relatime

└─/var                                /dev/sda2[/var]  ext4            rw,relatime

Normalement j'aurais dû avoir

/                                     /dev/sda1        ext4            rw,noatime

├─/data_large                         /dev/sdb1        ext4            rw,nosuid,nodev,relatime

├─/dbck_large                         /dev/sdc1        ext4            rw,nosuid,nodev,relatime

├─/dbck_small                         /dev/sdc2        ext4            rw,nosuid,nodev,relatime

├─/data_small                         /dev/sdb2        ext4            rw,relatime

├─/home                               /dev/sdb2[/home] ext4            rw,relatime

├─/root                               /dev/sdb2[/root] ext4            rw,relatime

└─/var                                /dev/sdb2[/var]  ext4            rw,relatime

La commande pour avoir cette sortie, c'est

findmnt | grep sd | grep -v "gvfsd" | grep -v "nsdelegate"

, et qu'est-ce que je peux faire pour avoir une machine fiable ?

Dernière modification par jpt (11-07-2021 15:01:44)

raleur · 11-10-2020 18:54:12

jpt a écrit :

Cette abomination

En quoi est-ce une abomination ? Cela me semble parfaitement normal et conforme aux attentes.

jpt a écrit :

Normalement j'aurais dû avoir

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 ?

jpt a écrit :

qu'est-ce que je peux faire pour avoir une machine fiable ?

En quoi n'est-ce pas fiable ? Qu'est-ce qui ne marche pas ?
Au contraire, les UUID ont parfaitement joué leur rôle en identifiant les bonnes partitions indépendamment du nommage des disques.

Dernière modification par raleur (11-10-2020 18:55:20)

jpt · 11-10-2020 20:22:25

Je ne sais plus quoi penser :

# lsblk -f

NAME   FSTYPE LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINT

sda                                                                           

├─sda1 ext4   data        83452e91-8384-45c3-b2c7-4315904d03fa    1,5T     1% /data_large

└─sda2 ext4   homerootvar ca124013-9812-4eac-8e52-35560d5ac7f4  178,1G     2% /data_small

sdb                                                                           

├─sdb1 ext4               99dc8d6c-8674-4c7d-b27f-7cd860bdd63f  149,3G    17% /

└─sdb2 swap               272a029e-4d4a-40e2-a3b7-51bf1ac7b0d0                

sdc                                                                           

├─sdc1 ext4   backup      0e65ae8e-d816-4ffc-a210-e616717de2fe    1,5T     0% /dbck_large

└─sdc2 ext4   reserved_c  99fc2adf-d339-4fcc-82fb-82f93db59f2a    178G     2% /dbck_small

Il ne faut pas donc tenir compte de sda, b, c ? Comment appelez-vous vos disques dans vos scripts ? C'est la première fois de ma vie que je vois ça !
Et ça me déstabilise grave, car j'ai des scripts qui récupèrent des infos sur les disques, basés sur du grep dans les sorties de df ou d'autres.
Avec les labels ça serait mieux ? Parce que là, je ne sais plus que penser.

Et je n'ai jamais eu ce problème depuis que je "fréquente" Linux...

raleur · 11-10-2020 21:24:09

jpt a écrit :

Il ne faut pas donc tenir compte de sda, b, c ?

Ça dépend ce qu'on entend par "tenir compte". Pour monter des systèmes de fichiers automatiquement, certainement pas.

jpt a écrit :

Comment appelez-vous vos disques dans vos scripts ?

Je n'ai pas de script appelant mes disques. Si j'avais besoin d'adresser un disque dans un script, j'utiliserais un alias persistant du genre /dev/disk/by-id/<identifiant_matériel>.
Que font tes scripts avec les noms de disques /dev/sd* ?

jpt a écrit :

Avec les labels ça serait mieux ?

Une étiquette (label) est un attribut de système de fichiers, pas de disque.

jpt · 11-10-2020 23:25:45

raleur a écrit :

Que font tes scripts avec les noms de disques /dev/sd* ?

Exemple avec un qui s'appuie sur df pour récupèrer l'espace total, occupé et libre pour générer un affichage semi-graphique et proportionnel en couleurs :

Infodisk

 Disk - Cap tot en Mo - Rouge = occupé, Vert = libre

  sda2 :   84357 [|||!!]

  sda3 :    9263 []

  sda4 :  835509 [|||||||||||||||||||||||||||||||||||||||||||||||||||!!!!!!!]

  sdb1 :  827542 [|||||||||||||||||||||||||||||||||||||||||||||!!!!!!!!!!!!]

  sdb2 :  111102 [|||||!!]

ici j'ai remplacé les pipes verts par des !.
Va falloir que je revois mes systèmes de sauvegarde et d'autres bricoles.

Après mon post de 20 h 22 j'ai un peu cherché et j'avoue que je suis anéanti : je découvre aujourd'hui cette embrouille qui existe depuis au moins 15 ans !
J'ai lu des trucs de gens qui utilisent clonezilla (qui bosse avec hdxx/sdxx), les gens considèrent que c'est un miracle qu'ils n'aient rien perdu à ce jour !
Et cet outil est banni ! Alors que plein d'autres le recommandent...

Anéanti, je vous dis. Allez, la nuit porte conseil...

Dernière modification par jpt (11-10-2020 23:27:23)

raleur · 12-10-2020 13:04:42

Justement, il me semble que ton graphique d'occupation serait plus parlant s'il mentionnait les points de montage ou les étiquettes plutôt que les partitions.
Idem pour les sauvegardes : à mon avis il est plus important de spécifier qu'on veut sauvegarder le contenu de /home (par exemple) plutôt que le contenu de /dev/sdb2.

Je ne vois pas où est le problème avec Clonezilla ou d'autres outils qui utilisent les noms de fichiers de périphériques des disques et partitions, à partir du moment où on a identifié les disques ou partitions et leur contenu au moment où on les utilise.

Dernière modification par raleur (12-10-2020 13:07:54)

jpt · 12-10-2020 15:02:45

raleur a écrit :

Justement, il me semble que ton graphique d'occupation serait plus parlant s'il mentionnait les points de montage ou les étiquettes plutôt que les partitions.
Idem pour les sauvegardes : à mon avis il est plus important de spécifier qu'on veut sauvegarder le contenu de /home (par exemple) plutôt que le contenu de /dev/sdb2.

Question d'habitude.
Pendant presque 20 ans j'ai appris à vivre avec xda1 (x pour h ou s) comme première partition du premier disque de la machine et le reste en suivant, logiquement. Et voilà que j'apprends hier que cette règle est chamboulée, depuis au moins 10 ans, au vu des posts du web.

raleur a écrit :

Je ne vois pas où est le problème avec Clonezilla ou d'autres outils qui utilisent les noms de fichiers de périphériques des disques et partitions, à partir du moment où on a identifié les disques ou partitions et leur contenu au moment où on les utilise.

C'est-à-dire ? Tu t'y prends comment, toi, si tu veux travailler avec un disque dans gparted, qui ne t'affichera par exemple que /dev/sda /dev/sdb /dev/sdc dans la liste déroulante en haut à droite ?
Tu te repères avec un papier/crayon ou un fichier ?

J'aurais bien voulu pouvoir refaire des manips mais aujourd'hui, la machine refuse absolument de se mettre en mode "vrac".

PS : et à quoi sert alors le fichier /etc/mtab dans lequel je trouve ça (certaines lignes enlevées pour la lisibilité :

/dev/sda1 / ext4 rw,noatime 0 0

/dev/sdc2 /dbck_small ext4 rw,nosuid,nodev,relatime 0 0

/dev/sdc1 /dbck_large ext4 rw,nosuid,nodev,relatime 0 0

/dev/sdb1 /data_large ext4 rw,nosuid,nodev,relatime 0 0

/dev/sdb2 /data_small ext4 rw,relatime 0 0

/dev/sdb2 /var ext4 rw,relatime 0 0

/dev/sdb2 /root ext4 rw,relatime 0 0

/dev/sdb2 /home ext4 rw,relatime 0 0

alors que /etc/fstab n'utilise plus que les uuid ?

Dernière modification par jpt (12-10-2020 15:06:34)

jpt · 12-10-2020 16:04:26

jpt a écrit :

J'aurais bien voulu pouvoir refaire des manips mais aujourd'hui, la machine refuse absolument de se mettre en mode "vrac".

Amusant ! Il aura suffi que je poste ce qui précède puis un reboot de la machine concernée pour que, prise d'un remord, elle redémarre en mode vrac, alors en lançant Gparted depuis un terminal, je vois bien en haut à droite /dev/sda (1.82 Tio) et dessous les données du deuxième disque.
Le problème de Gparted, c'est quand on met des disques vierges de même taille dans une machine toute neuve qui ne comporte qu'un ssd pour booter. Je sens que ma fin de vie va être sportive, animée et pleine de prises de tête.

Car le df c'est pas brillant :

# df | grep sd

/dev/sdb1          200536336 33645860  156634092  18% /

/dev/sdc2          200537056  3642116  186638556   2% /dbck_small

/dev/sdc1         1720225688    69872 1632703760   1% /dbck_large

/dev/sda1         1720225688  8667716 1624105916   1% /data_large

/dev/sda2          200537056  3499096  186781576   2% /data_small

Rappel : sda1 c'est normalement la partoche système sur le ssd et sda2 le swap puisque l'install en voulait un.

Bon, ok, si j'ai bien compris il va donc me falloir apprendre à oublier tout ce que j'ai étudié sur ce sujet depuis 20 ans, et à parser la sortie de df sur le dernier champ. Pour commencer.
Ensuite revoir tous les scripts que j'ai ici et là, puis les programmes en Pascal.

Pas demain qu'elle est en prod', cette babasse...

raleur · 12-10-2020 18:13:07

jpt a écrit :

Tu t'y prends comment, toi, si tu veux travailler avec un disque dans gparted, qui ne t'affichera par exemple que /dev/sda /dev/sdb /dev/sdc dans la liste déroulante en haut à droite ?
Tu te repères avec un papier/crayon ou un fichier ?

Je m'assure d'identifier le disque avec lequel je veux travailler par son modèle, sa capacité, l'organisation de ses partitions...

jpt a écrit :

à quoi sert alors le fichier /etc/mtab

Historiquement, le fichier /etc/mtab était créé par mount qui y inscrivait les montages réalisés. Les noms de périphériques ne changent pas en cours de session. Mais cela avait des inconvénients, notamment quand on est dans un chroot ou quand la racine est en lecture seule. Maintenant, si tu le regardes attentivement, tu verras que c'est un lien symbolique qui pointe vers /proc/mounts ou /proc/self/mounts (le premier étant lui-même un lien symbolique vers le second). Il s'agit donc d'un pseudo-fichier dont le contenu est généré directement par le noyau. Tu remarqueras aussi que son contenu est similaire à ce qu'affiche la commande mount sans argument.

jpt a écrit :

alors que /etc/fstab n'utilise plus que les uuid

mount transforme les UUID en noms de périphériques car le noyau ne connaît rien aux UUID.

jpt · 12-10-2020 19:53:53

Faisons le point : j'ai rouvert la 3e édition de mon remarquable "Le système Linux" chez O'Reilly, daté de mai 2001 et nulle part il n'est question de ces embrouilles.
Si je dis que hda1 est la première partition du premier disque ATA, je ne l'invente pas, je le lis pages 62 et 175.
Depuis, on dirait que les choses ont évolué, mais on ne m'a pas prévenu, et c'est bien dommage.

De plus, à la fin du livre il y a un bel index bien fourni et l'acronyme uuid n'y est pas présent.

Quelle belle vie on avait en ce temps-là.

Parce qu'identifier le disque [...] par son modèle, sa capacité, l'organisation de ses partitions quand il est question de créer du raid 0, 1 ou 5, avec plein de disques identiques qui ont la même capacité et la même organisation, bon courage. Moi, même pas j'y pense.

Je vais essayer de voir du côté de udev et des rules, je n'en dis pas plus car je n'en sais pas plus. Va falloir étudier.

raleur · 12-10-2020 20:54:27

jpt a écrit :

Le problème de Gparted, c'est quand on met des disques vierges de même taille dans une machine toute neuve qui ne comporte qu'un ssd pour booter.

En quoi est-ce un problème ?

jpt a écrit :

Parce qu'identifier le disque [...] par son modèle, sa capacité, l'organisation de ses partitions quand il est question de créer du raid 0, 1 ou 5, avec plein de disques identiques qui ont la même capacité et la même organisation, bon courage.

Quel est le problème ? Tu vas tous les utiliser pour construire le RAID, alors que ce soit l'un ou l'autre, ça ne change rien.

jpt a écrit :

Je vais essayer de voir du côté de udev et des rules

On ne peut pas renommer un périphérique disque comme on renomme une interface réseau. Par contre on peut créer un alias (lien symbolique) spécifique pour un disque particulier. D'ailleurs udev en crée déjà automatiquement basés sur l'UUID, le label, le modèle, le chemin d'accès physique... dans /dev/disk/by-{uuid,label,id,path...}.

PS : merci pour le nettoyage.

Dernière modification par raleur (12-10-2020 22:04:37)

jpt · 13-10-2020 00:14:06

raleur a écrit :

jpt a écrit :
Le problème de Gparted, c'est quand on met des disques vierges de même taille dans une machine toute neuve qui ne comporte qu'un ssd pour booter.

En quoi est-ce un problème ?

Mettons que c'est un problème pour moi.

raleur a écrit :

jpt a écrit :
Parce qu'identifier le disque [...] par son modèle, sa capacité, l'organisation de ses partitions quand il est question de créer du raid 0, 1 ou 5, avec plein de disques identiques qui ont la même capacité et la même organisation, bon courage.
Quel est le problème ? Tu vas tous les utiliser pour construire le RAID, alors que ce soit l'un ou l'autre, ça ne change rien.

Jusqu'au jour où pour une raison inconnue le raid casse et il faut aller mettre les mains dans le cambouis profond profond...
Et là c'est quand même plus sympa de taper mount /dev/sda1 /point2montage que mount uuid=36lettres-chiffres-et-tirets-en-hexa-au-secours-rien-2-mémorisable

jpt · 13-10-2020 09:52:56

Bonjour,

Bon, c'est pas tout ça, mais moi j'aimerais bien comprendre d'où sort ce pataquès qui n'existait pas il y a 20 ans.

Car mine de rien, si la machine boote, c'est que le bios accède bien au premier disque (le ssd), qui est taggué "bootable" et qui contient initrd.img-numver et vmlinuz-numver.

En toute logique ce disque devrait donc s'appeler sda, et d'ailleurs, s'il était seul, on ne serait pas là à causer de ça. Alors comment se fait-il que parfois, à un moment, il s'appelle sdb (je ne crois pas l'avoir vu en tant que sdc [oui, j'ai 3 disques]) ? Qu'est-ce qui se passe à ce moment ? Et d'abord, qui pilote cette action : initrd ou vmlinuz ?

Une idée, quelqu'un ?

Dernière modification par jpt (13-10-2020 09:54:00)

raleur · 13-10-2020 14:24:15

jpt a écrit :

Jusqu'au jour où pour une raison inconnue le raid casse et il faut aller mettre les mains dans le cambouis profond profond...
Et là c'est quand même plus sympa de taper mount /dev/sda1 /point2montage que mount uuid=36lettres-chiffres-et-tirets

1) Rien ne t'empêche d'utiliser /dev/sda1 à partir du moment où tu as identifié le disque ou la partition.
2) Tu peux définir et utiliser des "étiquettes" (LABEL) à la place des UUID.
3) Avec du RAID on ne monte pas des partitions mais des ensembles RAID /dev/md* qui sont normalement plus stables que /dev/sd*.
4) Si tu veux parler de la difficulté de faire la correspondance entre /dev/sd* et un disque physique particulier (pour le remplacer par exemple), alors tu peux t'aider avec le modèle ou le numéro de série s'il y a plusieurs disques de même modèle.

jpt a écrit :

j'aimerais bien comprendre d'où sort ce pataquès qui n'existait pas il y a 20 ans

Plusieurs facteurs.
1) Autrefois, on utilisait des disques PATA (IDE) avec les pilotes "IDE". Ces pilotes affectaient un nom fixe à chaque disque ou lecteur optique en fonction de sa connexion physique :
- disque 0 (master) sur le canal primaire : hda
- disque 1 (slave) sur le canal primaire : hdb
- disque 0 (master) sur le canal secondaire : hdc
- disque 1 (slave) sur le canal secondaire : hdd
C'était simple avec un seul contrôleur IDE, comme sur la plupart des machines. Sur les machines dotées de plusieurs contrôleurs IDE, les disques du premier contrôleur trouvé étaient hda à hdd, les disques du second contrôleur étaient hde à hdh, etc. Le nommage dépendait donc en fait de l'ordre de découverte des contrôleurs, et donc de l'ordre de chargement des pilotes dans le cas où des contrôleurs différents étaient gérés par des pilotes différents.
2) Lors du passage au SATA, les pilotes "IDE" ont été remplacés par des pilotes "ATA" émulant des disques SCSI avec les disques PATA et SATA (comme les disques et clés USB). Avec deux différences notables : les disques ne sont plus nommés hd* mais sd*, et leur nommage ne dépend plus de leur position physique mais de l'ordre de leur découverte. D'autre part ces pilotes ont évolué vers de plus en plus de parallélisme : au lieu de scanner les ports d'un contrôleur SATA un par un, le pilote les scanne tous en parallèle pour gagner du temps. Le nommage des disques dépend donc du délai de réponse de chaque disque, qui comporte une composante aléatoire.
3) Autrefois, on n'utilisait pas d'initramfs et tous les pilotes disques étaient compilés en dur dans le noyau et non en modules. Leur ordre d'initialisation, et donc l'ordre de découverte des contrôleurs était constant.
4) Maintenant qu'on utilise un initrd puis initramfs, les pilotes disques sont compilés en modules et non plus en dur. Le nommage des disques dépend donc en partie de l'ordre de chargement des modules pilotes. Comme les modules sont chargés par udev suite à un événement de découverte du noyau, quand il y a plusieurs contrôleurs cela dépend de l'ordre de découverte des contrôleurs par le noyau et de l'ordre de traitement des événéments par udev.
Tous ces changements combinés vont donc dans le sens de l'imprévisibilité du nommage des disques SATA.

jpt a écrit :

si la machine boote, c'est que le bios accède bien au premier disque (le ssd), qui est taggué "bootable"

"Premier disque" est une notion arbitraire. C'est celui qui est défini en premier dans l'ordre de boot du BIOS.

jpt a écrit :

En toute logique ce disque devrait donc s'appeler sda

Non, car le noyau n'a aucune idée de l'ordre de boot du BIOS, et a son propre processus de découverte et de nommage des disques. Même avec les pilotes IDE le disque de boot n'était pas forcément hda (maître primaire).

jpt a écrit :

qui pilote cette action : initrd ou vmlinuz ?

Les deux. Le noyau (vmlinuz) détecte les contrôleurs SATA et génère des événements. udev dans l'initramfs (initrd) récupère ces événements et charge les modules pilotes noyau correspondants. Les pilotes s'initialisent et scannent les ports SATA pour détecter les disques. Et tout se fait plus ou moins en parallèle de façon concurrente. Le premier disque détecté est sda, le second sdb, etc.

jpt · 13-10-2020 19:53:39

raleur a écrit :

D'autre part ces pilotes ont évolué vers de plus en plus de parallélisme : au lieu de scanner les ports d'un contrôleur SATA un par un, le pilote les scanne tous en parallèle pour gagner du temps. Le nommage des disques dépend donc du délai de réponse de chaque disque, qui comporte une composante aléatoire.
[...]
Et tout se fait plus ou moins en parallèle de façon concurrente. Le premier disque détecté est sda, le second sdb, etc.

OK, j'ai compris, c'est le parallélisme qui met son bronx, ça tombe bien je n'ai jamais cru à ce miroir aux alouettes.

Et le temps que gagne le pilote, nous le perdons ensuite à essayer de recoller les morceaux. Ma machine précédente en 15 jours elle était en prod, là, entre ça et le problème du chipset, ça fait 4 mois qu'on est dessus et c'est toujours pas fini...

Merci pour ces explications.

smolski · 13-10-2020 20:32:12

C'est pas Terminé mais Résolu qu'y faut mettre dans le titre du post, c'est utile pour la recherche de solutions par d'autres visiteurs intéressés par ce cas.

jpt · 14-10-2020 10:24:22

smolski a écrit :

C'est pas Terminé mais Résolu qu'y faut mettre dans le titre du post, c'est utile pour la recherche de solutions par d'autres visiteurs intéressés par ce cas.

Je sais (je fréquente les forums depuis plus de 20 ans), et le nombre de fois que j'ai pu voir des posts taggués "Résolu" sans aucune solution, ça dépasse l'entendement, alors pour une fois que je suis sur un forum qui autorise d'écrire autre chose, je ne veux pas m'en priver : "Terminé", ça dit bien ce que ça veut dire, "fin de conversation", il n'y a pas de solution.

Ou alors je mets "Clos", comme Debian Alain ?

jarek · 14-10-2020 10:59:38

S'il n'y a pas de solution c'est que le problème n'existe pas . . .

smolski · 14-10-2020 23:11:03

Sur l'agencement du forum, il n'y a pas d'autre autorité que les membres eux-mêmes, l'essentiel reste que le post soit lu positivement.

jpt · 15-10-2020 10:06:13

Bonjour,

smolski a écrit :

Sur l'agencement du forum, il n'y a pas d'autre autorité que les membres eux-mêmes, l'essentiel reste que le post soit lu positivement.

Ça alors ! Il n'y a pas de modo(s) ? Mais c'est l'école de l'anarchie, ici
La vraie ! Moi ça me va.

Et alors, qui supprime les posts comme il y a deux jours quand il y a eu ces doublons, triplons (?) etc. suite au problème de proxy ?

jpt · 16-10-2020 18:15:15

smolski a écrit :

Sur l'agencement du forum, il n'y a pas d'autre autorité que les membres eux-mêmes, l'essentiel reste que le post soit lu positivement.

C'est bizarre, ça, au cours de mes promenades ici j'ai vu passer les intitulés "Administrateur" et "Modérateur" associés à des pseudos

jpt · 31-10-2020 16:43:13

Bonjour,

il y avait longtemps...

tout frais de ce matin :

$ lsblk -f

NAME   FSTYPE LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINT

sda                                                                           

├─sda1 ext4   data        83452e91-8384-45c3-b2c7-4315904d03fa    1,5T     1% /data_large

└─sda2 ext4   homerootvar ca124013-9812-4eac-8e52-35560d5ac7f4    178G     2% /data_small

sdb                                                                           

├─sdb1 ext4   system      99dc8d6c-8674-4c7d-b27f-7cd860bdd63f  148,5G    17% /

└─sdb2 swap               272a029e-4d4a-40e2-a3b7-51bf1ac7b0d0                

sdc                                                                           

├─sdc1 ext4   backup      0e65ae8e-d816-4ffc-a210-e616717de2fe    1,5T     0% /dbck_large

└─sdc2 ext4   reserved    99fc2adf-d339-4fcc-82fb-82f93db59f2a    178G     2% /dbck_small

Les UUID sont bien montés là où c'est défini dans /etc/fstab, le souci c'est la sortie de df, filtrée avec "grep sd", et qui n'est pas bonne du tout :

/dev/sdb1          200536336 34615344  155664608  19% /

/dev/sdc1         1720225688    95504 1632678128   1% /dbck_large

/dev/sda1         1720225688  8668260 1624105372   1% /data_large

/dev/sdc2          200537056  3642116  186638556   2% /dbck_small

/dev/sda2          200537056  3646084  186634588   2% /data_small

car l'utilisation d'un script perso basé sur df me sort :

 Disk - Cap tot en Mo - ! = occupé, | = libre

  sdb1 :  195837 [!|||||]

  sdc1 : 1679908 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||]

  sda1 : 1679908 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||]

  sdc2 :  195837 [||||||]

  sda2 :  195837 [||||||]

au lieu de

 Disk - Cap tot en Mo - ! = occupé, | = libre

  sda1 :  195837 [!|||||]

  sdb1 : 1679908 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||]

  sdb2 :  195837 [||||||]

  sdc1 : 1679908 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||]

  sdc2 :  195837 [||||||]

(bon, le graphique n'est pas très parlant car les disques sont neufs donc vides, en plus occupé c'est rouge et vide c'est vert, c'est plus fun).

Et là, c'est la misère noire !
L'ihm d'un outil écrit en gtk/FreePascal/Lazarus et s'appuyant sur la sortie parsée de df affiche des graphiques qui ne ressemblent plus à rien.
Pour l'heure, je ne sais que faire si ce n'est une table de corrélation entre les retours de df et une liste statique créée à la main...

J'avais pensé à passer par stat -f "point_de_montage" mais là aussi ça va coincer. Comparons les sorties sur une partition :

lsblk -h

└─sdc2 ext4   reserved    99fc2adf-d339-4fcc-82fb-82f93db59f2a    178G     2% /dbck_small

stat -f /dbck_small 

 Identif. : 26a8071be6d08cee Longueur du nom : 255     Type : ext2/ext3

C'est mort...
Une idée, quelqu'un ?

Dernière modification par jpt (31-10-2020 16:57:42)

raleur · 31-10-2020 17:23:48

Il me semble avoir déjà suggéré que ton script basé sur df devrait afficher les points de montage plutôt que les noms de périphériques, d'une part ce serait plus parlant et d'autre part ça ne serait pas sensible aux changements de noms des périphériques.

jpt · 31-10-2020 17:48:51

raleur a écrit :

Il me semble avoir déjà suggéré que ton script basé sur df devrait afficher les points de montage plutôt que les noms de périphériques, d'une part ce serait plus parlant et d'autre part ça ne serait pas sensible aux changements de noms des périphériques.

Oui, je m'en souviens, mais je vais avoir du mal à m'y adapter, imagine, presque 20 ans d'études et de pratiques qui s'écroulent...

jpt · 21-11-2020 14:17:52

Bonjour,

malgré le tag [terminé], quand mes galères réseau me laissent un peu de temps, je continue à creuser ce problème et ce matin, en étudiant les logs du démarrage de la machine, voilà sur quoi je tombe (dommage, l'ordre est correct aujourd'hui, mais ça continue à être aléatoire) :

nov. 21 10:25:05 debox64 smartd[720]: smartd 6.6 2017-11-05 r4594 [x86_64-linux-5.7.10] (local build)

nov. 21 10:25:05 debox64 smartd[720]: Opened configuration file /etc/smartd.conf

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sda, type changed from 'scsi' to 'sat'

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sda [SAT], opened

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sda [SAT], KINGSTON SA400S37240G, S/N:50026B7782FAC2F1, WWN:5-0026b7-782fac2f1, FW:SBFKB1D

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sda [SAT], not found in smartd database.

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sda [SAT], can't monitor Current_Pending_Sector count - no Attribute 197

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sda [SAT], can't monitor Offline_Uncorrectable count - no Attribute 198

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sda [SAT], is SMART capable. Adding to "monitor" list.

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sda [SAT], state read from /var/lib/smartmontools/smartd.KINGSTON_SA400S37240G-50026B7782F

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sdb, type changed from 'scsi' to 'sat'

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sdb [SAT], opened

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sdb [SAT], ST2000DM008-2FR102, S/N:WFL1V0FK, WWN:5-000c50-0bf340508, FW:0001, 2.00 TB

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sdb [SAT], not found in smartd database.

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sdb [SAT], state read from /var/lib/smartmontools/smartd.ST2000DM008_2FR102-WFL1V0FK.ata.s

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sdc, type changed from 'scsi' to 'sat'

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sdc [SAT], opened

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sdc [SAT], ST2000DM008-2FR102, S/N:WFL39CN5, WWN:5-000c50-0ccaf2625, FW:0001, 2.00 TB

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sdc [SAT], not found in smartd database.

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sdc [SAT], is SMART capable. Adding to "monitor" list.

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sdc [SAT], state read from /var/lib/smartmontools/smartd.ST2000DM008_2FR102-WFL39CN5.ata.s

nov. 21 10:25:05 debox64 smartd[720]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 21 to 29

nov. 21 10:25:06 debox64 smartd[720]: Device: /dev/sdb [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 79 to 65

nov. 21 10:25:06 debox64 smartd[720]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 21 to 35

nov. 21 10:25:06 debox64 smartd[720]: Device: /dev/sdc [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 79 to 66

nov. 21 10:25:06 debox64 smartd[720]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 21 to 34

Je vous laisse imaginer l'état de la smartd database, et que faut-il faire, alors ? Abandonner aussi smart ?

EDIT : Et j'ai bien l'impression que dd devrait être banni également, ce qui fait beaucoup.
Je n'ai pas poussé mes tests bien loin, juste avec cette ligne de commande, et je me suis fait insulter, comme on peut le voir :

$ dd if=/media/disk2p1/testdd of=/media/disk3p1/ bs=1k

dd: impossible d'ouvrir '/media/disk3p1/': est un dossier

$ dd if=/media/disk2p1/testdd of=/media/disk3p1 bs=1k

dd: impossible d'ouvrir '/media/disk3p1': est un dossier

media/disk2p1 et disk3p1 sont des dossiers servant de points de montage à des partitions issues de disques virtuels

Dernière modification par jpt (21-11-2020 15:16:32)

Debian-facile

#1 11-10-2020 18:43:52

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

#2 11-10-2020 18:54:12

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

#3 11-10-2020 20:22:25

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

#4 11-10-2020 21:24:09

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

#5 11-10-2020 23:25:45

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

#6 12-10-2020 13:04:42

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

#7 12-10-2020 15:02:45

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

#8 12-10-2020 16:04:26

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

#9 12-10-2020 18:13:07

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

#10 12-10-2020 19:53:53

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

#11 12-10-2020 20:54:27

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

#12 13-10-2020 00:14:06

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

#13 13-10-2020 09:52:56

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

#14 13-10-2020 14:24:15

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

#15 13-10-2020 19:53:39

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

#16 13-10-2020 20:32:12

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

#17 14-10-2020 10:24:22

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

#18 14-10-2020 10:59:38

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

#19 14-10-2020 23:11:03

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

#20 15-10-2020 10:06:13

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

#21 16-10-2020 18:15:15

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

#22 31-10-2020 16:43:13

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

#23 31-10-2020 17:23:48

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

#24 31-10-2020 17:48:51

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

#25 21-11-2020 14:17:52

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

Pied de page des forums