[Raspbian]Comment vérifier et réparer un disque Dur ?

Version imprimable

13/06/2018, 14h45
Artemus24

[Raspbian]Comment vérifier et réparer un disque Dur ?

Bonjour à tous.

J'utilise ma Raspberry Pi2 sous Raspbian et j'aimerai connaitre les différentes commandes pour :
--> vérifier les blocs défectueux qui ont déjà été réparés sur un disque dur.
--> vérifier les blocs défectueux qui n'ont pas encore été réparés.
--> réparer les blocs défectueux, c'est-à-dire les rendre inaccessibles à l'OS.
--> comment faire en sorte que mon OS fonctionne à nouveau.

Merci.
@+
13/06/2018, 18h18
Jipété

Yop !

Pour ces trois lignes,

Citation:

Envoyé par Artemus24

--> vérifier les blocs défectueux qui ont déjà été réparés sur un disque dur.
--> vérifier les blocs défectueux qui n'ont pas encore été réparés.
--> réparer les blocs défectueux, c'est-à-dire les rendre inaccessibles à l'OS.

j'aurais dit, en première approche, man fsck, en bootant sur un Live-CD.

Le souci c'est ça :

Citation:

Envoyé par Artemus24

J'utilise ma Raspberry Pi2 sous Raspbian et j'aimerai connaitre les différentes commandes pour :
--> comment faire en sorte que mon OS fonctionne à nouveau.

et j'en conclus que l'OS ne fonctionne plus et je ne sais pas du tout comment faire booter une Pi2 sur un CD (ou autre chose).
13/06/2018, 20h18
Artemus24

Salut Jipété.

J'ai rencontré un petit problème (des blocs défectueux) avec mon disque dur sur ma Rpi2, que j'ai pu résoudre.
J'ai, dans un premier temps, utilisé la commande "badblocks".
J'ai aussi utilisé la commande suivante :

Code:

sudo fsck.ext4 -cDfty -C 0 /dev/sda2

avec succès.

Le problème est que je n'ai pas compris d'où venait ce problème.
Est-ce dû à ma carte Micro SD qui était vérrolé ?
Est-ce que j'ai fait une mauvaise manipulation ?

J'ai aussi utilsé la commande suivante :

Code:

e2fsck -c /dev/sda2

J'ai fait aussi une recherche sur le net, et du coup, je m'y perds car il y a pléthore de solutions pour ce genre de problème.

Pour renormaliser ma OS (raspbian stretch), j'ai réinstallé le firmware avec succès.

Ma question est d'ordre général, histoire de savoir comment résoudre ce genre de problème (blocs défectueux) avec Raspbian.
Mais surtout, vérifier afin de savoir si ce que j'ai fait est bon pour mon disque et mon OS.

On peut aussi étendre la question à la création et manipulation des images, voire aussi en la compressant sur un périphérique, afin d'avoir un point de restauration au cas où.

Pourquoi je me pose ce genre de question ? Parce que je ne suis pas trop familiarisé avec l'OS linux (enfin raspbian) et du coup, je ne connais pas les commandes.

@+
17/06/2018, 16h50
Artemus24

Salut jipété.

Comme je ne suis pas trop linuxien, j'aurai aimé savoir pourquoi dans le répertoire "lost+found" je me retrouve avec des fichiers ou des répertoires qui ont un numéro.
Ces numéros sont-ils mes blocs défectueux ? Est-ce une bonne idées de les supprimer ?

Si je recopie cette partition sur une carte micro SD, est-ce que les blocs défectueux seront aussi recopié ?

Avez-vous des conseils à me donner pour réparer mon disque dur ?

Merci !
@+
17/06/2018, 18h23
chrtophe

fsck va contenir les blocs qui semblent occupés mais affectés à aucun fichier, mis sous forme de fichiers lors de la réparation du fs avec fsck. C'est un peu l’équivalent des fichiers .chk sous Windows après utilisation de chkdsk.

Si tu ne sais pas quoi en faire tu peux les effacer.
17/06/2018, 20h01
Artemus24

Salut chrtophe.

Citation:

Envoyé par chrtophe

fsck va contenir les blocs qui semblent occupés mais affectés à aucun fichier, mis sous forme de fichiers lors de la réparation du fs avec fsck.

Vous voulez dire que ces blocs ne seront plus accessibles par l'OS. Est-ce bien cela ?
Et qu'ils sont mis sous forme de fichiers ou de répertoire dans le répertoire lost+found.
C'est pourquoi ils ont tous un identifiant du genre "#12DS58".

Ce que je ne comprends pas, ils sont encore lisible dans le répertoire lost+found.
S'ils sont défectueux pourquoi j'arrive à les lire ?

Citation:

Envoyé par chrtophe

Si tu ne sais pas quoi en faire tu peux les effacer.

Mais cela ne va-t-il pas libérer ces blocs défectueux et de les rendre accessible à nouveau pour l'OS ?

Si je désire faire une sauvegarde de mon disque par la commande DD, ne va-t-il pas recopier ces blocs défectueux ?
Comment faire pour que cela ne soit pas le cas ?

@+
18/06/2018, 07h19
chrtophe

Citation:

Ce que je ne comprends pas, ils sont encore lisible dans le répertoire lost+found.
S'ils sont défectueux pourquoi j'arrive à les lire ?

Il ne s'agit pas de blocs défectueux, mais de blocs orphelins suite à plantage FS. Le FS les voient occupés mais ne sait pas à quels fichiers ils sont affectés. fsck va les stocker dans des fichiers dans lost+found pour que tu puisses jeter un œil avant de les effacer. En gros, tu peux pas en faire grand-chose et peut vider le dossier. Leurs blocs seront alors dispo.

Citation:

Si je désire faire une sauvegarde de mon disque par la commande DD, ne va-t-il pas recopier ces blocs défectueux ?
Comment faire pour que cela ne soit pas le cas ?

dd recopie tous les blocs sans se préoccuper de ce qu'il y a dessus. En cas de blocs physiquement endommagés, tu auras des I/O errors.

Pour vérifier les blocs physiquement défectueux, c'est avec la commande badbloks, pour les déclarer défectueux c'est avec hdparm. Commandes dangereuses, à faire après sauvegarde et FS démonté
18/06/2018, 19h47
Artemus24
Salut chrtophe.

Merci pour vos explications, mais je ne comprends rien.

Je reprends le problème que j'ai rencontré.
Quand je fais une mise à jour de ma raspberry, je me suis retrouvé avec deux types d'anomalies, qui sont :

Code:

somme de contrôle de hachage incohérente.

ainsi que :
Code:

1 2 dpkg : erreur fatale irréversible, abandon : la liste des fichiers pour le paquet « linux-headers-2.6.35-22-generic » n'a pas de retour à la ligne en fin de fichier
Je suis arrivé à la conclusion que j'avais des blocs défectueux sur mon disque.

J'ai fait une recherche sur le net et j'ai trouvé, en premier, la commande "badblocks".
J'ai lancé :

Code:

badblocks -svm -o file_badblocks.txt /dev/sda

et en second; cette autre commande :

Code:

mke2fs -l file_badblocks.txt /dev/sda

J'ai aussi fait par la suite :

Code:

fsck.ext4 -cDfty -C0 /dev/sda2

J'ai supprimé tous les packages où j'avais l'erreur "fin de ligne".
Et j'ai réinstallé le firmware". J'ai refais une mise_a_jour afin de vérifier mes problèmes.

Et depuis, tout semble fonctionner normalement.
J'ai refais le badblocks mais je n'ai plus de blocs défectueux.
C'est là, que j'ai découvert le contenu du répertoire "/lost+found".

Maintenant, ce que je cherche à faire, c'est :
--> vérifier que mon disque soit en état de fonctionner correctement.
--> de connaitre la liste des blocs défectueux.
--> de faire une sauvegarde, sans recopier ces blocs défectueux.

C'est mon manque de connaissance de Raspbian qui fait que je pose toutes ses questions.

@+
18/06/2018, 21h13
chrtophe

L'erreur de dpkg n'a rien à voir avec des blocs défectueux.

Tu ne devrais pas avoir de problème pour faire une sauvegarde. Si il y a réellement des probs, tu auras des I/O error lors de la copie. Tu pourras éventuellement exclure les fichiers inaccessibles de la copie.

Salut Chrtophe.

Citation:

Envoyé par Chrtophe

L'erreur de dpkg n'a rien à voir avec des blocs défectueux.

En êtes-vous certain ? Car après avoir réparé mon disque dur, je n'ai plus eu ces deux erreurs.

Je reprends mes tests. Voici mon disque dur qui pose problème :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
~> fdisk -l /dev/sda
Disk /dev/sda: 465,8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x9cba179a
 
