Modules disques du noyau passés en dur

Support Debian
#1

Bonjour,

Je crois l’avoir déjà signalé, j’en remets une 'tite couche : j’ai été emm3rd3 pendant 18 mois avec ces problèmes jusqu’à ce que je me décide, à force d’analyses des logs de démarrage à la loupe, à générer un noyau où les pilotes des disques ne sont pas en modules mais intégrés en dur.
Depuis, plus de soucis.
Et méfiance car les uuid m’ont parfois claqué entre les doigts, ça aussi ce n’était pas fiable…

Mais tout ça est peut-être lié à ma carte-mère (une GigaByte), comment savoir ?

EDIT : j’ai retrouvé certaines notes de mai 2021 (un an !), je vous les livre telles quelles :

L’analyse du /var/log/messages confirme ce que j’ai déjà signalé, il se passe quelque chose après la détection correcte des disques (note : j’ai récupéré de plus bas les 2e et 3e lignes, passées ci-dessous pour une meilleure lisibilité, et ce n’est pas gênant, on n’est pas encore dans la partie « bad » au niveau des timings de ces deux lignes) :

...
May 27 10:53:45 debox64 kernel: [    2.686505] scsi 0:0:0:0: Direct-Access     ATA      KINGSTON SA400S3 B1D2 PQ: 0 ANSI: 5
May 27 10:53:45 debox64 kernel: [    3.246967] scsi 1:0:0:0: Direct-Access     ATA      ST2000DM008-2FR1 0001 PQ: 0 ANSI: 5
May 27 10:53:45 debox64 kernel: [    3.807253] scsi 4:0:0:0: Direct-Access     ATA      ST2000DM008-2FR1 0001 PQ: 0 ANSI: 5
  scsi 0, 1, 4 c'est les bons identifiants et les bons disques, ça correspond à ata1, ata2, ata5
  1er disque, le sdd destiné au système :
May 27 10:53:45 debox64 kernel: [    2.686050]  ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
May 27 10:53:45 debox64 kernel: [    2.686196]  ata1.00: ATA-10: KINGSTON SA400S37240G, SBFKB1D2, max UDMA/133
May 27 10:53:45 debox64 kernel: [    2.686214]  ata1.00: 468862128 sectors, multi 1: LBA48 NCQ (depth 32), AA
May 27 10:53:45 debox64 kernel: [    2.686330]  ata1.00: configured for UDMA/133
  2e disque, un 2 To dédié aux données :
May 27 10:53:45 debox64 kernel: [    3.158484]  ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
May 27 10:53:45 debox64 kernel: [    3.196132]  ata2.00: ATA-10: ST2000DM008-2FR102, 0001, max UDMA/133
May 27 10:53:45 debox64 kernel: [    3.196200]  ata2.00: 3907029168 sectors, multi 16: LBA48 NCQ (depth 32), AA
May 27 10:53:45 debox64 kernel: [    3.246625]  ata2.00: configured for UDMA/133
  3e disque, un 2 To dédié aux sauvegardes des données :
May 27 10:53:45 debox64 kernel: [    3.718071]  ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
May 27 10:53:45 debox64 kernel: [    3.756167]  ata5.00: ATA-10: ST2000DM008-2FR102, 0001, max UDMA/133
May 27 10:53:45 debox64 kernel: [    3.756238]  ata5.00: 3907029168 sectors, multi 16: LBA48 NCQ (depth 32), AA
May 27 10:53:45 debox64 kernel: [    3.806906]  ata5.00: configured for UDMA/133
  le dvd :
May 27 10:53:45 debox64 kernel: [    4.278415]  ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
May 27 10:53:45 debox64 kernel: [    4.281265]  ata6.00: ATAPI: HL-DT-ST DVDRAM GH24NSD5, LV00, max UDMA/133
May 27 10:53:45 debox64 kernel: [    4.284541]  ata6.00: configured for UDMA/133
May 27 10:53:45 debox64 kernel: [    4.288412] scsi 5:0:0:0: CD-ROM            HL-DT-ST DVDRAM GH24NSD5  LV00 PQ: 0 ANSI: 5
  >>>>>>>>>>>>>>> et à partir d'ici c'est bad <<<<<<<<<<<<<<<<<<<<
May 27 10:53:45 debox64 kernel: [    4.313914] sd 0:0:0:0: [sdb] 468862128 512-byte logical blocks: (240 GB/224 GiB) <<< c'est le ssd Kingston, should be sda
May 27 10:53:45 debox64 kernel: [    4.313949] sd 1:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB) <<< un des deux 2 To, sdb ou sdc
May 27 10:53:45 debox64 kernel: [    4.313950] sd 1:0:0:0: [sda] 4096-byte physical blocks
May 27 10:53:45 debox64 kernel: [    4.313958] sd 1:0:0:0: [sda] Write Protect is off
May 27 10:53:45 debox64 kernel: [    4.313971] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
May 27 10:53:45 debox64 kernel: [    4.313942] sd 4:0:0:0: [sdc] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB) <<< l'autre 2 To
May 27 10:53:45 debox64 kernel: [    4.314826] sd 0:0:0:0: [sdb] Write Protect is off
May 27 10:53:45 debox64 kernel: [    4.315707] sd 4:0:0:0: [sdc] 4096-byte physical blocks
May 27 10:53:45 debox64 kernel: [    4.316664] sd 0:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
May 27 10:53:45 debox64 kernel: [    4.320944] sd 4:0:0:0: [sdc] Write Protect is off
May 27 10:53:45 debox64 kernel: [    4.321630] sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
  regardez l'ordre ! sd0 est sdb, sd1 est sda, sd4 est sdc :
May 27 10:53:45 debox64 kernel: [    4.328506]  sdb: sdb1 sdb2
May 27 10:53:45 debox64 kernel: [    4.330040] sd 0:0:0:0: [sdb] Attached SCSI disk
May 27 10:53:45 debox64 kernel: [    4.345643]  sda: sda1 sda2
May 27 10:53:45 debox64 kernel: [    4.347612] sd 1:0:0:0: [sda] Attached SCSI disk
May 27 10:53:45 debox64 kernel: [    4.360758]  sdc: sdc1 sdc2
May 27 10:53:45 debox64 kernel: [    4.362381] sd 4:0:0:0: [sdc] Attached SCSI disk

Autre note :
ce matin, en pleine forme, j’ai attaqué par make menuconfig et je me suis permis de passer, dans

Device Drivers, 
SCSI device support de Module à *
ainsi que
SCSI disk support
SCSI CDROM support
SCSI generic support

Pareil dans File Systems pour

Extended 4 
ainsi que
  Caches
    General filesystem local caching manager
    Filesystem caching on file

et enfin dans Firmware Drivers, pareil pour

  BIOS Enhanced Disk Drive calls determine boot disk.

Ensuite la trilogie habituelle, make, make install et make menu_install et roule ma poule.

Et depuis, plus de soucis d’identification en vrac. /EDIT

Grappe redondante non formelle pour partition EFI sur plusieurs disques
Grappe redondante non formelle pour partition EFI sur plusieurs disques
Besoin d'éclaircissement sur le travail de unattended-upgrades
Besoin d'éclaircissement sur le travail de unattended-upgrades
#2

@jipete
Ta problématique est intéressante et je veux bien en discuter mais dans un sujet séparé car je trouve qu’on s’éloigne un peu trop de la question de départ et je ne voudrais pas ajouter des digressions supplémentaires comme celles sur le RAID (à moins que cela ne dérange pas @Almtesh).

#3

Voilà qui est fait, merci à Clochette

#4

Peut-être en rapport avec la pagaille générée par systemd au lancement de tous les pilotes en même temps, sans doute en relation avec le fait que la musiquette du démarrage était parfois pourrie et tronquée, j’ai regardé un peu cette histoire d’allocator, qui offre deux options et dont l’aide ci-dessous vient directement du make menuconfig :

  • SLUB is a slab allocator that minimizes cache line usage instead of managing queues of cached objects (SLAB approach). Per cpu caching is realized using slabs of objects instead of queues of objects.
    La seconde phrase en français par ggl : La mise en cache par processeur est réalisée à l’aide de dalles d’objets et comme c’est pas clair, mon Harrap’s m’éclaire en m’apportant tranches à la place de dalles et j’en conclus que les objets sont découpés en tranches et ensuite ? On ne sait pas.
    SLUB can use memory efficiently and has enhanced diagnostics.
    SLUB is the default choice for a slab allocator.

  • The regular slab allocator that is established and known to work well in all environments. It organizes cache hot objects in per cpu and per node queues.

J’ai écrit en haut à l’imparfait car on dirait que depuis que je suis passé en slab, après avoir lu et relu « known to work well in all environments », ça va mieux : le son n’est plus déglingué et, incroyable mais vrai, la machine démarre un peu plus vite !

À suivre.

#5

Ce sont le noyau et udev qui sont seuls responsables du chargement asynchrone des modules, pas systemd. D’ailleurs les modules gérant les périphériques de stockage sont chargés à partir de l’initramfs pour pouvoir monter la racine, avant le lancement de systemd.

Qu’entends-tu par « claqué entre les doigts » ?
Changé ? Un UUID ne change pas tout seul, mais seulement à l’occasion d’un reformatage (dans ce cas on peut utiliser le PARTUUID qui n’est pas affecté) ou d’une modification explicite de l’UUID.
Pas reconnu correctement (des détails stp) ?

Il n’y a pas de sd0, sd1 ni sd4. Il y a des périphériques SCSI de type « sd » (SCSI disk) dont les adresses sont 0:0:0:0, 1:0:0:0 et 4:0:0:0. Le format d’une adresse SCSI est contrôleur hôte:bus:périphérique:unité logique, on peut donc voir que le pilote libata émule un contrôleur SCSI différent pour chaque port SATA.

Il ne faut pas s’attendre à une relation statique entre les ports SATA physiques et les numéros de ports ata0, ata1…, ni avec les adresses SCSI 0:0:0:0, 1:0:0:0… et encore moins avec les noms de disques sda, sdb… Ici on peut voir que l’attribution des noms de disques (par le pilote sd_mod) ne commence qu’après la détection de tous les périphériques SATA, comme si le module était chargé après. Comme à ce moment tous les disques sont déjà détectés, il n’est pas étonnant que l’ordre de nommage soit aléatoire. Je suppose que si le pilote sd_mod état déjà actif, les disques seraient nommés dans l’ordre de leur détection.

Mais de toute façon je répète que les noms sd* ne sont pas persistants par nature et qu’il ne faut pas compter dessus.

Je ne suis même pas sûr que mettre les pilotes en dur dans le noyau soit nécessaire ni suffisant pour assurer un nommage persistant des disques dans tous les cas.

Inutile de mettre ça en dur pour les disques.

Les pilotes de systèmes de fichiers n’ont rien à voir avec la détection, l’énumération et le nommage des périphériques de stockage.

A ma connaissance ce pilote n’a aucune influence sur le nommage des disques.

#6

Merci pour ton retour,

Bon, ok, j’ai dû lire ça quelque part et je n’ai pas les compétences pour vérifier en profondeur.

Oui, tu as raison, je devrais être plus précis et je me rends compte que j’écris parfois comme dans un roman.
Bref, à l’époque, utiliser les UUID dans /etc/fstab n’a pas pour moi stabilisé le nommage des disques et de leurs partitions, et lire tout en bas pourquoi j’y tiens (à la stabilité du nommage, pas à l’utilisation des UUID).

À ce jour plus de soucis.

Bah, qui peut le plus peut le moins, et si ça ne fait pas de bien, en tout cas ça ne fera pas de mal.

Tu as certainement raison, mais je me suis dit qu’il valait mieux avoir trop de trucs en dur que pas assez.

Enfin, je reviens sur un point qui me chagrine :
tu dis que tu n’es même pas sûr que mettre les pilotes en dur dans le noyau soit [nécessaire ni] suffisant pour assurer un nommage persistant des disques dans tous les cas.
Ce qui revient à dire qu’un jour où l’autre je peux encore me retrouver avec la partition système nommée sdb1 ? Alors pourquoi tous les tutos, tous les exemples, tous les man continuent-ils à nous inonder de lignes de commande comme par exemple pour copier un disque dd if=/dev/sda of=/dev/sdb ?
Et ça, ça me démonte et ça me décourage…

Et au cas où ça aiderait, voilà le dmesg (édité) de ce soir, avec un ssd de 240 Go et deux hdd de 2 To avec 2 partitions pour chaque disque :

