Bah! Si c'est matériel, Windows ne pourra rien y faire non plus. Si c'est logiciel, il est vraisemblablement à l'origine du problème.
10.11 El Capitan USB bloquée sur lecture seule
- Créateur du sujet yeedaki
- Date de début
Bof... On finit pas s'y faire.
Récemment c'est un PC qui m'a permis de récupérer un fichier Excel comportant de nombreuses macros et que je ne pouvais plus ouvrir sur Mac sans désactiver les macros.
C'est encore un PC (le meme) qui m'a permis d'effectuer un CHKDSK sur une partition BootCamp et réparer les erreurs qui empêchaient WinClone de me la dupliquer.
Bref un PC dans sa boîte à outils c'est toujours utile meme pour un Mac-user convaincu.
(Mais pour ta clé, je reste convaincu que c'est un problème matériel que le PC ne saura pas plus outrepasser. Fais une recherche Google sur "clé USB protégée en écriture" et tu verras que dans quasiment tous les cas le diagnostic finit par conclure au décès de la clé...)
Récemment c'est un PC qui m'a permis de récupérer un fichier Excel comportant de nombreuses macros et que je ne pouvais plus ouvrir sur Mac sans désactiver les macros.
C'est encore un PC (le meme) qui m'a permis d'effectuer un CHKDSK sur une partition BootCamp et réparer les erreurs qui empêchaient WinClone de me la dupliquer.
Bref un PC dans sa boîte à outils c'est toujours utile meme pour un Mac-user convaincu.
(Mais pour ta clé, je reste convaincu que c'est un problème matériel que le PC ne saura pas plus outrepasser. Fais une recherche Google sur "clé USB protégée en écriture" et tu verras que dans quasiment tous les cas le diagnostic finit par conclure au décès de la clé...)
regarde l'execution de SOS est passé malgré tout je vois "des problèmes rencontrés sur la carte de partition risquant d'empêcher le démarrage"
Bref, je ne sais pas s'il y a un rapport entre un problème qui risque d'empêcher le démarrage et la clé en lecture seule mais perso ça ne me parle pas beaucoup ...
M
Membre supprimé 1060554
Invité
Salut yeedaki
Ta clé attachée à ton Mac, vérifie une fois de plus au préalable par un diskutil list que le disque global de ta clé est bien identifié comme disk1 (le disque de ton Mac, ou premier disque, étant identifié par défaut comme disk0 - si tu avais un ou plusieurs périphériques intercalés, tu modifierais comme il faut le numéro du disque pour qu'il corresponde à celui de ta clé dans la commande suivante).
Passe à présent la commande :
et ↩︎ --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> cette commande appelle l'utilitaire gpt (GUID Partition Table maintenance utility) avec le verbe show (montrer) sur la cible du device (appareil) : disk1.
Comme c'est une commande de simple lecture, elle doit passer et tu vas voir s'afficher le tableau de la distribution des blocs, qui constitue la "carte logique" du disque de ta clé => est-ce que tu peux faire un copier-coller de l'ensemble de ce tableau ici (pas de cliché) ?
Ta clé attachée à ton Mac, vérifie une fois de plus au préalable par un diskutil list que le disque global de ta clé est bien identifié comme disk1 (le disque de ton Mac, ou premier disque, étant identifié par défaut comme disk0 - si tu avais un ou plusieurs périphériques intercalés, tu modifierais comme il faut le numéro du disque pour qu'il corresponde à celui de ta clé dans la commande suivante).
Passe à présent la commande :
Bloc de code:
sudo gpt show /dev/disk1Comme c'est une commande de simple lecture, elle doit passer et tu vas voir s'afficher le tableau de la distribution des blocs, qui constitue la "carte logique" du disque de ta clé => est-ce que tu peux faire un copier-coller de l'ensemble de ce tableau ici (pas de cliché) ?
Salut macomaniac,
voici le résultat de la commande ...
et en version copier/coller
gpt show: /dev/disk1: Suspicious MBR at sector 0
start size index contents
0 1 MBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
409640 2008
411648 7573504 2 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
7985152 2015
7987167 32 Sec GPT table
7987199 1 Sec GPT header
dis moi y'aurait pas un conflit entre le MBR de la ligne 0 MBR et le reste qui est en GPT ?
Je sens que mon hypothèse d'une défaillance matérielle est en train de battre de l'aile.... au profit d'un conflit logiciel entre une table de partition GPT créée initialement sur le Mac et un boot block passé de force en MBR à l'occasion d'un fricotage entre cette clé et un PC sous Windows
M
Membre supprimé 1060554
Invité
Comme je le subodorais, il existe 2 secteurs de boot (espaces de démarrage) alternatifs sur le disque de la clé :
[Sinon, tous les blocs intermédiaires sont répartis régulièrement entre les 2 partitions EFI (n°1) et Boba Fett (n°2) avec des zones-tampons (de 6 blocs, 2008 blocs et 2015 blocs) sans qu'il y ait aucune anomalie à remarquer à ce niveau-là].
Il y a donc en somme 2 secteurs de boot alternatifs sur ce disque (bloc 0 et blocs 1-32) avec 2 Tables de Partitions alternatives : [Hybrid]_MBR et GPT.
La commande que j'avais proposée précédemment : sudo gpt destroy /dev/rdisk1 s'adressait directement aux blocs 1-32 afin de tenter d'effacer la GPT qui y était inscrite - malheureusement, même en droits root et le système de fichiers de la Boba Fett démonté en volume, cette initiative d'écriture a été rejetée au motif de : « unable to open device '/dev/rdisk1' ».
Il est aisé de vérifier si une commande de ré-initialisation adressée ce coup-ci au secteur 0 (afin d'effacer l'Hybrid_MBR en place) est honorée, ou si un message d'erreur du même type que pour la commande gpt se trouve renvoyé.
Donc : ta clé attachée au Mac et t'étant toujours assuré par un diskutil list préalable que le disque de ta clé est bien identifié comme un disk1, d'abord tu passes une commande de démontage en volume du système de fichiers de Boba Fett (condition pour tenter de manipuler les Tables de Partition) :
qui devrait te retourner un :
Tu essaies alors la commande suivante :
qui appelle l'utilitaire fdisk ce coup-ci (fat_disk maintenance utility : utilitaire de maintenance des disques MS-DOS) sur la cible du secteur 0 du disque de la clé pour tenter d'initialiser sa table de partition MBR => tu vas bien voir si la commande est honorée... ou s'il y a rejet de la tentative d'écriture.
[NB. Utiliser rdisk au lieu de disk a pour signification d'adresser le «raw_disk», càd. les blocs bruts, et pas leur représentation dans un cache ou «buffer» => on peut considérer qu'une commande de ce type est plus brut(al)e
]
- Un secteur MBR dont la taille est de 1 cluster (= bloc n°0) qui supporte un boot_code, un magic_number + les descripteurs d'une Table de Partition qui est probablement une "Hybrid_MBR" (= MBR ayant intégré a posteriori comme secteurs de sa propre carte des partitions définies a priori dans une GPT : l'EFI et la Bobba Fett) : mon interprétation du « suspicious MBR » allégué.
- Un secteur GPT dont la taille est de 32 clusters (= blocs 1 à 32) qui supporte les descripteurs de la Table de Partition GUID (avec une redondance sur les 32 derniers blocs = 7987167 à 7987199 qui constitue le backup de la GPT des 32 premiers blocs).
- Un secteur GPT dont la taille est de 32 clusters (= blocs 1 à 32) qui supporte les descripteurs de la Table de Partition GUID (avec une redondance sur les 32 derniers blocs = 7987167 à 7987199 qui constitue le backup de la GPT des 32 premiers blocs).
[Sinon, tous les blocs intermédiaires sont répartis régulièrement entre les 2 partitions EFI (n°1) et Boba Fett (n°2) avec des zones-tampons (de 6 blocs, 2008 blocs et 2015 blocs) sans qu'il y ait aucune anomalie à remarquer à ce niveau-là].
Il y a donc en somme 2 secteurs de boot alternatifs sur ce disque (bloc 0 et blocs 1-32) avec 2 Tables de Partitions alternatives : [Hybrid]_MBR et GPT.
La commande que j'avais proposée précédemment : sudo gpt destroy /dev/rdisk1 s'adressait directement aux blocs 1-32 afin de tenter d'effacer la GPT qui y était inscrite - malheureusement, même en droits root et le système de fichiers de la Boba Fett démonté en volume, cette initiative d'écriture a été rejetée au motif de : « unable to open device '/dev/rdisk1' ».
Il est aisé de vérifier si une commande de ré-initialisation adressée ce coup-ci au secteur 0 (afin d'effacer l'Hybrid_MBR en place) est honorée, ou si un message d'erreur du même type que pour la commande gpt se trouve renvoyé.
Donc : ta clé attachée au Mac et t'étant toujours assuré par un diskutil list préalable que le disque de ta clé est bien identifié comme un disk1, d'abord tu passes une commande de démontage en volume du système de fichiers de Boba Fett (condition pour tenter de manipuler les Tables de Partition) :
Bloc de code:
diskutil umount disk1s2
Bloc de code:
Volume Boba Fett on disk1s2 unmounted
Bloc de code:
sudo fdisk -i /dev/rdisk1[NB. Utiliser rdisk au lieu de disk a pour signification d'adresser le «raw_disk», càd. les blocs bruts, et pas leur représentation dans un cache ou «buffer» => on peut considérer qu'une commande de ce type est plus brut(al)e
Dernière édition par un modérateur:
Comme je le subodorais, il existe 2 secteurs de boot (espaces de démarrage) alternatifs sur le disque de la clé :
- Un secteur MBR dont la taille est de 1 cluster (= bloc n°0) qui supporte un boot_code, un magic_number + les descripteurs d'une Table de Partition qui est probablement une "Hybrid_MBR" (= MBR ayant intégré a posteriori comme secteurs de sa propre carte des partitions définies a priori dans une GPT : l'EFI et la Bobba Fett) : mon interprétation du « suspicious MBR » allégué.
- Un secteur GPT dont la taille est de 32 clusters (= blocs 1 à 32) qui supporte les descripteurs de la Table de Partition GUID (avec une redondance sur les 32 derniers blocs = 7987167 à 7987199 qui constitue le backup de la GPT des 32 premiers blocs).
[Sinon, tous les blocs intermédiaires sont répartis régulièrement entre les 2 partitions EFI (n°1) et Boba Fett (n°2) avec des zones-tampons (de 6 blocs, 2008 blocs et 2015 blocs) sans qu'il y ait aucune anomalie à remarquer à ce niveau-là].
Il y a donc en somme 2 secteurs de boot alternatifs sur ce disque (bloc 0 et blocs 1-32) avec 2 Tables de Partitions alternatives : [Hybrid]_MBR et GPT.
La commande que j'avais proposée précédemment : sudo gpt destroy /dev/rdisk1 s'adressait directement aux blocs 1-32 afin de tenter d'effacer la GPT qui y était inscrite - malheureusement, même en droits root et le système de fichiers de la Boba Fett démonté en volume, cette initiative d'écriture a été rejetée au motif de : « unable to open device '/dev/rdisk1' ».
Il est aisé de vérifier si une commande de ré-initialisation adressée ce coup-ci au secteur 0 (afin d'effacer l'Hybrid_MBR en place) est honorée, ou si un message d'erreur du même type que pour la commande gpt se trouve renvoyé.
Donc : ta clé attachée au Mac et t'étant toujours assuré par un diskutil list préalable que le disque de ta clé est bien identifié comme un disk1, d'abord tu passes une commande de démontage en volume du système de fichiers de Boba Fett (condition pour tenter de manipuler les Tables de Partition) :
qui devrait te retourner un :Bloc de code:diskutil umount disk1s2
Tu essaies alors la commande suivante :Bloc de code:Volume Boba Fett on disk1s2 unmountedqui appelle l'utilitaire fdisk ce coup-ci (fat_disk maintenance utility : utilitaire de maintenance des disques MS-DOS) sur la cible du secteur 0 du disque de la clé pour tenter d'initialiser sa table de partition MBR => tu vas bien voir si la commande est honorée... ou s'il y a rejet de la tentative d'écriture.Bloc de code:sudo fdisk -i /dev/rdisk1
[NB. Utiliser rdisk au lieu de disk a pour signification d'adresser le «raw_disk», càd. les blocs bruts, et pas leur représentation dans un cache ou «buffer» => on peut considérer qu'une commande de ce type est plus brut(al)e]
Grrrrr la vilaine ne se laisse pas faire !!!!
M
Membre supprimé 1060554
Invité
Bon : ça ne marche pas mieux avec fdisk. Je te propose encore une tentative différente =>
Tu attaches ta clé au Mac (ou tu la détaches, si elle était restée attachée et tu la ré-attaches), ce qui fait monter le volume Boba Fett sur le Bureau de session. Retour au «Terminal». Vérifie comme toujours par un diskutil list préalable que le disque est bien disk1. Puis comme précédemment par un :
tu re-démontes le système de fichiers de Boba Fett (tu as un message de démontage et l'icône du volume disparaît du Bureau). À présent, tu tentes un :
(avec mot-de-passe admin à l'aveugle) --> cette commande appelle l'utilitaire mount (qui permet de monter des systèmes de fichiers de partitions selon des options spécifiées) avec les options suivantes : -t exFAT => format exFAT comme type de système de fichiers ; -w => remonter le système de fichiers en mode read_write = lecture & écriture ; -o noowners => ignorer l'ownership, càd. les propriétés en place sur le volume de la partition, au profit de l'utilisateur dont la session est ouverte et qui fait monter le volume - tout ce paquet sur la cible du système de fichiers de la partition /dev/disk1s2 = Boba Fett et indication du répertoire /tmp (éléments temporaires) comme point de remontage du système de fichiers.
=> tu vas vite être édifié : si la commande passait, l'invite de commande valdamour$ se réafficherait directement sans message d'erreur et tu verrais ré-apparaître l'icône du volume Boba Fett sur ton Bureau de session --> si jamais il en était ainsi, tente un glisser-déposer de fichier dans le volume pour voir ce qui se passe. Par contre, si le système de fichiers est verrouillé dans son mode de montage, tu vas te faire rembarrer dans le «Terminal».
Tu attaches ta clé au Mac (ou tu la détaches, si elle était restée attachée et tu la ré-attaches), ce qui fait monter le volume Boba Fett sur le Bureau de session. Retour au «Terminal». Vérifie comme toujours par un diskutil list préalable que le disque est bien disk1. Puis comme précédemment par un :
Bloc de code:
diskutil umount /dev/disk1s2
Bloc de code:
sudo mount -t exFAT -w -o noowners /dev/disk1s2 /tmp=> tu vas vite être édifié : si la commande passait, l'invite de commande valdamour$ se réafficherait directement sans message d'erreur et tu verrais ré-apparaître l'icône du volume Boba Fett sur ton Bureau de session --> si jamais il en était ainsi, tente un glisser-déposer de fichier dans le volume pour voir ce qui se passe. Par contre, si le système de fichiers est verrouillé dans son mode de montage, tu vas te faire rembarrer dans le «Terminal».
Dernière édition par un modérateur:
ben quand ça veut pas ça veut pas ... elle est coriace la bougresse !!!!!
mount_exFAT: /dev/disk1s2 on /private/tmp: Permission denied
Dernière édition:
M
Membre supprimé 1060554
Invité
Je te propose encore une tentative (un baroud d'honneur, quoi).
Clique le lien de téléchargement ☞Download gdisk-1.0.1.pkg (725.9 kB)☜ qui va te faire télécharger le gdisk-1.0.1-2.pkg. Un double-clic dessus te permettra de lancer l'installation de l'utilitaire de Roderick Smith (le développeur de «rEFInd») : gdisk at: /usr/local/bin (même si le SIP est actif dans ton «El Capitan», il ne verrouille pas normalement l'adresse /usr/local et ses dépendances). gdisk est un utilitaire interactif de maintenance des tables de partition gpt.
Ta clé attachée à ton Mac et vérification faite que son disque est bien toujours disk1, passe la commande qui appelle gdisk sur cette cible :
(avec password à l'aveugle) --> tu devrais toucher en retour quelque chose qui ressemblera à :
--> saisis :
et ↩︎ qui demande la création d'un nouvelle table de partition gpt vide --> tu devrais toucher un :
(cette option détruit toutes les partitions et crée une nouvelle "protective_MBR") --> saisis :
et ↩︎ --> tu devrais récupérer en retour le prompt interactif :
--> saisis :
et ↩︎ (qui demande d'écrire la nouvelle gpt au disque) --> tu pourrais toucher en retour un :
(Vérification finale terminée. Prêt à écrire les données gpt. Cette opération écrasera les partitions existantes !! - Voulez-vous l'exécuter?) --> saisis :
et ↩︎ --> si l'écriture de la nouvelle gpt réussissait, tu toucherait un :
Clique le lien de téléchargement ☞Download gdisk-1.0.1.pkg (725.9 kB)☜ qui va te faire télécharger le gdisk-1.0.1-2.pkg. Un double-clic dessus te permettra de lancer l'installation de l'utilitaire de Roderick Smith (le développeur de «rEFInd») : gdisk at: /usr/local/bin (même si le SIP est actif dans ton «El Capitan», il ne verrouille pas normalement l'adresse /usr/local et ses dépendances). gdisk est un utilitaire interactif de maintenance des tables de partition gpt.
Ta clé attachée à ton Mac et vérification faite que son disque est bien toujours disk1, passe la commande qui appelle gdisk sur cette cible :
Bloc de code:
sudo gdisk /dev/disk1
Bloc de code:
Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Partition table scan:
MBR: hybrid
BSD: not present
APM: not present
GPT: present
Found valid GPT with hybrid MBR; using GPT.
Command (? for help): ?
Bloc de code:
o
Bloc de code:
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N):
Bloc de code:
Y
Bloc de code:
Command (? for help):
Bloc de code:
w
Bloc de code:
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N):
Bloc de code:
Y
Bloc de code:
OK; writing new GUID partition table (GPT) to /dev/disk1.
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.
The operation has completed successfully.--> si tu lisais la dernière phrase : "L'opération a complètement réussi", il te faudrait détacher la clé du Mac puis la ré-attacher car, comme le remarque Roderick Smith : « le kernel est susceptible de continuer à utiliser les partitions précédentes ou détruites » (et par exemple ici de maintenir un volume monté alors que tous les systèmes de fichiers de partitions ont été supprimés).
Cette opération par gdisk non seulement réécrit la table de partition GPT sur les 32 premiers blocs du disque (sans recréer de partition), mais également efface l'Hybrid_MBR du secteur 0 pour la remplacer par une Protective_MBR qui ne peut pas interférer avec la GPT, car elle ne comporte pas par défaut de partitions définies : elle est censée seulement protéger la GPT active contre des interférences venant d'autres systèmes d'exploitations qu'OS X. Au cas où la commande aurait réussi, aucun volume n'apparaîtrait plus monté sur le Bureau au ré-attachement de la clé (car aucune partition n'a été recréée avec un système de fichier) => lancer l'«Utilitaire de Disque» et effacer le disque de la clé pour recréer une table de partition avec une partition principale.
--> si le disque de la clé continue d'être verrouillé à l'écriture, tu toucheras par contre un message d'échec et tout restera comme avant...
Cette opération par gdisk non seulement réécrit la table de partition GPT sur les 32 premiers blocs du disque (sans recréer de partition), mais également efface l'Hybrid_MBR du secteur 0 pour la remplacer par une Protective_MBR qui ne peut pas interférer avec la GPT, car elle ne comporte pas par défaut de partitions définies : elle est censée seulement protéger la GPT active contre des interférences venant d'autres systèmes d'exploitations qu'OS X. Au cas où la commande aurait réussi, aucun volume n'apparaîtrait plus monté sur le Bureau au ré-attachement de la clé (car aucune partition n'a été recréée avec un système de fichier) => lancer l'«Utilitaire de Disque» et effacer le disque de la clé pour recréer une table de partition avec une partition principale.
--> si le disque de la clé continue d'être verrouillé à l'écriture, tu toucheras par contre un message d'échec et tout restera comme avant...
Dernière édition par un modérateur:
Sujets similaires
10.12 Sierra
Echec installation MacOS Sierra
MacBook Pro
Carte SD lecture seule
