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

jpt · 20-05-2021 10:08:51

Tawal a écrit :

Je crois que c'est assez clair.

Faut croire que non puisque la même commande (excepté 3 --> 2 parce que mes disques n'ont que 2 partitions) me retourne

partx: /dev/sda2 : échec de lecture de table de partitions

Et pareil si je mets 1 au lieu de 3.
Et tout ça je l'ai déjà écrit.

Tawal · 26-05-2021 10:01:09

Je ne vois rien d'anormal.
Sur ton disque sda, tu n 'as que 2 partitions (primaire je suppose), donc c'est le disque sda qui détient la table de partition.

Par contre si tu crées un 3iéme partition étendue sous la partition primaire sda2, alors la commande te donnera un retour.
Car sda2 contiendra sa table de partition "étendue".

C'est peut-être plus clair ainsi.

Dernière modification par Tawal (26-05-2021 10:04:23)

jpt · 26-05-2021 10:46:28

Bonjour,

Tawal a écrit :

C'est peut-être plus clair ainsi.

Oui, grâce à toi et ta persévérance, et je t'en remercie.

Effectivement, en relisant les derniers échanges, je me rends compte que je me suis pris les pieds dans le tapis, faut dire aussi que cette histoire d'identification fluctuante commence à me prendre sérieusement la tête (et la machine qui ne veut pas tomber en panne alors que j'ai plein d'outils pour analyser, grrrrr).

Tawal · 26-05-2021 11:21:16

Tant mieux.

Et pourtant j'ai dit une con#@!%$

On ne crée pas de partition étendue sous une partition primaire mais plutôt sous une partition logique

Edit : 2iéme con#@!%$

Dernière modification par Tawal (26-05-2021 13:18:22)

Debian Alain · 26-05-2021 11:42:05

bonjour

tu es sûr , Tawal ?

la structure classique , c'est pas plutôt :

3 partitions principales , une partiton étendue et n partitions logiques ?

https://www.tech2tech.fr/quelle-est-la- … un-disque/

amicalement ,

alain.

Dernière modification par Debian Alain (26-05-2021 11:44:05)

Tawal · 26-05-2021 11:48:04

Je te crois sur message

J'avais pas révisé

Merci, là c'est très clair

Debian Alain · 26-05-2021 11:52:25

d'ailleurs , c'est fâcheux , c'est vrai .

mais çà fait longtemps que les dénominations "sdX" sont connues comme étant non fiables .

seulement , jusqu'ici , elles étaient plutôt stables .

parfois , çà déconne .

pas de chance .

mais t'inquiète , moi aussi , çà m'est arrivé .

je peux te donner un exemple où j'ai dû utiliser les uuid en lieu et place des classiques "sdX"

çà complique énormément les choses mais , en cas de besoin précis , c'est nécessaire .

Dernière modification par Debian Alain (26-05-2021 11:57:01)

jpt · 26-05-2021 11:52:32

Debian Alain a écrit :

3 partitions principales , une partition étendue et n partitions logiques ?

3 partitions primaires, une partition étendue contenant n partitions secondaires (ou logiques) source

Dernière modification par jpt (26-05-2021 11:53:18)

jpt · 26-05-2021 11:57:02

Debian Alain a écrit :

mais çà fait longtemps que les dénominations "sdX" sont connues comme étant non fiables.

Longtemps, really ? Je n'ai jamais été emm…dé par ces changements d'identification jusqu'à ce que systemd vienne semer sa pagaille. Jamais ! Et pourtant j'en ai vu passer, des machines, ces vingt dernières années (et je suis un adepte des machines multi-disques).

jpt · 26-05-2021 11:59:08

Debian Alain a écrit :

je peux te donner un exemple où j'ai dû utiliser les uuid en lieu et place des classiques "sdX"

Simple coup de bol pour toi, car moi aussi je les ai utilisés, sans pour autant que ça soit une franche réussite, la preuve ce post et cette machine à côté de moi toujours pas en prod' depuis 11 mois et demi…

Tiens, je retrouve ça dans son fstab :

#### premier dd, sdb -- les datas

##/dev/sdb1 : 1,6 To

##/dev/sdb1 /data_large ext4  relatime,rw,auto,users,exec 0 2

## 11-10/2020, suite conseils Alain suite micmac sda1<>sdb1, passage aux uuid.

## 11/11/2020 : mais ça ne change rien... Création d'un nouveau noyau avec 6 modifications, à suivre...

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

Lis bien les lignes du 11-10 et 11/11. Le Alain c'est toi !

Dernière modification par jpt (26-05-2021 12:01:49)

Debian Alain · 26-05-2021 12:01:30

bonjour JPT

JPT a écrit :

Longtemps, really ? Je n'ai jamais été emm…dé par ces changements d'identification jusqu'à ce que systemd vienne semer sa pagaille

je ne peux pas soutenir suffisamment cette assertion devant toi . je n'ai pas assez de connaissances .

simplement , demande plus amples éclairages à râleur .

lui pourra te répondre précisément .

amicalement ,

alain.

Dernière modification par Debian Alain (26-05-2021 12:03:41)

Croutons · 26-05-2021 15:02:51

https://fr.wiktionary.org/wiki/entre_la … le_clavier

jpt · 26-05-2021 19:52:24

Debian Alain a écrit :

simplement , demande plus amples éclairages à râleur .

Bah, on en parle depuis le début de cette discussion, et la seule chose qui en ressort, c'est qu'avant d'appuyer sur <ENTREE> avec une commande "chaude" (genre dd pour remettre un disque à zéro), y a intérêt à être sûr et archi-sûr de son coup puisque l'OS n'est plus fiable à 100%.

Quant à ça,

Croutons a écrit :

https://fr.wiktionary.org/wiki/entre_la … le_clavier

ça me fait à moitié rire, quand la seule différence entre la machine opérationnelle et la machine en vrac c'est un simple reboot sans toucher à aucun paramètre.
Ou l'inverse : j'allume la machine, quand j'ai le bureau je regarde et je vois que le swap est sur /dev/sdc1 (par exemple) alors je reboote et là il passe comme attendu (par moi *ici*) sur /dev/sda2.

Ça me fait terriblement peur et j'ai l'impression d'être le seul concerné (sauf tous ceux qui en parlent sur le web -- mais sur ce forum, walou…)

Dernière modification par jpt (26-05-2021 19:53:36)

Debian Alain · 26-05-2021 20:10:09

jpt a écrit :

Ça me fait terriblement peur et j'ai l'impression d'être le seul concerné (sauf tous ceux qui en parlent sur le web -- mais sur ce forum, walou…)

non , tu n'es pas le seul concerné , jpt .

cela m'arrive aussi . sur une machine récente .

dmesg | grep DMI:

[    0.000000] DMI: System manufacturer System Product Name/PRIME X570-PRO, BIOS 3603 03/20/2021

normalement , le disque de "stable" devrai être sda et sdb , le hdd "sauvegarde" (4TB)

voilà comment j'ai , à moitié , résolu mon souci .
maintenant , conky me dit qui est qui .
cela me dépanne .

$hr

${alignc} -- Noms -- 

  N.v.m.e.${goto 150}: ${texeci 60 sudo smartctl -a /dev/nvme0n1 | grep "Model Number:" | awk '{print $3 ,$4}'} ${goto 390}: ${texeci 60 sudo smartctl -a /dev/nvme0n1 | grep "Data Units Written:" |awk '{sub(/^\[/, "",$5); print $5 " TBW "}'}/ ${texeci 60 sudo smartctl -a /dev/nvme0n1 | grep "Percentage Used:" | awk '{print $NF}'} used

(${texeci 60 udevadm info /dev/disk/by-id/ata-CT1000MX500SSD1_2027E2B2B9E2 | awk -F= '/ID_BUS/{print $2}'}) ${texeci 60 lsblk /dev/disk/by-id/ata-CT1000MX500SSD1_2027E2B2B9E2-part2 -noPKNAME 2>/dev/null} ${goto 150}: ${texeci 60 lsblk /dev/disk/by-id/ata-CT1000MX500SSD1_2027E2B2B9E2-part2 -noLABEL 2>/dev/null}${goto 390}: ${texeci 60 sudo smartctl -a  /dev/disk/by-id/ata-CT1000MX500SSD1_2027E2B2B9E2 | awk '/Device Model:/{print $NF}'}   

(${texeci 60 udevadm info /dev/disk/by-id/ata-ST4000VM000-2AF166_WDH0AFF6 | awk -F= '/ID_BUS/{print $2}'}) ${texeci 60 lsblk /dev/disk/by-id/ata-ST4000VM000-2AF166_WDH0AFF6 -noPKNAME|grep sd 2>/dev/null} ${goto 150}: ${texeci 60 lsblk /dev/disk/by-id/ata-ST4000VM000-2AF166_WDH0AFF6-part1 -noLABEL 2>/dev/null}${goto 390}: ${texeci 60 sudo smartctl -a /dev/disk/by-id/ata-ST4000VM000-2AF166_WDH0AFF6 | awk '/Device Model:/{print $NF}'}

ls -l /dev/disk/by-uuid/

total 0

lrwxrwxrwx 1 root root 10 26 mai   17:37 0d9fc33f-1f78-4b1c-8956-0f79f95b7fec -> ../../sdb3

lrwxrwxrwx 1 root root 10 26 mai   17:37 24484c9c-b16e-4960-b4e3-378272350cf5 -> ../../sdb2

lrwxrwxrwx 1 root root 15 26 mai   17:37 4C19-32CF -> ../../nvme0n1p1

lrwxrwxrwx 1 root root 15 26 mai   17:37 723480b2-77b1-4521-ba4b-a2060c4a6187 -> ../../nvme0n1p4

lrwxrwxrwx 1 root root 10 26 mai   17:37 72b67e18-c7bc-4734-b802-63fe432a8ed5 -> ../../sdb4

lrwxrwxrwx 1 root root 10 26 mai   17:37 78AB-CDD1 -> ../../sdb1

lrwxrwxrwx 1 root root 15 26 mai   17:37 b884f660-d3bb-4409-9fe4-3077479cb40a -> ../../nvme0n1p3

lrwxrwxrwx 1 root root 10 26 mai   17:37 ba86cfa4-fed0-4809-a91a-14ef0a8ea671 -> ../../sda1

lrwxrwxrwx 1 root root 15 26 mai   17:37 bd1730f1-9eb5-4a9c-9773-0d0455ba6aa1 -> ../../nvme0n1p2

Dernière modification par Debian Alain (26-05-2021 21:02:51)

raleur · 26-05-2021 20:29:32

jpt a écrit :

Debian Alain a écrit :
çà fait longtemps que les dénominations "sdX" sont connues comme étant non fiables.

Longtemps, really ?

Depuis toujours, en fait. C'est inhérent à l'attribution de ces noms : sda est le premier disque trouvé, sdb le second, et ainsi de suite. Le nommage dépend donc de l'ordre de détection, et cet ordre dépend de divers facteurs comme l'ordre de chargement des pilotes concernés qui peut être variable, et de bien d'autres facteurs comme le temps que va mettre chaque disque à répondre à l'énumération.

Autrefois, il y a très longtemps. les disques SCSI étaient rares et chers, la plupart des PC avaient des disques IDE/PATA (ou SATA avec des contrôleurs en mode IDE) et le noyau avait des pilotes "IDE" qui exposaient les disques PATA/SATA en tant que /dev/hd*... en fonction de leur position/réglage physique :
- hda = primary master
- hdb = primary slave
- hdc = secondary master
- hdd = secondary slave

Tout a changé quand d'une part les disques SATA se sont répandus et les pilotes "IDE" ont été remplacés par des pilotes "ATA" exposant les disques PATA et SATA comme des disques SCSI /dev/sd*, et d'autre part 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. Il est devenu plus sûr d'utiliser les UUID plutôt que les noms de périphériques des disques.

Debian Alain a écrit :

demande plus amples éclairages à râleur

J'ai déjà essayé de lui expliquer, c'est peine perdue.
Il voudrait que /dev/sdb soit toujours tel disque et soit monté sur /data. Si le disque qui doit être monté sur /data est /dev/sda ou /dev/sdc, ça ne va pas.

Sur ce, je retourne à des activités plus productives.

Dernière modification par raleur (26-05-2021 20:31:32)

jpt · 26-05-2021 23:32:49

raleur a écrit :

Il voudrait que /dev/sdb soit toujours tel disque et soit monté sur /data. Si le disque qui doit être monté sur /data est /dev/sda ou /dev/sdc, ça ne va pas.

Évidemment puisque quand je prends les fichiers représentant les disques virtuels d'une machine virtuelle et que je les monte dans le host avec le guest éteint, ça me permet d'y faire des modifs sans démarrer la mv. Et si je monte le disque des données et que j'y recopie des données, lorsque je vais démarrer la mv j'espère bien retrouver les données que j'ai mises dans /dev/sdb1 par exemple dans /data.
Mais si systemd et sa pagaille me montent /dev/sdb1 dans / ou ailleurs, je suis à la rue !

Et ce que personne n'a vu, c'est qu'à l'allumage de la machine sda est bien le premier disque détecté et c'est ensuite que c'est modifié. Par qui par quoi je ne sais pas.
Je remets (post #45) :

jpt a écrit :

Un résumé édité de /var/log/messages du boot d'hier soir, (je peux tout fournir mais ça n'apportera rien de plus) :
ça c'est correct :
May 18 22:43:58 kernel: [ 2.726045] scsi 0:0:0:0: Direct-Access ATA KINGSTON SA400S3 B1D2 PQ: 0 ANSI: 5
May 18 22:43:58 kernel: [ 3.296757] scsi 1:0:0:0: Direct-Access ATA ST2000DM008-2FR1 0001 PQ: 0 ANSI: 5
May 18 22:43:58 kernel: [ 3.867293] scsi 4:0:0:0: Direct-Access ATA ST2000DM008-2FR1 0001 PQ: 0 ANSI: 5
et ça, une demi-seconde plus tard, c'est pas bon :
May 18 22:43:58 kernel: [ 4.369267] sd 1:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
May 18 22:43:58 kernel: [ 4.369284] sd 4:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
May 18 22:43:58 kernel: [ 4.372958] sd 0:0:0:0: [sdc] 468862128 512-byte logical blocks: (240 GB/224 GiB)

Explication de texte : la dernière ligne, à 4.3729, montre sdc (sd 0:0:0:0:) comme étant un disque de 240 Gb, alors que la première ligne, à 2.7260, montre scsi 0:0:0:0: comme ce disque de 240 Gb et il n'y a pas d'erreur puisqu'il n'y a qu'un seul disque de 240 Gb dans cette machine.

Et personne n'a répondu à l'interrogation que j'ai posée concernant l'utilisation de dd le jour où sda sera sdb et inversement.

Il faudrait récrire tous les man's, tous les exemples, prévenir le monde entier que des catastrophes nous guettent mais non, rien !

raleur a écrit :

Il est devenu plus sûr d'utiliser les UUID plutôt que les noms de périphériques des disques.

J'ai déjà dit que ça aussi ça m'a joué des tours ! Et je l'ai encore posté aujourd'hui (ou hier, flemme de chercher).

Mais tu viens de me donner une piste :

raleur a écrit :

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.

Demain je regarde en profondeur mon .config en passant par make menuconfig.
Merci !

Dernière modification par jpt (26-05-2021 23:33:26)

jpt · 27-05-2021 13:24:08

Bonjour,

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, reboot tout confiant mais mal m'en a pris, je me suis retrouvé avec un message à la onc me disant qu'un disque uuid=blabla... n'était pas trouvé.
Des sueurs froides me sont apparues, j'ai rebooté en allant chercher le noyau précédent, qui est venu mais, lol !, depuis le temps que j'attendais qu'il se mette en vrac, ben il y était, cette fois !
J'en ai donc profité pour faire tourner mes scripts dont je vous livre le résultat ci-dessous, à gauche données good récupérées il y a qq jours et à droite celles toutes chaudes en live :
(note : curieusement, le sdc et ses 2 partoches sont toujours corrects, alors j'enlève leurs trois lignes, ça allégera)

by-id omis, c'est pareil qu'avec by-path

by-path :

pci-0000:01:00.1-ata-1        sda     | pci-0000:01:00.1-ata-1  sdb

pci-0000:01:00.1-ata-1-part1  sda1    | pci-0000:01:00.1-ata-1-part1  sdb1

pci-0000:01:00.1-ata-1-part2  sda2    | pci-0000:01:00.1-ata-1-part2  sdb2

pci-0000:01:00.1-ata-2        sdb     | pci-0000:01:00.1-ata-2  sda

pci-0000:01:00.1-ata-2-part1  sdb1    | pci-0000:01:00.1-ata-2-part1  sda1

pci-0000:01:00.1-ata-2-part2  sdb2    | pci-0000:01:00.1-ata-2-part2  sda2

by-label :

sda1 system                           | sda1 data

sda2 swap                             | sda2 homerootvar (non utilisé)

sdb1 data                             | sdb1 system

sdb2 homerootvar (non utilisé)        | sdb2 swap

avec /proc/partitions : comparez les tailles !

major minor  #blocks  name            |

   8        0  234431064 sda          |   8        0 1953514584 sda

   8        1  204800000 sda1         |   8        1 1748713472 sda1

   8        2   29627488 sda2         |   8        2  204800000 sda2

   8       16 1953514584 sdb          |   8       16  234431064 sdb

   8       17 1748713472 sdb1         |   8       17  204800000 sdb1

   8       18  204800000 sdb2         |   8       18   29627488 sdb2

avec swaplabel :  

LABEL: swap                                 | swaplabel: /dev/sda2 : pas une partition d'échange valable

UUID:  272a029e-4d4a-40e2-a3b7-51bf1ac7b0d0 |

OK

avec blkid -o list :

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    homerootvar (non monté) ca124013-9812-4eac-8e52-35560d5ac7f4

KC

avec blkid -o list :

device     fs_type label    mount point    UUID

/dev/sda1  ext4    data     /data          83452e91-8384-45c3-b2c7-4315904d03fa

/dev/sda2  ext4    homerootvar (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

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 parfois interverti des lignes pour avoir une meilleure lisibilité, donc les timings ne sont plus chronologiques) :

...

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

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

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

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

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.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.313949] sd 1:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB) <<< un des deux 2 To

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.315707] sd 4:0:0:0: [sdc] 4096-byte physical blocks

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

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

Bref, en mode "secours" j'ai modifié le fstab pour virer tous les uuid's et utiliser à l'ancienne les /dev/sdxy, un coup de update-grub, reboot et… rateau !
Le même que précédemment.
Rebelote avec le noyau de secours, cette fois au pif je tente un update-initramfs -u version, reboot et c'est bon !
Ouf, car j'ai tremblé.

Je vais rester deux-trois jour comme ça puis je repasserai sur les uuid's, pour voir.

Un dernier mot, pour montrer que des choses ne sont pas finies : quand j'étais dans le make menuconfig, j'ai revu un setting qui est mal pris en compte, le default hostname, que j'avais intitulé debox64-570 (64 par opposition à l'ancienne machine qui est en 32 bits, et 570 pour la version du noyau) et que je ne voyais jamais, ou plutôt, je voyais juste debox64, comme si le "tiret-du-6" et ce qui le suivait n'étaient pas admis. Alors puisque j'y étais, j'ai remplacé par debox64_570 et croyez-le ou pas, mais ce 570 n'apparaît toujours pas.
Et ça me gonfle, vous n'imaginez pas à quel point !

Sur ce, bon app' et bon aprème (je bouge),

Croutons · 27-05-2021 15:27:22

moi je dis ce post aurait du s’arrêter au message #2
toute tes interventions sont négative, on doit bannir dd maintenant ba voyons

et comme tu dis on a pas fini de rigoler

man dd a écrit :

of=FICHIER
écrire dans le FICHIER plutôt que sur la sortie standard

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

Dernière modification par Croutons (27-05-2021 15:27:53)

jpt · 27-05-2021 19:13:59

Au lieu de poster des réponses non constructives, relis le post d'Alain (#64), et aussi ça :

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.

, extrait d'ici

Dernière modification par jpt (27-05-2021 19:26:34)

Croutons · 27-05-2021 19:48:15

c'est non constructif, si tu veux je peux te citer un exemple aussi:
quand j'ai créé ma clé ventoy la clé a changé pendant l'opération
elle s’appelait sdc puis du a un point de montage temporaire elle est passé sdd

raleur a déja répondu message #2

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

jpt · 27-05-2021 20:58:12

Hé bien, s'il y a quelqu'un qui connaît les internals du noyau, et qu'il se penche sur l'extrait de /var/log/messages dans lequel j'ai montré qu'à un moment (4.313914 pour l'extrait de ce matin) les disques (et donc du coup les partoches qu'ils portent) changent de nom, peut-être qu'il va regarder plus attentivement ce qui se passe à ce moment et que ça fera "tilt" dans sa tête et qu'il viendra poster, pourquoi pas ? On peut toujours rêver, non ?

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,

.

Et mes interventions ne sont pas négatives, elles mettent juste le doigt là où ça fait mal, étant entendu que ceux qui n'ont qu'un disque ne verront jamais ce problème alors que moi je l'avais encore sous le nez ce matin, et mes scripts n'ont rien à voir avec tout ça, puisqu'ils se contentent de lire les infos dans /dev/disk ou /proc/partitions ou celles remontées par blkid, pas plus.

Tiens, cadeau (attention tout en bas au swap, je l'ai forcé à /dev/sda2) :

#!/bin/bash

Disks=(); Targets=()

for disk in /dev/disk/by-id/ata*

do

  id=${disk##*/}

  target=$(readlink "$disk")

  target=${target##*/}

  [[ $target == sr* ]] && continue # pour virer le cdrom

  Disks+=("$id")

  Targets+=( "$target" )

  test ${#id} -gt ${fmt:-0} && fmt=${#id}

done

for d in "${!Disks[@]}"; do printf "%-${fmt}s %s\n" "${Disks[d]}" "${Targets[d]}"; done

echo

# manip IFS obligatoire pour tout avoir sur la même ligne,

# sinon tous les champs sont indépendants, chacun sur sa ligne. 

OLDIFS=$IFS

IFS=$'\n'

echo "Note perso : refaire 'by-path et by-label' à la sauce 'by-id'"

echo "by-path :"

liste=$(ls -lGg /dev/disk/by-path | grep ata | grep -v sr)

for ligne in ${liste[@]}

do 

  #echo $ligne

  name=$(echo $ligne | awk '{print $7}')

  sdxx=$(echo $ligne | awk '{print $9}')

  sdxx=${sdxx:6}

  echo $name $sdxx

done

echo

echo "by-label :"

liste=$(ls -lGg /dev/disk/by-label | grep -v total | grep -v sr)

declare -a tableau

for ligne in ${liste[@]}

do

  #echo $ligne

  name=$(echo $ligne | awk '{print $7}')

  sdxx=$(echo $ligne | awk '{print $9}')

  tableau+=(${sdxx:6}_$name)

done

sortedtab=($(sort <<<"${tableau[*]}"))

printf "%s\n" "${sortedtab[@]//_/ }" # pour remplacer le "_" par une espace

echo

IFS=$OLDIFS

echo "avec /proc/partitions :"

cat /proc/partitions | grep -v "^$" | grep -v sr

echo

echo "avec blkid -o list :"

blkid -o list | grep -v sr

echo

echo "avec swaplabel :"

swaplabel /dev/sda2

hybridemoineau · 27-05-2021 21:50:21

Tu as plusieurs disques.

Tu as un souci au démarrage, tu regardes les UUID, avec blkid par exemple.

Tu fais des scripts ou des réglages, tu passes par les UUID.

Tu t'interroges sur la variation de sdX, tu changes le fonctionnement de ton OS par rapport au matériel.

Dernière modification par hybridemoineau (27-05-2021 21:50:55)

Debian Alain · 28-05-2021 08:11:14

bonjour

jpt a écrit :

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.

jpt · 28-05-2021 10:30:02

Bonjour,

hybridemoineau a écrit :

Tu as plusieurs disques.

Oui.

hybridemoineau a écrit :

Tu as un souci au démarrage, tu regardes les UUID, avec blkid par exemple.

Pas toujours, mais oui.

hybridemoineau a écrit :

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).

hybridemoineau a écrit :

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

raleur a écrit :

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) !

May 28 09:52:08 debox64 kernel: [    2.638042] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

May 28 09:52:08 debox64 kernel: [    2.638494] ata1.00: ATA-10: KINGSTON SA400S37240G, SBFKB1D2, max UDMA/133

May 28 09:52:08 debox64 kernel: [    2.639194] scsi 0:0:0:0: Direct-Access     ATA      KINGSTON SA400S3 B1D2 PQ: 0 ANSI: 5

May 28 09:52:08 debox64 kernel: [    2.639390] sd 0:0:0:0: Attached scsi generic sg0 type 0

May 28 09:52:08 debox64 kernel: [    2.639489] sd 0:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/224 GiB)

May 28 09:52:08 debox64 kernel: [    2.646476]  sda: sda1 sda2

May 28 09:52:08 debox64 kernel: [    2.647076] sd 0:0:0:0: [sda] Attached SCSI disk

May 28 09:52:08 debox64 kernel: [    3.110342] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

May 28 09:52:08 debox64 kernel: [    3.148306] ata2.00: ATA-10: ST2000DM008-2FR102, 0001, max UDMA/133

May 28 09:52:08 debox64 kernel: [    3.209909] scsi 1:0:0:0: Direct-Access     ATA      ST2000DM008-2FR1 0001 PQ: 0 ANSI: 5

May 28 09:52:08 debox64 kernel: [    3.210490] sd 1:0:0:0: Attached scsi generic sg1 type 0

May 28 09:52:08 debox64 kernel: [    3.210532] sd 1:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)

May 28 09:52:08 debox64 kernel: [    3.229108]  sdb: sdb1 sdb2

May 28 09:52:08 debox64 kernel: [    3.231853] sd 1:0:0:0: [sdb] Attached SCSI disk

May 28 09:52:08 debox64 kernel: [    3.678377] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

May 28 09:52:08 debox64 kernel: [    3.718938] ata5.00: ATA-10: ST2000DM008-2FR102, 0001, max UDMA/133

May 28 09:52:08 debox64 kernel: [    3.784909] scsi 4:0:0:0: Direct-Access     ATA      ST2000DM008-2FR1 0001 PQ: 0 ANSI: 5

May 28 09:52:08 debox64 kernel: [    3.786546] sd 4:0:0:0: Attached scsi generic sg2 type 0

May 28 09:52:08 debox64 kernel: [    3.786693] sd 4:0:0:0: [sdc] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)

May 28 09:52:08 debox64 kernel: [    3.815782]  sdc: sdc1 sdc2

May 28 09:52:08 debox64 kernel: [    3.818181] sd 4:0:0:0: [sdc] Attached SCSI disk

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…

Debian Alain a écrit :

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.

Debian Alain a écrit :

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,

Dernière modification par jpt (28-05-2021 10:31:41)

raleur · 28-05-2021 21:48:32

jpt a écrit :

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.

jpt a écrit :

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.

jpt a écrit :

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*.

Debian-facile

#51 20-05-2021 10:08:51

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

#52 26-05-2021 10:01:09

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

#53 26-05-2021 10:46:28

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

#54 26-05-2021 11:21:16

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

#55 26-05-2021 11:42:05

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

#56 26-05-2021 11:48:04

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

#57 26-05-2021 11:52:25

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

#58 26-05-2021 11:52:32

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

#59 26-05-2021 11:57:02

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

#60 26-05-2021 11:59:08

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

#61 26-05-2021 12:01:30

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

#62 26-05-2021 15:02:51

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

#63 26-05-2021 19:52:24

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

#64 26-05-2021 20:10:09

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

#65 26-05-2021 20:29:32

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

#66 26-05-2021 23:32:49

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

#67 27-05-2021 13:24:08

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

#68 27-05-2021 15:27:22

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

#69 27-05-2021 19:13:59

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

#70 27-05-2021 19:48:15

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

#71 27-05-2021 20:58:12

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

#72 27-05-2021 21:50:21

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

#73 28-05-2021 08:11:14

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

#74 28-05-2021 10:30:02

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

#75 28-05-2021 21:48:32

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

Pied de page des forums