[Linux-bruxelles] Carte sd non reconnu

Depuydt, Patrick patrick at htag2.com
Jeu 23 Mai 14:15:39 CEST 2019


Bon,... c'est bien sympa de vouloir réparrer le filesystem, mais encore
faut-il qu'il y en ait un.

Donc étape n°1: Vérifier ce que le système vois quand on insere la carte SD.

En gros moi ce que je fait c'est :
1.1 Mettre la carte SD dans le lecteur (que ce soit usb ou natif sur le
portable peu importe)
1.2 Je tappe *dmesg* dans la console et vérifie ce que le kernel voit, et
là deux possibilités:

1.2.1 le kernel n'affiche rien par rapport à la carte SD. Cela veux dire
que le lecteur déconne (si une autre carte fonctionne dans ce lecteur,
c'est que le lecteur est probablement OK), aussi la carte pourrait faire
partie de ces quelques "block devices" non reconnues par le kernel (en
fonction de la distro le kernel et modules attachés sont différents, mais
en gros, pour ceux qui ont déjà compilé un kernel, il y a une option pour
les legacy storage devices et autres options qui peuvent ne pas être
comprises dans le kernel en fonction de la distro (en général ce n'est pas
un problème mais je ne sais pas de quand date la carte SD ni quelle marque
etc. bref, c'est juste une possibilité), soit la carte est foutue (dans le
cas ou elle fonctionne dans l'appareil c'est qu'elle est OK).

1.2.2 le kernel affiche bien qu'il reconnait un device, probablement un
mmcblkXXX ou une nouveau sdX si il s'agit d'un adaptateur usb. En gros il
faut lire, comme d'hab, car le kernel devrais en gros cracher la structure
du disque qu'il à trouvé, voici un petit exemple (désolé ce n'est pas par
rapport à une SD mais c'est pareil):
*La en gros il charge le module qui lui permet de détecter mes disques:*
[    2.245069] scsi host32: VMware PVSCSI storage adapter rev 2,
req/cmp/msg rings:
8/8/1
pages, cmd_per_lun=254
[    2.246303] vmw_pvscsi 0000:03:00.0: VMware PVSCSI rev 2 host #32
*Ici il scanne les ports SATA*
[    2.246600] scsi 32:0:0:0: Direct-Access     VMware   Virtual disk
2.0  PQ: 0
ANSI
: 6
[    2.246724] scsi 32:0:1:0: Direct-Access     VMware   Virtual disk
2.0  PQ: 0
ANSI
: 6
*La il à trouvé qqchose*
[    3.023165] sd 32:0:0:0: [sda] 104857600 512-byte logical blocks: (53.6
GB/50.0 GiB)
[    3.023228] sd 32:0:0:0: [sda] Write Protect is off
[    3.023231] sd 32:0:0:0: [sda] Mode Sense: 61 00 00 00
[    3.023249] sd 32:0:0:0: [sda] Cache data unavailable
[    3.023251] sd 32:0:0:0: [sda] Assuming drive cache: write through
[    3.023781] sd 32:0:1:0: [sdb] 33554432 512-byte logical blocks: (17.1
GB/16.0 GiB)
[    3.023835] sd 32:0:1:0: [sdb] Write Protect is off
[    3.023838] sd 32:0:1:0: [sdb] Mode Sense: 61 00 00 00
[    3.023852] sd 32:0:1:0: [sdb] Cache data unavailable
[    3.023855] sd 32:0:1:0: [sdb] Assuming drive cache: write through
*Vous pouvez constatter qu'il indique (en simple) la structure de la table
des partitions*
[    3.025571]  sda: sda1 sda2
*Et la il confirme qu'il à attribué un identifiant pour accèder au disque*
[    3.025874] sd 32:0:0:0: [sda] Attached SCSI disk
[    3.026261] sd 32:0:1:0: [sdb] Attached SCSI disk

et effectivement quand je lance* lsblk* il me confirme bien deux disques
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda             8:0    0   50G  0 disk
├─sda1          8:1    0    1G  0 part /boot
└─sda2          8:2    0   49G  0 part
  ├─rhel-root 253:0    0 45.1G  0 lvm  /
  └─rhel-swap 253:1    0  3.9G  0 lvm  [SWAP]
sdb             8:16   0   16G  0 disk

Alors je dis ça car normalement si il y a un problème avec la SD ce sera
affiché quelque part dans la partie sdX ou mmcblkXX du log kernel (dmesg).

Le problème I/O que tu mentionne est bêtement un problème de communication
hardware avec la clé, soit elle n'est pas bien branchée, soit elle n'est
pas reconnue, soit il y a physiquement des problèmes de lecture (secteurs
défectueux).


Passons à l'étape 2 (moyennant le fait qu'on considère que le kernel à bien
détecté un disque (sdX ou mmcblkXX, peu importe, c'est pareil)
FSCK c'est bien mais des fois il faut un peu lui tenir la main. Alors:

2. Déterminer le système de fichier de la partition:
Moi je ne me casse pas la tête et je tappe *blkid*, ce qui retourne un truc
du style (soit la liste des partition reconnues par le système):
/dev/sda1: UUID="1634a185-f948-4547-9140-f6f1fda3d28c" TYPE="xfs"
/dev/sda2: UUID="pQA1YO-aMWI-ssKb-5Bxl-4J15-UJdk-dwWHjM" TYPE="LVM2_member"
/dev/mapper/rhel-root: UUID="5d7ed08a-3a51-47cf-877b-6b29ad794653"
TYPE="xfs"
/dev/mapper/rhel-swap: UUID="644747ff-cf87-4643-b420-bdeee6e1046e"
TYPE="swap"

Constattez que le système nous indique le format de la partition avec la
variable TYPE. En fonction du format de la partition il faut s'assurer
qu'on à bien les outils pour gérer ces formats.

Petite note: f/gdisk peut aussi donner une idée tu type de système de
fichier en fonction du type de partition, mais ce n'est pas assez précis,
exemple: type 82 (soit linux fs) en général peut être ext2/3/4, reiserfs,
xfs, etc.

Si le disque n'est pas affiché, soit vous n'avez pas les modules
nécéssaires (a checker en fonction de la distro, les packages additionels
on tendance à s'appeller kmod-[qqchose], soit il manque certains userspace
utils (indiqués ci-dessous), soit l'étape 1 ci dessus ne vous as pas
détecté le disque, soit la table des partitions est corrompue.

Si il sagit d'une carte FAT alors il faut être sur que les *dosfstools*
soient installés (a chercher exactement le nom du package en fonction de
votre distro), si c'est du ntfs il sagit de *ntfsprogs*, *xfsutils *pour
xfs, enfin bref vous aurez compris il faut installer les outils
correspondant à votre système de fichiers.

Une fois que ça c'est fait on passe à l'étape 3:
3. Vérifier le système de fichier (on vas prendre pour acquis qu'il sagit
d'un système FAT et que vous avez deployé les dosfstools)

Je pense que fsck est capable de détecter tout seul le système de fichier,
mais comme je n'ai jamais lancé fsck tout court je n'en suis pas sur.
Par habitude je lance toujours fsck.[fs_type], soit dans notre cas
*fsck.fat* suivi du device qu'on à trouvé à l'étape 1, soit en gros un truc
du genre:
~#: fsck.fat /dev/mmcblk0
ou encore:
~#: fsck.fat -atvV /dev/mmcblk0 (pour réparrer et tester les secteurs
défectueux, donner plus d'infos sur ce qu'il fait et finalement vérifier le
tout après avoir fait les modifs si il y en eu)


Voilà qui devrais te sortir de la panade :)

Sinon si tu as une SD totalement pareille, j'insiste TOTALEMENT pareille
(en taille en tout cas) qui fonctionne bien, tu peux la cloner avec *dd*.


@pluche la liste...

On Sat, May 18, 2019 at 1:34 AM Alain Belkadi <xigulor at linuxbeach.be> wrote:

> On 2019-05-18 00:31, fabrice wrote:
>
> > apres avoir fait un fsck /dev/mmcblk0p1 -n
> >  resultat:fsck de util-linux 2.29.2
> > e2fsck 1.43.4 (31-Jan-2017)
> > fsck.ext2: Erreur d'entrée/sortie lors de la tentative d'ouverture de
> > /dev/mmcblk0p1
> >
> > 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
>
>
> fsck.fat pas fsck sinon tu vas chercher à fixer des erreurs pour le
> mauvais filesystem !
>
> --
> [Alain Belkadi / LinuxBeach]
> _______________________________________________
> Linux-bruxelles :
> Èchanger, partager, s'informer par mails sur toute action, proposition
> accordée avec: http://www.bxlug.be/?Nos-statuts
>
> Linux-bruxelles at lists.bxlug.be
> https://listes.domainepublic.net/listinfo/linux-bruxelles
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: </pipermail/linux-bruxelles/attachments/20190523/8f8d4e52/attachment-0002.html>


Plus d'informations sur la liste de diffusion Linux-bruxelles