iMac Partition bootcamp disparu

Mr-Kimita

Mr-Kimita

Membre confirmé
17 Janvier 2020
87
4
40
Bonjour,

Suite à l’utilisation de Onyx sur mon Imac retina 2017 "os Catalina" pour un nettoyage de mon système. Je viens d'avoir une mauvaise surprise, en effet il m'est impossible d’accéder à mon autre partition Windows 10 sous bootcamp.

Des que je boot sur Windows 10, mon mac bloque complétement il ne fait que redémarré. Je n'ai accés qu'a ma partition principal en faisant la manip "option" au démarrage.

Suite à cela j'ai décidé de supprimer ma partition via bootcamp étant donnné qu'il ya peu de donné (100 go), pour tout réinstallé par la suite. Pour ce faire je suis donc passé par l'utilitaire de disque afin de supprimé la partition bootcamp/Win10. La un message apparait "l'opération à échoué".

Et c'est la que les ennuis commence puisque ma partition à disparu d'aprés mon os, alors qu'en réalité elle est toujours la Disons qu'elle est devenu invisible puisque j'ai 100 go en moins sur mon DD.



Afin d'y voir plus claire j'ai décidé de passé par la terminal en redémarrant mon mac. Et la je constate un bazar total dans mes partitions, je ne comprend plus rien. Voici le rendu :

-bash-3.2# diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk2 898.0 GB disk0s2

/dev/disk1 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +2.1 GB disk1
1: Apple_HFS macOS Base System 2.0 GB disk1s1

/dev/disk2 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +898.0 GB disk2
Physical Store disk0s2
1: APFS Volume Macintosh HD 451.0 GB disk2s1
2: APFS Volume Preboot 53.4 MB disk2s2
3: APFS Volume Recovery 510.4 MB disk2s3
4: APFS Volume VM 5.4 GB disk2s4

/dev/disk3 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +5.2 MB disk3

/dev/disk4 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk4

/dev/disk5 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk5

/dev/disk6 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk6

/dev/disk7 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +2.1 MB disk7

/dev/disk8 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk8

/dev/disk9 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk9

/dev/disk10 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +12.6 MB disk10

/dev/disk11 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +4.2 MB disk11

/dev/disk12 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +1.0 MB disk12

/dev/disk13 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +2.1 MB disk13

/dev/disk14 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk14

/dev/disk15 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk15

/dev/disk16 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +1.0 MB disk16

/dev/disk17 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk17

/dev/disk18 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +6.3 MB disk18

/dev/disk19 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +6.3 MB disk19

/dev/disk20 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk20

/dev/disk21 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +2.1 MB disk21

-bash-3.2#



Personnellement je trouve que le bazar est tellement immense que j'ai envie de tout formaté pour ensuite faire une instal propre. Mais la question que je me pose, si je formate mon DD va t'il bien formaté l'intégralité du DD, ce qui comprend les partitions perdue également. Et non la partition principal sur lequel mon OS est installé. Évidemment j'ai pris soin de faire une save avec time machine.

Sur mon screen on peut voir également que la taille de disque ne fait pas 1TO mais 898go, mais qu'en plus il précise que le DD est partagé en 4 volumes. ça me dépasse pérsonnelement...



Merci pour votre retour.
 

Fichiers joints

  • Capture d’écran 2020-01-17 à 16.37.04.png
    Capture d’écran 2020-01-17 à 16.37.04.png
    575,3 KB · Affichages: 141
Ah oui je précise qu'a la base je n'ai crée qu'une seule partition via bootcamp afin d'installé Win10.

Pour tout dire j'ai l'impression que des que mon imac redémarre suite à son impossibilité de chargé Win10, il va recrée une partition supplémentaire. Mon hypothése est peut etre un peu farfelu de ma part mais je ne comprend vraiment pas ce que vient faire cette liste dans mon terminal.

/dev/disk3 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +5.2 MB disk3

/dev/disk4 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk4

/dev/disk5 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk5

/dev/disk6 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk6

/dev/disk7 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +2.1 MB disk7

/dev/disk8 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk8

/dev/disk9 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk9

/dev/disk10 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +12.6 MB disk10

/dev/disk11 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +4.2 MB disk11

/dev/disk12 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +1.0 MB disk12

/dev/disk13 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +2.1 MB disk13

/dev/disk14 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk14

/dev/disk15 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk15

/dev/disk16 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +1.0 MB disk16

/dev/disk17 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk17

/dev/disk18 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +6.3 MB disk18

/dev/disk19 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +6.3 MB disk19

/dev/disk20 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk20

/dev/disk21 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +2.1 MB disk21

-bash-3.2#
 
Bonjour Mr-Kimita

Tu as passé la commande dans le terminal de la session de secours (⌘R). Ce qui n'était pas requis > car tu as un terminal disponible depuis ta session d'utilisateur (at: Applications > Utilitaires > Terminal). Voici une explication succincte concernant les disques disk3 > disk21 -->

  • une série de micro-disques correspond à des images-disques créées en RAM à l'occasion du démarrage en mode Recovery > dont les volumes sont montés en lecture & écriture à l'espace de dossiers de l'OS de secours qui leur servent de points de montage. Ce qui permet pendant le fonctionnement de cet OS hébergé dans un volume monté en lecture seule > à des écritures de s'effectuer à l'espace des dossiers où se trouvent montés les volumes des images-disques de la RAM. Ces images-disques s'effacent à l'extinction ou au re-démarrage.

Puisque tu as le terminal de secours sous la main > passe la commande :
Bloc de code: 
gpt show disk0

  • qui affiche la distribution des blocs du disque > tels que gérés par la table de partition GPT de l'en-tête de ce même disque

Poste le tableau en copier-coller comme tu as déjà fait > en veillant à faire le coller dans une fenêtre de code (c'est plus lisible !) par le procédé suivant -->

- en bas de cette page des forums MacGé => utilise le menu ...▾ (à droite de la bobine souriante) 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.
​
 
Maconamiac, un grand merci pour ton retour,

Voici mon rapport, j’espère que la mise en page est plus claire pour toi.


Bloc de code: 
-bash-3.2# gpt show disk0
       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  1753907160      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
  1754316800   199208335         
  1953525135          32         Sec GPT table
  1953525167           1         Sec GPT header
-bash-3.2#


Que dois-faire à présent ?
 
En complément je te laisse le rapport du terminal sous ma session.
Elle contient forcément moins d'information.

Bloc de code: 
Last login: Fri Jan 17 17:11:58 on console
Juliens-iMac:~ julienberzi$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         898.0 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +898.0 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            451.2 GB   disk1s1
   2:                APFS Volume Preboot                 53.4 MB    disk1s2
   3:                APFS Volume Recovery                510.4 MB   disk1s3
   4:                APFS Volume VM                      4.3 GB     disk1s4

Juliens-iMac:~ julienberzi$
 
Bien posté !

- cette ligne -->​
Bloc de code: 
  1754316800   199208335

  • s'interprète ainsi : à partir du bloc n° 1754316800 (= 1er bloc libre après la fin de la partition apfs principale) > existe une bande de 199208335 blocs libres (de 512 octets = 101,99 Go). Étant située juste en-dessous de la partition apfs > elle lui est donc récupérable (ainsi qu'au Conteneur virtualisé à partir de cette partition).

Dans le terminal de ta session julienberzi > passe la commande (copier-coller direct) :
Bloc de code: 
diskutil ap resizeContainer disk1 0b ; diskutil list

  • qui récupère l'espace libre > puis réaffiche le tableau des disques

Poste le retour intégral de la commande (que je vérifie s'il n'y a pas eu un blocage de la part de l'apfs).
 
Hum je n'y vois pas forcément plus claire...

Bloc de code: 
Last login: Fri Jan 17 17:17:53 on ttys000
Juliens-iMac:~ julienberzi$
Juliens-iMac:~ julienberzi$
Juliens-iMac:~ julienberzi$ diskutil ap resizeContainer disk1 0b ; diskutil list
Started APFS operation
Error: -69524: Unable to get APFS Container resize limit information
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         898.0 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +898.0 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            451.2 GB   disk1s1
   2:                APFS Volume Preboot                 53.4 MB    disk1s2
   3:                APFS Volume Recovery                510.4 MB   disk1s3
   4:                APFS Volume VM                      4.3 GB     disk1s4
 
Il y a eu une erreur de la part de l'apfs :
Bloc de code: 
Error: -69524: Unable to get APFS Container resize limit information

  • en somme > un Conteneur apfs possède une limite inférieure de redimensionnement. Normalement déterminée par l'occupation des blocs constituée par les 4 volumes contenus. Mais qui peut se trouver déterminée par des snapshots (instantanés archivant des états passés du volume et verrouillant les blocs correspondant aux fichiers archivés). Si par malchance un des blocs verrouillés se trouvait dans la partie basse de la partition support de l'apfs => alors un Conteneur même avec beaucoup d'espace libre théorique => ne peut pas se trouver rétréci notablement.
  • ouaip ! mais pourquoi s'enquérir d'une limite inférieure de redimensionnement > puisqu'ici il s'agit d'augmenter le Conteneur ? --> il doit s'agir d'une routine de vérification activée pour tout cas de redimensionnement (rétrécissement ou dilatation).

En tout cas > cette erreur ne fait pas tes affaires. Passe la commande :
Bloc de code: 
diskutil verifyVolume disk1

  • qui vérifie l'apfs : du Conteneur > puis des 4 volumes (en montrant au passage s'il y a des snapshots)

Poste le retour.
 
Pas mal de chose à priori afin d'y voir plus claire.

macomaniac, j'en profite pour te posé la question mais utilise tu Onyx personnellement ?
Qu'est ce que Onyx à bien pu faire pour en arrivé la ? J'ai presque envie de m'en débarrassé.



Bloc de code: 
Juliens-iMac:~ julienberzi$
Juliens-iMac:~ julienberzi$
Juliens-iMac:~ julienberzi$
Juliens-iMac:~ julienberzi$ diskutil verifyVolume disk1
Started file system verification on disk1
Verifying storage system
Using live mode
Performing fsck_apfs -n -x -l /dev/disk0s2
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the space manager free queue trees
Checking the object map
Checking volume
Checking the APFS volume superblock
The volume Macintosh HD was formatted by hfs_convert (945.250.134) and last modified by apfs_kext (945.275.8)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
warning: apfs_num_other_fsobjects (57) is not valid (58)
Checking volume
Checking the APFS volume superblock
The volume Preboot was formatted by hfs_convert (945.250.134) and last modified by apfs_kext (945.275.8)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume Recovery was formatted by diskmanagementd (945.250.134) and last modified by apfs_kext (945.275.8)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume VM was formatted by apfs.util (945.250.134) and last modified by apfs_kext (945.275.8)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Verifying allocated space
The volume /dev/disk0s2 appears to be OK
Storage system check exit code is 0
Finished file system verification on disk1
Juliens-iMac:~ julienberzi$
Juliens-iMac:~ julienberzi$
 
ça coince ici !

Bloc de code: 
Checking the APFS volume superblock
The volume Macintosh HD was formatted by hfs_convert (945.250.134) and last modified by apfs_kext (945.275.8)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
warning: apfs_num_other_fsobjects (57) is not valid (58)
 
Il n'y a un avertissement signalé dans l'apfs concernant Macintosh HD (et aucun snapshot).

- réouvre la session de secours. Lance l'Utilitaire de disque. Clique la pastille "Présentation" et coche : "Afficher tous les appareils" pour afficher le Conteneur global. Sélectionne-le et fais un S.O.S. dessus (on ne peut réparer que si tous les volumes du Conteneur sont démontables --> ce qui n'est pas le cas lorsque le volume-Système est démarré).​

Cela fait > reviens dans ta session. Repasse la commande :
Bloc de code: 
diskutil ap resizeContainer disk1 0b ; diskutil list

  • et poste le retour.

Note : j'utilise Onyx occasionnellement pour vider des caches. Je n'ai jamais constaté d'effets négatifs suite à son utilisation.
 
Tu m’excusera Macomaniac, l'opération à du prendre plus de temps.

Voici mon rapport:

Bloc de code: 
Last login: Fri Jan 17 18:23:14 on console
Juliens-iMac:~ julienberzi$
Juliens-iMac:~ julienberzi$
Juliens-iMac:~ julienberzi$ diskutil ap resizeContainer disk1 0b ; diskutil list
Started APFS operation
Aligning grow delta to 101 994 663 936 bytes and targeting a new physical store size of 999 995 129 856 bytes
Determined the maximum size for the targeted physical store of this APFS Container to be 999 994 101 760 bytes
Resizing APFS Container designated by APFS Container Reference disk1
The specific APFS Physical Store being resized is disk0s2
Verifying storage system
Using live mode
Performing fsck_apfs -n -x -l -S /dev/disk0s2
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the space manager free queue trees
Checking the object map
Checking volume
Checking the APFS volume superblock
The volume Macintosh HD was formatted by hfs_convert (945.250.134) and last modified by apfs_kext (945.275.8)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
warning: apfs_num_other_fsobjects (57) is not valid (58)
Checking volume
Checking the APFS volume superblock
The volume Preboot was formatted by hfs_convert (945.250.134) and last modified by apfs_kext (945.275.8)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume Recovery was formatted by diskmanagementd (945.250.134) and last modified by apfs_kext (945.275.8)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume VM was formatted by apfs.util (945.250.134) and last modified by apfs_kext (945.275.8)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Verifying allocated space
The volume /dev/disk0s2 appears to be OK
Storage system check exit code is 0
Growing APFS Physical Store disk0s2 from 898 000 465 920 to 999 995 129 856 bytes
Modifying partition map
Growing APFS data structures
Finished APFS operation
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         1000.0 GB  disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +1000.0 GB  disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            451.2 GB   disk1s1
   2:                APFS Volume Preboot                 53.4 MB    disk1s2
   3:                APFS Volume Recovery                510.4 MB   disk1s3
   4:                APFS Volume VM                      4.3 GB     disk1s4

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *1.0 TB     disk2
   1:                  Apple_HFS LaCie                   1.0 TB     disk2s1

Juliens-iMac:~ julienberzi$
Juliens-iMac:~ julienberzi$


En revanche pour ce qui est du S.O.S
est ce que c'est bien c'est partition que je devait m'occuper ? (voir la capture)


Ps: Ne préte pas attention à mon DD externe dans le rapport, c'est ici que je save ma session avec time machine.
 

Fichiers joints

  • IMG_1627.JPG
    IMG_1627.JPG
    762,2 KB · Affichages: 152
J'ai tout de meme l'impression que ça s'améliore (voir capture), depuis ma session l'utilitaire de disque m'indique bien 1TO et non 898go comme tout à l'heure...
 

Fichiers joints

  • Capture d’écran 2020-01-17 à 18.36.27.png
    Capture d’écran 2020-01-17 à 18.36.27.png
    501,4 KB · Affichages: 153
Problème résolu en ce qui concerne la récupération d'espace : le Conteneur fait 1 To = sa taille maximale.

- lorsque des erreurs mineures existent dans le système de fichiers apfs > une réparation du Conteneur global (S.O.S. dans l'Utilitaire de disque de la session de secours) => peut amender les choses. Ça a fonctionné dans ton cas.​
 
Formidable Macomaniac merci beaucoup pour la précision de tes messages,

Ceci dit: cette ligne de code m'intrigue tout de même.

Bloc de code: 
Checking the APFS volume superblock
The volume Macintosh HD was formatted by hfs_convert (945.250.134) and last modified by apfs_kext (945.275.8)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
warning: apfs_num_other_fsobjects (57) is not valid (58)
 
Cette ligne -->
Bloc de code: 
warning: apfs_num_other_fsobjects (57) is not valid (58)

  • est un avertissement concernant une erreur mineure : un dénombrement d'objets (57) erroné d'une unité (il faudrait 58). La réparation de l'apfs a débloqué le redimensionnement sans corriger cette erreur. Comme elle n'est pas invalidante => tu peux laisser passer.
 
Trés bien merci, malgré tout et suite à cette mésaventure j'ai décidé de me refaire une installation clean avec time machine.
J'ai l'intention de passé au dernier OS Catalina.
 

Sujets similaires

E
Problème de disque dur MacOS Catalina
Réponses
8
Affichages
1K
Mac
Enzo67
E
F
Problème osx base system
Réponses
3
Affichages
482
macOS
Locke
Locke
J
10.12 Sierra Réinstallation mac Sierra
Réponses
2
Affichages
423
macOS
JulieReap
J
J
10.13 High Sierra Permission denied en essayant d'installer High Sierra depuis une clef USB
Réponses
12
Affichages
2K
macOS
jackoup
J
M
Imac mi-2010 High Sierra - Freeze
Réponses
0
Affichages
712
Mac
Maxbass
M
Haut Bas