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
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
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
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.
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.
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.
Le Sun, 22 Nov 2015 22:25:22 +0100
Ascadix a écrit :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
Le Sun, 22 Nov 2015 22:25:22 +0100
Ascadix <ascadix.ng@free.fr> a écrit :
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
Le Sun, 22 Nov 2015 22:25:22 +0100
Ascadix a écrit :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
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 ?
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 ?
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 ?
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 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 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
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 ?
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 ?
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 ?
Type d'étiquette de disque : gpt
Type d'étiquette de disque : dos
Type d'étiquette de disque : gpt
Type d'étiquette de disque : dos
Type d'étiquette de disque : gpt
Type d'étiquette de disque : dos
Yliur , dans le message , a écrit :Type d'étiquette de disque : gpt
Type d'étiquette de disque : dos
C'est peut-être ça la différence la plus importante.
Yliur , dans le message <20151123222204.7eebfc09@free.fr>, a écrit :
Type d'étiquette de disque : gpt
Type d'étiquette de disque : dos
C'est peut-être ça la différence la plus importante.
Yliur , dans le message , a écrit :Type d'étiquette de disque : gpt
Type d'étiquette de disque : dos
C'est peut-être ça la différence la plus importante.
Nicolas George a écrit :Yliur , dans le message , a écrit :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.
Nicolas George a écrit :
Yliur , dans le message <20151123222204.7eebfc09@free.fr>, a écrit :
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.
Nicolas George a écrit :Yliur , dans le message , a écrit :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.
Yliur , dans le message , a écrit :
> Type d'étiquette de disque : gpt
> Type d'étiquette de disque : dos
C'est peut-être ça la différence la plus importante.
Yliur , dans le message <20151123222204.7eebfc09@free.fr>, a écrit :
> Type d'étiquette de disque : gpt
> Type d'étiquette de disque : dos
C'est peut-être ça la différence la plus importante.
Yliur , dans le message , a écrit :
> Type d'étiquette de disque : gpt
> Type d'étiquette de disque : dos
C'est peut-être ça la différence la plus importante.