# Formatter SDCard



## daffyb (16 Mars 2018)

Bonjour,

J'ai une carte SD Samsung 16Go impossible à Formatter. Je crois que je vais avoir besoin de @macomaniac et que ce sujet va lui plaire 
Je pense que la table de partition est corrompue ou qu'il y a un protection empêchant son formatage.
Pour la petite histoire, cette carte était dans un Raspberry Pi qui a été piraté et je crois que le pirate a fait un tour dans la fstab (sans savoir ce qu'il y a fait).
Au boot de Raspbian, j'ai une indication comme quoi le disque est abimé.
Voici ce que j'ai essayé de faire :
Utilitaire de disque High Sierra, Sierra et SnowLeopard : échec
SD card Formatter.app : fait mine de formatter et à l'arrivée me dit que c'est bon, mais n'a rien fait.
Formattage depuis un appareil photo : marche pas
Formattage depuis une Nintendo 3DS avec Godmode9 : ne marche pas
Impossibilité de supprimer les partitions depuis UbuntuMate.

Tout ça en interface graphique, car, moi, la gestion des disques en lignes de commandes, ce n'est pas mon fort, mais j'y travaille.

Voici ce que j'ai en diskutil list :

```
/dev/disk2 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *16.0 GB    disk2
   1:             Windows_FAT_16 RECOVERY                854.8 MB   disk2s1
   2:                      Linux                         33.6 MB    disk2s3
   3:             Windows_FAT_32 boot                    62.9 MB    disk2s5
   4:                      Linux                         6.9 GB     disk2s6
```

Je ne sais plus quoi faire (il me reste Windows, mais pas avant lundi).
Une idée, ou un défis à relever avant qu'elle ne part à la poubelle ?


----------



## flotow (16 Mars 2018)

daffyb a dit:


> Je crois que je vais avoir besoin de @macomaniac et que ce sujet va lui plaire
> [...]
> Une idée, ou un défis à relever avant qu'elle ne part à la poubelle ?



Si ça c'est pas un appât...


----------



## daffyb (16 Mars 2018)

flotow a dit:


> Si ça c'est pas un appât...


J'avoue être bien sec quant à une éventuelle réparation de la carte 
TestDisk n'arrive à rien non plus.
Là, je tente un gros dd sur la carte


----------



## daffyb (16 Mars 2018)

daffyb a dit:


> Là, je tente un gros dd sur la carte


eh non. J'ai fait un dd d'une image vide de 15Go  sur la carte et voici le résultat :

```
iDaffy3:~$ sudo dd if=/Users/daffyb/Downloads/VIDE15.dmg of=/dev/disk2 bs=4m
3576+1 records in
3576+1 records out
15000020480 bytes transferred in 1269.323443 secs (11817335 bytes/sec)
iDaffy3:~$ diskutil list
/dev/disk2 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *16.0 GB    disk2
   1:             Windows_FAT_16 RECOVERY                854.8 MB   disk2s1
   2:                      Linux                         33.6 MB    disk2s3
   3:             Windows_FAT_32 boot                    62.9 MB    disk2s5
   4:                      Linux                         6.9 GB     disk2s6
```
et le diskutil list est inchangé


----------



## macomaniac (17 Mars 2018)

*daffyb*

L'intérêt d'une commande qui échoue > c'est qu'elle bavarde un peu en déclarant son échec.

Passe la commande :

```
diskutil eraseDisk jhfs+ Brol disk2
```


après avoir vérifié par un *diskutil list* préalable que la carte est toujours *disk2* > sinon tu modifies en rapport  le chiffre indexant le disque tout en queue de commande pour ne pas t'en aller ré-initialiser un autre disque

la commande inscrit une table *GPT* > un format *jhfs+* > remonte un volume intitulé *Brol*

Tu n'as qu'à poster le message retourné par la commande --> on verra bien.


----------



## daffyb (17 Mars 2018)

macomaniac a dit:


> *daffyb*
> 
> L'intérêt d'une commande qui échoue > c'est qu'elle bavarde un peu en déclarant son échec.
> 
> ...



Pas devant le Mac pour un moment (les activités sportives des enfants toussa)
Je ferai le test. 
Pour le moment les différents essais ne renvoyaient pas d’erreur. Très étrange. 
À+


----------



## daffyb (17 Mars 2018)

daffyb a dit:


> Pas devant le Mac pour un moment (les activités sportives des enfants toussa)
> Je ferai le test.
> Pour le moment les différents essais ne renvoyaient pas d’erreur. Très étrange.
> À+


ce qu'il se passe :
les 2 partitions montées sur le Finder se démontent puis remontent presque instantanément et donc ça semble bloquer la création de la table de partition. La commande reste bloquée et n'aboutie pas :

```
diskutil eraseDisk jhfs+ Brol disk2
Started erase on disk2
Unmounting disk
Creating the partition map
Waiting for partitions to activate
[ | 0%..10%..20%..30%..40%..50%.......................... ]
```


----------



## macomaniac (18 Mars 2018)

Tous les volumes montés sur un disque doivent être démontés avant effacement de la table de partition. C'est donc le remontage rapide des volumes après démontage qui est problématique.

Je te propose un test un peu plus radical -->

- tu peux aller à cette page internet de SourceForge : ☞*GPT fdisk*☜ > ce qui te permet de télécharger le paquet d'installation (*738 Ko*) : *gdisk-1.0.3.pkg*. Un double-clic permet l'installation de *gdisk* at: */usr/local/bin/gdisk*. *gdisk* est un exécutable créé par _Roderick Smith_ (le développeur du gestionnaire de démarrage rEFInd) > qui permet de manipuler tables de partitions et partitions en ligne de commande. Un outil des plus précieux. L'installation faite > *gdisk* est appelable directement en ligne de commande.

Ta carte SD attachée > tu passes d'abord un : 
	
	



```
diskutil list
```

histoire de bien vérifier l'index de disque de la carte (je vais continuer de supposer que c'est *disk2* mais tu adaptes s'il y a lieu). Tu enchaînes avec la commande :


```
sudo gdisk /dev/disk2
```

qui appelle *gdisk* à ouvrir le secteur d'amorçage du disque en lecture --> tu vas déjà voir si *gdisk* retourne un message d'erreur > ou s'il t'affiche le tableau des tables de partitions et l'invite de commande du mode "*main*" (principal).

Si tu as bien l'invite de commande : 
	
	



```
Command (? for help):
```

tu tapes 
	
	



```
x
```
 (comme mode "e*x*pert") et tu valides --> ce qui affiche l'invite de commande du mode "*expert*" : 
	
	



```
Expert command (? for help):
```



tu saisis : 
	
	



```
z
```
 (comme *z*ap : effacer la table de partition et tu valides --> ce qui affiche un : 
	
	



```
About to wipe out GPT on /dev/disk5. Proceed? (Y/N):
```



tu saisis 
	
	



```
y
```
 (*y*es) et tu valides --> tu obtiens un boniment déclarant que le *kernel* ne va pas suivre mais continuer de charger la table de partition et les partitions antérieures mises-en-mémoire et qu'il faudra redémarrer ou détacher/réattacher le disque pour mettre à jour le *kernel* + la demande finale : 
	
	



```
Blank out MBR? (Y/N):
```
 (effacer la table de partition *MBR* du bloc *0* ?


tu saisis bien sûr : 
	
	



```
y
```
 (*y*es) car tu as fait tout ça pour ça --> après un résumé du boniment précédent sur le *kernel* qui va continuer d'opérer sur sa mémoire sans se mettre à jour en "*live*" --> tu récupères l'invite de commande *iDaffy3:~* qui montre que le programme *gdisk* a quitté. Cela --> si l'effacement fonctionne. Sinon > *gdisk* va afficher un message d'erreur.

S'il y a un message d'erreur > poste-le ici.

Sinon > démonte les volumes montés de ta carte > détache-la du Mac > ré-attache-la --> si tu as une boîte de dialogue du Finder déclarant : "*le disque que vous avez inséré n'est pas lisible par cet ordinateur*" --> c'est que le table de partition *MBR* a bien été effacée --> première étape avant la ré-inscription d'une nouvelle table.


----------



## daffyb (18 Mars 2018)

macomaniac a dit:


> Tous les volumes montés sur un disque doivent être démontés avant effacement de la table de partition. C'est donc le remontage rapide des volumes après démontage qui est problématique.
> 
> Je te propose un test un peu plus radical -->
> 
> ...


J'avoue avoir fait la manip sans conviction (j'avais déjà tenté avec TestDisk qui permet aussi de faire un wipe du MBR).

Voici ma manip :

```
sudo gdisk /dev/disk2
Password:
GPT fdisk (gdisk) version 1.0.3

Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************


Command (? for help):


Expert command (? for help): z
About to wipe out GPT on /dev/disk2. Proceed? (Y/N): Y
Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Warning: The kernel may continue to use old or deleted partitions.
You should reboot or remove the drive.
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
Blank out MBR? (Y/N):y
Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
```

Ça ne touche à rien.
Encore un comportement étrange :
je ne peux pas supprimer de fichier bien que je puisse les mettre dans la corbeille et la vider. Si j'éjecte le disque et que je le remonte, le fichier est revenu.
Idem si j'ajoute un fichier. Je peux le mettre, mais il disparait après éjection et remontage.
Chose "sympa" aussi, les fichiers "copiés" apparaissent sur la carte, mais le Finder m'indique qu'ils sont corrompus et je ne peux pas les ouvrir.


----------



## macomaniac (18 Mars 2018)

Tout s'est passé comme si *gdisk* avait opéré > mais rien ne s'est passé de ce qui était escompté (= effacement de la table de partition et disque non initialisé) --> puisque au ré-attachement de la carte tu récupères tout intact comme au départ.

Tu n'as qu'à reposter le tableau retourné par un : 
	
	



```
diskutil list
```

que je voie la configuration du disque *disk2*.


----------



## daffyb (18 Mars 2018)

hop : 

```
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *16.0 GB    disk2
   1:             Windows_FAT_16 RECOVERY                854.8 MB   disk2s1
   2:                      Linux                         33.6 MB    disk2s3
   3:             Windows_FAT_32 boot                    62.9 MB    disk2s5
   4:                      Linux                         6.9 GB     disk2s6
```


----------



## macomaniac (18 Mars 2018)

Ouaip ! --> changement = zéro.

ça sent le disque verrouillé (et la poubelle)-


----------



## daffyb (18 Mars 2018)

macomaniac a dit:


> Ouaip ! --> changement = zéro.
> 
> ça sent le disque verrouillé (et la poubelle)-


ouais, c'est bien ce que je pensais…


----------



## bompi (18 Mars 2018)

C'est assez typique des cartes fichues : cela m'est arrivé avec une carte SD de 64 GB (aargl !!) il y a un mois.

Je me suis amusé (?) à la reformater avec Linux, FreeBSD, Windows et Android avec deux issues possibles : une erreur manifeste ou pas d'erreur mais aucun changement. Rien n'y a fait (même pas la menace de la poubelle).


----------



## daffyb (18 Mars 2018)

bompi a dit:


> Je me suis amusé (?)


on s'amuse comme on peut 
il me reste un essai avec un outil Windows et après, c'est coup de ciseaux et poubelle. RIP !


----------



## daffyb (19 Mars 2018)

daffyb a dit:


> on s'amuse comme on peut
> il me reste un essai avec un outil Windows et après, c'est coup de ciseaux et poubelle. RIP !


MiniTool Partition Wizard sur Windows ne s'en sort pas mieux.
Windows 7 non plus...

Par contre, j'ai un autre outil qui lui me renvoie ENFIN une erreur:


> Format Failed: -Support non valde ou piste 0 incorrecte - disque inutilisable.


----------



## byte_order (20 Mars 2018)

Le connecteur sdcard des raspberry est connu pour etre fragile et au bout d'un certain temps générer des faux contacts entrainant des erreurs d'I/O qui peuvent se terminer par corrompre définitivement l'intégrité de la sd card.


----------



## daffyb (21 Mars 2018)

byte_order a dit:


> Le connecteur sdcard des raspberry est connu pour etre fragile et au bout d'un certain temps générer des faux contacts entrainant des erreurs d'I/O qui peuvent se terminer par corrompre définitivement l'intégrité de la sd card.


Pour info, c'est sur un Pi 2
Mais comme c'est un Raspberry Pi qui est dans une chaudière.
https://www.bricozone.fr/t/interface-vitodens-200-avec-raspberry-pi.14671/


----------



## daffyb (22 Mars 2018)

Quand on lit les avis… c'est éloquent, surtout pour la version 32 GO, Amazing !
http://www.samsung.com/fr/consumer/memory-storage/memory-storage/memory-cards/MB-MP16D/EU/#
http://www.samsung.com/fr/consumer/memory-storage/memory-storage/memory-cards/MB-MP32D/EU/#
Donc, pour en revenir à ma carte, vu que je l'avais achetée sur le Store Samsung (la bonne idée), je les ai appelé, et là :
SAV au top, comme chez Apple :
J'ai un bon pour un renvoi et ils me remboursent car ils ne peuvent pas me faire un échange. La solution royale aurait été un échange avec un modèle de capacité ou de performance supérieure, mais bon…
Conclusion, comme souvent, quand un fabricant a son propre store, toujours acheter chez lui !
J'ai plusieurs expériences à ce niveau :
Apple, Samsung, Philips…


----------