Device     Boot  Start      End  Sectors  Size Id Type
/dev/sda1         2048   206847   204800  100M  c W95 FAT32 (LBA)
/dev/sda2       206848 33761279 33554432   16G 83 Linux
~>

Comme on peut le voir, la partition linux (RootFS) fait seulement 16Go.
Puis ensuite, j'ai lancé ceci sur ma partition linux démontée :

Code:

1
2
3
4
5
6
7
8
~> badblocks -svn /dev/sda2
 
Vérification des blocs défectueux dans un mode non destructif de lecture-écriture
Du bloc 0 au bloc 16777215
Vérification des blocs défectueux (test non destructif de lecture-écriture)
Test en cours avec un motif aléatoire*: complété
Passe complétée, 0 blocs défectueux repérés. (0/0/0 erreurs)
~>

Après 40 minutes, il n'a rien trouvé. Je fais aussi cela :

Code:

1
2
3
~> dumpe2fs -b /dev/sda2
dumpe2fs 1.43.4 (31-Jan-2017)
~>

A priori, il n'a rien trouvé comme blocs défectueux (en espérant que je ne me suis pas trompé de commande).

Mais quand je lance ceci :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
sudo dumpe2fs -h /dev/sda2
dumpe2fs 1.43.4 (31-Jan-2017)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          037616fd-28fe-4652-8248-2042ea30b929
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              963840
Block count:              3906048
Reserved block count:     167061
Free blocks:              2288881
Free inodes:              800968
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      289
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8032
Inode blocks per group:   502
Flex block group size:    16
Filesystem created:       Wed Aug 16 03:34:52 2017
Last mount time:          Sun Jun 17 03:03:31 2018
Last write time:          Sun Jun 17 03:03:35 2018
Mount count:              5
Maximum mount count:      -1
Last checked:             Sun Jun 17 00:25:53 2018
Check interval:           0 (<none>)
Lifetime writes:          25 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      e74fe120-6d30-4aab-978c-4263e212bfb6
Journal backup:           inode blocks
FS Error count:           5
First error time:         Sun Jun 17 03:03:34 2018
First error function:     ext4_mb_generate_buddy
First error line #:       756
First error inode #:      0
First error block #:      0
Last error time:          Sun Jun 17 03:03:35 2018
Last error function:      ext4_mb_generate_buddy
Last error line #:        756
Last error inode #:       0
Last error block #:       0
Fonctionalités du journal*:  journal_incompat_revoke
Taille du journal*:         64M
Longueur du journal*:      16384
Séquence du journal*:      0x0000f366
Début du journal*:         1

~>

il m'indique quelque chose en erreur (ce que j'ai mis en rouge) sans bien comprendre de quoi il s'agit.

Comme je ne suis pas trop familiarisé avec la réparation d'un disque dur sous Raspbian, je ne sais pas si je fais tout correctement.

@+

19/06/2018, 07h50
chrtophe

Tu peux avoir des erreurs dans le FS sans blocs défectueux. Si le FS est montable, il s'agit la plupart du temps d’erreurs mineures.
Après je peux pas te dire si l'erreur signalée est mineure ou pas.
19/06/2018, 17h32
Artemus24

Salut chrtophe.

Si je comprends bien, un "bad block" n'est pas nécessairement un bloc qui a subit un dommage physique.
Cela peut être dû à un problème logique qui rend le bloc incompréhensible pour le FS.
Si c'est cela, ça me rassure car je n'ai pas compris pourquoi j'ai eu ce genre de problème.

Sinon, je fais appel à votre connaissance pour obtenir la bonne démarche pour vérifier la conformité d'un disque dur.
Quels sont les commandes que je utiliser et dans quel ordre je dois les passer ?

Est-ce que le badblocs n'est pas redondant avec fsck ? Y-a-t-il d'autres commandes à connaitre ?
Et qu'est-ce que e2fsprogs ?

@+
19/06/2018, 20h49
chrtophe

Pour la vérification matérielle, contrôler l'état SMART, pour le reste en général un fsck suffit. La protection indispensable est la sauvegarde. Un disque peut tenir 10 ans comme 2 mois.

e2fsprogs est l'ensemble des outils de gestion de FS ext(2/3/4). Parmi eux fsck que tu connais, mkfs pour créer les FS, resize2fs ( nom explicite), et d'autres outils plus techniques comme tune2fsd, debugfs, etc.