10.15 Catalina Espace disque manquant

christoph-marti

Membre confirmé
1 Février 2013
17
0
Bonjour,

Le MacBook Pro 2015 de ma femme est sous Catalina (10.15.7). Il a un SSD de 500 Go,

Capture d’écran 2021-02-03 à 20.57.18.png

mais dans l'utilitaire disque on voit que seuls 480 Go sont disponibles.

Capture d’écran 2021-02-03 à 20.58.41.png

Où sont les 20 Go manquants ? La commande diskutil list indique ceci :

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_APFS Container disk1         479.9 GB   disk0s3

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +479.9 GB   disk1
                                 Physical Store disk0s3
   1:                APFS Volume Macintosh HD - Données  219.5 GB   disk1s1
   2:                APFS Volume Preboot                 82.1 MB    disk1s2
   3:                APFS Volume Recovery                528.9 MB   disk1s3
   4:                APFS Volume VM                      1.1 GB     disk1s4
   5:                APFS Volume DD principal            11.3 GB    disk1s5

Je ne suis pas habitué à interpréter ce type de listes, est-ce que quelqu'un peut m'aider et a une explication ce que sont ces 20 Go "fantômes" ?

Et à quoi correspond ce disque "Macintosch HD - Données"? Dans le Finder on ne le voit pas. Le nom "officiel" de son DD est "DD principal".

Merci !
 
Dernière édition par un modérateur:
Dernière édition par un modérateur:
Bonsoir,

Il te manque effectivement 20 Go qui devait être la capacité du volume disk0s2. Volume manquant dans ton retour de commande du terminal. Le problème est que tu peux uniquement rattraper les espaces vides (et non fantômes) du bas vers le haut mais jamais du haut vers le bas puisque le premier bloc d’un volume (superbloc) est inamovible. Ce volume est donc rattrapable qu’au volume du dessus soit le disk0s1 qui est hélas l’EFI non dimensionnable. Deux possibilités, soit admettre cet état, soit tout re installer après formatage.

Le volume données est une spécificité de Catalina. Il stocke toutes tes données. Le système occupe un autre volume en lecture seule qui s’appelle bizarrement chez toi DD principal. Sans doute une re installation
 
Dernière édition par un modérateur:
  • J’aime
Réactions: maxou56
Hello !

Petite question assez bête, mais as-tu essayé de regarder en détail via une app ? J’utilise OmniSweepDisk qui est pour moi très simple et très bien fait. Ce n’est pas sûr que tu arriveras à régler ton problème, mais mieux vaut essayer !

Autre chose, dans le menu  > à propos de ce Mac > stockage (laisse charger un moment). Peux-tu poster une capture d’écran?

Lien de l’app : https://www.omnigroup.com/more <<
 
Dernière édition par un modérateur:
Bonjour,
Je ne vois pas le rapport entre un volume vide de tout système de fichiers de 20 Go et un logiciel destiné à déterminer l’encombrement d’un disque
Il manque 20 Go à un disque de 500 Go de capacité qui n’offre donc plus que 480 Go. C’est donc un problème de capacité et non d’encombrement.
 
Dernière édition par un modérateur:
Je ne vois pas le rapport entre un volume vide de tout système de fichiers de 20 Go et un logiciel destiné à déterminer l’encombrement d’un disque
Il manque 20 Go a un disque de 500 Go de capacité qui n’offre donc plus que 480 Go. C’est donc un problème de capacité et non d’encombrement.

Le logiciel peut montrer le corps d’une partition étrangère qui pourrait être présente. Des fois après une maj, il se peut qu’une partition soit allouée comme une deuxième partition recovery et ça, l’application le voit.

Je n’ai pas dit que cela allait marcher, je propose juste une potentielle solution à son problème ;)

Boby
 
Dernière édition par un modérateur:
Bonjour,

Cette configuration du disque interne -->
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_APFS Container disk1         479.9 GB   disk0s3
  • montre qu'il existe actuellement sur le disque une bande de blocs libres de 20 Go. Soit cet espace libre est situé sous la partition apfs2 => et il peut directement se trouver récupéré au Conteneur apfs et à sa partition primaire > soit cet espace libre est situé entre la partition EFI1 et la partition apfs2 => et dans ce cas-là l'espace libre ne peut pas se trouver récupéré à la partition apfs et à son Conteneur.

Il suffit que Christoph passe la commande (copier-coller) :
Bloc de code:
diskutil ap resizeContainer disk1 0b ; diskutil list internal
  • qui récupère au Conteneur apfs et à sa partition tout espace libre situé en-dessous sur le disque > puis ré-affiche la configuration du disque interne

Poster le retour intégral de la commande => qui statuera sur l'état des lieux : réussite (=> l'espace libre était en-dessous de la partition apfs) ou échec (l'espace libre doit être en-dessus de la partition apfs). Sinon > une commande appelant l'utilitaire gpt (guid_partition_table_utility) peut afficher la distribution des blocs du disque et par là révéler l'emplacement de la bande de blocs libres > mais elle requiert en préalable la désactivation du SIP (protocole de sécurité) > car ce dernier bloque l'accès même en lecture seule à la table de partition GPT d'en-tête du disque de démarrage (table GPT qui gère la distribution des blocs du disque).
 
Dernière édition par un modérateur:
  • J’aime
Réactions: izel mor
Ton OS (Catalina ici présent) et tes App(s) prennent de l'espace sur le disque, normal ...
Merci Fullcrum mais ça ne doit pas être l'explication : sur mon iMac avec 2 To de DD la capacité est bien affichée juste : 2 To partout (utilisé + disponible = total). En revanche sur le MacBook de ma femme utilisé + disponible = 480 Go alors que son disque a une capacité de 500 Go.

Et merci à toutes vos autres propositions, j'essaierai la solution proposée par macomaniac ce soir.
 
Dernière édition:
@ izel mor

Dans l'OS Big Sur > la commande diskutil list a été implémentée et affiche les bandes d'espace libre de taille notable à leur localisation sur le disque. Pas dans les OS antérieurs.

- dans les OS antérieurs (comme l'OS Catalina de Christoph) > la commande diskutil list affiche la distribution des partitions du disque dans l'ordre de leur rang dans la table GPT (rang affiché en tête de chaque entrée = 1: > 2: etc.) > mais les bandes d'espace libre par définition hors partitionnement => ne sont pas affichées à leur localisation par rapport aux partitions.​
- les partitions d'un disque Mac n'existent pas "matériellement" sur le disque > au sens où aucune balise ne marque un bloc donné en lui attribuant la fonction de bloc de tête d'une partition > et aucune balise ne marque non plus le bloc de queue d'une partition. Mais les partitions sont des "projections logiques" d'après les descripteurs de partitions de la table GPT. Un descripteur GPT définit logiquement une partition selon 4 critères (et aucun autre) : le de rang de la partition > le du bloc de tête de la partition (dans la série arithmétique des blocs allant du n° 0 = 1er bloc au n°n = dernier bloc) > l'extension de la partition (en nombre de blocs) > le type de la partition (défini par un UUID qui le détermine universellement). C'est le kernel (le moteur du Système démarré en RAM) qui lit la table GPT d'en-tête du disque > et effectue la projection logique sur le disque des partitions correspondant aux descripteurs de cette table. Il construit par là les partitions projetées en tant qu'appareils logiques chargés en kernel.​
 
Dernière édition par un modérateur:
Merci pour ces explications précises et claires. Je note dans un bloc de mon cerveau qui a bien besoin d’une mise à jour.
 
@ izel mor

Je rajoute un petit topo explicatif :

- le bloc de tête d'une partition n'est donc jamais "balisé" matériellement (matérialisé) en tant que 1er bloc de partition > mais assigné tel par projection logique du kernel d'après le descripteur GPT correspondant.​
- mais le bloc de tête d'une partition a nonobstant une absolue spécificité dûment inscrite (écrite) sur ce bloc : il est le super-bloc du système de fichiers (formateur ou générateur de volume) > inscrit sur la série des blocs de tête d'une partition. Le super-bloc d'un système de fichiers est son point d'ancrage ou d'initialisation. Ses contenus d'écriture diffèrent selon les systèmes de fichiers (jhfs+ ou apfs etc.).​
- en conséquence : le bloc de tête d'une partition a toujours un double statut (c'est une espèce de Janus pour le dire en image) : il a un statut purement logique de 1er bloc d'une partition assigné par le descripteur GPT de la table > et il a un statut proprement matériel de super-bloc des écritures du système de fichiers formateur du volume de la partition.​
- ce double statut du bloc de tête (logique vs physique > théorique = début de la partition vs pratique = super-bloc du système de fichiers) => est absolument décisif à bien garder à l'esprit en cas de problèmes de dépannage consistant à recréer un descripteur GPT de partition perdue. Car il faut absolument que le bloc de tête de la partition logique qu'on recrée via la recréation théorique d'un descripteur GPT => coïncide avec le super-bloc du système de fichiers toujours inscrit sur les blocs du disque s'il n'y a pas eu reformatage.​
- c'est le kernel (démarré en RAM comme kernel_task) qui gère entièrement cette problématique. C'est lui qui projette logiquement une partition sur le disque d'après son descripteur GPT et construit par là un appareil logique ou disque virtuel de partition. Et c'est encore le kernel qui charge le système de fichiers de la partition > à la condition sine qua non que son super-bloc coïncide absolument avec le bloc de tête de l'appareil logique de la partition > chargement du système de fichiers donnant lieu au montage du volume qu'il forme.​
 
Dernière édition par un modérateur:
Merci encore. J’avais partiellement intégré ces informations en suivant tes dépannages. Un bon résumé remet de l’ordre dans mes idées disparates.

J’ai entre autres le souvenir d’un fil où tu tentais (et réussissais) de localiser avec précision le « point d’ancrage » pour réinjecter le descripteur.
 
Dernière édition par un modérateur:
Alors voici le résultat de cette commande Terminal :

Bloc de code:
MacBook-Pro-Barbara:~ Barbara$ diskutil ap resizeContainer disk1 0b ; diskutil list internal
Started APFS operation
Error: -69743: The new size must be different than the existing size
/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_APFS Container disk1         479.9 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +479.9 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD - Données  219.7 GB   disk1s1
   2:                APFS Volume Preboot                 82.1 MB    disk1s2
   3:                APFS Volume Recovery                528.9 MB   disk1s3
   4:                APFS Volume VM                      2.1 GB     disk1s4
   5:                APFS Volume DD principal            11.3 GB    disk1s5Û/code]

On dirait que cela n'a pas fonctionné... j'avoue aussi de ne pas avoir une grande idée de ce que suis en train de faire, vos discussions volent en tout cas 2 niveaux en dessus de mes connaissances !
 
Dernière édition par un modérateur:
Ce message d'erreur :
Bloc de code:
Error: -69743: The new size must be different than the existing size
  • montre qu'aucun espace libre récupérable n'existe en-dessous de la partition apfs. L'espace libre doit donc être située en-dessus > entre la partition EFI1 et la partition apfs2.

- pour le vérifier > il faut passer une commande exigeant la désactivation du SIP (protocole de sécurisation). Donc passe la commande préalble :​
Bloc de code:
csrutil status
  • qui affiche l'état du SIP

Poste le retour.
 
SIP activé (enabled).

----------

Pour désactiver le SIP > redémarre > les 2 touches ⌘R (cmd R) tenues pressées de l'écran noir => à la  = démarrage sur l'OS de secours. Tu obtiens un écran affichant une fenêtre de 4 Utilitaires macOS. Va à la barre de menus supérieure de l'écran > Menu Utilitaires > sous-menu : Terminal.

Lance-le et passe la commande :
Bloc de code:
csrutil disable
  • qui désactive le SIP

Cela fait > quitte le Terminal > va à : Menu  > Disque de démarrage > sélectionne DD principal > redémarre dessus.

----------

De retour dans ta session > passe la commande (copier-coller) :
Bloc de code:
sudo gpt show disk0
  • à validation > une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe de session admin en aveugle - aucun caractère ne se montrant à la frappe - et revalide
  • la commande lit la table GPT d'en-tête du disque > et affiche en conséquence la distribution des blocs gérés par cette table en : secteur de boot > partitions > bandes d'espace libre > sauvegarde de la GPT

Poste le tableau obtenu dans un bloc de code.
 
J'ai suivi tes instructions :

Bloc de code:
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   39324640       
   39734280  937370744      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
  977105024          3       
  977105027         32         Sec GPT table
  977105059          1         Sec GPT header
 
Dernière édition par un modérateur: