10.11 El Capitan USB bloquée sur lecture seule
- Créateur du sujet yeedaki
- Date de début
donc pour mes futures clés USB qui devront migrer de Mac vers PC ou voiture tu me conseilles de les formater en "Format" exFAT et en "Schéma" MRB (Enregistrement de de démarrage principal) et de le faire directement depuis le disque physique et non pas depuis le volume physique externe USB ou en repliant le petit triangle pour occulter le volume, c'est ça j'ai bon ?
PS question de béotien ça change quoi de faire le formatage depuis le disque ou depuis le volume ?
Ce serait un disque dur, je chercherais une solution "logicielle"
Avec une clé USB, je sais par expérience que les problèmes (fréquents) sont dans 90% des cas des problèmes matériels.
Je pense que cette clé est morte (une soudure a lâché par exemple....) d'où mon conseil.
M
Membre supprimé 1060554
Invité
Salut yeedaki
Ne confonds pas le "tablage" et le "formatage".
Le "tablage" consiste à fixer sur le secteur de boot d'un disque une série de descripteurs conformes à un type de Programme Interne d'ordinateur (GPT pour un Programme Interne EFI, MBR pour un Programme Interne BIOS) et réalisant le "mappage logique" de l'espace total du disque : assimilation primaire des cellules du disque à une série continue de blocs (de 512 octets chacun) numérotés de 1 à n et regroupement secondaire des blocs en secteurs distincts = partitions.
Le "formatage" consiste à générer, par un logiciel dédié à cette opération (dit : « formateur de système de fichiers »), un système de fichiers sur l'en-tête = les premiers blocs d'une partition. Ce système de fichiers consiste en une série de fichiers gestionnaires des opérations de lecture / écriture aux blocs de la partition ( comme un fichier du catalogue, dit catalogue B-tree, un fichier des attributs étendus...). Il existe plusieurs types de systèmes de fichiers, le JHFS+ étant le standard Apple, le NTFS le standard Windows notamment.
En résumé : une Table de Partition gère logiquement l'espace total d'un disque, un système de fichiers gère logiquement l'espace local d'une partition. Si tu cibles (dans l'«Utilitaire de Disque» par exemple) le disque, tu agis sur sa table de partition globale (pour l'effacer et en recréer une neuve, par exemple, avec tant de partitions prévues, le formateur de système de fichiers étant appelé pour générer, sur chaque partition prévue, le type de système de fichiers envisagé) ; si tu cibles le volume (l'espace monté d'une partition), tu n'agis absolument pas sur la table de partition qui reste inchangée dans son type et dans le découpage des partitions, mais seulement sur le système de fichiers gestionnaire de la partition, que tu peux effacer pour le re-créer à l'identique ou le remplacer par un système de fichiers d'un autre type.
De ce point de vue, le message d'erreur : « Error: -69877: Couldn't open device » révèle que l'utilitaire diskutil ne peut pas écrire une nouvelle table de partition sur le secteur de boot GPT du disque (les 32 premiers blocs) qui paraît verrouillé (peut-être bien par la MBR du secteur 0 : conjecture hasardeuse de ma part).
Au point où tu en es, je te propose les quelques manipulations suivantes. D'abord, ta clé attachée au Mac, assure-toi de nouveau par un diskutil list que le disque de la clé est bien toujours identifié comme disk1. Cela fait, passe d'abord la commande :
qui commande le démontage du volume Boba Fett de la partition disk1s2 (si un système de fichiers est monté, en effet, la table de partition du disque ne peut pas être manipulée) => tu devrais avoir en réponse un :
Passe alors la commande :
qui tente de détruire la table de partition GPT sur l'en-tête des 32 premiers blocs du disque. Si ça passe, tu auras peut-être le message :
Comme le volume Boba Fett a normalement été remonté, repasse la commande de démontage :
puis passe la commande :
qui demande l'initialisation du secteur 0 recelant la suspicious MBR => tu devrais toucher l'affichage :
tu tape y en réponse (comme yes = oui) et tu valides par ↩︎.
Après ces interventions drastiques sur les 2 Tables de partition qui se disputaient l'en-tête du disque (aucun volume ne devant plus apparaître monté), tu conclus par un :
=> si tu obtiens un :
tu te retrouverais avec un standard table GPT > partition JHFS+, ce qui te permettrait de remanipuler ta clé à ta guise dans l'«Utilitaire de Disque»...
Ne confonds pas le "tablage" et le "formatage".
Le "tablage" consiste à fixer sur le secteur de boot d'un disque une série de descripteurs conformes à un type de Programme Interne d'ordinateur (GPT pour un Programme Interne EFI, MBR pour un Programme Interne BIOS) et réalisant le "mappage logique" de l'espace total du disque : assimilation primaire des cellules du disque à une série continue de blocs (de 512 octets chacun) numérotés de 1 à n et regroupement secondaire des blocs en secteurs distincts = partitions.
Le "formatage" consiste à générer, par un logiciel dédié à cette opération (dit : « formateur de système de fichiers »), un système de fichiers sur l'en-tête = les premiers blocs d'une partition. Ce système de fichiers consiste en une série de fichiers gestionnaires des opérations de lecture / écriture aux blocs de la partition ( comme un fichier du catalogue, dit catalogue B-tree, un fichier des attributs étendus...). Il existe plusieurs types de systèmes de fichiers, le JHFS+ étant le standard Apple, le NTFS le standard Windows notamment.
En résumé : une Table de Partition gère logiquement l'espace total d'un disque, un système de fichiers gère logiquement l'espace local d'une partition. Si tu cibles (dans l'«Utilitaire de Disque» par exemple) le disque, tu agis sur sa table de partition globale (pour l'effacer et en recréer une neuve, par exemple, avec tant de partitions prévues, le formateur de système de fichiers étant appelé pour générer, sur chaque partition prévue, le type de système de fichiers envisagé) ; si tu cibles le volume (l'espace monté d'une partition), tu n'agis absolument pas sur la table de partition qui reste inchangée dans son type et dans le découpage des partitions, mais seulement sur le système de fichiers gestionnaire de la partition, que tu peux effacer pour le re-créer à l'identique ou le remplacer par un système de fichiers d'un autre type.
--------------------
Une table de partition de type GPT s'inscrit sur les 32 premiers blocs du disque qui est son secteur de boot (avec un backup sur les 32 derniers blocs). Par contre, une table de partition de type MBR s'inscrit sur un secteur 0 du disque qui est son secteur de boot. Normalement, les 2 dispositifs sont exclusifs l'un de l'autre, mais en cas de combinaison (comme sur ta clé) : table GPT > partition exFAT, alors une hybridation intervient telle que 2 tables de partition se trouvent inscrites sur le disque : une MBR sur un secteur 0 et une GPT sur les 32 premiers blocs. Il n'est pas impossible alors qu'un conflit intervienne entre ces 2 types de descripteurs.
De ce point de vue, le message d'erreur : « Error: -69877: Couldn't open device » révèle que l'utilitaire diskutil ne peut pas écrire une nouvelle table de partition sur le secteur de boot GPT du disque (les 32 premiers blocs) qui paraît verrouillé (peut-être bien par la MBR du secteur 0 : conjecture hasardeuse de ma part).
Au point où tu en es, je te propose les quelques manipulations suivantes. D'abord, ta clé attachée au Mac, assure-toi de nouveau par un diskutil list que le disque de la clé est bien toujours identifié comme disk1. Cela fait, passe d'abord la commande :
Bloc de code:
diskutil umount disk1s2
Bloc de code:
Volume Boba Fett on disk1s2 unmountedPasse alors la commande :
Bloc de code:
sudo gpt destroy /dev/rdisk1
Bloc de code:
gpt destroy: /dev/rdisk1: Suspicious MBR at sector 0
Bloc de code:
diskutil umount disk1s2
Bloc de code:
sudo fdisk -i /dev/rdisk1
Bloc de code:
-----------------------------------------------------
------ ATTENTION - UPDATING MASTER BOOT RECORD ------
-----------------------------------------------------
Do you wish to write new MBR and partition table? [n]Après ces interventions drastiques sur les 2 Tables de partition qui se disputaient l'en-tête du disque (aucun volume ne devant plus apparaître monté), tu conclus par un :
Bloc de code:
sudo diskutil eraseDisk jhfs+ "Boba Fett" /dev/rdisk1
Bloc de code:
Started erase on disk1
Unmounting disk
Creating the partition map
Waiting for the disks to reappear
Formatting disk1s2 as Mac OS Extended (Journaled) with name Boba Fett
Initialized /dev/rdisk1s2 as a 4 GB case-insensitive HFS Plus volume with a 8192k journal
Mounting disk
Finished erase on disk1
Dernière édition par un modérateur:
Oui, MBR + exFAT. Oublier le GUID. Avec Windows il n'apporte que des problèmes.
Le GUID, c'est bien avec OS X pour un volume de démarrage et pour une partition chiffrée ; sur une clef USB destinée à un format Windows, avec une seule partition, ça n'a aucun intérêt, ça fait même perdre de la place.
T'as d'autres options car tu agis en amont.
Pour le reste, passe par les commandes données par Macomaniac. Le nouvel utilitaire (sic) de disque introduit par El Capitan emploie d'autres outils.
Il y a de fortes probabilités que Remy soit dans le vrai. Les clefs USB ne sont pas le support le plus fiable.
Dernière édition:
Bonjour macomaniac et surtout merci pour tes explications même si je pense avoir besoin d'une deuxième lecture voir une troisième pour tout comprendre ...
M
Membre supprimé 1060554
Invité
Ton essai de réparation dans l'«Utilitaire de Disque» signale que la carte de partition (dont dépend le système de fichiers du volume Boba Fett) doit être réparée. 2 vérifications sont alors lancées : la « vérification de la région de démarrage principale » (= le secteur de boot des 32 premiers blocs qui porte la Table de Partition GPT principale) et la « vérification de la région de démarrage alternative » (le secteur 0 qui porte la Table de Partition MBR secondaire) => le code de sortie annoncé est 1 (= présence d'erreur majeure) => échec de l'opération.
Ton essai de destruction par la commande sudo gpt destroy /dev/rdisk1 de la Table de Partition principale (la GPT des 32 premiers blocs) se solde également par une erreur : « gpt destroy: unable to open device '/dev/rdisk1': Permission denied ». La commande étant en droits root (sudo), j'interprète ce déni de permission comme une impossibilité : les écritures du disque sont figées.
Tu peux encore attacher ta clé à un PC et vérifier s'il est possible de la manipuler (ré-initialiser --> ajouter des fichiers). En cas de nouvel échec, autant donner raison àCassandre r e m y :
et déplacer l'appareil à la corbeille.
Ton essai de destruction par la commande sudo gpt destroy /dev/rdisk1 de la Table de Partition principale (la GPT des 32 premiers blocs) se solde également par une erreur : « gpt destroy: unable to open device '/dev/rdisk1': Permission denied ». La commande étant en droits root (sudo), j'interprète ce déni de permission comme une impossibilité : les écritures du disque sont figées.
Tu peux encore attacher ta clé à un PC et vérifier s'il est possible de la manipuler (ré-initialiser --> ajouter des fichiers). En cas de nouvel échec, autant donner raison à
et déplacer l'appareil à la corbeille.
Je remarque que tu sembles n'avoir essayé S.O.S. que sur Boba Fett. Et sur l'ensemble de la clef, au niveau de Generic Flash... ? Parce que si c'est la carte de partition qui est fautive, c'est de là qu'il faut agir.
M'enfin, si les lignes de commande ne sont pas passées, je ne vois pas beaucoup d'espoirs.
M'enfin, si les lignes de commande ne sont pas passées, je ne vois pas beaucoup d'espoirs.
Sujets similaires
10.12 Sierra
Echec installation MacOS Sierra
MacBook Pro
Carte SD lecture seule
