iMac Partition invisible après repartitionnement

Conjecture gagnante : le bloc n° 2441721170 était bien le bloc de départ originel de la partition de secours --> conséquence : la recréation au bloc près d'une partition de 650 Mo à partir de ce bloc > a "ressuscité" le système de fichiers récupéré sur les blocs à son ancrage - la preuve de ce succès : un volume Recovery HD a été redéfini pour la partition > signe que le système de fichiers a été récupéré.

Cette partition n°5 est-elle à jour > ou n'est-elle pas l'ancienne correspondant à «Mavericks» et qui a été restaurée à sa place ? --> pour le savoir > passe la commande à rallonges (copier-coller) :
Bloc de code: 
diskutil mount disk0s5 ; defaults read /Volumes/Recovery\ HD/com.apple.recovery.boot/SystemVersion.plist ProductVersion

  • cette commande monte le volume Recovery HD sur la partition disk0s5 > puis lis la valeur de la clé ProductVersion dans le fichier SystemVersion.plist du volume

=> tu n'as qu'à poster ici le retour. Je conjecture que ça va être un :
Bloc de code: 
Volume Recovery HD on disk0s5 mounted
10.9.5
 
Bien joué ! OSX te suis à la baguette :-)
Pour info, j'ai exécuté la commande en rebootant vers El Capitan.

Bloc de code: 
iMacdeMikael:~ Zabriskie$ diskutil mount disk0s5 ; defaults read /Volumes/Recovery\ HD/com.apple.recovery.boot/SystemVersion.plist ProductVersion
Volume Recovery HD on disk0s5 mounted
10.11.2
 
Alors tant mieux pour toi : tu as bien une partition de récupération Recovery HD fonctionnelle > de surcroît correspondant à l'OS du volume El Capitan situé au-dessus. Tu as récupéré la paire logicielle : partition de l'OS - partition de secours et tu n'as plus rien à envisager (sinon peut-être des mises-à-jour).

----------

Pour la suite > j'ai besoin que tu repasses une commande :
Bloc de code: 
sudo gpt show /dev/disk0
et que tu postes ici le tableau des blocs mis à jour.
 
La voici :

Bloc de code: 
iMacdeMikael:~ Zabriskie$ sudo gpt show /dev/disk0
Password:
       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34           6        
          40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      409640  1262032904      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  1262442544      262146        
  1262704690   298793424      3  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  1561498114      262144        
  1561760258   879960912      4  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  2441721170     1269536      5  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  2442990706  1464038429        
  3907029135          32         Sec GPT table
  3907029167           1         Sec GPT header
 
Bien sûr on peut rêver et imaginer que la partition de BigMama va ressusciter elle aussi des blocs comme Lazare d'entre les morts.

[Ah ! si avant de se lancer dans des tarabiscotages de partitions > les utilisateurs avaient le réflexe de passer une commande :
Bloc de code: 
sudo gpt show /dev/disk0
(ou tout autre n° de disque) et d'enregistrer le tableau sur un fichier ! - en effet, connaissant au bloc près la localisation des partitions initiales > il serait toujours possible après de les refaire surgir comme des ballons, avec leurs volumes et leurs fichiers intacts, rien qu'en les re-créant sur leurs ancrages...]

Alors pour la BigMama > je ne peux évidemment que me livrer à des conjectures. La première et la plus importante de toutes > consiste à déterminer en pensée le bloc d'ancrage de la partition : on va supposer là encore que cette partition n'était distante d'aucun bloc de la Recovery HD qui la précédait - ce qui est plausible > mais pas aussi nécessaire logiquement que pour la Recovery HD. Cette conjecture amène donc à décider que le bloc n°2442990706 a des chances d'être le bloc de départ de la partition disparue.

Rien qu'en se laissant inspirer par la sémantique > qui dit BigMama dit partition aussi volumineuse qu'une matrone napolitaine --> il est donc plausible qu'elle ait occupé tout l'espace restant sauf...

... que le backup de la table GPT principale, ou secondary table, qui commence au bloc n°3907029135, n'apprécie jamais d'être serré par en-dessus par la partition de queue de disque. En général > un espace de 7 blocs libres est de rigueur. Au lieu donc d'évaluer la BigMama à la totalité des 1464038429 blocs disponibles > on va l'évaluer à 1464038422 blocs (moins 7).

La commande à passer sera alors :
Bloc de code: 
sudo gpt add -b 2442990706 -s 1464038422 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk0

Mais évidemment > il faut encore que tous les volumes du disque interne du Mac soient démontés --> donc re-démarre sur «Mavericks» > dans l'«Utilitaire de Disque» démonte les volumes = Anthologies > Transit-Logiciels > El Capitan. Avec «Safari» récupère la commande et fais-en un copier-coller dans le «Terminal» de «Mavericks» puis exécute-la.

