Containers à supprimer, oui, mais lesquels ?

[jxs1]

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 :

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.

 

[Membre supprimé 1060554]

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

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.

 

[jxs1]

Bonjour @macomaniac,

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

/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

 

[Sly54]

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.

 

[Membre supprimé 1060554]

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 -->​

   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 -->​

   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 ?

 

[jxs1]

macomaniac, oui, je suis prêt à faire un test de vérification, mais qu'entends tu par test de vérification ?

 

[Membre supprimé 1060554]

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  :

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]

@macomaniac , voilà ce que donne le retour de commande diskutil list internal via le terminal de l'OS de secours

/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

 

[Membre supprimé 1060554]

Tu n'as qu'un volume Update en 6è position. Et une distribution à 6 volumes régulière - sans doublon.

- repasse un :​

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]

Voilà le retour de la commande dans la session habituelle :

/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

 

[Membre supprimé 1060554]

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

diskutil ap list

• qui affiche un tableau détaillé de l'apfs

Poste le retour.

 

[jxs1]

@macomaniac

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

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)

 

[Moonwalker]

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 :

Effacer un Mac à processeur Intel à l’aide d’Utilitaire de disque - Assistance Apple (ML)

Découvrez comment effacer (formater) le disque de démarrage intégré d’un ordinateur Mac à processeur Intel.

support.apple.com

La version Apple Silicon :

Utiliser Utilitaire de disque pour effacer un Mac avec puce Apple - Assistance Apple (FR)

Découvrez comment effacer (formater) le disque de démarrage intégré d’un Mac avec puce Apple.

support.apple.com

Bonne continuation.

 

[Membre supprimé 1060554]

@ 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 où 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ï]

Et un coup d'Onyx qui utilise les commandes Terminal pour réparer les systèmes ?

 

[jxs1]

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 où 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 ?

 

[baron]

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)

 

[Membre supprimé 1060554]

@ 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.

 

[izel mor]

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.


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]

Bonjour izel mor,

Comment puis-je lister en ligne de commande ce que contient le volume update ?