Disque sans méta-données

Le
Yliur
Bonjour

Après redémarrage, un de mes disques n'est plus monté automatiquement
(ce qui fait plus ou moins échouer le démarrage en demandant une
intervention manuelle). Le disque ne contient pas le système et je l'ai
supprimé de fstab, le reste fonctionne sans lui.

Après inspection le disque n'apparaît plus sous son uuid
dans /dev/disk/by-uuid/. Il semble qu'il y en ait un autre qui
corresponde mais avec un uuid différent.

J'arrive à monter le disque manuellement avec
mount /dev/sdd1 /mnt/truc -t ext4

Si je ne précise pas le type du système de fichiers j'ai ce message
d'erreur :
mount: /dev/sdd1 : plus de systèmes de fichiers ont été trouvés.
Ce n'est pas censé arriver, utilisez -t <type> pour
indiquer explicitement le type de système de fichiers
ou utilisez wipefs(8) pour nettoyer le périphérique.

J'ai deux disques de données très similaires, pour le premier blkid
donne ça :
/dev/sdc1: UUID="d401716c-deb2-4ba4-9c76-2944d1e78d4b" TYPE="ext4"
PARTUUID="2544c6b2-7dd9-4abc-9960-039fcf6d7252"

Et pour le second, celui qui ne marche pas, blkid n'affiche rien du
tout (retour à l'invite de commande, rien d'affiché ; j'ai bien tapé le
bon chemin).

On dirait que certaines méta-données du disque ont été perdues. fsck ne
pense pas que quelque chose va mal sur ce disque, mais je pense que le
problème se situe avant la lecture du système de fichiers de toutes
façons (?). Peut-être que ça marcherait en modifiant l'uuid du disque
dans fstab et en précisant au passage le système de fichiers, mais ça
m'intrigue : une idée de ce qui a pu se passer ? Est-ce qu'il y a un
moyen de régénérer ces infos ? D'autres remarques/idées ?

Merci

Yliur
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Ascadix
Le #26379209
Yliur a exposé le 22/11/2015 :
Bonjour

Après redémarrage, un de mes disques n'est plus monté automatiquement
(ce qui fait plus ou moins échouer le démarrage en demandant une
intervention manuelle). Le disque ne contient pas le système et je l'ai
supprimé de fstab, le reste fonctionne sans lui.

Après inspection le disque n'apparaît plus sous son uuid
dans /dev/disk/by-uuid/. Il semble qu'il y en ait un autre qui
corresponde mais avec un uuid différent.

J'arrive à monter le disque manuellement avec
mount /dev/sdd1 /mnt/truc -t ext4

Si je ne précise pas le type du système de fichiers j'ai ce message
d'erreur :
mount: /dev/sdd1 : plus de systèmes de fichiers ont été trouvés.
Ce n'est pas censé arriver, utilisez -t <type> pour
indiquer explicitement le type de système de fichiers
ou utilisez wipefs(8) pour nettoyer le périphérique.

J'ai deux disques de données très similaires, pour le premier blkid
donne ça :
/dev/sdc1: UUID="d401716c-deb2-4ba4-9c76-2944d1e78d4b" TYPE="ext4"
PARTUUID="2544c6b2-7dd9-4abc-9960-039fcf6d7252"

Et pour le second, celui qui ne marche pas, blkid n'affiche rien du
tout (retour à l'invite de commande, rien d'affiché ; j'ai bien tapé le
bon chemin).

On dirait que certaines méta-données du disque ont été perdues. fsck ne
pense pas que quelque chose va mal sur ce disque, mais je pense que le
problème se situe avant la lecture du système de fichiers de toutes
façons (?). Peut-être que ça marcherait en modifiant l'uuid du disque
dans fstab et en précisant au passage le système de fichiers, mais ça
m'intrigue : une idée de ce qui a pu se passer ? Est-ce qu'il y a un
moyen de régénérer ces infos ? D'autres remarques/idées ?

Merci

Yliur



Coté SMART ça dis quoi ? t'aurais pas qq pbs sur ce DD ?

Sinon, des corruptions liés au hardware autour de la piste 0, et qui
emmerde bien l'OS, c'était il y a qq années la "marque de fabrique" des
DD Maxtor.

--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
Yliur
Le #26379251
Le Sun, 22 Nov 2015 22:25:22 +0100
Ascadix
Yliur a exposé le 22/11/2015 :
> Bonjour
>
> Après redémarrage, un de mes disques n'est plus monté automatiquement
> (ce qui fait plus ou moins échouer le démarrage en demandant une
> intervention manuelle). Le disque ne contient pas le système et je l'ai
> supprimé de fstab, le reste fonctionne sans lui.
>
> Après inspection le disque n'apparaît plus sous son uuid
> dans /dev/disk/by-uuid/. Il semble qu'il y en ait un autre qui
> corresponde mais avec un uuid différent.
>
> J'arrive à monter le disque manuellement avec
> mount /dev/sdd1 /mnt/truc -t ext4
>
> Si je ne précise pas le type du système de fichiers j'ai ce message
> d'erreur :
> mount: /dev/sdd1 : plus de systèmes de fichiers ont été trouvés.
> Ce n'est pas censé arriver, utilisez -t <type> pour
> indiquer explicitement le type de système de fichiers
> ou utilisez wipefs(8) pour nettoyer le périphérique.
>
> J'ai deux disques de données très similaires, pour le premier blkid
> donne ça :
> /dev/sdc1: UUID="d401716c-deb2-4ba4-9c76-2944d1e78d4b" TYPE="ext4"
> PARTUUID="2544c6b2-7dd9-4abc-9960-039fcf6d7252"
>
> Et pour le second, celui qui ne marche pas, blkid n'affiche rien du
> tout (retour à l'invite de commande, rien d'affiché ; j'ai bien tapé le
> bon chemin).
>
> On dirait que certaines méta-données du disque ont été perdues. fsck ne
> pense pas que quelque chose va mal sur ce disque, mais je pense que le
> problème se situe avant la lecture du système de fichiers de toutes
> façons (?). Peut-être que ça marcherait en modifiant l'uuid du disque
> dans fstab et en précisant au passage le système de fichiers, mais ça
> m'intrigue : une idée de ce qui a pu se passer ? Est-ce qu'il y a un
> moyen de régénérer ces infos ? D'autres remarques/idées ?
>
> Merci
>
> Yliur

Coté SMART ça dis quoi ? t'aurais pas qq pbs sur ce DD ?

Sinon, des corruptions liés au hardware autour de la piste 0, et qui
emmerde bien l'OS, c'était il y a qq années la "marque de fabrique" des
DD Maxtor.



Là ce n'est pas de leur faute :) .

Je n'ai jamais vraiment eu de problème avec ces disques, à part qu'il
faut parfois du temps pour qu'ils soient trouvés au démarrage, mais
ça c'est depuis que je les ai.

J'ai activé SMART et lancé un test de diagnostic complet. Voilà ce que
dit le rapport sur le disque maintenant... Ça ne me parle pas trop : à
part que le disque n'est pas tout jeune et que le test s'est bien passé,
il y a quelque chose d'important dedans ?


"
smartctl 6.4 2015-06-04 r4109 [i686-linux-4.2.3-1-ARCH] (local build)
Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION == Model Family: Western Digital Caviar Blue EIDE
Device Model: WDC WD5000AAKB-00H8A0
Serial Number: WD-WCASY3394843
LU WWN Device Id: 5 0014ee 257a92a7d
Firmware Version: 05.04E05
User Capacity: 500 107 862 016 bytes [500 GB]
Sector Size: 512 bytes logical/physical
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS (minor revision not indicated)
Transport Type: Parallel, ATA8-APT
Local Time is: Mon Nov 23 14:29:42 2015 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION == SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (10800) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 127) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x303f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 160 160 021 Pre-fail Always - 4983
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 128
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0
9 Power_On_Hours 0x0032 036 036 000 Old_age Always - 47093
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 126
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 104
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 128
194 Temperature_Celsius 0x0022 104 093 000 Old_age Always - 43
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 47091 -
# 2 Conveyance offline Completed without error 00% 47089 -
# 3 Short offline Completed without error 00% 47089 -

SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
"
Ascadix
Le #26379296
Dans son message précédent, Yliur a écrit :
Le Sun, 22 Nov 2015 22:25:22 +0100
Ascadix
Yliur a exposé le 22/11/2015 :
Bonjour

Après redémarrage, un de mes disques n'est plus monté automatiquement
(ce qui fait plus ou moins échouer le démarrage en demandant une
intervention manuelle). Le disque ne contient pas le système et je l'ai
supprimé de fstab, le reste fonctionne sans lui.

Après inspection le disque n'apparaît plus sous son uuid
dans /dev/disk/by-uuid/. Il semble qu'il y en ait un autre qui
corresponde mais avec un uuid différent.

J'arrive à monter le disque manuellement avec
mount /dev/sdd1 /mnt/truc -t ext4

Si je ne précise pas le type du système de fichiers j'ai ce message
d'erreur :
mount: /dev/sdd1 : plus de systèmes de fichiers ont été trouvés.
Ce n'est pas censé arriver, utilisez -t <type> pour
indiquer explicitement le type de système de fichiers
ou utilisez wipefs(8) pour nettoyer le périphérique.

J'ai deux disques de données très similaires, pour le premier blkid
donne ça :
/dev/sdc1: UUID="d401716c-deb2-4ba4-9c76-2944d1e78d4b" TYPE="ext4"
PARTUUID="2544c6b2-7dd9-4abc-9960-039fcf6d7252"

Et pour le second, celui qui ne marche pas, blkid n'affiche rien du
tout (retour à l'invite de commande, rien d'affiché ; j'ai bien tapé le
bon chemin).

On dirait que certaines méta-données du disque ont été perdues. fsck ne
pense pas que quelque chose va mal sur ce disque, mais je pense que le
problème se situe avant la lecture du système de fichiers de toutes
façons (?). Peut-être que ça marcherait en modifiant l'uuid du disque
dans fstab et en précisant au passage le système de fichiers, mais ça
m'intrigue : une idée de ce qui a pu se passer ? Est-ce qu'il y a un
moyen de régénérer ces infos ? D'autres remarques/idées ?

Merci

Yliur



Coté SMART ça dis quoi ? t'aurais pas qq pbs sur ce DD ?

Sinon, des corruptions liés au hardware autour de la piste 0, et qui
emmerde bien l'OS, c'était il y a qq années la "marque de fabrique" des
DD Maxtor.



Là ce n'est pas de leur faute :) .

Je n'ai jamais vraiment eu de problème avec ces disques, à part qu'il
faut parfois du temps pour qu'ils soient trouvés au démarrage, mais
ça c'est depuis que je les ai.

J'ai activé SMART et lancé un test de diagnostic complet. Voilà ce que
dit le rapport sur le disque maintenant... Ça ne me parle pas trop : à
part que le disque n'est pas tout jeune et que le test s'est bien passé,
il y a quelque chose d'important dedans ?


"
smartctl 6.4 2015-06-04 r4109 [i686-linux-4.2.3-1-ARCH] (local build)
Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION == > Model Family: Western Digital Caviar Blue EIDE
Device Model: WDC WD5000AAKB-00H8A0
Serial Number: WD-WCASY3394843
LU WWN Device Id: 5 0014ee 257a92a7d
Firmware Version: 05.04E05
User Capacity: 500 107 862 016 bytes [500 GB]
Sector Size: 512 bytes logical/physical
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS (minor revision not indicated)
Transport Type: Parallel, ATA8-APT
Local Time is: Mon Nov 23 14:29:42 2015 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled





Ceux qui pouraient êtres préoccupants, c'est surtout ceux-là:

ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail 0
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail 0
7 Seek_Error_Rate 0x002e 100 253 000 Old_age 0
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age 0


Mais là, ils sont nickels.


Te reste à fouiler coté OS, mais là fstab et Cie, c'est pas ma tasse de
thé, désolé.

Bonne chasse.

--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
Lucas Levrel
Le #26379312
Le 22 novembre 2015, Yliur a écrit :

On dirait que certaines méta-données du disque ont été perdues. fsck ne
pense pas que quelque chose va mal sur ce disque, mais je pense que le
problème se situe avant la lecture du système de fichiers de toutes
façons (?). Peut-être que ça marcherait en modifiant l'uuid du disque
dans fstab et en précisant au passage le système de fichiers, mais ça
m'intrigue : une idée de ce qui a pu se passer ? Est-ce qu'il y a un
moyen de régénérer ces infos ? D'autres remarques/idées ?



As-tu vérifié le type de la partition dans la table de partitions du
disque ?

--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
Pascal Hambourg
Le #26379311
Ascadix a écrit :

Ceux qui pouraient êtres préoccupants, c'est surtout ceux-là:

ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail 0
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail 0
7 Seek_Error_Rate 0x002e 100 253 000 Old_age 0
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age 0



Ceux-là aussi :

197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline 0
Yliur
Le #26379317
Le Mon, 23 Nov 2015 21:34:01 +0100
Lucas Levrel
Le 22 novembre 2015, Yliur a écrit :

> On dirait que certaines méta-données du disque ont été perdues.
> fsck ne pense pas que quelque chose va mal sur ce disque, mais je
> pense que le problème se situe avant la lecture du système de
> fichiers de toutes façons (?). Peut-être que ça marcherait en
> modifiant l'uuid du disque dans fstab et en précisant au passage le
> système de fichiers, mais ça m'intrigue : une idée de ce qui a pu
> se passer ? Est-ce qu'il y a un moyen de régénérer ces infos ?
> D'autres remarques/idées ?

As-tu vérifié le type de la partition dans la table de partitions du
disque ?



Si ça répond bien à la question, avec fdisk j'ai demandé "afficher la
table de partitions" sur mes deux disques.

Celui qui marche (/dev/sdc) :
"
Disque /dev/sdc : 465,8 GiB, 500107862016 octets, 976773168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 4A1AF2E5-D873-2046-A8E0-2A3AC0009B2C

Périphérique Début Fin Secteurs Taille Type
/dev/sdc1 2048 976773119 976771072 465,8G Système de fichiers Linux
"

Celui qui se comporte bizarrement (/dev/sdd) :
"
Disque /dev/sdd : 465,8 GiB, 500107862016 octets, 976773168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x65f4c4f5

Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sdd1 2048 976773119 976771072 465,8G 83 Linux
"

Les deux lignes "Type d'étiquette de disque" et "Identifiant de disque"
sont effectivement assez différentes, mais je ne sais pas bien à quoi
ça correspond. Est-ce que ça te parle ?


Avec parted j'ai des infos similaires (apparemment il voit bien que
le deuxième disque est en ext4, alors que mount ne semble pas trouver
cette info) :

Celui qui marche (/dev/sdc) :
"
Modèle: ATA WDC WD5000AAKB-0 (scsi)
Disque /dev/sdc : 500GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : gpt
Disk Flags:

Numéro Début Fin Taille Système de fichiers Nom Fanions
1 1049kB 500GB 500GB ext4
"

Celui qui se comporte bizarrement (/dev/sdd) :
"
Modèle: ATA WDC WD5000AAKB-0 (scsi)
Disque /dev/sdd : 500GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags:

Numéro Début Fin Taille Type Système de fichiers Fanions
1 1049kB 500GB 500GB primary ext4
"
Nicolas George
Le #26379319
Yliur , dans le message
Type d'étiquette de disque : gpt
Type d'étiquette de disque : dos



C'est peut-être ça la différence la plus importante.
Pascal Hambourg
Le #26379320
Nicolas George a écrit :
Yliur , dans le message
Type d'étiquette de disque : gpt
Type d'étiquette de disque : dos



C'est peut-être ça la différence la plus importante.



C'est un peu court. Que je sache, les méta-données du système de
fichiers sont indépendantes du format de table de partition.
Ascadix
Le #26379329
Pascal Hambourg a exprimé avec précision :
Nicolas George a écrit :
Yliur , dans le message
Type d'étiquette de disque : gpt
Type d'étiquette de disque : dos



C'est peut-être ça la différence la plus importante.



C'est un peu court. Que je sache, les méta-données du système de
fichiers sont indépendantes du format de table de partition.



Si on part sur l'idée que le ok est en GPT, et le ko en MBR, on peut se
demander si il n'y aurait pas eu utilisation sur le PC d'un soft X
"ancien" gerne partitionneur ou truc du même acabit pas sympa qui
aurait mal tripatouillé la partition sur le DD MBR mais n'a p'tet pas
touché la partition sur le DD GPT car il aurait buté sur la pseudo
table MBR de protection du GPT ?

Mais c'est un peu tiré par les cheveux.

--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
Yliur
Le #26379336
Le 23 Nov 2015 21:37:52 GMT
Nicolas George
Yliur , dans le message > Type d'étiquette de disque : gpt
> Type d'étiquette de disque : dos

C'est peut-être ça la différence la plus importante.



Comme j'ai utilisé ces disques en raid 1 avec zfs puis que j'ai plus
récemment (mais il y a des mois) séparé les deux disques pour les
utiliser normalement (sans miroir) avec de l'ext4, je ne me souviens
pas de tout l'historique et si à un moment j'aurais moi-même fait deux
choix différents ou si le deuxième a mystérieusement changé d'avis.

J'imagine que pour que la partition soit encore utilisable (montable
avec mount, si on précise le système de fichiers) il faut que la table
de partition du disque soit cohérente, ça n'a pas vraiment pu se casser
en retombant sur un nouvel état stable.

Maintenant je ne connais pas les différences concrètes entre les deux,
si ça se joue à beaucoup ou non...
Publicité
Poster une réponse
Anonyme