première entrée concernant disques et partitions (j'ai enlevé tout ce qui n'en fait pas partie) :
[    1.761246] libata version 3.00 loaded.
[    1.762001] ahci 0000:01:00.1: version 3.0
[    1.762099] ahci 0000:01:00.1: SSS flag set, parallel bus scan disabled
[    1.762507] ahci 0000:01:00.1: AHCI 0001.0301 32 slots 8 ports 6 Gbps 0x33 impl SATA mode
[    1.762962] ahci 0000:01:00.1: flags: 64bit ncq sntf stag pm led clo only pmp pio slum part sxs deso sadm sds apst 
[    1.831329] scsi host0: ahci
[    1.840763] scsi host1: ahci
[    1.848339] scsi host2: ahci
[    1.853807] scsi host3: ahci
[    1.856487] scsi host4: ahci
[    1.887842] scsi host5: ahci
[    1.909783] scsi host6: ahci
[    1.932954] scsi host7: ahci
[    1.963321] ata1: SATA max UDMA/133 abar m131072@0xfce80000 port 0xfce80100 irq 42
[    1.975024] ata2: SATA max UDMA/133 abar m131072@0xfce80000 port 0xfce80180 irq 42
[    1.985479] ata3: DUMMY
[    1.995283] ata4: DUMMY
[    2.004822] ata5: SATA max UDMA/133 abar m131072@0xfce80000 port 0xfce80300 irq 42
[    2.014546] ata6: SATA max UDMA/133 abar m131072@0xfce80000 port 0xfce80380 irq 42
[    2.024208] ata7: DUMMY
[    2.033790] ata8: DUMMY
beaucoup plus loin 
[    2.192885] scsi host8: ahci
[    2.193312] scsi host9: ahci
[    2.193357] ata9: SATA max UDMA/133 abar m2048@0xfcf00000 port 0xfcf00100 irq 54
[    2.193361] ata10: SATA max UDMA/133 abar m2048@0xfcf00000 port 0xfcf00180 irq 55
[    2.504200] ata9: SATA link down (SStatus 0 SControl 300)
[    2.504276] ata10: SATA link down (SStatus 0 SControl 300)
[    2.511019] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    2.511156] ata1.00: ATA-10: KINGSTON SA400S37240G, SBFKB1D2, max UDMA/133
[    2.511178] ata1.00: 468862128 sectors, multi 1: LBA48 NCQ (depth 32), AA
[    2.511314] ata1.00: configured for UDMA/133
[    2.511402] scsi 0:0:0:0: Direct-Access     ATA      KINGSTON SA400S3 B1D2 PQ: 0 ANSI: 5
[    2.511545] scsi 0:0:0:0: Attached scsi generic sg0 type 0
[    2.511658] sd 0:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/224 GiB)
[    2.511686] sd 0:0:0:0: [sda] Write Protect is off
[    2.511702] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    2.511709] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.512345]  sda: sda1 sda2
[    2.512647] sd 0:0:0:0: [sda] Attached SCSI disk
[    2.975030] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    3.012215] ata2.00: ATA-10: ST2000DM008-2FR102, 0001, max UDMA/133
[    3.012239] ata2.00: 3907029168 sectors, multi 16: LBA48 NCQ (depth 32), AA
[    3.071895] ata2.00: configured for UDMA/133
[    3.071997] scsi 1:0:0:0: Direct-Access     ATA      ST2000DM008-2FR1 0001 PQ: 0 ANSI: 5
[    3.072400] sd 1:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[    3.072426] sd 1:0:0:0: [sdb] 4096-byte physical blocks
[    3.072447] sd 1:0:0:0: [sdb] Write Protect is off
[    3.072464] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    3.072471] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    3.072575] sd 1:0:0:0: Attached scsi generic sg1 type 0
[    3.093958]  sdb: sdb1 sdb2
[    3.094320] sd 1:0:0:0: [sdb] Attached SCSI disk
[    3.535024] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    3.572027] ata5.00: ATA-10: ST2000DM008-2FR102, 0001, max UDMA/133
[    3.572057] ata5.00: 3907029168 sectors, multi 16: LBA48 NCQ (depth 32), AA
[    3.632386] ata5.00: configured for UDMA/133
[    3.633405] scsi 4:0:0:0: Direct-Access     ATA      ST2000DM008-2FR1 0001 PQ: 0 ANSI: 5
[    3.634562] sd 4:0:0:0: [sdc] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[    3.635505] sd 4:0:0:0: [sdc] 4096-byte physical blocks
[    3.636601] sd 4:0:0:0: Attached scsi generic sg2 type 0
[    3.637591] sd 4:0:0:0: [sdc] Write Protect is off
[    3.638392] sd 4:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[    3.638482] sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    3.658131]  sdc: sdc1 sdc2
[    3.659438] sd 4:0:0:0: [sdc] Attached SCSI disk
[    4.103039] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    4.105224] ata6.00: ATAPI: HL-DT-ST DVDRAM GH24NSD5, LV00, max UDMA/133
[    4.107502] ata6.00: configured for UDMA/133
[    4.111853] scsi 5:0:0:0: CD-ROM            HL-DT-ST DVDRAM GH24NSD5  LV00 PQ: 0 ANSI: 5
[    4.139850] sr 5:0:0:0: [sr0] scsi3-mmc drive: 48x/12x writer dvd-ram cd/rw xa/form2 cdda tray
[    4.140886] cdrom: Uniform CD-ROM driver Revision: 3.20
[    4.153846] sr 5:0:0:0: Attached scsi CD-ROM sr0
[    4.154031] sr 5:0:0:0: Attached scsi generic sg3 type 5
[    4.571023] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
bien plus loin
[    5.193621] EXT4-fs (sda1): re-mounted. Opts: (null)
encore plus loin
[    6.736946] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
[    6.809042] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null)
#7

Normal, ce n’est pas l’objectif des UUID qui est de ne pas devoir compter sur les noms des disques, donc peu importe qu’ils soient stables ou pas.

Le suspense est insoutenable.

Si, ça peut faire du mal : image du noyau plus grosse qui occupe plus d’espace sur disque et en mémoire, prend plus de temps à charger, et peut faire planter le chargeur d’amorçage si elle est trop grosse.

Oui. Peut-être pas d’un démarrage à l’autre, mais après l’ajout ou la suppression d’un disque par exemple.

Ne précisent-ils pas qu’il faut vérifier quels disques sont sda et sdb avant ?
Une fois que tu sais qu’actuellement le disque source est sda et le disque de destination est sdb, alors tu peux tranquillement utiliser ces noms jusqu’au prochain arrêt/démarrage. Mais après avoir redémarré, il sera sain de vérifier à nouveau les noms et ajuster la commande en conséquence. Donc ne jamais mettre ça en dur dans un script exécuté inconditionnellement.

La différence, c’est que les disques sont nommés au fur et à mesure qu’ils sont détectés, probablement parce que le pilote de disque SCSI sd_mod est déjà actif, et non tous en même temps après qu’ils aient tous été détectés comme dans le dmesg précédent. Je soupçonne qu’on pourrait obtenir le même résultat avec le noyau standard en chargeant le module sd_mod avant le module ahci (par exemple en ajoutant sd_mod dans /etc/initramfs-tools/modules, cf. man initramfs.conf).

Et donc, où est cette raison ?

#8

Ah ! Pourtant j’ai pu trouver des discussions qui ne juraient que par ça, pour faire court : mets des uuid dans ton fstab et tout ira bien.
Ce qu ne fut pas le cas.

:joy:

Rhôôô, tu pinailles, là, c’est capillotracté : la machine met entre 8 et 10 secondes à démarrer, ça va, quoi. Et ce n’est pas l’espace disque pris par les pilotes rajoutés qui devraient la mettre en péril, :stuck_out_tongue:

Si si, d’un démarrage à l’autre, j’ai eu des surprises, à tel point que je m’étais bricolé un script dans une mv, s’exécutant au démarrage et vérifiant les nommages, pour m’informer des déviances, et si pas de déviances le script rebootait la babasse, si déviance une info pour moi sans reboot – et j’en ai eu, des non-reboots.

Non, jamais rien de précisé comme on aurait pu/dû s’y attendre…
Et ta phrase avec le mot jamais en gras, on devrait la retrouver partout, et toute en gras, ce qui est loin d’être le cas. :worried:

Hé oui…
Le plus curieux dans cette affaire, c’est que mon fichier de conf, brut d’installation, est ainsi rédigé, comme chez tout le monde je suppose :

# List of modules that you want to include in your initramfs.
# They will be loaded at boot time in the order below.
#
# Syntax:  module_name [args ...]
#
# You must run update-initramfs(8) to effect this change.
#
# Examples:
#
# raid1
# sd_mod

Amusant, isn’t it ? Le plus dément, c’est que dans tout ce que j’ai pu lire à ce sujet, personne n’a jamais parlé de cette astuce toute simple.

Juste avant la fin de mon précédent post :

alors qu’on sait que sda et sdb sont fluctuants et aléatoires, d’où mon désir d’un nommage fiable, gravé dans le marbre et coulé dans le bronze !

Trêve de plaisanteries : tu écris tout un tas de choses intéressantes, que je ne découvre que ce matin.
Et comme je n’ai pas plein de machines pour tester et encore tester, ça restera (malheureusement ?) comme ça, mais je note quand même tes propositions, pour la prochaine machine (dans 10 ans ?).

#9

Mettre des UUID à la place des noms de partitions dans /etc/fstab assure que la bonne partition sera montée au bon endroit, ni plus ni moins. Cela n’a aucun effet sur les noms des disques et partitions, si c’est ce que tu veux dire.
As-tu un exemple où la mauvaise partition était montée en utilisant l’UUID dans /etc/fstab ?

Oui, j’avoue.

Peut-être les auteurs considèrent-ils que c’est évident ?

Oui. sd_mod n’est qu’un exemple mis en commentaire, j’ignore si ce choix est une coïncidence ou s’il y a une raison.

Je n’en avais jamais parlé non plus. J’en parle maintenant parce que c’est le résultat d’un raisonnement à partir de ton cas particulier. Et je le redis, à mon avis ce n’est pas fiable à 100% car cela repose sur un séquencement temporel qui peut fluctuer selon les conditions.

A mon avis, chercher à stabiliser les noms des disques est un combat perdu d’avance. Il y a des alternatives :

  • utiliser les liens symboliques persistants présents dans /dev/disk/

  • identifier le disque ou la partition avec blkid, exemple avec l’identifiant de table de partition :

    blkid -t PTUUID="xxxxxxxx" -o device /dev/sd?

  • créer et utiliser des liens symboliques persistants avec des règles udev dans /etc/udev/rules.d/, exemple avec le numéro de série :

    SUBSYSTEM=="block", ACTION=="add", KERNEL=="sd*", KERNELS=="ata*", ENV{ID_SERIAL_SHORT}=="xxxxxxxx", SYMLINK+="ssd%n"
#10

avec

blkid -o list 
quand tout va bien
device     fs_type label    mount point    UUID
/dev/sda1  ext4    system   /              99dc8d6c-8674-4c7d-b27f-7cd860bdd63f
/dev/sda2  swap    swap     [SWAP]         272a029e-4d4a-40e2-a3b7-51bf1ac7b0d0
/dev/sdb1  ext4    data     /data          83452e91-8384-45c3-b2c7-4315904d03fa
/dev/sdb2  ext4    reserved (non monté)    ca124013-9812-4eac-8e52-35560d5ac7f4

quand ça va mal
device     fs_type label    mount point    UUID
/dev/sda1  ext4    data     /data          83452e91-8384-45c3-b2c7-4315904d03fa
/dev/sda2  ext4    reserved (non monté)    ca124013-9812-4eac-8e52-35560d5ac7f4
/dev/sdb1  ext4    system   /              99dc8d6c-8674-4c7d-b27f-7cd860bdd63f
/dev/sdb2  swap    swap     [SWAP]         272a029e-4d4a-40e2-a3b7-51bf1ac7b0d0

curieusement, le sdc et ses 2 partoches sont toujours corrects, alors je n’inclus pas leurs deux lignes, ça allègera.

Sans doute, oui. Je vous laisse imaginer les newbies face à ça…

Ceux de quel dossier ?

$ ls -lGg /dev/disk/
total 0
drwxr-xr-x 2 440 18 mai   08:47 by-id
drwxr-xr-x 2 160 18 mai   08:47 by-label
drwxr-xr-x 2 160 18 mai   08:47 by-partuuid
drwxr-xr-x 2 440 18 mai   08:47 by-path
drwxr-xr-x 2 160 18 mai   08:47 by-uuid

En me basant sur

$ ls -lGg /dev/disk/by-partuuid/
total 0
lrwxrwxrwx 1 10 18 mai   08:47 ca7ed134-01 -> ../../sdb1
lrwxrwxrwx 1 10 18 mai   08:47 ca7ed134-02 -> ../../sdb2
lrwxrwxrwx 1 10 18 mai   08:47 ec0402c2-01 -> ../../sda1
lrwxrwxrwx 1 10 18 mai   08:47 ec0402c2-02 -> ../../sda2
lrwxrwxrwx 1 10 18 mai   08:47 edfce0d7-01 -> ../../sdc1
lrwxrwxrwx 1 10 18 mai   08:47 edfce0d7-02 -> ../../sdc2

je tente
$ blkid -t PTUUID="ca7ed134-01" -o device /dev/sd?
mais ça me redonne le prompt sans rien d’autre, alors je tente, au pif,
$ blkid -t PTUUID="ca7ed134" -o device /dev/sd?
/dev/sdb
mais c’est un peu léger à mon goût : où sont sdb1 et 2 ?

Je ne comprends absolument rien à la complexité inouïe (pour moi) du bazar udev, ça, c’est un coup à tout casser.

#11

Les noms des disques sda et sdb sont intervertis mais les bonnes partitions sont montées aux bons endroits, ce qui est la raison d’être des UUID. Qu’est-ce qui te fait dire que « ça va mal » ?

Ceux que tu veux en fonction de l’identifiant persistant sur lequel tu veux te baser.

  • Pour identifier un disque par son modèle et numéro de série, by-id.
  • Pour identifier une partition par son UUID de partition (indépendant du contenu), by-partuuid.
  • Pour identifier un disque ou une partition par l’UUID de son contenu, by-uuid.
  • Etc.

PTUUID désigne l’identifiant de disque contenu dans la table de partition, il ne s’applique qu’à un disque entier partitionné, pas à une partition.
PARTUUID désigne l’identifiant de partition contenu dans la table de partition (indépendant du contenu de la partition, ne change pas lors d’un reformatage contrairement à l’UUID), il ne s’applique qu’à une partition.
Tu peux utiliser l’un ou l’autre selon que tu veux identfier un disque ou une partition.

Ici, la ressemblance entre les deux est un cas particulier : la table de partition au format DOS ne contient pas de PARTUUID mais le noyau l’émule en associant l’identifiant de disque (PTUUID) et le numéro de partition. Ce n’est pas aussi fiable qu’un vrai PARTUUID (présent dans une table de partition au format GPT) car l’identifiant de disque est facultatif et le numéro de partition est susceptible de changer, en particulier pour les partitions logiques (n° > 4 ).

Il faut s’y plonger une bonne fois pour toutes, et notamment lire entièrement la page de manue d’udev. L’écriture d’une règle udev n’est pas très compliquée une fois qu’on a compris la logique, il suffit de choisir les bons critères pour identifier le périphérique.
Pour afficher les critères disponibles pour un périphérique donné, il y a deux commandes :

udevadm info /dev/sdX

Tout ce qui est préfixé par « E: » peut être utilisé dans la règle avec ENV{NOM}=="valeur".

udevadm info --attribute-walk /dev/sdX

Les éléments NOM=="valeur" peuvent être inclus dans la règle.

#12

Ce que je dis depuis le début, que dans ma tête et dans tous les tutos, /dev/sda1 est le premier disque et habituellement le disque système, alors exécuter le jour où ça va mal dd if=/dev/sda1 of=/dev/sdb1 va se terminer avec les data recopiées sur le disque système, :cold_face:.
Alors oui, avec les uuid on s’en sort, mais c’est une abomination et une source d’erreur de taper ces informations sur la ligne de commande.

Pour le reste, je reprendrai ça à tête reposée (déjà que j’ai traduit par PARTUUID là où tu avais écrit PTUUID), pour le moment je suis complètement sur autre chose, avec un ampli vintage qui fait du bruit à l’allumage alors si quelqu’un connait un bon forum audio, je veux bien le lien.

#13

Ça dépend de la définition de « premier ».

Le jour où ça ne va pas comme tu veux, nuance.

Tu le sais, donc si tu fais à la main tu vérifies avant, et si c’est un script tu ajoutes de quoi identifier formellement les partitions, par leur (PART)UUID ou autre.