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

raleur · 21-11-2020 14:55:41

Quel est le problème ?
Si c'est que ton SSD et tes disques ne sont pas présents dans la base de données de smartmontools, tu peux la mettre à jour au cas où ils auraient été inclus dans une version plus récente.

update-smart-drivedb

Si c'est que certains attributs ne sont pas supportés par le SSD, alors il doit être possible de configurer /etc/smartd.conf pour ne pas les demander.

Dernière modification par raleur (21-11-2020 14:59:22)

jpt · 21-11-2020 15:43:42

raleur a écrit :

Quel est le problème ?

Aujourd'hui aucun. Mais si un disque se mettait à développer un problème de lecture par exemple, et que les erreurs ne se reportent pas sur le bon à cause du fait qu'un disque n'est pas toujours celui qu'on pense et qui nous est signalé, je te laisse imaginer l'embrouille.

raleur · 21-11-2020 16:03:38

C'est pareil avec les messages du noyau. Si une anomalie concernant /dev/sda est rapportée, il faut regarder à quel disque physique cela correspond à ce moment.

jpt · 23-11-2020 11:54:58

Bonjour,

depuis le temps que je l'attendais, enfin je l'ai, au 4e reboot de ce matin :

1-ok pour sda1

/                                     /dev/sda1        ext4       rw,noatime

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

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

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

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

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

├─/var                                /dev/sdb2[/var]  ext4       rw,nosuid,nodev,relatime

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

2-ok

/                                     /dev/sda1        ext4       rw,noatime

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

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

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

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

├─/var                                /dev/sdb2[/var]  ext4       rw,nosuid,nodev,relatime

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

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

3-ok

/                                     /dev/sda1        ext4       rw,noatime

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

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

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

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

├─/var                                /dev/sdb2[/var]  ext4       rw,nosuid,nodev,relatime

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

└─/home                               /dev/sdb2[/home] ext4       rw,nosuid,nodev,relatime

4-kc !

/                                     /dev/sdb1        ext4       rw,noatime

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

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

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

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

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

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

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

Si vous comparez les première et deuxième colonnes, vous constatez qu'elles sont en non-concordance d'une sortie à l'autre. Le bon ordre (du fstab, qui s'appuie sur les uuid, qu'on nous a vantées comme plus robustes -- mais ce n'est pas le cas, la preuve...) devrait être :

/                                     /dev/sda1        ext4       rw,noatime

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

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

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

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

├─/var                                /dev/sdb2[/var]  ext4       rw,nosuid,nodev,relatime

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

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

Je vous laisse imaginer l'embrouille dans gparted, qui s'appuie sur les "/dev/...", tout comme lsblk ou blkid dont voilà la sortie :

/dev/sda1: LABEL="data" UUID="83452e91-8384-45c3-b2c7-4315904d03fa" TYPE="ext4" PARTUUID="ca7ed134-01"

/dev/sda2: LABEL="homerootvar" UUID="ca124013-9812-4eac-8e52-35560d5ac7f4" TYPE="ext4" PARTUUID="ca7ed134-02"

/dev/sdb1: LABEL="system" UUID="99dc8d6c-8674-4c7d-b27f-7cd860bdd63f" TYPE="ext4" PARTUUID="ec0402c2-01"

/dev/sdb2: UUID="272a029e-4d4a-40e2-a3b7-51bf1ac7b0d0" TYPE="swap" PARTUUID="ec0402c2-02"

/dev/sdc1: LABEL="backup" UUID="0e65ae8e-d816-4ffc-a210-e616717de2fe" TYPE="ext4" PARTUUID="edfce0d7-01"

/dev/sdc2: LABEL="reserved" UUID="99fc2adf-d339-4fcc-82fb-82f93db59f2a" TYPE="ext4" PARTUUID="edfce0d7-02"

quand elle devrait être :

/dev/sda1: LABEL="system" UUID="99dc8d6c-8674-4c7d-b27f-7cd860bdd63f" TYPE="ext4" PARTUUID="ec0402c2-01"

/dev/sda2: UUID="272a029e-4d4a-40e2-a3b7-51bf1ac7b0d0" TYPE="swap" PARTUUID="ec0402c2-02"

/dev/sdb1: LABEL="data" UUID="83452e91-8384-45c3-b2c7-4315904d03fa" TYPE="ext4" PARTUUID="ca7ed134-01"

/dev/sdb2: LABEL="homerootvar" UUID="ca124013-9812-4eac-8e52-35560d5ac7f4" TYPE="ext4" PARTUUID="ca7ed134-02"

/dev/sdc1: LABEL="backup" UUID="0e65ae8e-d816-4ffc-a210-e616717de2fe" TYPE="ext4" PARTUUID="edfce0d7-01"

/dev/sdc2: LABEL="reserved" UUID="99fc2adf-d339-4fcc-82fb-82f93db59f2a" TYPE="ext4" PARTUUID="edfce0d7-02"

En gros, il n'y a que le sdc qui soit toujours correct, .

Alors j'ai une piste (forcer une histoire de after/before dans le fstab, j'ai pas tout bien compris, faudra que je fasse des tests dans une machine virtuelle) mais j'ai une autre urgence ces jours-ci.
Alors comme la machine n'est toujours pas en prod' (cinq mois et demi qu'elle a été achetée...), qq jours de plus ou de moins n'y changeront rien.

Un dernier mot : pour avoir ce bel affichage, je me suis créé un alias msd='findmnt | grep sd | grep -v gvfsd | grep -v nsdelegate ' qui me facilite bien la vie,

Dernière modification par jpt (23-11-2020 11:58:34)

jpt · 04-03-2021 20:48:48

Bonsoir,

je réactive cette discussion, constatant que pas mal de gens ont des problèmes bizarres avec leurs disques, alors allez savoir s'il n'y aurait pas un rapport avec la blague dont on cause ici.

J'avais noté depuis novembre que ma piste

jpt a écrit :

Alors j'ai une piste (forcer une histoire de after/before dans le fstab, j'ai pas tout bien compris

avait foiré, parce que ce n'était pas clair du tout, alors je me suis acharné, j'ai lu des posts des discussions des tutos des trucs des machins, bref, la dernière machine virtuelle a l'air de tenir le choc pendant que la machine physique, toujours pas en prod', vient de me refaire le gag, au bout d'une dizaine de reboots sans accrocs.

Voilà quelques remarques, l'une est très intéressante car, bien que raleur explique (et il a raison et j'en apporte la preuve) que sda sdb sdc etc. c'est aléatoire, d'autres continuent, ici comme dans les man, à utiliser ces identifiants.
La bonne question c'est comment faire autrement s'il ne faut plus les utiliser ? Et là, silence radio sur les fréquences…

Bref, voilà ce que j'ai pu noter ce soir, après avoir découvert cette commande (source) ce matin

Croutons a écrit :

parted /dev/sdb print all free

$ parted /dev/sda print all free

Model: ATA ST2000DM008-2FR1 (scsi)

Disk /dev/sda: 2000GB            FAUX : c'est le premier disque de données, sdb  

Sector size (logical/physical): 512B/4096B

Partition Table: msdos

Disk Flags: 

Number  Start   End     Size    Type     File system  Flags

        32,3kB  1049kB  1016kB           Free Space

 1      1049kB  1791GB  1791GB  primary  ext4

 2      1791GB  2000GB  210GB   primary  ext4

        2000GB  2000GB  90,1kB           Free Space

Model: ATA ST2000DM008-2FR1 (scsi)

Disk /dev/sdb: 2000GB            FAUX : c'est le second disque de données, sdc

Sector size (logical/physical): 512B/4096B

Partition Table: msdos

Disk Flags: 

Number  Start   End     Size    Type     File system  Flags

 1      1049kB  1791GB  1791GB  primary  ext4

 2      1791GB  2000GB  210GB   primary  ext4

Model: ATA KINGSTON SA400S3 (scsi)

Disk /dev/sdc: 240GB             FAUX : c'est le disque système, sda

Sector size (logical/physical): 512B/512B

Partition Table: msdos

Disk Flags: 

Number  Start   End    Size    Type     File system     Flags

 1      1049kB  210GB  210GB   primary  ext4            boot

 2      210GB   240GB  30,3GB  primary  linux-swap(v1)

il y a longtemps j'ai noté | maintenant  | normalement

cat /sys/block/sda/size

               3907029168  | 3907029168  |  468862128

cat /sys/block/sdb/size

                468862128  | 3907029168  | 3907029168

cat /sys/block/sdc/size

               3907029168  |  468862128  | 3907029168

donc les erreurs sont aléatoires, cool…

Les erreurs vues par

df | grep sd :

Sys. de fichiers blocs de 1K   Utilisé Disponible Uti% Monté sur    COMMENTAIRES

/dev/sdc1          200536336  39705696  150574256  21% /            devrait être sda1

/dev/sda2          200537056   5213436  185067236   3% /data_small  devrait être sdb2

/dev/sda1         1720225688 252507868 1380265764  16% /data_large  devrait être sdb1

/dev/sdb1         1720225688 194562780 1438210852  12% /dbck_large  devrait être sdc1

/dev/sdb2          200537056  48677760  141602912  26% /dbck_small  devrait être sdc2

et par

lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT   DEVRAIT ÊTRE

sda      8:0    0   1,8T  0 disk 

├─sda1   8:1    0   1,6T  0 part /data_large  system

└─sda2   8:2    0 195,3G  0 part /data_small  (swap, donc pas de mountpoint)

sdb      8:16   0   1,8T  0 disk 

├─sdb1   8:17   0   1,6T  0 part /dbck_large  /data_large

└─sdb2   8:18   0 195,3G  0 part /dbck_small  /data_small

sdc      8:32   0 223,6G  0 disk 

├─sdc1   8:33   0 195,3G  0 part /            /dbck_large

└─sdc2   8:34   0  28,3G  0 part              /dbck_small

Un petit dernier pour la route :

findmnt | grep '/sd'            quand ça va mal | et quand ça va bien

/                                     /dev/sdc1 | /dev/sda1

├─/data_small                         /dev/sda2 | /dev/sdb2

├─/data_large                         /dev/sda1 | /dev/sdb1

├─/dbck_large                         /dev/sdb1 | /dev/sdc1

└─/dbck_small                         /dev/sdb2 | /dev/sdc2

Fait pour servir et valoir ce que de droit,

La suite quand la machine virtuelle aura fait des dizaines de reboots sans anicroches.

En attendant, méditez sur l'exemple suivant, qui permet de remettre le second disque à zéro :

dd if=/dev/zero bs=1M of=/dev/sdb

et que va-t-il se passer le jour où sdb sera le premier disque ? (source)

Dernière modification par jpt (21-04-2021 19:14:13)

jpt · 21-04-2021 19:11:20

Bonsoir,

le combat fut rude et laborieux, mais depuis deux semaines à peu près, la machine susceptible ne me change plus les noms des disques ou plutôt, j'ai toujours sda1 monté sur /, sdb1 sur /data et sdc1 sur /dbck, ce que je voulais.
La solution a consisté à écrire correctement deux fichiers data.mount et dbck.mount, à les mettre dans /etc/systemd/system, et à les activer, après avoir longuement étudié ce boxon de systemd.

Bien sûr tout ça a été auparavant longuement testé dans deux machines virtuelles (l'une sous Xfce, l'autre sous Lxde) avec un script qui se lançait à la fin du démarrage, attendait 5 secondes pour la sécurité et effectuait un test sur l'ordre des montages, si correct reboot et si pas correct arrêt du script et au bout d'environ 2000 reboots (sur plusieurs jours, avec arrêt machines la nuit), je n'ai jamais vu le script s'arrêter.

Donc je l'ai passé sur la machine de prod', qui a l'air de s'en porter bien, à tel point que je remplace ce [Réactivé] par un joli [Résolu], et hop !

En espérant ne plus avoir à y revenir.

raleur · 21-04-2021 19:44:18

jpt a écrit :

la machine susceptible ne me change plus les noms des disques ou plutôt, j'ai toujours sda1 monté sur /, sdb1 sur /data et sdc1 sur /dbck, ce que je voulais.
La solution a consisté à écrire correctement deux fichiers data.mount et dbck.mount, à les mettre dans /etc/systemd/system, et à les activer, après avoir longuement étudié ce boxon de systemd.

Sûrement pas. systemd n'a rien à voir dans le nommage des disques. Mais libre à toi de perdre ton temps à combattre les moulins...

jpt · 21-04-2021 23:54:07

raleur a écrit :

systemd n'a rien à voir dans le nommage des disques. Mais libre à toi de perdre ton temps à combattre les moulins...

Oui, j'ai écrit "disques" quand il est question de partitions, mettons ça sur le compte de la fatigue et de la lassitude.
Et je n'ai pas perdu mon temps, j'ai appris pendant ces recherches plein de choses sur la bestiole, tiens, regarde :

Cependant, par défaut, il semble que le systemd-fstab-generator ne tient pas compte de l’ordre dans lesquels les filesystems sont déclarés ce qui peut provoquer des problèmes d’ordonnancement des montages !
https://blog.zwindler.fr/2017/01/03/eme … e-systemd/

With the introduction of systemd in RHEL 7 the boot process has become a lot faster because many services and processes are now started in parallel.
One of those consequences is the lack of consistent order in which filesystems are mounted. Their order for mounting is no longer guaranteed based on the entries in /etc/fstab. Filesystems are now just another systemd unit. Because systemd defaults to parallel units execution process startup, specific target units startup order is not consistent.
https://www.golinuxcloud.com/mount-file … r-systemd/

With systemd being a parallelized system (part of why systemd-enabled systems boot faster that upstart-enabled or older init-type systems), you typically want to take extra care with your unit-files. Specifically, you'll want to make sure that your layered mounts' unit-files use appropriate dependency-directives — Requires and/or Before/After directives. Absent their use, you can end up in a situation where a lower-level mount happens after a higher-level mount (e.g., /opt/oracle/data mounts before /opt/oracle creating a situation where /opt/oracle effectively hides the content of /opt/oracle/data).
Wouldn't systemd provide an implicit dependencies in this case ?
Sort of. But only in as much as you get from alphabetical ordering. E.g., if you have the layered-mounts /var (var.mount), /var/log (var-log.mount), and /var/log/audit (var-log-audit.mount) systemd should initiate them a few msec apart and — in that order — simply because of the service-directory's scan-order. That said, you open yourself to unexpected results and race-conditions by not over-specifying the dependencies. Which is to say, 99.999% of the time, things will work as expected, but there can be times where they don't and then you'll be pulling your hair out wondering why.
https://dev.to/adarshkkumar/mount-a-vol … stemd-1h2f

Enfin quoi, je ne les ai pas inventées, ces notes :

il y a longtemps j'ai noté |un autre jour| la réalité

cat /sys/block/sda/size    |             |

               3907029168  | 3907029168  |  468862128

cat /sys/block/sdb/size    |             |

                468862128  | 3907029168  | 3907029168

cat /sys/block/sdc/size    |             |

               3907029168  |  468862128  | 3907029168

In fine, rendons à César ce qui lui appartient et à systemd les commentaires qu'il a suscités :

I hate systemd. Old good Debian 8.x was nice. Debian 10 and systemd. I may switch to FreeBSD.

1er commentaire de l'article https://www.cyberciti.biz/faq/how-to-en … ux-system/

This excellent question (and its answers) is an interesting example of how systemd violates the long-standing (and brilliant) design principles of Unix & Co... (most experienced users will just consider that complete bloat). I begin to see more clearly why Linus Torvalds is so vehemently critical of systemd.

https://askubuntu.com/questions/795226/ … -systemctl

Unfortunately, network-online.target is inconsistently implemented and otherwise unreliable. It's best not to rely on it.

https://superuser.com/questions/1538274 … il-success (avril 2020)

systemd is the best example of Suck.
There is a menace which is spreading like a disease throughout the Linux world, it is called systemd.

https://suckless.org/sucks/systemd/
et de la même page, tout en bas, juste pour passer une bonne nuit :

Practical systemd
Here is what happens on a stock Arch Linux system, powered by systemd, when a non-root user tries to restart the system:

 $ reboot

 Failed to set wall message, ignoring: The name org.freedesktop.PolicyKit1 was not provided by any .service files

 Failed to reboot system via logind: The name org.freedesktop.PolicyKit1 was not provided by any .service files

 Failed to talk to init daemon.

In contrast, here is the equivalent error message on a system powered by runit:

 $ reboot

 init: fatal: unable to create /etc/runit/stopit: access denied

And on the oldest and best, Slackware:

 $ reboot

 reboot: must be superuser.

systemd is driving "just google the problem" attitude, because how the hell are you expected to troubleshoot this kind of error otherwise?

On ne s'en lasse pas ! Dommage qu'il nous faille vivre avec ce machin, maintenant.

raleur · 24-04-2021 14:38:25

jpt a écrit :

Oui, j'ai écrit "disques" quand il est question de partitions

Peu importe puisque les noms de périphériques des partitions sont dérivés de ceux des disques. Partition n° 3 du disque sdb = sdb3.

jpt a écrit :

Cependant, par défaut, il semble que le systemd-fstab-generator ne tient pas compte de l’ordre dans lesquels les filesystems sont déclarés ce qui peut provoquer des problèmes d’ordonnancement des montages

Ça n'a strictement aucun rapport avec le nommage des disques et des partitions. Et il y a à boire et à manger dans les liens que tu cites. D'après la page de manuel de systemd.mount, systemd crée des dépendances automatiques entre les montages en fonction de leurs chemins ; par exemple, il monte /var avant /var/log. L'ordre de montage entre points de montage indépendants est sans importance. Le seul véritable problème que j'ai vu rapporté dans ces articles est l'absence de dépendance automatique des montages de type "bind", ce qui est quand même un cas assez particulier.

jpt a écrit :

Enfin quoi, je ne les ai pas inventées, ces notes :

Puisque tu reviens encore sur ton obsession du nommage non persistant des disques, je le répète aussi : c'est normal, prévu comme ça, on ne peut rien y faire et de toute façon cela ne gêne en rien une saine gestion des disques basée sur les identifiants persistants qui existent.

Dernière modification par raleur (24-04-2021 14:39:33)

jpt · 24-04-2021 16:11:55

raleur a écrit :

Puisque tu reviens encore sur ton obsession du nommage non persistant des disques, je le répète aussi : c'est normal, prévu comme ça, on ne peut rien y faire et de toute façon cela ne gêne en rien une saine gestion des disques basée sur les identifiants persistants qui existent.

Peut-être, peut-être, mais je ne me lasserai pas de répéter que tous les vieux bouquins et magazines des débuts de Linux ne causaient que comme ça (j'ai encore à côté de moi "Le système Linux" 3e édition chez O'Reilly qui confirme, et je te passe tous les Linux Mag', Login: et autres Misc…) et tu n'as rien dit à propos de ce que j'avais déjà écrit :

jpt a écrit :

En attendant, méditez sur l'exemple suivant, qui permet de remettre le second disque à zéro :
dd if=/dev/zero bs=1M of=/dev/sdb

et que va-t-il se passer le jour où sdb sera le premier disque ? (source)

Parce qu'avant de maîtriser un nommage qui n'évolue plus depuis quelques jours, j'ai parfois eu le cas de sdb attribué au "petit" disque, ce petit étant le ssd système qui boote et fait la suite. Tu vois la cata ?

raleur a écrit :

une saine gestion des disques basée sur les identifiants persistants qui existent.

Euh, à ce jour je n'ai jamais vu un post ou une réponse à une question qui s'appuie sur ces identifiants…

raleur · 24-04-2021 22:11:31

jpt a écrit :

tous les vieux bouquins et magazines des débuts de Linux ne causaient que comme ça

Les choses changent que tu le veuilles ou non, et il vaut mieux s'adapter plutôt que s'accrocher au passé.
Avant il n'y avait pas d'initrd/initramfs, les noyaux génériques devaient avoir tous les pilotes de supports de stockage (IDE, SCSI, RAID...) et de systèmes de fichiers courants en dur. Une fois chargé ça occupait de la mémoire pour rien. Avant il n'y avait pas udev et il fallait spécifier explicitement tous les modules à charger au démarrage. Avant il n'y avait pas GRUB mais LILO qui devait être réinstallé à chaque mise à jour du noyau ou de l'initramfs.

jpt a écrit :

que va-t-il se passer le jour où sdb sera le premier disque ?

Ça n'arrivera pas puisque par définition sdb est le second disque. Et si ta notion de premier ou second disque diffère de celle du noyau, demande-toi en quoi elle est plus légitime ou logique. C'est peut-être arbitraire, mais au moins c'est clair : le premier disque détecté est sda, le second est sdb, etc. Si ça ne te convient pas parce que c'est imprévisible, udev crée des liens symboliques dont les noms sont basés sur des identifiants prévisibles :
- modèle et numéro de série ou WWN dans /dev/disk/by-id/
- connexion physique dans /dev/disk/by-path/
- UUID ou labels dans /dev/disk/by-{,part}{uuid,label}/

Le paquet grub-pc mémorise le disque dans lequel il a installé le chargeur d'amorçage sous sa forme /dev/disk/by-id/* pour être sûr de le réinstaller sur le bon disque même si l'ordre change. On peut le voir avec

debconf-show grub-pc

jpt a écrit :

Parce qu'avant de maîtriser un nommage qui n'évolue plus depuis quelques jours, j'ai parfois eu le cas de sdb attribué au "petit" disque

Il n'y a aucune garantie que cela ne se reproduira pas. Au lieu de chercher à l'éviter, ce qui est voué à l'échec, tu ferais mieux de chercher comment en tenir compte pour ne pas en être affecté.

jpt · 25-04-2021 13:23:00

Bonjour,

raleur a écrit :

Les choses changent que tu le veuilles ou non, et il vaut mieux s'adapter plutôt que s'accrocher au passé.

Je veux bien m'adapter à ce qui est mieux, pour le reste, puisque c'était mieux avant, bref...

raleur a écrit :

Le paquet grub-pc mémorise le disque dans lequel il a installé le chargeur d'amorçage sous sa forme /dev/disk/by-id/* pour être sûr de le réinstaller sur le bon disque même si l'ordre change. On peut le voir avec
debconf-show grub-pc

Exact. Je peux récupérer la ligne :

* grub-pc/install_devices: /dev/disk/by-id/ata-KINGSTON_SA400S37240G_50026B7782FAC2F1

mais ça m'avance à quoi ?

raleur a écrit :

jpt a écrit :
que va-t-il se passer le jour où sdb sera le premier disque ?
Ça n'arrivera pas puisque par définition sdb est le second disque.

Ah ouais ! Ça n'arrivera pas ? Comme tu le dis si bien, le premier disque détecté est sda, le second est sdb, etc.
Alors tant que le premier disque détecté est le petit ssd, ça me va.
Mais il est arrivé des fois où le premier disque détecté a été l'un des deux mécaniques, et des fois le premier disque détecté a été l'autre mécanique. Et pour moi c'est monstrueux, inqualifiable et ingérable dans des outils comme parted, gparted, fdisk, sfdisk, etc.
Bon, depuis 15 jours ça n'arrive plus. Avant, ça pouvait être 2 ou 3 fois par jour…

Allez, tiens, une commande toute simple trouvée là (c'est pas vieux, c'est de mars 2021) : dd if=/dev/sda of=/dev/sdb

Copy the contents from the if= drive /dev/sda to the of= drive /dev/sdb.

Tu veux bien me l'écrire en mode secure, stp ?, genre dd if=premier_disk of=second_disk mais attention !, pas le premier_disk détecté puisque ça c'est aléatoire, non, celui que moi j'appelle le premier_disk, et ici pour moi c'est le petit (240 G) ssd.

Quelque chose m'a mis sur la piste, une piste poussiéreuse, mal entretenue, pleine d'ornières (on se croirait dans Les routes de l'impossible en Afrique à la saison des pluies, ), je veux parler de ls -lGg /dev/disk/by-<TAB> et là, on trouve

by-id

by-label

by-partuuid

by-path

by-uuid

dans une machine (le host physique) et dans une autre (une virtuelle) j'ai by-partlabel en plus. Dunno why.
Alors si on zappe le label puisque pas fiable, le partuuid parce qu'on va pas compliquer et le path parce que ça n'apporte rien, il reste by-uuid :

$ ls -lGg /dev/disk/by-uuid/

lrwxrwxrwx 1 10 avril 25 10:47 0e65ae8e-d816-4ffc-a210-e616717de2fe -> ../../sdc1

lrwxrwxrwx 1 10 avril 25 10:47 272a029e-4d4a-40e2-a3b7-51bf1ac7b0d0 -> ../../sda2

lrwxrwxrwx 1 10 avril 25 10:47 83452e91-8384-45c3-b2c7-4315904d03fa -> ../../sdb1

lrwxrwxrwx 1 10 avril 25 10:47 99dc8d6c-8674-4c7d-b27f-7cd860bdd63f -> ../../sda1

lrwxrwxrwx 1 10 avril 25 10:47 99fc2adf-d339-4fcc-82fb-82f93db59f2a -> ../../sdc2

lrwxrwxrwx 1 10 avril 25 10:47 ca124013-9812-4eac-8e52-35560d5ac7f4 -> ../../sdb2

et à moins de se faire un tableau des uuid's (puisque les sdXY sont fluctuants) pour savoir qui est qui, c'est limite inexploitable et il ne reste plus qu'une option :

$ ls -lGg /dev/disk/by-id

lrwxrwxrwx 1  9 avril 25 10:47 ata-KINGSTON_SA400S37240G_50026B7782FAC2F1 -> ../../sda

lrwxrwxrwx 1 10 avril 25 10:47 ata-KINGSTON_SA400S37240G_50026B7782FAC2F1-part1 -> ../../sda1

lrwxrwxrwx 1 10 avril 25 10:47 ata-KINGSTON_SA400S37240G_50026B7782FAC2F1-part2 -> ../../sda2

lrwxrwxrwx 1  9 avril 25 10:47 ata-ST2000DM008-2FR102_WFL1V0FK -> ../../sdb

lrwxrwxrwx 1 10 avril 25 10:47 ata-ST2000DM008-2FR102_WFL1V0FK-part1 -> ../../sdb1

lrwxrwxrwx 1 10 avril 25 10:47 ata-ST2000DM008-2FR102_WFL1V0FK-part2 -> ../../sdb2

lrwxrwxrwx 1  9 avril 25 10:47 ata-ST2000DM008-2FR102_WFL39CN5 -> ../../sdc

lrwxrwxrwx 1 10 avril 25 10:47 ata-ST2000DM008-2FR102_WFL39CN5-part1 -> ../../sdc1

lrwxrwxrwx 1 10 avril 25 10:47 ata-ST2000DM008-2FR102_WFL39CN5-part2 -> ../../sdc2

lrwxrwxrwx 1  9 avril 25 10:47 wwn-0x5000c500bf340508 -> ../../sdb

lrwxrwxrwx 1 10 avril 25 10:47 wwn-0x5000c500bf340508-part1 -> ../../sdb1

lrwxrwxrwx 1 10 avril 25 10:47 wwn-0x5000c500bf340508-part2 -> ../../sdb2

lrwxrwxrwx 1  9 avril 25 10:47 wwn-0x5000c500ccaf2625 -> ../../sdc

lrwxrwxrwx 1 10 avril 25 10:47 wwn-0x5000c500ccaf2625-part1 -> ../../sdc1

lrwxrwxrwx 1 10 avril 25 10:47 wwn-0x5000c500ccaf2625-part2 -> ../../sdc2

lrwxrwxrwx 1  9 avril 25 10:47 wwn-0x50026b7782fac2f1 -> ../../sda

lrwxrwxrwx 1 10 avril 25 10:47 wwn-0x50026b7782fac2f1-part1 -> ../../sda1

lrwxrwxrwx 1 10 avril 25 10:47 wwn-0x50026b7782fac2f1-part2 -> ../../sda2

sauf que là je ne sais pas du tout pourquoi les premières lignes (j'ai viré celle du cdrom) ata-gnagnagna, très intéressantes car human-readables, sont dupliquées dessous en mode wwn-0x500blabla dont je ne sais pas ce que ça signifie et qui ne me serviront à rien.
Dommage, ça brouille la lecture, et aussi, ça n'existe pas dans la machine virtuelle :

$ ls -lGg /dev/disk/by-id/

lrwxrwxrwx 1  9 avril 25 11:44 ata-VBOX_CD-ROM_VB2-01700376 -> ../../sr0

lrwxrwxrwx 1  9 avril 25 11:44 ata-VBOX_HARDDISK_VB67341020-13ed8236 -> ../../sdc

lrwxrwxrwx 1 10 avril 25 11:44 ata-VBOX_HARDDISK_VB67341020-13ed8236-part1 -> ../../sdc1

lrwxrwxrwx 1  9 avril 25 11:44 ata-VBOX_HARDDISK_VB83396e7b-03edc414 -> ../../sda

lrwxrwxrwx 1 10 avril 25 11:44 ata-VBOX_HARDDISK_VB83396e7b-03edc414-part1 -> ../../sda1

lrwxrwxrwx 1  9 avril 25 11:44 ata-VBOX_HARDDISK_VB9c16ba32-f4252648 -> ../../sdb

lrwxrwxrwx 1 10 avril 25 11:44 ata-VBOX_HARDDISK_VB9c16ba32-f4252648-part1 -> ../../sdb1

lrwxrwxrwx 1 10 avril 25 11:44 ata-VBOX_HARDDISK_VB9c16ba32-f4252648-part2 -> ../../sdb2

Alors quoi ? Parce que cette sortie devrait être facilement parsable à coups de awk.
Bah,

$ ls -lGg /dev/disk/by-id/ | grep ata

lrwxrwxrwx 1  9 avril 25 10:47 ata-HL-DT-ST_DVDRAM_GH24NSD5_KMIJBEM3806 -> ../../sr0

lrwxrwxrwx 1  9 avril 25 10:47 ata-KINGSTON_SA400S37240G_50026B7782FAC2F1 -> ../../sda

lrwxrwxrwx 1 10 avril 25 10:47 ata-KINGSTON_SA400S37240G_50026B7782FAC2F1-part1 -> ../../sda1

lrwxrwxrwx 1 10 avril 25 10:47 ata-KINGSTON_SA400S37240G_50026B7782FAC2F1-part2 -> ../../sda2

lrwxrwxrwx 1  9 avril 25 10:47 ata-ST2000DM008-2FR102_WFL1V0FK -> ../../sdb

lrwxrwxrwx 1 10 avril 25 10:47 ata-ST2000DM008-2FR102_WFL1V0FK-part1 -> ../../sdb1

lrwxrwxrwx 1 10 avril 25 10:47 ata-ST2000DM008-2FR102_WFL1V0FK-part2 -> ../../sdb2

lrwxrwxrwx 1  9 avril 25 10:47 ata-ST2000DM008-2FR102_WFL39CN5 -> ../../sdc

lrwxrwxrwx 1 10 avril 25 10:47 ata-ST2000DM008-2FR102_WFL39CN5-part1 -> ../../sdc1

lrwxrwxrwx 1 10 avril 25 10:47 ata-ST2000DM008-2FR102_WFL39CN5-part2 -> ../../sdc2

On y voit plus clair,

Allez, la bonne nouvelle c'est que dd if=/dev/disk/by-id/<TAB> fonctionne, la mauvaise c'est que ça fonctionne MAL !

$ dd if=/dev/disk/by-id/ata-VBOX_<TAB> 

ata-VBOX_CD-ROM_VB2-01700376                 ata-VBOX_HARDDISK_VB83396e7b-03edc414-part1

ata-VBOX_HARDDISK_VB67341020-13ed8236        ata-VBOX_HARDDISK_VB9c16ba32-f4252648

ata-VBOX_HARDDISK_VB67341020-13ed8236-part1  ata-VBOX_HARDDISK_VB9c16ba32-f4252648-part1

ata-VBOX_HARDDISK_VB83396e7b-03edc414        ata-VBOX_HARDDISK_VB9c16ba32-f4252648-part2

Le décodage de ci-dessus montre que la deuxième ligne = sdb, la troisième = sdb1 et la dernière sdb2 mais alors, où sont passées les 4 lignes qui concernent sda et sdc ?
Totalement inutilisable, ça !
Par contre, en forçant à la mano, on peut y arriver :

$ dd if=/dev/disk/by-id/ata-VBOX_<TAB>

ata-VBOX_CD-ROM_VB2-01700376                 ata-VBOX_HARDDISK_VB83396e7b-03edc414-part1

ata-VBOX_HARDDISK_VB67341020-13ed8236        ata-VBOX_HARDDISK_VB9c16ba32-f4252648

ata-VBOX_HARDDISK_VB67341020-13ed8236-part1  ata-VBOX_HARDDISK_VB9c16ba32-f4252648-part1

ata-VBOX_HARDDISK_VB83396e7b-03edc414        ata-VBOX_HARDDISK_VB9c16ba32-f4252648-part2

<saisie du "H" -> la complétion complète puis TAB>

$ dd if=/dev/disk/by-id/ata-VBOX_HARDDISK_VB

ata-VBOX_HARDDISK_VB67341020-13ed8236        ata-VBOX_HARDDISK_VB9c16ba32-f4252648

ata-VBOX_HARDDISK_VB67341020-13ed8236-part1  ata-VBOX_HARDDISK_VB9c16ba32-f4252648-part1

ata-VBOX_HARDDISK_VB83396e7b-03edc414        ata-VBOX_HARDDISK_VB9c16ba32-f4252648-part2

ata-VBOX_HARDDISK_VB83396e7b-03edc414-part1___zap_de_la_suite-de-la-ligne,_non_mais_allô_quoi_!______

<saisie du "6" (qui n'était pas proposé, faut avoir fait une liste avant et la suivre) -> la complétion complète encore puis TAB>  

$ dd if=/dev/disk/by-id/ata-VBOX_HARDDISK_VB67341020-13ed8236<TAB>

ata-VBOX_HARDDISK_VB67341020-13ed8236        ata-VBOX_HARDDISK_VB67341020-13ed8236-part1

2 propositions valides, ok.

Donc à part utiliser le parsing de la sortie "by-id" dans un tableau à garder sous la main pour utiliser dd avec les sdXY, je ne vois pas trop comment faire autrement et simplement.
On a connu plus agréable.
Et j'attends toujours de savoir comment les grands gourous font (je ne vois rien sur le web)...

Noté pour mémoire : un truc sympa, mais uniquement utilisable par copier/coller ou pour des scripts :

$ ls -lGg /dev/disk/by-uuid/ | grep sd | awk '{print $7,$9}'

3fbe3b06-8529-4d67-8280-48bfa2f732e7 ../../sdb2

c7ec8ec7-b8f9-4a63-9126-50d9495193ee ../../sdc1

e1b0e8eb-1020-41c0-9076-3cf0c768dced ../../sdb1

ec18b072-2cae-494a-a1da-d1abc8d7cd7f ../../sda1

Bon dimanche,

Dernière modification par jpt (25-04-2021 13:29:13)

raleur · 25-04-2021 16:07:25

jpt a écrit :

mais ça m'avance à quoi ?

C'est un exemple concret de ce qu'on peut utiliser pour identifier un disque de façon fiable.

jpt a écrit :

je veux parler de ls -lGg /dev/disk/by-<TAB>

C'est précisément ce dont je parlais dans mon message précédent.

jpt a écrit :

dans une machine (le host physique) et dans une autre (une virtuelle) j'ai by-partlabel en plus. Dunno why.

Je suppose que /dev/disk/by-partlabel n'est créé que si un partlabel est défini pour au moins une partition. Cf. blkid. Le format de table de partition DOS/MBR ne supporte pas les partlabels.

jpt a écrit :

Alors si on zappe le label puisque pas fiable, le partuuid parce qu'on va pas compliquer et le path parce que ça n'apporte rien

Je n'ai pas dit que les labels n'étaient pas fiables mais que leur unicité était moindre que celle des UUID, à moins de les choisir très soigneusement (mais la lisibilité va à l'encontre de l'unicité). De toute façon un disque entier partitionné n'a ni label ni UUID (sauf cas particulier de format non standard comme les images ISO-hybrides). Il a un PTUUID (identifiant contenu dans la table de partition) mais cet attribut n'est pas utilisé par udev pour créer un lien dans /dev/disk. Un disque entier non partitionné peut avoir un UUID ou un label. Mais les labels, UUID et PTUUID sont des identifiants du contenu et non du contenant, et sont effacés ou modifiés si on efface, repartitionne ou formate le disque.

Quant au PARTUUID, il n'est défini que pour une partition, pas un disque entier.

Pourquoi dis-tu que le path n'apporte rien ? Il peut servir à identifier le disque qui est connecté à tel port de tel contrôleur, indépendamment de son modèle.

jpt a écrit :

je ne sais pas du tout pourquoi les premières lignes (j'ai viré celle du cdrom) ata-gnagnagna, très intéressantes car human-readables, sont dupliquées dessous en mode wwn-0x500blabla dont je ne sais pas ce que ça signifie

Les liens "ata-*" sont basés sur le modèle et le numéro de série du disque. Les liens "wwn-*" sont basés sur le WWN (world wide name), un identifiant unique défini par le constructeur sur le même principe que l'adresse MAC des interfaces réseau.
Je suppose que tu as compris que les liens qui finissent en "-part*" pointent vers les partitions.

jpt a écrit :

Dommage, ça brouille la lecture, et aussi, ça n'existe pas dans la machine virtuelle

Tu n'es pas obligé de les utiliser. Les liens wwn ne sont créés que pour les disques qui ont un WWN. Apparemment tes disques virtuels n'en ont pas.

jpt a écrit :

Le décodage de ci-dessus montre que la deuxième ligne = sdb, la troisième = sdb1 et la dernière sdb2 mais alors, où sont passées les 4 lignes qui concernent sda et sdc ?

Regarde mieux, il y a 4 lignes et deux colonnes, soit 8 liens en tout. Le compte est bon.

Si tu trouves que ces liens ne sont pas assez pratiques, tu peux en créer avec des règles udev, par exemple /dev/ssd (et surtout pas /dev/sdd !) qui pointerait toujours sur le SSD identifié par son modèle+numéro de série ou son WWN.

Dernière modification par raleur (25-04-2021 18:48:13)

jpt · 25-04-2021 18:38:47

raleur a écrit :

jpt a écrit :
Le décodage de ci-dessus montre que la deuxième ligne = sdb, la troisième = sdb1 et la dernière sdb2 mais alors, où sont passées les 4 lignes qui concernent sda et sdc ?
Regarde mieux, il y a 4 lignes et deux colonnes, soit 8 liens en tout. Le compte est bon.

Deux colonnes, ah b0rd3l ! À force d'avoir le nez sur le guidon j'ai raté les paysages,

raleur a écrit :

Si tu trouves que ces liens ne sont pas assez pratiques, tu peux en créer avec des règles udev, par exemple /dev/sdd qui pointerait toujours sur le SSD identifié par son modèle+numéro de série ou son WWN.

Ne compliquons pas les choses, j'ai la tête qui va exploser, ce soir !

Merci à toi, pour les wwn (première fois que j'entendais parler de ça -- faut dire aussi qu'avec l'ancienne machine j'ai vécu 8 ans dans la peau d'un user et pas du tout dans celle d'un sysadmin), et pour le reste.
Je vais m'en dépatouiller à partir de là et des disk/by-id.

raleur · 25-04-2021 18:54:39

A minima, tu peux te faire un petit script qui identifie les disques, à lancer avant de préparer une commande qui va écrire sur un disque, par exemple :

echo SSD = $(realpath /dev/disk/by-id/ata-KINGSTON_SA400S37240G_50026B7782FAC2F1)

echo HD1 = $(realpath /dev/disk/by-id/ata-ST2000DM008-2FR102_WFL1V0FK)

echo HD2 = $(realpath /dev/disk/by-id/ata-ST2000DM008-2FR102_WFL39CN5)

Dernière modification par raleur (25-04-2021 18:55:03)

jpt · 25-04-2021 20:01:57

Ah ben vi, et v'là encore un outil, realpath, dont j'ignorais l'existence !

Mais il doit correspondre à un besoin, je vois Copyright © 2018 dans son man.

Encore merci pour cette petite chose fort sympathique.

Dernière modification par jpt (25-04-2021 20:02:41)

jpt · 26-04-2021 11:50:30

Bonjour,

Cadeau (c'est la même chose que realpath mais en Bash, comme ça on peut mettre les mains dedans pour comprendre ce que ça fait, et j'ai laissé mes commentaires) :

#!/bin/bash

#echo "test"$IFS"test" # donne 'test test' donc l'ifs c'est l'espace.

# 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'

#liste=$(ls -lGg /dev/disk/by-id)

# grep's pour n'avoir que les ata (j'ai aussi scsi et wwn) et supprimer le cdrom

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

for ligne in ${liste[@]}

do 

  #echo $ligne

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

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

# man awk -- substr(s,i,n)  substr(s,i)

# Returns substring of s starting at i, of length n. If n is omitted, returns suffix of s starting at i.

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

  echo $name $sdxx

done

IFS=$OLDIFS

Et voilà ce que ça donne dans la vieille machine (2 disques) :

$ ident-disks.sh 

ata-SAMSUNG_HD103SJ_S27EJ9BZ300246 sda

ata-SAMSUNG_HD103SJ_S27EJ9BZ300246-part1 sda1

ata-SAMSUNG_HD103SJ_S27EJ9BZ300246-part2 sda2

ata-SAMSUNG_HD103SJ_S27EJ9BZ300246-part3 sda3

ata-SAMSUNG_HD103SJ_S27EJ9BZ300246-part4 sda4

ata-ST31000528AS_9VPA4LYV sdb

ata-ST31000528AS_9VPA4LYV-part1 sdb1

ata-ST31000528AS_9VPA4LYV-part2 sdb2

Enjoy,

raleur · 26-04-2021 13:13:36

Si le but est d'afficher le modèle et numéro de série de chaque disque, il y a plus simple et lisible :

lsblk -o name,type,size,model,serial -d

Mébon, ce n'est utile que si les disques sont de modèles différents, ou qu'on connaît leurs numéros de série par coeur.

jpt · 26-04-2021 13:31:38

raleur a écrit :

Mébon, ce n'est utile que si les disques sont de modèles différents,

ce qui est le cas dans la vieille machine, mais qui dit vieille machine gagne

lsblk: colonne inconnue : serial

et du coup

# lsblk -o name,type,size,model -d

NAME TYPE   SIZE MODEL

sda  disk 931,5G SAMSUNG HD103SJ 

sdb  disk 931,5G ST31000528AS    

sr0  rom   1024M CDDVDW TS-H653Z 

# lsblk -o name,type,size,model

NAME   TYPE   SIZE MODEL

sda    disk 931,5G SAMSUNG HD103SJ 

├─sda1 part   9,3G 

├─sda2 part  83,8G 

├─sda3 part   9,3G 

└─sda4 part 829,1G 

sdb    disk 931,5G ST31000528AS    

├─sdb1 part 821,2G 

└─sdb2 part 110,4G 

sr0    rom   1024M CDDVDW TS-H653Z

Bah,

raleur a écrit :

ou qu'on connaît leurs numéros de série par cœur.

jpt · 19-05-2021 10:07:41

Bonjour,

(suite de là-bas)
et ce matin, à la fraîche, tout est rentré dans l'ordre :

        hier soir                                 | ce matin, la même commande, copiée/collée du forum

$ df -h | grep /dev/sd | sort                     |

/dev/sda1          1,7T    269G  1,3T  18% /data  |/dev/sda1          192G     39G  143G  22% / 

/dev/sdb1          1,7T    217G  1,4T  14% /dbck  |/dev/sdb1          1,7T    269G  1,3T  18% /data

/dev/sdc1          192G     39G  143G  22% /      |/dev/sdc1          1,7T    217G  1,4T  14% /dbck

Accordez-moi qu'avec ce comportement, on marche sur la tête.

Alors d'accord, tant qu'on travaille avec les points de montage, ça ne devrait pas avoir d'incidence.
Mais l'histoire ne sera pas la même avec tous les outils qui travaillent avec /dev/sdXY où il risque d'y avoir du sport et des déconvenues.
Exemple avec man swapon, extrait de la Debian 10.7 :

swapon -o pri=1,discard=pages,nofail /dev/sda2

avec man sfdisk

flock /dev/sdc sfdisk /dev/sdc

man partx (que je découvre ce jour) :

partx --show - /dev/sdb3

       Lists all subpartitions on /dev/sdb3 (the device is used as whole-disk).

partx -o START -g --nr 5 /dev/sdb

       Prints the start sector of partition 5 on /dev/sdb without header.

partx -o SECTORS,SIZE /dev/sda5 /dev/sda

       Lists the length in sectors and human-readable size of partition 5 on /dev/sda

Maintenant, cet outil n'est peut-être pas très fiable, ou c'est moi qui commence à ne plus avoir confiance en rien : en m'inspirant de la première commande indiquée ci-dessus, je fais

$ partx --show - /dev/sda2

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

Allons bon ! mais c'est la partoche de swap, alors je tente

$ partx --show - /dev/sda1

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

Pas mieux, et pourtant

$ partx --show - /dev/sda

NR     START       END   SECTORS   SIZE NAME UUID

 1      2048 409602047 409600000 195,3G      ec0402c2-01

 2 409602048 468857024  59254977  28,3G      ec0402c2-02

C'est cet outil qui foire ou quoi ? Autre disque, même déconvenue :

$ partx --show - /dev/sdb1

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

$ partx --show - /dev/sdb

NR      START        END    SECTORS   SIZE NAME UUID

 1       2048 3497428991 3497426944   1,6T      ca7ed134-01

 2 3497428992 3907028991  409600000 195,3G      ca7ed134-02

C'est lassant.
Et cet abruti de ggl qui, sur recherche de bug partx, me remonte des pages de bug party ! En rajoutant linux devant la string, c'est mieux et ça fait peur : cet outil (partx) n'a pas l'air bien fiable, je vous laisse faire vos propres recherches.
En ce qui me concerne, je ne sais plus ce que je dois faire.

Analyser les logs ?
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)

Tout découle d'un sac de nœuds entre 3.86 et 4.36, or tout ce qui s'y trouve c'est trois bricoles ACPI et la prise en compte du dvd (sur scsi 5:0:0:0, ça ne devrait pas concerner les trois disques) :

...

May 18 22:43:58 kernel: [    3.867293] scsi 4:0:0:0: Direct-Access     ATA      ST2000DM008-2FR1 0001 PQ: 0 ANSI: 5

May 18 22:43:58 kernel: [    4.118604] ACPI: Invalid passive threshold

May 18 22:43:58 kernel: [    4.119665] thermal LNXTHERM:00: registered as thermal_zone0

May 18 22:43:58 kernel: [    4.120480] ACPI: Thermal Zone [TZ10] (17 C)

May 18 22:43:58 kernel: [    4.333424] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

May 18 22:43:58 kernel: [    4.336875] ata6.00: ATAPI: HL-DT-ST DVDRAM GH24NSD5, LV00, max UDMA/133

May 18 22:43:58 kernel: [    4.339677] ata6.00: configured for UDMA/133

May 18 22:43:58 kernel: [    4.344541] scsi 5:0:0:0: CD-ROM            HL-DT-ST DVDRAM GH24NSD5  LV00 PQ: 0 ANSI: 5

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)

...

kern.log contient les mêmes lignes, debug ne contient rien d'intéressant et syslog n'a pas l'air bien complet.

Si quelqu'un a une idée…

Dernière modification par jpt (19-05-2021 10:11:05)

raleur · 19-05-2021 20:09:15

jpt a écrit :

l'histoire ne sera pas la même avec tous les outils qui travaillent avec /dev/sdXY

Quand tu veux utiliser un tel outil sur une clé ou un disque USB, tu as pris l'habitude de vérifier le nom de périphérique /dev/sd* correspondant parce que tu sais qu'il est variable, n'est-ce pas ? Et bien il faut faire de même avec tous les disques "SCSI" (PATA, SATA, USB...).

jpt a écrit :

C'est cet outil qui foire ou quoi ?

Non, j'ai l'impression que c'est toi qui n'as pas compris ce que partx fait. Si tu lui demandes de chercher une table de partition dans une partition normale, il y a de grandes chances qu'il n'en trouve pas. Si tu lui demandes de chercher une table de partition dans un disque partitionné, il va en trouver une. C'est comme fdisk et ses amis.

jpt a écrit :

et ça, une demi-seconde plus tard, c'est pas bon

Quand finiras-tu par admettre qu'il n'y a pas de nommage "bon" ou "pas bon" mais différents nommages qui dépendent de l'ordre de détection variable et qu'il faut prendre en compte, que tu le veuilles ou non ?

jpt · 19-05-2021 23:15:55

Merci de tes retours.
Cependant,

raleur a écrit :

Non, j'ai l'impression que c'est toi qui n'as pas compris ce que partx fait.

là, je me suis contenté d'appliquer une commande trouvée dans le man de l'outil.

raleur a écrit :

Quand finiras-tu par admettre qu'il n'y a pas de nommage "bon" ou "pas bon" mais différents nommages qui dépendent de l'ordre de détection variable et qu'il faut prendre en compte, que tu le veuilles ou non ?

J'ai du mal, j'ai énormément de mal à admettre qu'un disque détecté comme le premier dans une liste va devenir le dernier une demi-seconde plus tard dans une autre liste.
Je ne m'y ferai jamais.

raleur · 19-05-2021 23:55:45

jpt a écrit :

je me suis contenté d'appliquer une commande trouvée dans le man de l'outil.

Mais as-tu compris ce qu'elle fait ? Sinon il est normal que tu ne comprennes pas son résultat.

jpt · 20-05-2021 09:14:08

Bonjour,

raleur a écrit :

Mais as-tu compris ce qu'elle fait ?

Qu'est-ce qu'il y a à comprendre de plus que ce que dit le man ? D'une vieille version (vieille machine) :

EXAMPLES
partx --show /dev/sdb3

partx --show --nr 3 /dev/sdb

partx --show /dev/sdb3 /dev/sdb
All three commands list partition 3 of /dev/sdb.

et donc j'ai repris la 1re commande et ai remplacé b3 par a2, j'ai le droit ? Je pense que oui, et je m'attendais à voir les infos de la partition 2 de /dev/sda, au lieu du message d'erreur.

En fait, en comparant les 2 man (vieille machine vs nouvelle), c'est le petit tiret du 6 après --show qui fait la différence :
Vieille machine :

# partx --show /dev/sda2

NR    START       END   SECTORS  SIZE NAME UUID

 2 19535040 195318269 175783230 83,8G      

# partx --show /dev/sda1

NR START      END  SECTORS SIZE NAME UUID

 1    63 19535039 19534977 9,3G      

# partx --show /dev/sda

NR     START        END    SECTORS   SIZE NAME UUID

 1        63   19535039   19534977   9,3G      

 2  19535040  195318269  175783230  83,8G      

 3 195318270  214857727   19539458   9,3G      

 4 214857728 1953523711 1738665984 829,1G      

# partx --show - /dev/sda2

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

# partx --show - /dev/sda1

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

# partx --show - /dev/sda

NR     START        END    SECTORS   SIZE NAME UUID

 1        63   19535039   19534977   9,3G      

 2  19535040  195318269  175783230  83,8G      

 3 195318270  214857727   19539458   9,3G      

 4 214857728 1953523711 1738665984 829,1G

Conclusion : le man a été mis à moitié à jour.

(et si j'ai pris cet exemple, c'était juste pour montrer que les outils "bas niveau" travaillent avec les identifiants sdXY et qu'il est donc impensable pour moi que les informations y afférentes fluctuent)

PS : je viens de démarrer la nouvelle machine, pas de bol elle est tombée en marche. Donc sans le tiret du 6, elle fonctionne correctement :

$ partx --show /dev/sda2

NR     START       END  SECTORS  SIZE NAME UUID

 2 409602048 468857024 59254977 28,3G      ec0402c2-02

$ partx --show /dev/sda1

NR START       END   SECTORS   SIZE NAME UUID

 1  2048 409602047 409600000 195,3G      ec0402c2-01

$ partx --show /dev/sda

NR     START       END   SECTORS   SIZE NAME UUID

 1      2048 409602047 409600000 195,3G      ec0402c2-01

 2 409602048 468857024  59254977  28,3G      ec0402c2-02

Conclusion de la conclusion : même les man's ne sont plus aussi fiables qu'avant -- ne pas s'étonner que tout parte en sucette, alors…

Dernière modification par jpt (20-05-2021 09:15:46)

Tawal · 20-05-2021 09:43:27

Hello,
Tiré du man de partx :

Pour forcer l'analyse d'une partition  comme  s'il  s'agissait  d'un

disque entier (par exemple pour afficher les sous-partitions imbriquées), utilisez l'argument - (tiret). Par exemple :

            partx --show - /dev/sda3

Je crois que c'est assez clair.

Dernière modification par Tawal (20-05-2021 09:45:03)

Debian-facile

#26 21-11-2020 14:55:41

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

#27 21-11-2020 15:43:42

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

#28 21-11-2020 16:03:38

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

#29 23-11-2020 11:54:58

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

#30 04-03-2021 20:48:48

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

#31 21-04-2021 19:11:20

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

#32 21-04-2021 19:44:18

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

#33 21-04-2021 23:54:07

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

#34 24-04-2021 14:38:25

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

#35 24-04-2021 16:11:55

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

#36 24-04-2021 22:11:31

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

#37 25-04-2021 13:23:00

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

#38 25-04-2021 16:07:25

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

#39 25-04-2021 18:38:47

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

#40 25-04-2021 18:54:39

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

#41 25-04-2021 20:01:57

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

#42 26-04-2021 11:50:30

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

#43 26-04-2021 13:13:36

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

#44 26-04-2021 13:31:38

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

#45 19-05-2021 10:07:41

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

#46 19-05-2021 20:09:15

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

#47 19-05-2021 23:15:55

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

#48 19-05-2021 23:55:45

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

#49 20-05-2021 09:14:08

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

#50 20-05-2021 09:43:27

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

Pied de page des forums