10.11 El Capitan Disque dur non lisible

swake29

swake29

Membre actif
1 Juin 2016
122
4
53
Bonjour, j'ai remplacé le disque dur de mon Mac Mini par un SSD me disant que ensuite je pourrais transférer les photo qui ce trouve dessus.

J'ai donc mis l'ancien DD dans un boitier externe que j'ai relié en USB au Mac Mini mais le problème
c'est que sa me signal que ce disque ne pas pas être lu sur cette ordinateur.

Ais je une solution?

lisible.png
 
Ce que propose OSX par défaut lors d'un formatage, je ne suis pas un grand spécialiste donc je touche à rien.

J'ai aussi essayé sur mon iMac mais même boite de dialogue.
 
Tu es sûr de ton boîtier, tu l'avais déjà utilisé précédemment ?

Tu pourrais peut-être remettre le DD dans le Mac Mini et redémarrer.
S'il ne redémarre pas c'est peut-être que le disque est, en fait, cassé (soit, pas de chance, c'est arrivé pile poil au moment où tu le manipules, soit c'est parce qu'il est tombé ou a été secoué alors qu'il fonctionnait et une des têtes à abîmé un plateau, par exemple).
Une fois redémarré, tu prends le maximum d'information à son sujet avec l'utilitaire de disque, voire dans Terminal avec la commande diskutil (on commence par diskutil list puis on peut approfondir).
S'il permet bien au Mac de redémarrer lorsqu'il est à l'intérieur, je dirais que rien n'est perdu (optimiste...)
Notamment la possibilité alors d'en faire une sauvegarde sur un autre disque externe (essentiel, ça, les sauvegardes !!)

Enfin, toujours si le Mac Mini a redémarré avec son ancien disque, essaie de connecter le SSD par le truchement du boîtier et dis-nous ce qui se passe.
 
J'ai oublié un détail, le remplacement était pour une vente.
J'ai voulu faire le transfert avant qu'il ne parte mais c'est à ce moment la que je m'en suis aperçu.
Il n'y à pas un logiciel qui me permettrai de lire et récupérer ce qui si trouve sans avoir à le faire démarrer depuis une machine?
 
Salut swake

Quand tu connectes en USB ton boîtier qui contient l'ancien HDD > le disque se trouve « attaché » au Système de l'OS démarré > cet « attachement » au Système entraîne une « probation » du dispositif logique du disque par le daemon diskarbitrationd > en cas de table de partition lisible répertoriant des secteurs gérés par des systèmes de fichiers identifiables > les informations sont passées au kernel qui va monter les volumes correspondants.

L'affichage par le Finder d'un panneau : « Le disque que vous avez inséré n'est pas lisible par cet ordinateur » est le signalement d'un échec de la « probation » du dispositif logique du disque par diskarbitrationd :

- soit aucune table de partition n'est trouvée présente sur le secteur de boot du disque (et par suite aucun secteur recélant des systèmes de fichiers ne peut être reconnu) > ce qui peut arriver : un disque peut être vendu sans aucune table de partition inscrite, ou le secteur de boot d'un disque peut être expérimentalement effacé (il m'est arrivé de le faire > pour voir l'effet produit...) ;

- soit une table de partition présente sur le secteur de boot n'est pas reconnue lisible par diskarbitrationd (il peut se faire que des erreurs graves se produisent dans les descripteurs d'une table de partition. Ou encore que la table de partition n'ait pas un schéma reconnaissable : par exemple, connecter une clé USB dont le disque supporte une GPT <GUID Partition Table> à un Mac PPC dont l'OS démarré est «Tiger» > fait que le diskarbitrationd de «Tiger» qui s'attend à une Carte de Partition Apple ne comprend rien à la GPT) ;

- soit enfin, une table de partition présente étant lisible, aucun secteur du disque qu'elle répertorie n'est reconnu porteur d'un système de fichiers d'un format identifiable (il m'est arrivé expérimentalement d'instaurer un format CoreStorage sur la partition d'une clé USB > puis de la connecter à un Mac ancien dont l'OS démarré était «Snow Léopard 10.6» > le résultat de la « probation » est le même panneau : « Le disque que vous avez inséré n'est pas lisible par cet ordinateur » > parce que, si une table de partition GUID est bien lue par le diskarbitrationd de 10.6, le format CoreStorage est illisible dans l'environnement de cet OS, puisqu'il n'a été créé qu'à partir de «Lion 10.7»...​

Ce contexte général brossé > si l'OS installé dans le volume principal du HDD était au moins «Snow Léopard 10.6» > alors la table de partition sur le secteur de boot du disque est nécessairement une GPT > et le format du système de fichiers gestionnaire de la partition est un JHFS+ (Mac OS étendu journalisé). En conséquence > un dispositif logique parfaitement identifiable par le diskarbitrationd de l'OS Intel que je suppose démarré.

Je rejoins donc bompi :

--> soit il y a un problème physique qui empêche la probation du dispositif logique du disque : boîtier défectueux ou atterrissage des têtes de lecture sur un plateau. Est-ce que tu entends ou sens tourner le disque à la connexion ? Si oui, essaie avec un autre boîtier (replacer le disque dans le Mac pour tenter de booter dessus équivaut à changer de boîtier, si tu n'en as pas un autre).

--> soit (pour une raison qui m'échappe) il y a échec de la probation logique du disque, alors que, physiquement parlant, tout est en ordre. Afin de récolter des informations > une fois le disque attaché > presse le bouton "Ignorer" dans le panneau du Finder pour éviter les 2 autres options ("Éjecter" = désattacher le disque du Système ou "Initialiser" = effacer la table de partition) > va alors à : Applications > Utilitaires > lance le «Terminal» > dans la fenêtre ouverte, saisis la commande :
Bloc de code: 
diskutil list
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) => en retour, tu vas voir s'afficher le tableau des disques attachés au Mac (en interne / externe) avec leurs tables de partition et leurs partitions décrites en format > nom > taille > device. Peux-tu poster ici ce tableau en copier-coller (sans prendre de photo d'écran) > qu'on voie comment le disque est appréhendé par le Système ?
 
Salut swake

Dans ta capture > quel est le n° du disque concerné par le message : « Le disque que vous avez inséré n'est pas lisible par cet ordinateur » ?
 
Le /dev/disk4 ? - bouffre ! Tu as vu comment il se présente ?

Bloc de code: 
/dev/disk4 (external, physical):
   #:                        TYPE NAME                    SIZE       IDENTIFIER
   0:      FDisk_partition_scheme                        *320.1 GB   disk4
   1:                        0xEE                         320,1 GB   disk4s1

Au lieu d'avoir en table de partition en usage une GUID_partition_scheme (GPT) > tu as une FDisk_partition_scheme (MBR). Ce qui revient à dire que la carte de partition secondaire MBR a pris le pas sur la GPT principale et commande la lecture du disque (alors que c'est un ancien disque-Système d'OS X ! - incompréhensible).

Or qu'est-ce que cette MBR usurpatrice annonce comme partitionnement ? Une seule partition de 320 Go de type 0xEE - qui est la manière dont une Protective_MBR cartographie en une seule section tout l'espace d'un disque.

Cette combinaison d'une carte de partition MBR qui a pris l'ascendant en volatilisant la carte de partition GPT et d'une description du disque comme constitué d'une seule partition totale au lieu des 3 partitions Apple originales => fait qu'aucun volume ne peut monter lorsque tu attaches ton disque au Mac.

Ce que je me demande > c'est si cette situation est récupérable ou non ? Et là ça devient super-technique, ce type d'opération logique...

Je te propose de passer dans le «Terminal» la commande (purement informative = lecture seule - aucune action d'écriture) suivante :
Bloc de code: 
sudo gpt show /dev/disk4
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 ↩︎

=> en retour > tu vas voir s'afficher le tableau de la distribution des blocs du disque 4 > avec identification des tables de partition inscrites sur le secteur d'amorçage - voire en backup de fin du disque. Poste ce tableau ici, mais en copier-coller s'il te plaît et pas en cliché d'écran : tu sélectionnes le tableau > ⌘C pour copier la sélection dans le presse-papier > ⌘V pour la coller dans ce fil (c'est parce qu'un affichage tout en texte est beaucoup plus lisible).
 
Last login: Thu Oct 6 07:39:30 on console

diskutil list

/dev/disk0 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *250.1 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_HFS Macintosh HD 249.2 GB disk0s2

3: Apple_Boot Recovery HD 650.0 MB disk0s3

/dev/disk2 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: Apple_partition_scheme +19.7 MB disk2

1: Apple_partition_map 32.3 KB disk2s1

2: Apple_HFS Flash Player 19.7 MB disk2s2

/dev/disk3 (external, physical):

#: TYPE NAME SIZE IDENTIFIER

0: FDisk_partition_scheme *320.1 GB disk3

1: 0xEE 320.1 GB disk3s1

sudo gpt show /dev/disk3

Password:

Sorry, try again.

Password:

start size index contents

0 1 PMBR

1 78142805
 
Salut swake

La commande :
Bloc de code: 
sudo gpt show /dev/disk3
retourne donc ceci :
Bloc de code: 
0 1 PMBR
1 78142805

En voici l'interprétation : il y a une seule carte de partition sur ce disque : une MBR résidant sur le bloc 0 (et dont l'étendue est donc comptabilisée comme 1 = 1 seul bloc)

Cette carte de partition est une PMBR (Protective_MBR) dont la particularité est de cartographier l'espace total du disque comme équivalant à une partition unique.

C'est ce qui ressort, puisque la seule partition identifiée en-dessous de ce secteur d'amorçage du disque réduit à un bloc (0) > c'est une mono-partition totale allant du bloc 1 au bloc final 78142805.

Ce qui est à noter, c'est qu'aucune carte de partition GPT (GUID Partition Table) n'existe sur ce disque, ni sur le secteur d'amorçage initial (où elle devrait résider sur les blocs 1 > 32), ni en queue de disque où les 32 derniers blocs devraient porter le backup (sauvegarde) de cette GPT.

J'avais secrètement espéré que la GPT du secteur d'amorçage ayant été détruite, son backup sur les 32 derniers blocs aurait été préservé > de sorte qu'il aurait été possible de reconstruire une GPT sur les 32 premiers blocs à partir de son image préservée des 32 derniers blocs.

Mais ce n'est pas le cas. Du tout.

J'ajoute encore que si la PMBR décrit l'espace du disque comme monopartitionné (ce qui est intrinsèquement faux) > aucun système de fichiers n'est jamais associé à cette monopartition qui permettrait de monter un volume à partir de cet espace.

Tu as deviné où ça nous mène : il est absolument impossible de reconstituer l'ancien partitionnement GPT de ce disque. Il est donc logiquement invalide et juste bon à ré-initialiser en mode Apple.

Si tu voulais récupérer des données qui doivent toujours être écrites sur les blocs correspondant à l'ancienne partition Macintosh HD > alors la seule méthode serait d'utiliser un logiciel de scan des blocs capable de recréer une grande partie des fichiers.

Mais je m'étonne quand même de cette situation inconcevable : qu'un ancien disque-Système de ton mini - qui devait donc porter une GPT sur son en-tête et en backup, avec 3 partitions décrites en mode GPT (EFI > Macintosh HD > Recovery HD), par le simple fait d'avoir été extrait du mini > loggé dans un boîtier USB > attaché en externe au Mac, se retrouve dans la situation d'avoir perdu sa table de partition directrice (sans qu'aucune opération logique n'en soit responsable).

Le disque a-t-il été choqué et a-t-il un problème mécanique ? Le boîtier USB n'est-il pas tout simplement déficient ? Tu aurais intérêt à tester avec un autre boîtier déjà...
 
Dernière édition par un modérateur:
Bonjour, je me permet de poster mon message ici car j'ai également un souci avec mes disques durs.
Je m'explique, j'ai vendu mon PC sous Windows afin de passer sur un MacBook Pro. J'ai récupéré mes disques durs internes Western Digital au nombre de deux qui font 4To et un qui fait 2To qui contiennent de nombreuses données. Je me suis dit que j'allais les lire et les utiliser en les mettant d'un dock USB 3 qui fonctionne très bien sur un PC.
Le souci et que là, lorsque je mets mes disque 4To j'ai systématiquement le message suivant : "Le disque que vous avez inséré n'est pas lisible par cet ordinateur."
J'ai effectué la manipulation donnée par macomaniac plus haut et voici le rapport pour un de mes disque :

Bloc de code: 
/dev/disk0 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *500.3 GB   disk0

   1:                        EFI EFI                     209.7 MB   disk0s1

   2:          Apple_CoreStorage Macintosh HD            499.4 GB   disk0s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3


/dev/disk1 (internal, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                            Macintosh HD           +499.1 GB   disk1

                                Logical Volume on disk0s2

                                4E08C29C-6512-4F3E-B439-51D13487A3C1

                                Unencrypted


/dev/disk2 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *4.0 TB     disk2

   1:         Microsoft Reserved                         134.2 MB   disk2s1

Je pense que c'est la partition "Microsoft Reserved" qui doit poser problème, sans en être certain.
Vous pensez que le problème vient de quoi ? Et pensez-vous que je peux retrouver l'accès aux disques et leurs données via le Mac ?

Merci à vous.
 
Dernière édition par un modérateur:
Salut Vengeur

Vengeur a dit:
J'ai récupéré mes disques durs internes Western Digital au nombre de deux qui font 4To
Cliquez pour agrandir...

Tu as bien voulu écrire "internes" (ce n'est pas un lapsus pour : "externes") ? Tu aurais eu un PC avec 2 disques internes de 4 To chacun ? Chacun avec une table de partition GUID (au lieu du standard MBR) - ce qui invite à penser que ce PC était récent (càd. répondant à la norme UEFI --> requérant une table de partition GUID sur les disques de boot) ?

Si cette reconstruction imaginaire (de ma part) n'erre pas > faut-il encore supposer que ces 2 disques internes de 4 To chacun étaient solidarisés logiciellement par une matrice RAID ? Auquel cas > la partition principale de chacun ne pourrait pas monter isolément un volume > mais elle serait flanquée d'une partition secondaire jouant le rôle de « booter » (démarreur) de la bande RAID principale > laquelle apparaîtrait dans le tableau retourné par la commande diskutil comme Microsoft Reserved ? - la seule chose qui me fait construire cette conjecture est la taille de cette partition : 134 Mo --> c'est exactement la taille régulière du « booter » d'une bande RAID sur un disque.

Mais je me fais à moi-même des objections relativement à cette conjecture : si la table de partition est bien d'origine une GPT (GUID Partition Table) comme affiché dans le tableau > càd. impliquant un accès au disque par un Programme Interne de type EFI (et pas BIOS) > comment se fait-il alors que ne soit pas affiché en partition n°1 une ESP (EFI_System_Partition) de 209 Mo > qui est la partition de tête solidaire régulièrement d'une table de partition GUID ?

Bref : le paramétrage logique du disque de 4 To en question n'a rien d'évident. Pour tenter de clarifier un peu les choses > ce même disque toujours attaché à ton Mac > tu n'as qu'à repasser d'abors dans le «Terminal» la commande basique :
Bloc de code: 
diskutil list
afin de récupérer le n° de device (appareil) du disque (qui pourrait ne plus être disk2 s'il y avait d'autres périphériques intercalés au moment où tu as attaché ce disque).

Cela fait > tu passes la commande :
Bloc de code: 
sudo gpt show /dev/disk2
(en modifiant le n° de disque s'il le fallait) et tu valides --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe de session admin à l'aveugle - aucun caractère ne se montrant à la frappe - et valide de nouveau.

En retour > tu vas voir s'afficher le tableau de la distribution des blocs du disque > avec leur allocation à des : tables de partition > partitions > bandes d'espace libre.

=> tu n'as qu'à poster ce tableau ici en copier-coller.
 
Salut macomaniac,

Ca c'est de l'explication !!! Je m'y connais pas mal en informatique, mais surtout sous Windows, que ce soit hardware ou Software; mais tu m'as un peu perdu. Ce que je me doute c'est qu'il me semble que j'ai transformer mon disque en GPT > MBR ou l'inverse afin que le disque de 4To soit reconnu a pleine capacité sous Windows, je ne me souvient plus exactement, et effectivement Windows a créée une nouvelle partition dont je ne connais pas l'utilité. Et pour le BIOS j'était effectivement en EFI. Mes disques n'étaient pas en RAID.
Là, je souhaite juste utiliser mes disques en les mettant dans ma base externe SATA 3 connectée en USB 3 au Mac, en attendant de me procurer un NAS que je mettrai d'ailleurs en RAID.

Voici la copie de la commande que tu m'as transmis.

Bloc de code: 
MacBook-Pro-de-Sebastien:~ Sebastien$ diskutil list

/dev/disk0 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *500.3 GB   disk0

   1:                        EFI EFI                     209.7 MB   disk0s1

   2:          Apple_CoreStorage Macintosh HD            499.4 GB   disk0s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3


/dev/disk1 (internal, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                            Macintosh HD           +499.1 GB   disk1

                                Logical Volume on disk0s2

                                4E08C29C-6512-4F3E-B439-51D13487A3C1

                                Unencrypted


/dev/disk2 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:     FDisk_partition_scheme                        *4.0 TB     disk2

   1:               Windows_NTFS Films 3                 4.0 TB     disk2s1


MacBook-Pro-de-Sebastien:~ Sebastien$ sudo gpt show /dev/disk2

Password:

      start       size  index  contents

          0          1         MBR

          1        255       

        256  976745984      1  MBR part 7
 
Dernière édition par un modérateur:
Le disk2 de 4 To qui est ainsi décrit dans ton message #15 :

Bloc de code: 
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *4.0 TB     disk2
   1:               Windows_NTFS Films 3                 4.0 TB     disk2s1

devrait être lisible attaché à ton Mac avec ces paramètres logiques : table de partition FDisk_partition_scheme = MBR et format de volume Windows_NTFS = terme passe-partout qui peut désigner du FAT32 > comme de l'exFAT > comme encore du NTFS.

=> est-ce que tu ne vois pas un volume monté intitulé Films 3 sur ton Bureau de session ?

----------

Par contre le disk2 de 4 To qui était ainsi décrit dans ton message #13 :

Bloc de code: 
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *4.0 TB     disk2
   1:         Microsoft Reserved                         134.2 MB   disk2s1

ne monte aucun volume visible. C'est un autre disque de celui que je viens de mentionner ci-dessus, non ?

=> parce que > le disque interne de ton Mac étant a priori indexé comme disk0 (= premier disque) > et le format CoreStorage sur la partition de l'OS exportant un disque virtuel (= Volume Logique : Macintosh HD) indexé comme disk1 (= second disque) --> en conséquence tout disque que tu attacheras à ton Mac ensuite, quel que soit ce disque (clé USB ou DDE), sera automatiquement indexé comme disk2 (= troisième disque). En d'autres termes : disk2 n'identifie pas un disque unique > mais "tout disque externe attaché au Mac en 3è position"...

C'était à propos du disque de 4 To en GUID_partition_scheme du message #13 que je suggérais de passer la commande :
Bloc de code: 
sudo gpt show /dev/disk2
 
Désolé je me suis trompé de disque, celui-ci est effectivement un disque dur mais externe qui fonctionne parfaitement. Voici la correction :

MacBook-Pro-de-Sebastien:~ Sebastien$ diskutil list

/dev/disk0 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *500.3 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_CoreStorage Macintosh HD 499.4 GB disk0s2

3: Apple_Boot Recovery HD 650.0 MB disk0s3


/dev/disk1 (internal, virtual):

#: TYPE NAME SIZE IDENTIFIER

0: Macintosh HD +499.1 GB disk1

Logical Volume on disk0s2

4E08C29C-6512-4F3E-B439-51D13487A3C1

Unencrypted


/dev/disk2 (external, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *4.0 TB disk2

1: Microsoft Reserved 134.2 MB disk2s1


MacBook-Pro-de-Sebastien:~ Sebastien$ sudo gpt show /dev/disk2

Password:

gpt show: error: bogus map

gpt show: unable to open device '/dev/disk2': Undefined error: 0

MacBook-Pro-de-Sebastien:~ Sebastien$


Je n'ai pas de tableau la. Pourquoi il reste mes anciennes commandes tapées dans le terminal ? C'est normal ?
 
Le message retourné par l'utilitaire gpt n'est pas très folichon :
Bloc de code: 
gpt show: error: bogus map
gpt show: unable to open device '/dev/disk2': Undefined error: 0
en résumé :
  • erreur --> table de partition bidon (bogus) ;
  • impossible d'ouvrir en lecture l'appareil disk2 --> erreur indéterminée sur le bloc 0 (où est inscrite une table MBR secondaire en cas de GPT = GUID_Partition_Table principale).

Il faudrait que tu en dises plus concernant ce disque : c'était un disque interne de ton PC ? - un disque démarrable ou de simple stockage ? - tu n'as pas modifié la table de partition après l'avoir récupéré > donc c'était bien une GPT ? - il y a des données dessus que tu souhaites récupérer ?
 
C'était un disque dur interne, non bootable, que je n'ai pas modifié depuis le retrait de ma tour; il y a juste des données dessus (photos et vidéo) que je souhaite biensur récupérer. Le disque est bien visible si je le branche de la même façon à mon PC portable, j'accède au contenu sans problème. Pourquoi je ne peux pas sur Mac ? je trouve ça fou.

[Petite question pour en apprendre encore] C'est normal que mes commande précédemment tapées dans le Terminal restent affichées lorsque je réouvre le Terminal ? Peut-on le réinitialiser ?

Merci encore pour ton aide.
 
La table de partition a beau être GPT > elle est illisible sur Mac. Je suis totalement ignorant de Windows et de la façon dont les nouveaux PC répondant à la norme UEFI gèrent les paramètres de la table de partition GPT. Donc je ne peux plus aider en étant sûr de ne pas compromettre le secteur d'amorçage du disque.

Je te conseillerais d'avoir à ta disposition un autre DDE paramétré comme celui dont tu as donnée le tableau (table MBR > format exFAT) > de vérifier que le disque MBR est bien reconnu par le Mac et que le volume vide monte > d'attacher alors les 2 disques en parallèle à ton PC portable > et de recopier les données du disque GPT dans le volume du disque MBR.

Vérifier encore que tu as accès à tes données avec le disque MBR attaché à ton Mac > cela fait > ré-initialiser complètement le disque GPT illisible sur Mac. La table de partition dépendant de ton usage :
  • exclusif Mac --> table de partition GUID et format OS X étendu ;
  • partagé Mac <=> PC --> table de partition MBR et format exFAT.
 
  • J’aime
Réactions: Vengeur

Sujets similaires

L
10.13 High Sierra DDE exFAT non lu sur Mac
Réponses
4
Affichages
430
macOS
Locke
Locke
P
restaurer à partir de Time Machine
Réponses
20
Affichages
805
macOS
photophil07
P
R
Utiliser Mac mini comme disque externe
Réponses
2
Affichages
1K
macOS
gibus67
G
V
Problème transfert photos vers disque dur externe format HEIC
Réponses
16
Affichages
1K
macOS
Vincedu49
V
Herve1
10.13 High Sierra Problème Disque dur MBP 2010
Réponses
13
Affichages
863
macOS
Sly54
Sly54
Haut Bas
Back