Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Formatage impossible clé USB

moko138

Naziel a écrit C'est pas linux qui a décidé de mettre la clé en lecture seule mais la clé elle même à mon avis

Tu as sûrement raison : on voit le même "Error is 30!" dans le lien trouvé par xubu1957.
- -

Comment fais-tu pour lire le code source ? J'ai tenté sudo cat /sbin/sgdisk | less, mais le retour - quand il est lisible - n'est pas convaincant.

[center]= =[/center]

Par ailleurs,

man sgdisk
Known bugs and limitations include:
       *      Converting  from  MBR  format  sometimes fails because of insufficient space at the
              start or (more commonly) the end of the disk. Resizing the partition  table  (using
              the  's' option in the experts' menu) can sometimes overcome this problem; however,
              in extreme cases it may be necessary to resize a partition using GNU  Parted  or  a
              similar tool prior to conversion with gdisk.

Converting from MBR format sometimes fails because of insufficient space at the start or (more commonly) the end of the disk.
C'est un sacré bug ! Et apparemment, c'est ce qui a eu lieu ici.
Même si je ne comprends toujours pas pourquoi, en l'occurrence, sgdisk a voulu d'abord convertir en gpt avant d'effacer ("converting MBR to GPT format in memory."). Alors que dans un test que j'avais fait il y a 3 semaines, j'avais tout simplement obtenu l'effacement direct :

sudo sgdisk -Z /dev/sdg
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.

- -

J'en retiens :
1) que - quand le support n'est pas mort - il faut d'abord réduire la dernière partition ou la supprimer (pour éviter le chevauchement, alias "overlap").

2) Que dans l'opération de nettoyage, il faut d'abord exécuter :

sudo dd if=/dev/zero of=/dev/disk/by-id/(...) bs=512 count=4096

et ensuite seulement :

sudo sgdisk -Z /dev/disk/by-id/(...)

ce qui donne (que je note dans mon mémo) :

sudo dd if=/dev/zero of=/dev/disk/by-id/(...) bs=512 count=4096; echo; sudo sgdisk -Z /dev/disk/by-id/(...)

NicoApi73

moko138 a écrit
Comment fais-tu pour lire le code source ? J'ai tenté sudo cat /sbin/sgdisk | less, mais le retour - quand il est lisible - n'est pas convaincant.

Salut moko

C'est l'exécutable que tu as regardé. La page d'un des développeur se trouve ici : http://www.rodsbooks.com/gdisk/ Tu trouves le lien à la fin de la page man (dans see also)

Et la page sourceforge dans laquelle se trouve le code source de la dernière version : https://sourceforge.net/projects/gptfdisk/files/gptfdisk/1.0.4/

Ce qui me surprend (un peu), c'est que c'est écrit en C++. Habituellement c'est en C.

xubu1957

Bonjour,

Pour le message d'erreur avec le nombre 30, je viens de trouver cette discussion > [ubuntu] USB is read only and won't unlock

NicoApi73

Naziel a écrit

      cerr << "Warning! MBR not overwritten! Error is " << errno << "!\n";

@Naziel : errno est une macro linux, pas une variable dans le programme, n'est ce pas?

Nuliel

http://manpagesfr.free.fr/man/man3/errno.3.html a écriterrno est définie par le standard ISO C comme une lvalue modifiable, de type int, et n'a pas besoin d'être définie explicitement. errno peut être une macro. errno est locale à un thread ; lui affecter une valeur dans un thread ne modifie pas sa valeur dans les autres threads.

(Je vois pas trop la différence entre macro et variable globale)
Pour moi c'est une sorte de variable globale qui est modifiée principalement par les appels systèmes (et par le programme lui même pour remettre errno à 0 afin de détecter d'autres erreurs)

Si on veut remettre la clé en marche il faudrait sûrement reflasher le bout de code dans le controller de la clé usb (j'ai déjà essayé pour le fun, j'ai jamais réussi)

NicoApi73

ok, je comprends pourquoi je ne trouvais pas où elle était déclarée.

Naziel a écritSi on veut remettre la clé en marche il faudrait sûrement reflasher le bout de code dans le controller de la clé usb (j'ai déjà essayé pour le fun, j'ai jamais réussi)

C'est la table des bad blocks qu'il faut écraser. Je ne pense pas qu'elle soit accessible. Ca ne change pas le problème que certains blocks ont morts et donc la clé inutilisable.

Ce qu'il faut savoir également, c'est que la flash NAND se dégrade (également) à la lecture. Elle a un nombre de cycle d'écriture limité, mais aussi un nombre de cycle de lecture limité (bien supérieur à celui de l'écriture)

Nuliel

Oui, elle n'est pas accessible, mais il est possible de reflasher certaines clés usb et ainsi supprimer cette table. Mais je n'ai jamais réussi pour l'instant

Ce qu'il faut savoir également, c'est que la flash NAND se dégrade (également) à la lecture. Elle a un nombre de cycle d'écriture limité, mais aussi un nombre de cycle de lecture limité (bien supérieur à celui de l'écriture)

Merci pour l'info, je ne savais pas

moko138

NicoApi73 a écrit C'est l'exécutable que tu as regardé. La page d'un des développeur se trouve ici : http://www.rodsbooks.com/gdisk/ Tu trouves le lien à la fin de la page man (dans see also)

Et la page sourceforge dans laquelle se trouve le code source de la dernière version : https://sourceforge.net/projects/gptfdisk/files/gptfdisk/1.0.4/

Salut NicoApi73,
Merci, le 1er lien est très intéressant.
Le second me fournit un zip contenant des exécutables pour windows.

Donc
a) Je n'ai pas trouvé de code source.
b) Avec quel outil ça se lit ?

Merci !

Nuliel

Le code source c'est le fichier gptfdisk-1.0.4.tar.gz
C'est dans le fichier gpt.cc que se trouve l'erreur rencontrée.
Je l'ai trouvé à coup de grep sur les sources

Un éditeur de texte est largement suffisant

NicoApi73

J'utilise beaucoup geany (c'est dans les dépôts officiels).

C'est effectivement le tar.gz qui contient l'ensemble des sources.

C'est programmé en C++, relativement bien commenté.

Le main se trouve dans sgdisk.cc

La class principale (GPTDataCL) se trouve dans gptcl.cc, qui hérite de GPTData qui se trouve dans gpt.cc (avec les headers .h associés)

moko138

NicoApi73 a écrit C'est la table des bad blocks qu'il faut écraser.

NON. NE PAS CONFONDRE !

Les badblocks sont codés dans le système de fichiers d'une partition - et encore : seulement s'il est de type Linux.
Donc leur liste disparaît avec un dd if=/dev/zero ... ou avec un reformatage.

Les secteurs défectueux, au sens où smartctl, sur un hdd ou sur un ssd, les voit,
sont stockés indépendamment des données,
dans deux listes :
- la Primary-List, (secteurs défectueux en sortie d'usine),
- la Secondary-List, (secteurs se révélant défectueux plus tard),

Concernant les clefs usb,
je manque d'informations.
Et la conception doit varier selon le sérieux du fabricant.
J'imagine seulement que, chez les fabricants sérieux, le stockage des badblocks et celui des secteurs défectueux sont séparés, comme pour les hdd et ssd.

Quant à flasher la puce, ça revient à remettre le thermomètre à 37°C : ça n'empêche pas le malade d'être fiévreux.
.
[center]= =[/center]
.
Annexes

man e2fsck
       -c     Cette  option oblige e2fsck à exécuter le programme badblocks(8)
              pour trouver les blocs défectueux du système de fichiers avec un
              test en lecture seule. Ils seront alors marqués comme défectueux
              et ajoutés à l'inœud des blocs défectueux pour éviter qu'ils  ne
              soient  utilisés  pour  un  fichier  ou  un répertoire. Si cette
              option est précisée deux fois, la recherche des blocs défectueux
              sera effectuée avec un test non destructif en lecture-écriture.

man mke2fs
       -c     Vérifier  les  blocs défectueux avant de créer le système de fichiers. Si cette
              option est indiquée deux fois, alors un test en lecture/écriture plus lent  est
              utilisé à la place d'un test rapide en lecture seule.

On peut, moyennant certaines options, lancer badblocks sur tout ou partie d'un disque, indépendamment des partitions.
Mais dans ce cas la sortie N'est PAS écrite dans le disque :

man badblocks
       -o fichier_sortie
              Écrire la liste des blocs défectueux dans  le  fichier  indiqué.
              Sans  cette  option,  badblocks  affiche  la liste sur la sortie
              standard. Le  format  de  ce  fichier  peut  être  utilisé  avec
              l'option -l de e2fsck(8) ou de mke2fs(8).

moko138

Naziel a écritLe code source c'est le fichier gptfdisk-1.0.4.tar.gz
C'est dans le fichier gpt.cc que se trouve l'erreur rencontrée.
Je l'ai trouvé à coup de grep sur les sources

Un éditeur de texte est largement suffisant

Merci ! 🙂

NicoApi73

moko138 a écrit
NicoApi73 a écrit C'est la table des bad blocks qu'il faut écraser.
NON. NE PAS CONFONDRE !

Les badblocks sont codés dans le système de fichiers d'une partition - et encore : seulement s'il est de type Linux.
Donc leur liste disparaît avec un dd if=/dev/zero ... ou avec un reformatage.

Les secteurs défectueux, au sens où smartctl, sur un hdd ou sur un ssd, les voit,
sont stockés indépendamment des données,
dans deux listes :
- la Primary-List, (secteurs défectueux en sortie d'usine),
- la Secondary-List, (secteurs se révélant défectueux plus tard),

Concernant les clefs usb,
je manque d'informations.
Et la conception doit varier selon le sérieux du fabricant.
J'imagine seulement que, chez les fabricants sérieux, le stockage des badblocks et celui des secteurs défectueux sont séparés, comme pour les hdd et ssd.

C'est vrai que les termes utilisés peuvent porter à confusion. Je parlais de ce que tu as nommé secteurs défectueux et dont la gestion au plus prêt du composant s'appelle BBM (Bad Block Management). Si tu connaissais déjà ce que je mets ci-dessous, veuilles bien m'en excuser.

Ce que je connais concerne les SLC NAND (Single Level Cell). Il y a peut être des différences pour les MLC (Multi Level Cell), voire d'autres méthodes de gestions, mais là je ne connais pas.

Au niveau de la gestion de la mémoire flash NAND, il y a un double système de gestion des défauts, l'un au niveau des bits dans un bloc, avec un système de correction d'erreur par bloc (ECC pour Error Correcting Code) et l'un au niveau des blocs (BBM), utilisant une table des bad blocks. C'est à cette table que je faisais référence, que certains appellent DBBT pour Discovered Bad Block Table. Cette table est mise à jour quand le nombre d'erreurs corrigeables pour un bloc est atteint.

Certains microcontroleurs et SOC sont paramétrables pour gérer directement la flash (ils ont des registres de configuration dédiés pour ça). Là on ne parle bien sûr que de la mémoire, sans contrôleur autour. Il est donc (théoriquement) possible d'accéder à la DBBT. Je ne pense pas que ce soit faisable sur une clé USB (encore moins un ssd) car ces modules ont de l'électronique embarquée qui gère directement la mémoire.

L'article wikipedia en anglais est plus complet que l'article français: https://en.wikipedia.org/wiki/Flash_memory. Le paragraphe NAND memories aborde ces sujets. C'est cohérent avec ce que je connais.

Pour préciser mon post #26, à la lecture il y a un risque de corrompre les cellules adjacentes. Ce qui n'est pas réellement une usure contrairement à ce que j'ai écrit. Les blocs sont monitorés en lecture et quand un nombre de lecture est atteint, le bloc est recopié dans un autre bloc.

La qualité de ce type de produits est étroitement lié à la qualité de la puce. S'il y a trop de fuite dans les portes (NAND gates), il y a corruption des données (pas uniquement la porte concernée, ça peut migrer dans les cellules adjacentes physiquement). Normalement, ça peut être effacé en formatant et habituellement ce n'est pas mémorisé dans la DBBT.
De même, le nombre de badblocks (secteurs défectueux) en sortie d'usine est également un gage de qualité, au même titre que le nombre moyen d'écriture garanti et celui de lecture. Par contre à ce niveau, quand une cellule devient défectueuse, elle ne peut pas être régénérée et le bloc est considéré comme inutilisable.

Pour l'instant je ne sais pas mettre ceci en relation avec les annexes que tu as données. Ce que j'ai écrit ci-dessus correspond plus aux retours des informations smart.

moko138

Merci ! Non, je ne connaissais pas cela.

Jpomec

Ca a l'air hyper intéressant ce que vous racontez, mais je manque cruellement de background. Vous n'auriez pas un petit lien pour que je me fasse les dents ?

moko138

On a abordé plusieurs aspects !
Tu peux lorgner de ce côté-ci, entre autres : thouvest.ovh/pages/hdd_defectueux/

NicoApi73

Bonjour,

Pour ce qui est de la technologie, les fondeurs mettent parfois des informations à disposition. Tu peux regarder chez des fabricants tels Micron, Macronix, Microchip, Cypress... On parle bien là de la partie mémoire, sur une clé par exemple, il y a de l'électronique autour (en général ce sont des puces intégrées qui contiennent la mémoire et le driver HW).

Sur le net tu peux trouver des informations intéressantes, mais aussi beaucoup de choses qui sont incomplètes ou fausses.

Nuliel

Tite question: peut on avoir le nom du controller de la clé usb sur linux?

NicoApi73

Comme ça, je ne sais pas répondre. Je vais regarder si je trouve quelque chose.

moko138

Je tente

lsusb | grep Lexar
Bus 001 Device 012: ID 05dc:c75c Lexar Media, Inc.

Je récupère 001 012 et je lance

sudo lsusb -D /dev/bus/usb/001/012

Mais je ne sais pas si le "Controller" y figure (si oui, c'est codé).

(Ce retour ressemble furieusement à celui de lsusb -v | grep -A100 Lexar ).

« Page précédente Page suivante »