Containers à supprimer, oui, mais lesquels ?

jxs1

Membre junior
3 Octobre 2018
43
11
44
Bonjour à tous,

Suite à une clean install de mon MBP 2018, lorsque je consulte "l'utilitaire de disque" j'ai eu la surprise de découvrir dans ceci :

e6m1.png

J'ai dans un premier temps installé Mojave, puis une fois installé, la mise à jour de Big Sur m'a été proposée donc je l'ai installée dans la foulée.

Une bonne âme pourrait elle m'indiquer quels sont les containers que je peux supprimer ?
Pour information, le container Update et apparu au moment où j'ai effacé totalement mon disque, puis les containers Macintosh - HD Données, com.apple.osupdate-35XXX avec la mise à jour vers Big Sur.

Merci d'avance de votre aide.
 
Dernière édition par un modérateur:

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
83 901
25 212
Forêt de Fontainebleau
Bonjour jxs

L'affichage graphique de l'Utilitaire de disque paraît refléter une distribution de volumes régulière pour l'OS Big Sur.

- en complément d'informations => va à : Applications > Utilitaires > lance le «Terminal». Dans la fenêtre ouverte > saisis la commande informative (ce qui est inscrit sous Bloc de code) :​
Bloc de code:
diskutil list internal
et ↩︎ (presse la touche "Entrée" du clavier pour exécuter la commande)
  • tu vas voir s'afficher de mode texte la configuration du disque interne décrite exhaustivement

