Vous n'êtes pas identifié(e).
J'ai droit à :
e2fsck 1.43.4 (31-Jan-2017)
ext2fs_open2: Numéro magique invalide dans le super-bloc
e2fsck : Superbloc invalide, tentons d'utiliser les blocs de sauvetage...
e2fsck: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/sdd
Le superbloc n'a pu être lu ou ne contient pas un système de fichiers
ext2/ext3/ext4 correct. Si le périphérique est valide et qu'il contient réellement
un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d'exécuter
e2fsck avec un autre superbloc :
e2fsck -b 8193 <périphérique>
ou
e2fsck -b 32768 <périphérique>
Trouvé une table de partitions gpt dans /dev/sdd
Si je fais encore plus bestialement
J'ai aussi droit à :
e2fsck 1.43.4 (31-Jan-2017)
ext2fs_open2: Numéro magique invalide dans le super-bloc
e2fsck : Superbloc invalide, tentons d'utiliser les blocs de sauvetage...
e2fsck: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/sdd
Le superbloc n'a pu être lu ou ne contient pas un système de fichiers
ext2/ext3/ext4 correct. Si le périphérique est valide et qu'il contient réellement
un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d'exécuter
e2fsck avec un autre superbloc :
e2fsck -b 8193 <périphérique>
ou
e2fsck -b 32768 <périphérique>
Heu.... il veut quoi en fait ?
Dernière modification par Desktaupe (09-07-2019 17:15:10)
Hors ligne
-->les cahiers du debutant<-- WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde
Hors ligne
…Me revoilà avec mon disque pourri avec des secteurs endommagés.
Reformaté en EXT4 avec Gparted.
…
Plutôt que de créer un système de fichier (<=> formater) directement sur ce disque,
tu aurais dû :
- Créer une table des partitions,
- Puis une partition,
- Et formater (<=> créer un système de fichiers dans...) cette partition
=======
Mais vu les retours de commande de e2fsck ("Trouvé une table de partitions gpt dans /dev/sdd")
c'est sans doute le nom de la cible de la commande qui ne va pas :
/dev/sdd est un nom de fichier de périphérique qui est associé à un disque (sdd <=> le quatrième),
et pas à une partition qui aurait pu être formatée avec un système de fichiers de type ext
alors que, par exemple, la première partition du quatrième disque
est accessible par le fichier de périphérique dont le nom est /dev/sdd1
Dernière modification par MicP (05-07-2019 22:51:40)
Hors ligne
Hello
J'ai pas mes notes sous la main mais si je me souviens bien le man dit qu'il faut démonter la partition sous peine d'avoir un résultat erroné
J'avais démonté.
A noter d'ailleurs qu'après avoir lancé e2fsck et récupéré le message d'erreur je me retrouve monté de nouveau.
Hors ligne
Bonjour
Desktaupe a écrit :…Me revoilà avec mon disque pourri avec des secteurs endommagés.
Reformaté en EXT4 avec Gparted.
…Plutôt que de créer un système de fichier (<=> formater) directement sur ce disque,
tu aurais dû :
- Créer une table des partitions,
- Puis une partition,
- Et formater (<=> créer un système de fichiers dans...) cette partition
=======
Mais vu les retours de commande de e2fsck
c'est peut-être le nom de la cible de la commande qui ne va pas :
/dev/sdd est un nom de fichier de périphérique qui est associé à un disque (sdd <=> le quatrième),
et pas à une partition qui aurait pu être formatée avec un système de fichiers de type ext
alors que, par exemple, la première partition du quatrième disque
est accessible par le fichier de périphérique dont le nom est /dev/sdd1
Ça marche avec sdd1
# e2fsck -L /tmp/badblocks.txt /dev/sdd1
e2fsck 1.43.4 (31-Jan-2017)
/dev/sdd1: Updating bad block inode.
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe
/dev/sdd1: ***** LE SYSTÈME DE FICHIERS A ÉTÉ MODIFIÉ *****
/dev/sdd1 : 14/183148544 fichiers (0.0% non contigus), 11783911/732566385 blocs
Enfin je suppose que ça a marché.
Comment je peux faire pour vérifier ?
Je repasse un badblocks ? ou bien il y a plus simple (ça a quand même duré 24 h)
Alors en fait je ne sais pas si les secteurs ont été réalloués mais maintenant le short offline test de SMART plante à 10% au lieu des 90% habituels...
Hors ligne
Dernière modification par Debian Alain (05-07-2019 14:52:31)
Hors ligne
ce qui serai intéressant , c'est de connaître l'emplacement géographique des secteurs abîmés .
comme çà les connaisseurs pourront te dire si on peut envisager une solution (même bancale)
ou si la santé de ton disque est compromise et à quel niveau ...
mais déjà , si c'est le début du disque qui est abîmé , les prémices ne sont pas bons .
faudrai pas que les secteurs traditionnels du mbr soien touchés .
ce serai vraiment pas bon du tout .
structure du MBR bon à savoir . je sais pas si çà peut aider ? https://debian-facile.org/img/smilies/xtras/coyotus.png
Liste de badblocks avant la réallocation
2919099
2919960
2920390
2920726
2921157
2921587
2922017
2922447
2926371
Ce qui est troublant c'est que je viens de relancer un short offline et cette fois-ci il plante à 90%
Voilà les logs
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 - 160
3 Spin_Up_Time 0x0027 180 176 021 Pre-fail Always - 5983
4 Start_Stop_Count 0x0032 076 076 000 Old_age Always - 24588
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 1
7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0
9 Power_On_Hours 0x0032 068 068 000 Old_age Always - 24038
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 079 079 000 Old_age Always - 21888
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 41
193 Load_Cycle_Count 0x0032 192 192 000 Old_age Always - 24550
194 Temperature_Celsius 0x0022 108 106 000 Old_age Always - 42
196 Reallocated_Event_Count 0x0032 199 199 000 Old_age Always - 1
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 19
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 19
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 - 30
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 Short offline Completed: read failure 10% 24038 23359680
# 2 Short offline Completed: read failure 90% 24038 14727759
# 3 Short offline Completed: read failure 10% 24011 14730736
# 4 Short offline Completed without error 00% 23996 -
# 5 Extended offline Completed: read failure 90% 23981 21525840
# 6 Short offline Completed: read failure 10% 23981 14733720
# 7 Short offline Completed: read failure 10% 23979 14724768
# 8 Short offline Completed: read failure 10% 23930 14724768
# 9 Short offline Completed without error 00% 22597 -
#10 Short offline Completed without error 00% 22027 -
#11 Short offline Completed without error 00% 21441 -
#12 Short offline Completed without error 00% 20846 -
#13 Short offline Completed without error 00% 20154 -
#14 Short offline Completed without error 00% 19442 -
#15 Short offline Completed without error 00% 18742 -
Hors ligne
Dernière modification par Debian Alain (05-07-2019 15:46:47)
Hors ligne
--cela-- peut il t'aider ? dans le but de solutionner ton problème de bad blocks ? https://debian-facile.org/img/smilies/x … chhead.gif
(dernière ligne de commandes : marquage des blocs défectueux)
je crains qu'il n'y ai plus que çà à faire ... avant de remettre le disque en service .
Merci, je peux toujours essayer.J'avais une procédure plus récente sur https://www.aplu.fr/v2/post/2016/01/07/ … defectueux
mais qui s'est finie par hdparm = commande inconnue.
Je dois avouer que dans ton lien je ne comprends pas trop d'où sort le /dev/hda1 de la dernière ligne aalors qu'on était sur sdb1...
J'aimerais assez ne pas flinguer un autre disque.
Hors ligne
à vérifier avant de lancer .
Ça marche avec sdd1
# e2fsck -L /tmp/badblocks.txt /dev/sdd1
e2fsck 1.43.4 (31-Jan-2017)
/dev/sdd1: Updating bad block inode.
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe
/dev/sdd1: ***** LE SYSTÈME DE FICHIERS A ÉTÉ MODIFIÉ *****
/dev/sdd1 : 14/183148544 fichiers (0.0% non contigus), 11783911/732566385 blocs
je pense que mon exemple est redondant .
je crois que tu l'as déjà fait .
pas exactement avec la même commande mais qd mme fait .
tente , peut être , un formatage bas niveau , en dernières ressources . c'est très long . ton disque est de quelle marque ?
histoire de trouver le bon utilitaire .
Dernière modification par Debian Alain (05-07-2019 18:12:46)
Hors ligne
je pense que mon exemple est redondant .
je crois que tu l'as déjà fait .
pas exactement avec la même commande mais qd mme fait .
tente , peut être , un formatage bas niveau , en dernières ressources . c'est très long . ton disque est de quelle marque ?
histoire de trouver le bon utilitaire .
Oui.Je pense que je vais relancer un badblocks comme hier on va bien voir s'il trouve les mêmes ou d'autres spots...
C'est un Western Digital Red Caviar.
Hors ligne
Hors ligne
Hors ligne
/dev/sdd:
reading sector 2919099: succeeded
/dev/sdd:
reading sector 2919960: succeeded
Donc les deux premiers détectés à chaque fois comme mauvais par badblocks sont donnés comme bons par hdparm.
Y a sûrement un truc qui m'échappe...
Hors ligne
Hors ligne
lancé hier soir.
12 erreurs trouvées au bout de 10 heures, comme le dernier badblocks en fait.On va voir ce soir si e2fsck les réalloue ou pas.
Hors ligne
Hors ligne
Dernière modification par raleur (06-07-2019 09:31:16)
Il vaut mieux montrer que raconter.
Hors ligne
Il a trouvé 12 erreurs, comme badblocks et probablement les mêmes.
La surprise c'est la façon dont ça s'est fini il y a quelques minutes...
complété
/dev/sdd1: Updating bad block inode.
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe
Erreur lors de l'écriture de l'information de système de fichier: Erreur d'entrée/sortie
Ca commence à me gonfler légèrement ce truc !!!
Je vais maintenant répondre à ceux qui m'ont écrit entre temps.
Hors ligne
Je n'ai pas lu toute la discussion en détail donc je vais peut-être être redondant sur certains points.
- Si le disque est partitionné (même avec une seule partition), il faut donner à fsck le nom de la partition contenant le système de fichiers ext*, pas du disque.
Vu, sdd1 c'est fait.
- e2fsck ne réalloue pas les blocs défecteux, il ne fait que les enregistrer dans une liste noire de blocs inutilisables.
Ben apparemment si :
Marquer les secteurs défectueux
La commande suivante permet de marquer les secteurs défectueux de la partition « /dev/sda1 » pour empêcher l’enregistrement sur ceux-ci :
e2fsck -c /dev/sda1
- La liste des blocs défectueux passé avec l'option -L doit être générée par badblocks avec les bonnes options et notamment le nom du périphérique contenant le système de fichiers (si on spécifie sdd dans badblocks et sdd1 dans fsck, l'origine ne sera pas bonne, le bloc 0 d'une partition n'étant pas le bloc 0 du disque) et la taille de bloc (badblocks utilise par défaut une taille de 1024 octets alors qu'un système de fichiers ext* utilise par défaut une taille de bloc de 4096 octets au delà de quelques giga-octets). Un fichier généré avec "badblocks /dev/sdd" ne convient donc pas. Pour ne pas s'embêter avec ces détails et éviter les risques d'erreur, il vaut mieux utiliser l'option -c de e2fsck qui va appeler badblocks avec les bonnes options.
Ça j'ai vu mais ça s'est mal fini.
- Pour sa part hdparm travaille avec des secteurs (512 ou 4096 octets selon le disque). Les numéros de blocs générés par badblocks doivent donc être convertis en numéros de secteurs.
Là tu m'intéresses, mais je ne comprends pas.
Ma commande badblocks c'était badblocks -sv -b 4096 /dev/sdb >/tmp/badblocks.txt
Donc le N° des blocs devraient correspondre aux N° de secteurs de hdparm. Non ?
- Pour tenter de réallouer un secteur, il faut écrire dedans. On peut le faire avec dd, badblocks -w ou hdparm. Ça ne marche pas toujours. Le résultat doit se voir avec smartctl -a.
J'aimerai bien en arriver là...
Hors ligne
https://coagul.org/drupal/publication/r … sous-linux
la commande debugfs
Ça a l'air bien aussi debugfs mais je ne suis pas sûr que ça corrige ces 12 secteurs.
Pourquoi le système de fichiers serait cassé alors que je viens de formater ce putain de disque ?
Hors ligne
Hors ligne
Hors ligne
Dernière modification par yole1 (06-07-2019 22:24:26)
Hors ligne
--cela-- peut il t'aider , Desktaupe ?
c'est surement très long . mais pour remettre un disque à zero , je sais pas comment faire .
tu sera obligé de le repartitionner et de le reformater (gparted par ex.) par la suite (çà , c'est vite fait) .
Je ne sais pas trop ce que je vais faire en fait.
Après avoir posté tout à l'heure, l'idée m'a pris de lancer Gparted pour visualiser la partition.Leque ls'est joyeusement planté sur ce disque.
Après un kill j'ai voulu lancer SmartControl qui a bien réagi jusqu'à ce que je coche la case collect offline data et là, plantage de Smart et impossible de le tuer.
J'ai donc redémarré la machine et là, blocage sur watchdog.
Je suis resté en freeze un certain temps, au cours duquel j'avais éteint ce disque et la machine a fini par s'éteindre et redémarrer normalement mais je me suis fait un peu peu sur ce coup...
Hors ligne