Vous n'êtes pas identifié(e).
Pages : 1
Hors ligne
Dernière modification par Debian Alain (13-09-2018 20:17:22)
Hors ligne
Hors ligne
Dernière modification par Debian Alain (13-09-2018 20:54:22)
Hors ligne
d'après gparted ça viendrait de probleme de super bloc.
C'est un peu vague. Quel est le message exact ? Lors de quelle action précise ?
D'autre part comme Alain l'a souligné, un superbloc est une structure de système de fichiers (mis en place par ce qu'on appelle familièrement le "formatage"), ce qui n'est pas la spécialité première de Gparted qui est avant tout un outil de manipulation des tables de partition. Si je devais vérifier un système de fichiers, je ne n'utiliserais pas Gparted mais directement les programmes en ligne de commande de vérification du type de système de fichiers.
Par exemple l'image de système préinstallée de Raspbian contient deux partitions, une FAT pour l'amorçage et une ext4 pour le système, qu'on peut vérifier avec fsck.
J'ai essayé la manip https://www.recantha.co.uk/blog/?p=1208 mais sans succès.
.
Dis-donc, tu es vraiment avare d'informations détaillées...
Ce que je ne comprends pas c'est que sous windows en fat32 pas de soucis.
Mais dés que je repasse sur ext sous linux le problème revient.
La carte peut avoir un ou plusieurs bloc défecteux dans une zone que le formatage de Windows n'utilise pas mais qui est utilisée en ext4.
p.s. : en plus , le raspberry est connu pour "bouffer" des cartes sd
J'ai lu ça aussi. Je n'ai jamais utilisé de Raspberry Pi mais je soupçonne fortement que le vrai responsable est en fait l'utilisation inappropriée de la carte SD qui est faite par le système d'exploitation et les logiciels qu'on fait tourner dessus. En effet, contrairement à un disque dur ou un SSD, une carte SD, comme une clé USB, n'est pas conçue pour subir des écritures répétitives. Si on l'utilise comme un disque sans prendre de précautions pour limiter ces écritures répétitives (choix d'un système de fichiers et d'options de montage adaptés, utilisation de tmpfs pour les fichiers temporaires...), la carte SD risque de s'user rapidement.
Dernière modification par raleur (13-09-2018 21:26:24)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par jules (13-09-2018 21:29:12)
Hors ligne
jules a écrit :
J'ai essayé la manip https://www.recantha.co.uk/blog/?p=1208 mais sans succès.
.
Dis-donc, tu es vraiment avare d'informations détaillées...
J'ai essayé de faire un backup des Superblocks avec la manip indiquée mais ça n'a pas fonctionner:
Down at the bottom of this output, should be a list of the backups:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
You’re almost there. Finally, restore the superblock from the backup, again replacing the x’s with your partition name, and block_number with the first backup superblock.
sudo e2fsck -b block_number /dev/xxx
Now reboot, and your superblock should be fixed. If it’s not, repeat the steps, but restore a different backup superblock
Hors ligne
Hors ligne
D'autre part comme Alain l'a souligné, un superbloc est une structure de système de fichiers (mis en place par ce qu'on appelle familièrement le "formatage"), ce qui n'est pas la spécialité première de Gparted qui est avant tout un outil de manipulation des tables de partition. Si je devais vérifier un système de fichiers, je ne n'utiliserais pas Gparted mais directement les programmes en ligne de commande de vérification du type de système de fichiers.
Ok je vais voir les tuto et essayer.
Hors ligne
Hors ligne
Voici le message que Gparted me donne
Je serais curieux de savoir comment Gparted détermine que la partition /dev/mmcblk0p1 est en ext4 alors que tous les programmes spécifiques à ext* qu'il invoque ne trouvent pas de superbloc ext*. D'ailleurs il me semble que la première partition est réservée à l'amorçage et doit être formatée en FAT.
On peut voir la sortie des commandes suivantes ?
EDIT : Apparemment quelque chose a changé car fsck ne relève aucune erreur. Gdisk se plaint toujours ?
PS : tu pourrais copier/coller le contenu du terminal en texte brut au lieu de faire une copie d'écran graphique.
J'oubliais : vérification en lecture seule de tous les secteurs de la carte :
Dernière modification par raleur (13-09-2018 21:38:00)
Il vaut mieux montrer que raconter.
Hors ligne
Je serais curieux de savoir comment Gparted détermine que la partition /dev/mmcblk0p1 est en ext4 alors que tous les programmes spécifiques à ext* qu'il invoque ne trouvent pas de superbloc ext*. D'ailleurs il me semble que la première partition est réservée à l'amorçage et doit être formatée en FAT.
Dans ce cas peut être que le problème vient de mon formatage initial que j'ai fais car il n'y a qu'une seule partition en ext4 d'après gparted.
Dernière modification par jules (13-09-2018 22:37:06)
Hors ligne
Dernière modification par jules (13-09-2018 22:27:49)
Hors ligne
Hors ligne
j'arrive à monter la carte sd après formatage mais pas à ajouter des fichiers dessus. Lorsque je la retire et la remet (après démontage) je ne peut même plus la monter.
De quelle façon essaies-tu d'ajouter des fichiers ? Quel est le message d'erreur ?
Tu vérifies que le système de fichiers est bien démonté avant de retirer la carte ?
De quelle façon la remontes-tu ? Manuellement avec mount, via le gestionnaire de fichiers, l'environnement de bureau ?
Qu'est-ce qui se passe lors de la tentive de remontage ?
As-tu vérifié la carte avec badblocks ? Si le test rapporte des erreurs de lecture, c'est inutile de chercher plus loin.
Il vaut mieux montrer que raconter.
Hors ligne
Pages : 1