10.15 Catalina Mise à jour impossible vers Big Sur

[boxter]

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

​

pourtant c'est plein :

​

et

​

J'ai regardé aussi avec :

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

 

[Moonwalker]

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

 

[Membre supprimé 1060554]

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) :

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.

 

[Sly54]

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 ?

 

[edenpulse]

Uniquement "sudo /Applications/OmniDiskSweeper.app" ne suffit pas à lancer l'application ?

Non, ça n'est pas comme ça que ça fonctionne dans le Terminal.
Un .app est un dossier, mais l'exécutable binaire est bien dans Contents/MacOS/OmniDiskSweeper du .app.

 

[Nolsen12345]

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 ?

 

[peyret]

On le télécharge où OmniDiskSweeper ?

Ici --> https://www.omnigroup.com/more