Tu n'auras qu'à poster le retour d'un :
Bloc de code: 
diskutil list
à la suite.

Évidemment > si la recréation de la partition tombait juste sur les blocs pour récupérer l'ancrage du système de fichiers > un volume BigMama bondirait sur le Bureau comme un ballon à hélium. Mais le cadrage de cette partition > sans compter les dévastations effectuées par le logiciel «Stellar» : tout cela correspond à des facteurs manquant de détermination.

Tu vas bien voir.
 
  • J’aime
Réactions: litobar71
Ok, c'est juste IN-CRO-YABLE. La matrone napolitaine est revenue, avec toutes ses rondeurs, et même bien plus !

Tout les fichiers de BigMama sont présents !
J'ai compris : tu es Jésus 2.0.

A ce niveau-là, c'est plus de la technique, c'est de la sorcellerie, ou de l'art contemporain, je sais pas trop !

Et au niveau pédago, c'est juste le top macomaniac ! Merci infiniment Monsieur :D:D:D

Bloc de code: 
imacdemikael:~ Mikehal$ sudo gpt add -b 2442990706 -s 1464038422 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk0
Password:
/dev/disk0s6 added
imacdemikael:~ Mikehal$ diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *2.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Anthologies             646.2 GB   disk0s2
   3:                  Apple_HFS Transit-Logiciels       153.0 GB   disk0s3
   4:                  Apple_HFS El Capitan              450.5 GB   disk0s4
   5:                 Apple_Boot Recovery HD             650.0 MB   disk0s5
   6:                  Apple_HFS FreeSpece               749.6 GB   disk0s6
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *2.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS Entrepot                1.8 TB     disk1s2
   3:                  Apple_HFS Systeme                 205.9 GB   disk1s3
   4:                 Apple_Boot Recovery HD             650.0 MB   disk1s4
 
Et en plus BigMama ne s'appelait pas BigMama mais FreeSpece (une variante inconnue de pizza napolitaine ?).

C'est la logique qui a permis cette rétro-génèse des partitions et des volumes.

Content pour toi que tu aies récupéré tes données à leur place. Si tu veux envisager des re-partitionnements > tu pourras en faire part ici (mais pas ce soir car... je ne suis pas du soir, en fait).
 
  • J’aime
Réactions: Zabriskie73
Zabriskie73 a dit:
j'ai pas trouvé comment on fait pour mettre que le fil est résolu !
Cliquez pour agrandir...

Il suffit que trois quidam s'entendent pour marquer un message unique d'un fil comme étant la "Meilleure réponse" et > par l'effet d'une conséquence qu'il est impossible à la Logique de déduire raisonnablement > le fil tout entier s'en trouve marqué comme "Résolu". Comme si un seul message isolé dans un fil - autant dire un paragraphe dans un discours - avait nécessairement la vertu d'apporter une solution séparée à l'« Ensemble d'un Problème ».

Il y a dans ce mécanisme de l'attribution, propre aux « Nouveaux Forums », une offense au « bon sens », càd. à la « Faculté de raisonner également répartie en tous les hommes » selon Descartes. Un problème se trouve résolu par un cheminement d'ensemble dont il est vain a priori de décréter qu'un seul moment en détiendrait isolément la solution.

J'étais parti dans l'idée que Zabriskie souhaitait « récupérer » l'espace libre suscité par la suppression d'une grosse partition de son disque. Et comme ce disque était déjà multi-partitionné > il convenait de savoir en-dessous de quelle partition se situait cette bande d'espace libre. Surprise ! Elle se situait de part (67 Go) et d'autre (683 Go) d'une partition de secours qui s'en trouvait décollée de la partition de l'OS qu'elle aurait dû flanquer.

Selon toute apparence > il fallait donc recréer une partition Recovery HD au pied de la partition El Capitan > supprimer la partition se secours intermédiaire > pour ensuite récupérer la bande continue de l'espace libre de queue de disque à la partition El Capitan. Comme la partition de secours intercalée s'avérait bidon > autant la supprimer carrément puis réparer la table de partition en préalable à la suite des opérations.

Mais non ! la problématique ne s'avérait pas exactement celle de récupérer de l'espace libre brut > car Zabriskie d'un seul coup manifestait le souhait de récupérer les données de la grosse partition supprimée (ce qui m'avait complètement échappé). Changement d'enjeu ! Il fallait tenter de recréer les partitions supprimées et de remonter leurs volumes originaux sur ces partitions...

Alors il fallait tenter de recréer à partir des blocs logiques la partition Recovery HD originale à sa place exacte > pour voir si son système de fichiers toujours inscrit sur les blocs pouvait se trouver réactivé à partir de son point d'ancrage. Opération réussie dans un premier temps. Amenant à envisager une répétition du procédé pour la grosse partition fantôme > en imaginant quel pouvait être le bloc de départ auquel se trouvait ancré le système de fichiers originel > et jusqu'à quelle limite de blocs courrait le conteneur de la partition gérée. Opération réussie dans un second temps.

La réussite de la seconde opération n'est pas détachable de la réussite de la première opération. La réussite de la première opération n'est pas détachable du tournant d'interprétation faisant passer d'un problème de récupération d'espace libre à un problème de récupération de partition.
 
  • J’aime
Réactions: litobar71
Bonjour,

Je relance ce topic car j'ai moi aussi quelques soucis.
Je suis sur un Macbook late 2017 sous 10.7.5. Cet ordi me sert à pratiquer l'astrophotographie.
J'avais jusqu'à présent 2 partitions : 1 MacOS et 1 bootcamp avec Win7.
Hier j'ai voulu installer Ubuntu Mate, l'installation s'est bien passée mais elle m'a créée 2 nouvelles partitions en "abimant" celle de bootcamp. J'ai donc tout partitionné en une seule partition. Mais depuis : Ma partition ne fait plus que 65Go sur 160. Je peux avec l'utilitaire de dique créer une deuxième partition MacOS dans ce cas, je récupère l'espace disponible (mais avec 2 partitions). Comment revenir à 1 seule partition ?

Si vous avez des idées …
Merci à tous

Pour info diskutil avec 1 partions :
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *160.0 GB disk0
1: EFI 209.7 MB disk0s1
2: Apple_HFS Macbook 65.2 GB disk0s2

Diskutil avec 2 partitions :
dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *160.0 GB disk0
1: EFI 209.7 MB disk0s1
2: Apple_HFS Macbook 73.2 GB disk0s2
3: Apple_HFS mac 2 86.4 GB disk0s3
 
Bonjour T0shop

Quelle est ta configuration actuelle ? - outre la petite partition EFI invisible --> 1 seule partition Macbook réduite ? - ou 2 partitions Macbook et mac ?
 
macomaniac a dit:
Bonjour T0shop

Quelle est ta configuration actuelle ? - outre la petite partition EFI invisible --> 1 seule partition Macbook réduite ? - ou 2 partitions Macbook et mac ?
Cliquez pour agrandir...
Bonjour Manomaniac et merci
Là je suis avec une partition et donc 80 Go disparu environ …

Bon après, l'idée est de réinstaller Linux et Window et d'avoir 3 partitions …
 
Dernière édition:
Passe la commande (copier-coller) :
Bloc de code: 
diskutil resizeVolume disk0s2 0b ; diskutil list
  • la commande récupère tout l'espace libre disponible --> à condition qu'il soit situé sur le disque en-dessous de la partition Macbook ("en-dessous" en terme de numérotation arithmétique linéaire des blocs de 0 à n)

Poste le retour en copier-coller > en veillant à faire le coller dans un Bloc de code (c'est plus lisible !) par le procédé suivant -->

- en bas de cette page des forums MacGé => utilise le menu ⫶ (le 17è depuis la gauche = vers le milieu de la barre) dans la barre de menus au-dessus du champ de saisie d'un message > sous-menu : </> (= Bloc de code) => tu fais ton coller dans la fenêtre de code et Continuer. 17è menu et pas 7è.​
 
Bon surprise … 8/
Diskutilities qui refusait obstinément de faire 1 seule partition, vient d'accepter. J'ai bien récupéré 1 seule partition de 160 Go.
Je n'y comprends rien.
Tu me conseilles d'installer Windows via bootcamp d'abord puis Linux (en créant une partition FAT via diskutilities ou l'inverse ?
 
Content pour toi !

- en ce qui concerne des installations de Windows ou de Linux : je ne suis pas compétent. Je n'installe ni n'utilise aucun de ces OS. Je te conseille de poster sur les forums correspondants à ces OS sur Mac si tu souhaites des avis bien informés.​
 
T0shop a dit:
Tu me conseilles d'installer Windows via bootcamp d'abord puis Linux (en créant une partition FAT via diskutilities ou l'inverse ?
Cliquez pour agrandir...
J'ai lu ta demande, mais je ne pense pas que ton MBP...
T0shop a dit:
Je suis sur un Macbook late 2017 sous 10.7.5.
Cliquez pour agrandir...
...soit de 2017 en égard de la taille de 160 Go du disque dur interne ! De 2007, ça se comprendrait mieux. En revanche, avec une taille de disque dur aussi petite, je te déconseille fortement de créer une partition pour Windows et une partition pour Linux ! Tu vas au devant de gros dysfonctionnements avec ce minuscule disque dur !
 

Sujets similaires

Typhuss
10.11 El Capitan Partition de données inaccessible
Réponses
17
Affichages
2K
macOS
Membre supprimé 1060554
M
Haut Bas