Poste le retour en copier-coller > en veillant à faire le coller dans un Bloc de code (c'est plus lisible !) par le procédé suivant -->

- en bas de cette page des forums MacGé => utilise le menu (le 16è depuis la gauche = vers le milieu de la barre) 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.​

=> ces informations montreront la distribution complète des volumes dans le Conteneur apfs => et je pourrais de la commenter.
 
  • J’aime
Réactions: litobar71

jxs1

Membre junior
3 Octobre 2018
43
11
44
Bonjour @macomaniac,

Toujours opérationnel et assidu, merci de ton retour. Ci-dessous le copier-coller du retour de commande diskutil list internal :

Bloc de code:
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:                        EFI ⁨EFI⁩                     314.6 MB   disk0s1
   2:                 Apple_APFS ⁨Container disk1⁩         500.0 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +500.0 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume ⁨Macintosh HD⁩            15.1 GB    disk1s1
   2:              APFS Snapshot ⁨com.apple.os.update-...⁩ 15.1 GB    disk1s1s1
   3:                APFS Volume ⁨Preboot⁩                 294.7 MB   disk1s2
   4:                APFS Volume ⁨Recovery⁩                611.0 MB   disk1s3
   5:                APFS Volume ⁨VM⁩                      1.1 GB     disk1s4
   6:                APFS Volume ⁨Macintosh HD - Données⁩  41.6 GB    disk1s5
   7:                APFS Volume ⁨Update⁩                  1.2 MB     disk1s6
 
Dernière édition par un modérateur:

Sly54

Acrobate de l'espace
Modérateur
Club MacG
31 Janvier 2005
50 269
9 401
Nancy___
Une bonne âme pourrait elle m'indiquer quels sont les containers que je peux supprimer.
Note de la modération: une bonne âme va déplacer ton post qui n'a pas de rapport avec les Mac portables dans le forum adéquat.
 
  • J’aime
Réactions: jxs1

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
83 901
25 212
Forêt de Fontainebleau
Tu as une distribution Big Sur "presque" régulière mais pas tout à fait. Car une distribution régulière de Big Sur comporte 6 volumes et la tienne en comprend 7.

- voici la distribution régulière -->​
Bloc de code:
   1:                APFS Volume ⁨Macintosh HD⁩            15.1 GB    disk1s1
   2:              APFS Snapshot ⁨com.apple.os.update-...⁩ 15.1 GB    disk1s1s1
   3:                APFS Volume ⁨Preboot⁩                 294.7 MB   disk1s2
   4:                APFS Volume ⁨Recovery⁩                611.0 MB   disk1s3
   5:                APFS Volume ⁨VM⁩                      1.1 GB     disk1s4
   6:                APFS Volume ⁨Macintosh HD - Données⁩  41.6 GB    disk1s5
  • Preboot (prédémarrage) > Recovery (secours) > VM (Virtual Memory : archivage de la RAM et du swap) => sont les 3 volumes auxiliaires classiques d'un OS apfs.
  • Macintosh HD - Données⁩ est le volume-Données associé au démarrage au volume-Système. Il contient les données sujettes à variation de l'OS + les données dédiées à l'utilisateur (fichiers personnels et logiciels tiers).
  • Macintosh HD est le volume-Système original. Scellé par un sceau d'intégrité > il ne sert pas à démarrer mais de paradigme (modèle) pour la confection d'un clone de démarrage (snapshot) dans le temps du boot. Il contient les données constantes de l'OS.
  • com.apple.os.update-(UUID kilométrique) est le clone démarré. Il s'agit d'un snapshot (image apfs) du volume-Système > monté normalement à un volume d'accueil dans le Conteneur intitulé ... Update au repos et renommé com.apple.os.update-(UUID kilométrique) après montage du snapshot et démarrage de l'OS imagé.

- voici l'anomalie -->​
Bloc de code:
   7:                APFS Volume ⁨Update⁩                  1.2 MB     disk1s6
  • ce n'est pas une anomalie "en soi" > car comme mentionné précédemment une distribution Big Sur "au repos" (non démarrée) => comporte un volume Update quasi vide qui servira de point de montage au snapshot de démarrage dans le temps du boot. Mais c'est une anomalie "fonctionnelle" pour l'OS Big sur démarré > car le volume Update original de la distribution Big Sur est la même chose (en tant que volume) que le : com.apple.os.update-(UUID kilométrique) qui est sa version montée du snapshot et démarrée. Il semble alors que le volume Update isolé soit un doublon sans emploi pour la distribution Big Sur canonique.

Es-tu prêt à faire un test de vérification ?
 
Dernière édition:
  • J’aime
Réactions: jxs1

jxs1

Membre junior
3 Octobre 2018
43
11
44
macomaniac, oui, je suis prêt à faire un test de vérification, mais qu'entends tu par test de vérification ? :rolleyes:
 
Dernière édition par un modérateur:

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
83 901
25 212
Forêt de Fontainebleau
Voici le test -->

- démarre les 2 touches ⌘R (cmd R) tenues pressées jusqu'à l'affichage d'une  = 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.​

Passe la commande  :
Bloc de code:
diskutil list internal
  • qui affiche la configuration interne seule

Voici comment tu vas pouvoir poster ici ce tableau sans avoir besoin de prendre de photo -->

  • tu sélectionnes le tableau > ⌘C pour le copier dans le presse-papier > ⌘Q pour quitter le Terminal > option  : "Safari" (dans la fenêtre des 4 Utilitaires) > ce qui lance un navigateur «Safari»
  • page Apple par défaut > un clic sur l'adresse de haut de page pour l'éditer > saisis  : macgénération (tout court  : c'est une barre de recherche Google) et valide > tu atteins le site MacGé > Forums > te connectes > ce fil > tu postes dans un bloc de code

=> ces informations montreront la distribution du Conteneur apfs. Si mon raisonnement antérieur est juste > ton OS Big Sur étant au repos (non démarré) => 2 volumes Update devraient se trouver affichés dans le Conteneur apfs : le Update original point de montage du snapshot > ayant récupéré son intitulé après démontage et extinction de l'OS > et le Update surnuméraire.

Note 1 : si tu ne peux pas poster via le Safari de la session de secours (ça arrive) --> poste une photo du tableau (à partir du commencement = le disque /dev/disk0 ou disque physique interne) - tu as un bouton : "Joindre un fichier" en bas de cette page.

Note 2 : dans la session de secours > les applications se lancent en mode "alternatif" et pas parallèle. Il faut quitter le Terminal pour lancer Safari. Vice-versa > quitter Safari pour récupérer l'écran général de la session de secours et pouvoir relancer le Terminal. Aucun redémarrage n'est requis.

Une fois que tu as posté ici les informations depuis la session de secours > redémarre normalement (Menu  > Redémarrer) et reviens dans ta session habituelle. La session de secours n'a plus d'emploi.
 

jxs1

Membre junior
3 Octobre 2018
43
11
44
@macomaniac , voilà ce que donne le retour de commande diskutil list internal via le terminal de l'OS de secours

Bloc de code:
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:                        EFI ⁨EFI⁩                     314.6 MB   disk0s1
   2:                 Apple_APFS ⁨Container disk2⁩         500.0 GB   disk0s2

/dev/disk2 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +500.0 GB   disk2
                                 Physical Store disk0s2
   1:                APFS Volume ⁨Macintosh HD⁩            15.1 GB    disk2s1
   2:                APFS Volume ⁨Preboot⁩                 294.7 MB   disk2s2
   3:                APFS Volume ⁨Recovery⁩                611.0 MB   disk2s3
   4:                APFS Volume ⁨VM⁩                      1.1 GB     disk2s4
   5:                APFS Volume ⁨Macintosh HD - Données⁩  41.8 GB    disk2s5
   6:                APFS Volume ⁨Update⁩                  1.3 MB     disk2s6
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
83 901
25 212
Forêt de Fontainebleau
Tu n'as qu'un volume Update en position. Et une distribution à 6 volumes régulière - sans doublon.

- repasse un :​
Bloc de code:
diskutil list internal
  • dans le terminal de ta session habituelle et poste le retour => qu'on voie la distribution une fois démarrée.
 

jxs1

Membre junior
3 Octobre 2018
43
11
44
Voilà le retour de la commande dans la session habituelle :

Bloc de code:
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:                        EFI ⁨EFI⁩                     314.6 MB   disk0s1
   2:                 Apple_APFS ⁨Container disk1⁩         500.0 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +500.0 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume ⁨Macintosh HD⁩            15.1 GB    disk1s1
   2:              APFS Snapshot ⁨com.apple.os.update-...⁩ 15.1 GB    disk1s1s1
   3:                APFS Volume ⁨Preboot⁩                 294.7 MB   disk1s2
   4:                APFS Volume ⁨Recovery⁩                611.0 MB   disk1s3
   5:                APFS Volume ⁨VM⁩                      1.1 GB     disk1s4
   6:                APFS Volume ⁨Macintosh HD - Données⁩  42.0 GB    disk1s5
   7:                APFS Volume ⁨Update⁩                  1.9 MB     disk1s6
 
Dernière édition par un modérateur:

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
83 901
25 212
Forêt de Fontainebleau
Toujours l'anomalie d'une distribution à 7 volumes au lieu de 6. Avec un volume Update affiché après démarrage.

- passe encore la commande :​
Bloc de code:
diskutil ap list
  • qui affiche un tableau détaillé de l'apfs

Poste le retour.
 

jxs1

Membre junior
3 Octobre 2018
43
11
44
@macomaniac

Bonjour, retour de commande diskutil ap list ci-dessous :

Bloc de code:
APFS Container (1 found)
|
+-- Container disk1 3189C471-3CBA-470A-B308-F2056ABD99A6
    ====================================================
    APFS Container Reference:     disk1
    Size (Capacity Ceiling):      499963174912 B (500.0 GB)
    Capacity In Use By Volumes:   59388301312 B (59.4 GB) (11.9% used)
    Capacity Not Allocated:       440574873600 B (440.6 GB) (88.1% free)
    |
    +-< Physical Store disk0s2 D4C06C67-BEB8-4672-BB59-1B97428E9EAF
    |   -----------------------------------------------------------
    |   APFS Physical Store Disk:   disk0s2
    |   Size:                       499963174912 B (500.0 GB)
    |
    +-> Volume disk1s1 36DB055F-1B70-474A-B234-9CEE08A53555
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk1s1 (System)
    |   Name:                      Macintosh HD (Case-insensitive)
    |   Mount Point:               Not Mounted
    |   Capacity Consumed:         15050698752 B (15.1 GB)
    |   Sealed:                    Broken
    |   FileVault:                 No (Encrypted at rest)
    |   |
    |   Snapshot:                  BE4D4E9F-7585-42F9-B25D-C3CD6788908E
    |   Snapshot Disk:             disk1s1s1
    |   Snapshot Mount Point:      /
    |   Snapshot Sealed:           Yes
    |
    +-> Volume disk1s2 BF038F35-BCD0-4AA0-84F6-E9F6177110AD
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk1s2 (Preboot)
    |   Name:                      Preboot (Case-insensitive)
    |   Mount Point:               /System/Volumes/Preboot
    |   Capacity Consumed:         294719488 B (294.7 MB)
    |   Sealed:                    No
    |   FileVault:                 No
    |
    +-> Volume disk1s3 8711FE56-8A4C-4B8C-BF24-31189A4D39D2
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk1s3 (Recovery)
    |   Name:                      Recovery (Case-insensitive)
    |   Mount Point:               Not Mounted
    |   Capacity Consumed:         610975744 B (611.0 MB)
    |   Sealed:                    No
    |   FileVault:                 No
    |
    +-> Volume disk1s4 6EA687B6-A571-41F6-8076-7B8CD5BFDFDB
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk1s4 (VM)
    |   Name:                      VM (Case-insensitive)
    |   Mount Point:               /System/Volumes/VM
    |   Capacity Consumed:         1073762304 B (1.1 GB)
    |   Sealed:                    No
    |   FileVault:                 No
    |
    +-> Volume disk1s5 451C587E-C05A-43E8-8FE2-2FD7A08E6747
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk1s5 (Data)
    |   Name:                      Macintosh HD - Données (Case-insensitive)
    |   Mount Point:               /System/Volumes/Data
    |   Capacity Consumed:         42194071552 B (42.2 GB)
    |   Sealed:                    No
    |   FileVault:                 No (Encrypted at rest)
    |
    +-> Volume disk1s6 7BBE2AB6-01AE-4B5E-A290-3EDFE6EF8451
        ---------------------------------------------------
        APFS Volume Disk (Role):   disk1s6 (No specific role)
        Name:                      Update (Case-insensitive)
        Mount Point:               /Volumes/Update
        Capacity Consumed:         1904640 B (1.9 MB)
        Sealed:                    No
        FileVault:                 No (Encrypted at rest)
 
Dernière édition par un modérateur:

Moonwalker

Dark Star
Club MacG
22 Avril 2006
22 462
4 685
Là-haut
Suite à une clean install de mon MBP 2018,

Rappel : pour effacer son Mac, il y a une procédure précise à suivre.

[depuis quelques années, on a des procédures précises pour tout et n’importe quoi sur macOS]

La version Intel :


La version Apple Silicon :


Bonne continuation.
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
83 901
25 212
Forêt de Fontainebleau
@ jxs

Le tableau détaillé n'apporte pas d'informations neuve. Il est absolument régulier pour l'OS Big Sur > sauf (comme signalé précédemment) en ce qui concerne le volume Update de fin de tableau. Ce volume ne devrait pas se trouver affiché en conditions de démarrage de Big Sur. Mais servir d'espace de "formation en volume" du snapshot de démarrage.

- car un snapshot en soi n'est pas un volume > mais une méta-donnée imageant un état temporel d'un volume source qui est ici le volume-Système Macintosh HD. Pour qu'un snapshot devienne un volume > il lui faut l'assignation d'un espace permettant cette "formation en volume". Normalement > d'après ce que j'ai compris du tonctionnement de Big Sur > c'est le volume Update qui tient ce rôle d'espace de "formation en volume" du snapshot. Mais lorsque cela se produit > le volume Update de départ cesse d'apparaître en tant que tel (càd. comme un volume autonome quasi vide) > mais se trouve converti en "espace de volume" du snapshot. Ce qui n'est manifestement pas le cas chez toi > puisque le volume Update continue de subsister en mode indépendant une fois Big Sur démarré.​
- ce qui soulève une question : si un snapshot a besoin d'un espace pour sa "formation en volume" > et étant donné que le volume Update dans ton Conteneur ne joue manifestement pas ce rôle => qu'est-ce qui permet actuellement au snapshot de démarrage d'avoir acquis la "forme d'un volume" ? Ce n'est pas nécessairement un volume d'accueil > cela peut aussi bien être un dossier qui joue ce rôle d'espace de "formation en volume". Si donc le volume Update du Conteneur a été dépossédé de la fonction d'espace de "formation en volume" du snapshot de démarrage au profit d'un dossier dédié à cette fonction --> quel est donc ce dossier et réside-t-il ?​
- on sait que le point de montage du snapshot est celui ci : Snapshot Mount Point: /. La / désigne par convention le point de montage du seul volume démarré "en kernel", càd. dans le processus moteur chargé en RAM au démarrage. Mais pour qu'un volume de démarrage se trouve monté "en kernel" comme / => il doit d'abord avoir une existence formelle de volume. Ce qui renvoie à ce que j'ai décrit précédemement : avant qu'un snapshot ne puisse se trouver monté "en kernel" au point de montage / --> il faut que la méta-donnée snapshot ait d'abord été convertie dans la "forme d'un volume". Et pour cela > disposer d'un espace (volume préexistant ou dossier) => permettant cette "formation en volume".​

Bon : cette espèce de méditation logique (n'y vois rien d'autre et en tout cas rien d'assertorique) me conduit à un constat d'échec de l'interprétation. Je ne peux pas rendre compte de l'anomalie d'un volume Update tenu hors jeu de la formation en volume du snaphot en condition de démarrage de ton Big Sur. Ça n'a pas l'air de gêner en quoi que ce soit dans la pratique le fonctionnement de ton OS. Ce n'est gênant que d'un point de vue théorique disons (lacune d'explication) et aussi cosmétique (affichage indû d'un volume Update dans l'Utilitaire de disque).
 

Toum'aï

Membre calcifié
Modérateur
Club MacG
16 Décembre 2010
4 702
3 725
MarWest
Et un coup d'Onyx qui utilise les commandes Terminal pour réparer les systèmes ?
 

jxs1

Membre junior
3 Octobre 2018
43
11
44
Le tableau détaillé n'apporte pas d'informations neuve. Il est absolument régulier pour l'OS Big Sur > sauf (comme signalé précédemment) en ce qui concerne le volume Update de fin de tableau. Ce volume ne devrait pas se trouver affiché en conditions de démarrage de Big Sur. Mais servir d'espace de "formation en volume" du snapshot de démarrage.

- car un snapshot en soi n'est pas un volume > mais une méta-donnée imageant un état temporel d'un volume source qui est ici le volume-Système Macintosh HD. Pour qu'un snapshot devienne un volume > il lui faut l'assignation d'un espace permettant cette "formation en volume". Normalement > d'après ce que j'ai compris du tonctionnement de Big Sur > c'est le volume Update qui tient ce rôle d'espace de "formation en volume" du snapshot. Mais lorsque cela se produit > le volume Update de départ cesse d'apparaître en tant que tel (càd. comme un volume autonome quasi vide) > mais se trouve converti en "espace de volume" du snapshot. Ce qui n'est manifestement pas le cas chez toi > puisque le volume Update continue de subsister en mode indépendant une fois Big Sur démarré.​
- ce qui soulève une question : si un snapshot a besoin d'un espace pour sa "formation en volume" > et étant donné que le volume Update dans ton Conteneur ne joue manifestement pas ce rôle => qu'est-ce qui permet actuellement au snapshot de démarrage d'avoir acquis la "forme d'un volume" ? Ce n'est pas nécessairement un volume d'accueil > cela peut aussi bien être un dossier qui joue ce rôle d'espace de "formation en volume". Si donc le volume Update du Conteneur a été dépossédé de la fonction d'espace de "formation en volume" du snapshot de démarrage au profit d'un dossier dédié à cette fonction --> quel est donc ce dossier et réside-t-il ?​
- on sait que le point de montage du snapshot est celui ci : Snapshot Mount Point: /. La / désigne par convention le point de montage du seul volume démarré "en kernel", càd. dans le processus moteur chargé en RAM au démarrage. Mais pour qu'un volume de démarrage se trouve monté "en kernel" comme / => il doit d'abord avoir une existence formelle de volume. Ce qui renvoie à ce que j'ai décrit précédemement : avant qu'un snapshot ne puisse se trouver monté "en kernel" au point de montage / --> il faut que la méta-donnée snapshot ait d'abord été convertie dans la "forme d'un volume". Et pour cela > disposer d'un espace (volume préexistant ou dossier) => permettant cette "formation en volume".​

Bon : cette espèce de méditation logique (n'y vois rien d'autre et en tout cas rien d'assertorique) me conduit à un constat d'échec de l'interprétation. Je ne peux pas rendre compte de l'anomalie d'un volume Update tenu hors jeu de la formation en volume du snaphot en condition de démarrage de ton Big Sur. Ça n'a pas l'air de gêner en quoi que ce soit dans la pratique le fonctionnement de ton OS. Ce n'est gênant que d'un point de vue théorique disons (lacune d'explication) et aussi cosmétique (affichage indû d'un volume Update dans l'Utilitaire de disque).
macomaniac, merci de ton retour et d'avoir pris le temps d'interpréter les résultats transmis... :)

Du coup et dans le doute, mieux vaut que je laisse dans l'état ? Le seul détail qui me chagrine là dedans c'est que ce container "update" s'affiche également sur mon bureau au même titre que le Macintosh HD, en sélectionnant l'option "afficher les disques durs" dans le Finder... Existe-t-il une possibilité de le faire disparaître ce container "update" du bureau ?
 
Dernière édition par un modérateur:

baron

Membre d’élite
22 Avril 2008
1 672
433
LLN
Un cas semblable ici (avec apparition du volume Update sur le bureau) :
https://discussions.apple.com/thread/252466543

J'ai beau avoir relu les articles de Eclecticlight Co. sur la structure des volumes de boot Big Sur, je n'ai pas trouvé d'explication probante à ce volume (apparemment un dossier monté comme volume ?) sur un Mac Intel.
Tout au plus, j'observe qu'il semble souvent être caché mais sous-jacent (sous l'index disk3s4 dans le fil cité et dans le schéma ci-dessous) :
(<— clic)
 
  • J’aime
Réactions: jxs1

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
83 901
25 212
Forêt de Fontainebleau
@ jxs

Le volume Update n'est pas un "container". Un Conteneur ("container") est un espace-disque global virtualisé par une partition apfs primaire. Cet espace-disque virtuel héberge des volumes : 7 dans ton cas - dont le volume Update. Utilise simplement le terme "volume" pour désigner Update.

- comme tu as énormément de place sur ton disque > je te proposerais bien le plan suivant : repartitionner le Conteneur apfs pour créer un second Conteneur indépendant en bas de disque. Cloner (via la démo gratuite un mois de Carbon Copy Cloner) => le Conteneur du haut dans celui du bas. Observer alors la structure clonée > vérifier au démarrage si l'anomalie persiste dans le clone.​
- quoi qu'il en soit de cette inspection du clone > supprimer / recréer le Conteneur du haut > réinstaller Big Sur proprement > migrer les données du clone via l'Assistant de migration. Tu devrais alors récupérer une distribution Big Sur canonique.​

Comme tu n'as pas beaucoup de données > les opérations de clonage puis de migration ne devraient pas prendre beaucoup de temps. Tu remarqueras qu'il s'agit d'une résolution "pratique" consistant à supprimer le problème en supprimant la structure apfs qui le suscite - et pas d'une résolution "théorique" qui rendrait raison logiquement de l'anomalie par la compréhension de sa cause.
 
  • J’aime
Réactions: jxs1

izel mor

penn ar bed
4 Juin 2020
1 059
110
35
Bonjour,
Le volume Update apparait depuis la session de secours ou depuis un second OS installé sur le même disque. Ce volume contient des fichiers en relation avec des mises à jour comme les onglets Safari...
Je ne suis évidemment pas capable de donner la raison de leur présence mais ils sont faciles à lister. Ci après le retour sur un MBP avec un conteneur BS et un Mojave.... vu depuis Mojave.

Capture d’écran 2021-04-13 à 21.18.46.png

Un article Update semble montrer que ce volume est d'abord destiné à effectuer les mises à jour. En effet le snapshot blindé avec hachage crypto est, si je comprends bien, indéboulonnable et la moindre modification même d'un caractère bloquerait le système ...et le Mac.
il faut donc un point d'accueil à la mise à jour légitime du sytème par Apple et le nouveau système (snapshot?) serait téléchargé dans ce volume Update pour être ensuite déclaré légitime à remplacer le précédent. L'utilisation du volume caché permettrait également la mise à jour Online et rapide (via l'instantané). L'article détaille ma candide analyse.
A partir de là, en admettant l'article pertinent, quelle est la localisation normale du snapshot de démarrage hors mise à jour (dans ce volume ?) toutefois distinct en numérotation du snapshot qui apparait en disk1s1s1, le disk1s1 étant le volume système.
On peut également se demander si un problème d'installation avortée d'une mise à jour peut bloquer et faire apparaitre ce volume.
Il pourrait être intéressant d'avoir le contenu du volume Update de @jxs1 et bien sûr l'analyse de l'article par @macomaniac.
Ce volume Update me taquine depuis un certain temps
 

jxs1

Membre junior
3 Octobre 2018
43
11
44
Bonjour izel mor,

Comment puis-je lister en ligne de commande ce que contient le volume update ?
 
Dernière édition par un modérateur: