Debian-facile
Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#26 21-11-2020 13:55:41
- raleur
- Membre
- Inscription : 03-10-2014
Re : [Réactivé] Ordre aléatoire de reconnaissance des disques au démarrage
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.
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 13:59:22)
Il vaut mieux montrer que raconter.
En ligne
#27 21-11-2020 14:43:42
- jpt
- Membre
- Distrib. : Debian 10.8
- Noyau : Linux 5.7.10 (backports)
- (G)UI : LXDE
- Inscription : 12-09-2020
Re : [Réactivé] Ordre aléatoire de reconnaissance des disques au démarrage
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.
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
#28 21-11-2020 15:03:38
- raleur
- Membre
- Inscription : 03-10-2014
Re : [Réactivé] Ordre aléatoire de reconnaissance des disques au démarrage
Il vaut mieux montrer que raconter.
En ligne
#29 23-11-2020 10:54:58
- jpt
- Membre
- Distrib. : Debian 10.8
- Noyau : Linux 5.7.10 (backports)
- (G)UI : LXDE
- Inscription : 12-09-2020
Re : [Réactivé] Ordre aléatoire de reconnaissance des disques au démarrage
depuis le temps que je l'attendais, enfin je l'ai, au 4e reboot de ce matin :
/ /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 :
├─/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/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/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 10:58:34)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
#30 04-03-2021 19:48:48
- jpt
- Membre
- Distrib. : Debian 10.8
- Noyau : Linux 5.7.10 (backports)
- (G)UI : LXDE
- Inscription : 12-09-2020
Re : [Réactivé] Ordre aléatoire de reconnaissance des disques au démarrage
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
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
parted /dev/sdb 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)
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
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
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 :
/ /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 :
et que va-t-il se passer le jour où sdb sera le premier disque ? (source)
Dernière modification par jpt (04-03-2021 20:03:53)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne