10.15 Catalina Mise à jour impossible vers Big Sur

boxter

Membre confirmé
31 Octobre 2007
62
1
Bonjour,

J'ai un souci sur un MacBook Pro sous Catalina. Le SSD est de 500 Go et il y au total moins de 100 Go de data, pourtant c'est plein, j'ai testé avec Disk Inventory, et bien sûr pas de données...

Je ne peux pas faire la mise à jour car il n'y a plus de place du tout, je ne peux rien supprimer j'ai regardé, le plus que je peux c'est 10 Go de photos et encore, ça ne suffira pas pour la mise à jour qui me réclame au total 35 Go de libre environ : 25 de plus que les 10 Go restants

Capture d’écran 2021-07-26 à 17.09.19.png

pourtant c'est plein :
Capture d’écran 2021-07-26 à 17.11.05.png
et
Capture d’écran 2021-07-26 à 17.11.11.png
J'ai regardé aussi avec :

Bloc de code:
MBPAppiAventure:Data circuitglace$ 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_APFS Container disk1         500.1 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +500.1 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD - Données  474.1 GB   disk1s1
   2:                APFS Volume Preboot                 77.8 MB    disk1s2
   3:                APFS Volume Recovery                529.0 MB   disk1s3
   4:                APFS Volume VM                      2.1 GB     disk1s4
   5:                APFS Volume Macintosh HD            11.4 GB    disk1s5

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *640.1 GB   disk2
   1:             Windows_FAT_32 DISQUE DUR              639.8 GB   disk2s1

/dev/disk3 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +12.9 GB    disk3
   1:                        EFI EFI                     209.7 MB   disk3s1
   2:                  Apple_HFS Shared Support          12.6 GB    disk3s2

Un petit peu d'aide serait la bienvenue :)
Merci
 
Dernière édition par un modérateur:
Libère de l’espace sur ton volume interne. Qu’est-ce que tu veux faire d’autre ?

Cela aurait dû être fait depuis longtemps, 10 Go c’est vraiment à minimum.

DiskInventory ou GrandPerspective ou OmniDiskSweeper, ne peuvent calculer que la taille des répertoires qu’ils peuvent lire. Tu n’as donc qu’une image partielle de la situation.

J’utilise OmniDiskSweeper que je lance avec les droits sudo depuis le Terminal :

sudo /Applications/OmniDiskSweeper.app/Contents/MacOS/OmniDiskSweeper
 
Bonjour boxter

D'après la représentation des fichiers par Disk Inventory > tu as dans les 72 Go de taille de fichiers catalogués --> pour les 2 volumes : Système (Macintosh HD) & Données (Macintosh HD - Données) agrégés en un seul au démarrage.

- en regard : tu as une occupation de blocs de 474,1 Go pour le volume-Données + 11,4 Go pour le volume-Système => 485,5 Go. Ce qui fait donc une sur-occupation de blocs occupés (par rapport à la taille des fichiers catalogués) de : 485,5 Go - 72 Go = 413,5 Go.​

La bonne question consiste donc à se demander dans ton cas : quelle est la cause de cette sur-occupation de blocs occupés en excédent sur la taille des fichiers catalogués ? --> 2 conjectures sont envisageables :

- a) des snapshots listables seraient associés au volume-Données = instantanés apfs imageant des états passés du volume et retenant comme occupés tous les blocs correspondants - quand bien même l'utiilsateur aurait-il supprimé ensuite des masses de fichiers. Car les fichiers sont alors désindexés du catalogue des fichiers de l'apfs > sans aucune réduction de l'occupation des blocs verrouillés par les snapshots.​
- b) un snapshot corrompu (in-listable mais actif néanmoins) retiendrait des blocs occupés - à moins qu'il ne s'agisse d'une erreur grave du : space_man (le gestionnaire de l'allocation des blocs de l'apfs).​

Afin de vérifier ou d'infirmer ces conjectures --> passe les 2 commandes (séparément) :
Bloc de code:
diskutil ap listSnaps disk1s1
diskutil verifyVolume disk1
  • qui : listent les snapshots identifiables associés éventuellement au volume-Données > puis vérifient l'apfs du Conteneur et de ses 5 volumes

Poste les 2 retours => qu'on voie la sanction de l'expérimentation.

Note : en cas d'inexistence de snapshots ou de corruption de l'apfs --> il faudrait admettre que des fichiers invisibles ou protégés d'accès en lecture par le SIP (protocole de sécurisation) n'aient pas pu être mesurés par Disk Inventory.
 
J’utilise OmniDiskSweeper que je lance avec les droits sudo depuis le Terminal :

sudo /Applications/OmniDiskSweeper.app/Contents/MacOS/OmniDiskSweeper
HS____

Pourquoi ajoutes tu "Contents/MacOS/OmniDiskSweeper" à la fin de la commande ?
Uniquement "sudo /Applications/OmniDiskSweeper.app" ne suffit pas à lancer l'application ?
 
J’utilise OmniDiskSweeper que je lance avec les droits sudo depuis le Terminal :

sudo /Applications/OmniDiskSweeper.app/Contents/MacOS/OmniDiskSweeper
Bonjour

On le télécharge où OmniDiskSweeper ?
 
Dernière édition par un modérateur: