Espace disque perdu

[RémiJulien]

Bonjour !
J'ai un Macbook pro mi-2010 qui tourne sous 10.13 installé sur un volume APFS, et mon support de stockage interne est un SSD d'environ 250 Go.

J'ai perdu de la place et n'arrive pas à la retrouver !
J'ai supprimé des anciennes partitions de stockages et d'anciennes version de macOS, mais je ne peux plus pour autant augmenter la taille de mon conteneur APFS.

Dans l'utilitaire de disque, on m'indique bien que le SSD fait ses 250 Go, que ma partition fait 160 Go, mais que le + pour créer une nouvelle partition ou conteneur est grisé :



Dans le terminal, ça donne ça :

diskutil list physical
/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_APFS Container disk2         159.8 GB   disk0s4

et même ça quand je veux changer la taille de conteneur :

diskutil ap resizeContainer disk0s4 limits
Resize limits for APFS Physical Store partition disk0s4:
  Current Physical Store partition size on map:   159.8 GB (159849594880 Bytes)
  Minimum (constrained by files/snapshots):       159.8 GB (159849594880 Bytes)
  Recommended minimum (if used with macOS):       159.8 GB (159849594880 Bytes)
  Maximum (constrained by partition map space):   159.8 GB (159849594880 Bytes)

Si l'un.e de vous arrive à m'aider, c'est merveilleux.
Merci !
Rémi

edit : j'ai lu les excellents coups de main sur le sujet "https://forums.macg.co/threads/redimensionner-partition-recovery-hd.1301132/", mais ne correspondant pas à mon cas spécifique et n'étant pas du tout un expert, je n'ai pas réussi à le transposer vers mon problème. Cependant il y a de nombreux points communs, notamment le coup de la partition de récupération qui avait enflé -et que j'ai fini par supprimer, ne sachant que faire d'autre (oui, c'était sans doute une connerie, ça)-. Peut-être qu'il ne me manque qu'une ligne de commande pour retrouver l'accès aux clusters qui errent dans les limbes de mon SSD. (J'ai tenté complètement aléatoirement des "resizeStack" mais évidemment ça n'a pas marché.)

 

[Membre supprimé 1060554]

Bonjour Rémi

Bravo pour ta prise en charge de ton problème. Dans la commande que tu as tentée -->

diskutil ap resizeContainer disk0s4 limits

• tu as utilisé le verbe resizeContainer (redimensionner le Conteneur) > avec la désignation de la partition primaire comme cible (disk0s4) --> il convient d'adresser avec ce verbe l'espace-disque virtuel du Conteneur apfs (disk2 d'après le tableau).

• tu as utilisé la mention limits comme valeur de redimensionnement. Voici ce qui est déclaré dans le man de diskutil à propos de cet emploi :

  Specifying limits instead of a size causes no action to be taken, but instead 
  prints a range of valid values, taking into account various constraints

  --> bref : limits produit un effet d'information mais n'a pas d'effet opératoire. L'utilisation de 0b (comme 0_byte) peut être recommandée - valeur qui s'interprète ainsi : "récupérer tout l'espace libre externe situé en-dessous du Conteneur > sans en excepter aucun byte"

Comme je note dans ton tableau (retourné par la commande 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_APFS Container disk2         159.8 GB   disk0s4

• un index décalé (disk0s4) pour désigner la partition de rang n°2 (ainsi qu'un bizarre disk2 en lieu du disk1 attendu pour le Conteneur) --> je te recommande de redémarrer une fois > afin que le kernel prenne en charge correctement la configuration du SSD. Repasse alors la commande :

diskutil list

• et poste la nouvelle version du tableau --> je pourrai te passer une commande ajustée pour récupérer l'espace manquant.

 

[RémiJulien]

Joli, ça me semble en effet plus propre comme ça :

/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_APFS Container disk1         159.8 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +159.8 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume SSD1013                 138.0 GB   disk1s1
   2:                APFS Volume Preboot                 22.2 MB    disk1s2
   3:                APFS Volume Recovery                518.8 MB   disk1s3
   4:                APFS Volume VM                      4.3 GB     disk1s4

 

[Membre supprimé 1060554]

En effet : comme tu le vois --> partition disk0s2 > Conteneur disk1.

Allez ! - une épreuve facile -->

• étant donné ta commande initiale > si je te dis qu'il faut adresser l'index d'appareil du Conteneur apfs et pas de la partition > et si je te dis qu'il ne faut pas mettre à la fin limits (qui retourne une information) > mais une valeur indiquant "tout l'espace libre disponible sans en excepter aucun byte"

=> qu'est-ce que tu proposes comme commande pour récupérer l'espace libre ? - poste-la ici.

 

[litobar71]

mon dieu ! jésus marie joseph! que les cornes du belzébuth m'en tombent !

un forum (à mon goût) où l'initiation du demandeur est suggérée/imposée.

cela est bien.

 

[RémiJulien]

hahaha !
Pas simple car je ne me suis mis à tout ça que cette nuit à 2h du mat
Mais je dirais...
diskutil ap resizeContainer disk1 0b
?

 

[Membre supprimé 1060554]

Exact : c'est bien -->

diskutil ap resizeContainer disk1 0b

• passe la commande > poste l'affichage retourné (toujours instructif) > repasse encore un :

diskutil list

• et poste le nouveau tableau --> qu'on voie si l'affaire est réglée (il peut y avoir des imprévus)...

 

[litobar71]

un certain Ouroboros prenant de l'âge, il pense sûrement à trouver successeur(e).

la sus-citée (phrase) est une boutade à prendre au sérieux.

 

[RémiJulien]

Mince !
Il semble persister dans ce qu'il m'annonçait quand je faisais mes trucs avec "limits" : à me dire qu'il ne peut pas être plus gros.
J'ai entré la ligne que tu m'as confirmée, mais voilà ce que ça donne :

/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_APFS Container disk1         159.8 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +159.8 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume SSD1013                 138.3 GB   disk1s1
   2:                APFS Volume Preboot                 22.2 MB    disk1s2
   3:                APFS Volume Recovery                518.8 MB   disk1s3
   4:                APFS Volume VM                      4.3 GB     disk1s4

Et pendant l'opération, il m'a "dit" :

Determined the maximum size for the targeted physical store of this APFS Container to be 159 848 566 784 bytes

 

[Membre supprimé 1060554]

Je me doutais qu'il y avait un lézard > à cause des index décalés au départ de la partition principale (disk0s4 et pas disk0s2) et du Conteneur (disk2 et pas disk1). L'espace libre (provenant vraisemblablement d'un Conteneur apfs disk1 supprimé) doit se situer en-dessus de l'actuelle partition disk0s2 (entre la partition EFI et la partition Apple_APFS) et pas en-dessous. Car si ça avait été en-dessous --> l'espace libre aurait été récupéré.

Il faut inspecter la distribution des blocs de la partition. Mais pour pouvoir la lire (avec un utilitaire appelé gpt = guid_partition_table_ utility) --> il ne faut pas que le SIP (System Integrity Protection) soit activé > car il verrouille l'accès (même en simple lecture) à la table de partition du disque de démarrage.

Donc passe la commande d'information préalable :

csrutil status

• qui retourne le statut du SIP

Poste l'affichage retourné.

 

[RémiJulien]

Merci Dieu !
Sacrebleu, jamais je ne m'en serais sorti seul
J'essaie de ne pas te faire perdre trop de temps et de sauter des étapes, j'ai redémarré avec un petit PommeR et enlevé cette cochonnerie de SIP
SIP status : disabled !

 

[Membre supprimé 1060554]

Alors enchaîne avec la commande :

sudo gpt show disk0

• au cas où tu ne serais pas familier de sudo --> à validation > une demande de password va s'afficher : tape ton mot-de-passe de session admin en aveugle - aucun caractère ne se montrant à la frappe - et revalide

• la commande affiche le tableau de la distribution des blocs du SSD

Poste ce tableau.

 

[RémiJulien]

Génial, j'apprends plein de trucs

      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  175781248       
  176190888  312206240      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
  488397128          7       
  488397135         32         Sec GPT table
  488397167          1         Sec GPT header

(et j'imagine que c'est cette chose qui commence à 409640 la clé du problème, car sa taille correspond, en proportion, exactement à l'espace manquant)

 

[Membre supprimé 1060554]

Voici la bande de blocs libres -->

     409640  175781248

• interprétation : cette bande commence au bloc n° 409640. L'extension totale de ces blocs libres - y compris le bloc de départ cité - est de 175781248 blocs (de 512 octets ici) = 89,99 Go.

Comme imaginé après l'échec de la commande de récupération > elle se situe entre cette tranche de blocs -->

         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B

• qui est la même chose que ceci -->

   1:                        EFI EFI                     209.7 MB   disk0s1

• et cette tranche de blocs -->

  176190888  312206240      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC

• qui est la même chose que cela -->

   2:                 Apple_APFS Container disk1         159.8 GB   disk0s2

• il serait assez poilant de recréer une partition exactement sur la bande de blocs intercalaire de 89,99 Go > mais je ne suis pas sûr que ça fasse ton affaire. Car manifestement ton souhait était de récupérer tout l'espace-disque possible au Conteneur apfs du volume SSD1013. Le problème est que les blocs d'un disque sont numérotés a priori (du n°0 ou 1er bloc au n°488397167 ici) > ce qui crée une orientation numérique de l'espace-disque. L'effet direct est qu'on peut récupérer à une partition de l'espace libre situé sur des blocs venant après (numériquement) > mais pas avant (numériquement). En images : situé "en-dessous" (numériquement) et pas "en-dessus" (numériquement) - comme c'est le cas ici.

• or la capacité de la bande de blocs libres est de 90 Go environ. Mais tu as 138 Go de données dans le volume SSD1013. En recréant une partition de 90 Go au-dessus avec un volume de la même taille > impossible de cloner SSD1013 dans le nouveau volume du dessus (excès de données). Sinon > le clonage fait > tu aurais pu démarrer sur le volume du haut > supprimer le Conteneur du bas et récupérer son espace.

Il faut donc que tu t'arranges pour sauvegarder tes 138 Go de données au volume d'un DDE USB > après quoi il faudra réinitialiser le SSD pour restaurer un seul volume-Système. Solution assez "vulgaire" mais incontournable.

 

[RémiJulien]

Je vois très bien !
Je vais faire suffisamment de sauvegardes pour redescendre au moins sous la barre des 90 Go, et je reviens vers toi.
Mille mercis !

 

[Membre supprimé 1060554]

Si tu copies dans le volume d'un DDE une bonne quantité de gros fichiers de ton compte d'utilisateur -->

• prévoir une marge de 10 Go après clonage dans un volume recréé au-dessus de 90 Go de capacité --> baisser les 138 Go à 80 Go = copier dans les 60 Go de données d'utilisateur

et si tu supprimes les originaux de ton compte --> alors le procédé : recréer un volume au-dessus > cloner SSD1013 dans ce volume > démarrer sur le clone > supprimer le Conteneur du bas > récupérer son espace => est une technique - certes acrobatique - mais bien rodée (en ce qui me concerne).

 

[litobar71]

la papatte du maître !

 

[RémiJulien]

Grand Sorcier, j'ai nettoyé, je suis donc apte à cloner !
(73 Go utilisés sur mon SSD1013)

 

[Membre supprimé 1060554]

Passe la commande :

diskutil list

• et poste le tableau --> que je voie à quoi ça ressemble.

 

[RémiJulien]

Voici !

/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_APFS Container disk1         159.8 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +159.8 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume SSD1013                 53.9 GB    disk1s1
   2:                APFS Volume Preboot                 22.2 MB    disk1s2
   3:                APFS Volume Recovery                518.8 MB   disk1s3
   4:                APFS Volume VM                      5.4 GB     disk1s4

Je suis même descendu à 54 Go utilisés

edit : est-ce que si je suis le protocole que tu vas je crois me proposer, je pourrai à postériori faire une partition Boot Camp ?