Containers à supprimer, oui, mais lesquels ?

[izel mor]

Bonjour,
C’était une simple suggestion avant de suivre ce que te propose @macomaniac pour que tu puisses retrouver une configuration normale.
Tu peux passer dans le terminal

ls /Vol*/Update

Le l de ls est un L minuscule

 

[Membre supprimé 1060554]

Je reviens dans le fil avec une interprétation révisée (A) sur un point et les résultats d'expérimentations diverses (B).

----------

A) Différemment à ce que je me figurais > le volume Update ne paraît pas jouer de rôle dans le boot de Big Sur. Pourquoi me figurais-je qu'il en jouait un ? Par transposition au snapshot de démarrage Big Sur du procédé qui permet de monter un snapshot standard. Voici le procédé -->

- supposons pour simplifier une distribution à 4 volumes apfs de Mojave avec un volume de démarrage unique Macintosh HD. Je passe dans le terminal de session d'utilisateur la commande :​

tmutil localsnapshot

• qui permet de créer un snapshot associé au volume de démarrage unique. Dans mon cas expérimental > la création se conclut par l'affichage :

Created local snapshot with date: 2021-04-15-151416

• et la commande additionnelle :

tmutil listlocalsnapshots /

• me permet de récupérer l'affichage complet du snapshot :

com.apple.TimeMachine.2021-04-15-151416

• le snapshot créé > une commande :

mkdir ~/Desktop/BOOT

• crée un dossier BOOT sur le Bureau de session. Dès lors la commande :

sudo mount_apfs -s com.apple.TimeMachine.2021-04-15-151416 / ~/Desktop/BOOT

• monte le snapshot (en lecture seule) au dossier BOOT pris pour point de montage avec le retour :

mount_apfs: snapshot implicitly mounted readonly

• graphiquement > le Bureau de session montre un remplacement du dossier BOOT par une paire d'objets identiquement libellés : Macintosh HD@snap-3288984 (3288984 étant le XID du snapshot dans mon cas particulier). Mais un glisser-déposer de chaque objet affiche l'identité : ~/Desktop/BOOT inchangée. Chacun de ces objets se comporte comme un dossier, ouvrant sur double-clic une fenêtre montrant un clone de la distribution des objets du volume Macintosh HD source. Si j'avais branché à mon Mac une clé USB configurée en GPT + jhfs+ avec volume CLE > une commande :

sudo mount_apfs -s com.apple.TimeMachine.2021-04-15-151416 / /Vol*/CLE

• convertirait l'affichage du volume CLE sur le Bureau de session en un objet unique Macintosh HD@snap-3288984 (ayant toujours l'identité /Volumes/CLE pour le terminal) comportant la même distribution des dossiers du volume source. Une commande correspondant au cas de figure expérimental existant :

diskutil umount ~/Desktop/BOOT
diskutil umount /Vol*/CLE

• démonte le snapshot et libère l'affichage du dossier BOOT ou du volume CLE qui servait de point de montage.

Étant donné ce mécanisme requérant un dossier ou un volume d'accueil pour servir de point de montage à un snapshot > et vu le non affichage du volume Update dans un tableau de diskutil de la distribution du Conteneur Big Sur démarré => j'avais conjecturé que le volume Update (entre autres fonctions) servait de point de montage au snapshot de démarrage de Big Sur.

Conjecture invalide - je m'en suis avisé suite à la conversation engagée dans ce fil. Pour une raison logique ultra simple à la base : un volume ne peut pas avoir 2 points de montage différents de manière simultanée (exclusion logique de la contradiction) > mais 1 seul. Si dans la distribution de Big Sur le snapshot de démarrage a pour point de montage / (point de montage en kernel privilégiant le volume actuellement démarré sur tous les autres volumes) > il ne peut pas simultanément avoir pour point de montage le volume Update. Cet argument logique se confirme par une preuve expérimentale : le volume Update se trouve monté indépendamment [où : j'y reviens ensuite] sous l'identité Update en même temps que le snapshot de démarrage a le point de montage / --> ce qui prouve qu'Update reste en-dehors du processus de boot de Big Sur.

- révision de la conjecture du boot de Big Sur : le snapshot de démarrage est une image apfs du volume source Macintosh HD > dont le kernel (= le moteur du Système chargé en RAM au démarrage en indépendance des disques) doit pouvoir assurer le montage en volume à son propre processus en RAM. Sans donc requérir un dossier ou un autre volume comme espace de point de montage. Ce montage en volume au kernel comme / du snapshot de démarrage de Big Sur assurerait donc le privilège de montage du volume-Système démarré. Il manque certes des détails techniques à cette conjecture révisée > mais n'étant pas ingénieur en informatique je suis cantonné à la rhétorique.​

----------

 

[Membre supprimé 1060554]

B) Puisque le volume Update se trouve libéré de fonction dans le boot de Big Sur --> j'admets l'interprétation de Cunningham dans l'article cité par izel mor : le volume Update est dédié aux mises-à-jour éventuelles du volume-Système Macintosh HD de Big Sur. Sans pour autant m'en satisfaire dans le détail. Car comment peut-on déclarer tranquillement qu'un snapshot alternatif se trouve créé dans le but d'être "patché" des différences du nouveau volume-Système de démarrage > sachant qu'un snapshot ne se monte qu'en lecture seule par défaut et n'affiche donc qu'un volume verrouillé ?

Je laisse de côté le détail technique (confus) du mécanisme de cette mise à jour > pour apporter les résultats de diverses expérimentations que j'ai pu faire avec ce volume.

- voici d'abord l'anomalie qui m'a déconcerté depuis le départ avec ce volume Update. Big Sur démarré > une commande diskutil dans le terminal de la session d'utilisateur n'affiche pas ce volume dans le Conteneur apfs. Pourtant dans la série des index d'appareils des volumes du Conteneur > il y a une lacune : par exemple d'un disk1s4 dans une série allant de disk1s1 à disk1s5 + l'index spécial du volume-snapshot démarré. Une commande simple :​

mount

• listant les volumes montés à leurs points de montage --> révèle alors que le volume Update non listé par diskutil se trouve néanmoins monté avec 3 autres comparses auxiliaires à la localisation :

/System/Volumes

• du volume-snapshot démarré. At: /System/Volumes donc > on trouve : Preboot (volume de prédémarrage) > VM (volume d'archivage de la RAM - nouvelle locailsation à la place de /private/var/vm avec Big Sur) et... Update (volume de mise-à-jour Système). Il manque Recovery (volume secours) non monté par défaut.

​

Ainsi : le volume Update concentre le paradoxe de se trouver monté à un point de montage caché du volume-Système démarré (/System/Volumes) sans donc que le Finder ne l'affiche monté > et de ne pas se trouver listé par diskutil comme volume apfs existant dans le Conteneur Big Sur démarré. Alors que si l'on boote sur la session de secours (ou sur toute autre distribution apfs externe : Big Sur ou pas) => le volume Update se trouve bien affiché par diskutil dans le Conteneur de référence non démarré. Il semble donc que la commande diskutil soustrait d'affichage le volume Update dans l'environnenement de session seul de l'OS démarré. Je faisait confiance à diskutil pour n'échapper d'existence aucun volume (monté ou non) --> il me faut réviser cette appréciation et soupçonner diskutil de camouflage d'affichage digne donc du Finder ou autre Utilitaire de disque.​

​

----------​

- voici maintenant une autre propriété du volume Update : comme son comparse VM d'archivage de la RAM => il a la propriété de se trouver régénéré automatiquement (en cas d'absence) au démarrage de la distribution Big Sur. Ce constat est parti d'une observation d'un clone brut produit par Carbon Copy Cloner : ce clone ne comporte dans la distribution de son Conteneur ni volume VM ni volume Update. Il suffit de démarrer sur le clone > pour que ces 2 volumes se trouvent automatiquement générés par le Système. Avec une différence poilante : le volume VM se trouve généré "en 1 seule fois" avec la spécification d'un point de montage : /System/Volumes/VM. Le volume Update lui "en 2 fois" (sic). Car au 1er démarrage sur le clone > un volume Update (commande mount) se trouve monté à une localisation : /private/tmp/tmp-mount/xxxxxx (ID variable) > et c'est après un 2è démarrage sur le clone > que ce point de montage temporaire se trouve déplacé à la location officielle : /System/Volumes/Update.​

​

Ce constat a son importance pratique pour le cas particulier de jxs. Car il va suffire qu'il démarre en mode secours > supprime dans le terminal de la session de secours le volume Update (bien affiché par diskutil pour une distribution non démarrée) dont le flag (attribut invisible) lui assignant un point de montage spécifique a été foiré > et qu'ii redémarre ... 2 fois (sic) sur le Macintosh HD de Big Sur. On peut présumer que le volume Update régénéré sera doté du flag lui assignant le point de montage : /System/Volumes/Udpate qui dissimulera ce volume d'affichage. Note : les fichiers dédiés à une mise-à-jour éventuelle se trouvent recréés automatiquement dans le volume Update régénéré. Comme l'oiseau Phénix en somme, ce volume dédié aux mises-à-jour possède la capacité de sa propre mise-à-jour après destruction.​

 

[jxs1]

Je reviens sur le fil avec un nouveau diskutil list internal après avoir fait une seconde clean Install de mon MBP...

Ceci dit semble-t-il que l'opération a fait le ménage...

Il a fallu d'abord que j'installe Catalina... qui a fait apparaître ce volume update, ensuite attendre que Catalina me propose la mise à jour vers Big Sur et voilà le résultat... le volume update a disparu après l'installation de Big Sur.

Pour information j'ai effectué la même opération à la première clean Install...

Existe-t-il une possibilité de virer ce "APFS Snapshot ⁨com.apple.os.update-...⁩ 15.1 GB disk1s1s1" ? ou est-il utile au bon fonctionnement de l'OS ?

/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.9 MB   disk1s2
   4:                APFS Volume ⁨Recovery⁩                613.9 MB   disk1s3
   5:                APFS Volume ⁨VM⁩                      1.1 GB     disk1s4
   6:                APFS Volume ⁨Macintosh HD - Données⁩  39.0 GB    disk1s5

 

[Locke]

Existe t'il une possibilité de virer ce "APFS Snapshot ⁨com.apple.os.update-...⁩ 15.1 GB disk1s1s1"?

Non.

où est-il utile au bon fonctionnement de l'OS?

Oui.

Lis la réponse #6 .

 

[jxs1]

Lis la réponse #6 .

Merci pour le lien effectivement, tout paraît plus clair...

 

[Membre supprimé 1060554]

@ jxs

Je vois que tu as réglé ton problème d'affichage du volume Update.

- par curiosité > passe la commande :​

mount

• qui affiche les volumes montés à leurs points de montage

Poste le retour,

 

[jxs1]

Hello macomaniac,

Oui, effectivement j'ai résolu cette histoire de volume update qui est réapparu à la seconde clean Install de Catalina et a disparu a l'installation de Big Sur... Merci toutefois de m'avoir apporter quelques explications sur la présence de ses volumes...

Pour répondre à ta demande, le retour de la commande mount ci-dessous :

/dev/disk1s1s1 on / (apfs, sealed, local, read-only, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk1s4 on /System/Volumes/VM (apfs, local, noexec, journaled, noatime, nobrowse)
/dev/disk1s2 on /System/Volumes/Preboot (apfs, local, journaled, nobrowse)
/dev/disk1s7 on /System/Volumes/Update (apfs, local, journaled, nobrowse)
/dev/disk1s5 on /System/Volumes/Data (apfs, local, journaled, nobrowse)
map auto_home on /System/Volumes/Data/home (autofs, automounted, nobrowse)

 

[izel mor]

Merci à @macomaniac. Ce volume Update et l'instantané sont effectivement très mystérieux et demandent de sérieuses compétences pour être décortiqués ainsi.

 

[Membre supprimé 1060554]

@ jxs

Cette ligne dans le retour de la commande mount -->

/dev/disk1s7 on /System/Volumes/Update (apfs, local, journaled, nobrowse)

• montre que le volume Update existe bien > et se trouve monté à la localisation : /System/Volumes/Update dans le volume-snapshot démarré. Alors que dans le 1er état de ta distribution Big Sur > il était monté à la localisation : /Volumes/Update.

• voici la différence : un volume monté au point de montage (invisible graphiquement) /Volumes du volume-Système démarré => l'est dans le répertoire /Volumes classique de montage des volumes indépendants (le volume-Système démarré n'y a qu'un lien symbolique redirigeant au point de montage en kernel /). En conséquence => le Finder prend en charge ce volume et l'affiche comme volume susceptible d'intéresser l'utilisateur sur le Bureau de session. Mais un volume monté au point de montage /System/Volumes du volume-Système démarré => l'est dans un répertoire dédié aux volumes apfs auxiliaires. En conséquence => le Finder n'affiche sur le Bureau de session aucun des volumes montés à cette localisation - car s'ils peuvent intéresser le fonctionnement du Système > ils ne sont pas estimés intéresser l'utilisateur. C'est ainsi du moins que se trouve programmée l'application : Finder.

• si tu avais au départ le volume Update monté at: /Volumes/Update (et donc affiché par le Finder) > au lieu de la localisation actuelle conforme : /System/Volumes/Update => c'est qu'un flag (une instruction invisible) de point de montage : /System/Volumes n'avait pas été attaché à ce volume à sa création. Il fonctionnait alors comme un volume ordinaire monté at: /Volumes et affiché de ce chef par le Finder. Ta restauration d'une distribution Big Sur conforme inclut actuellement par contre un volume Update dûment doté d'un flag de point de montage : /System/Volumes. Il est donc monté dans le répertoire de montage des volumes auxiliaires du Système et par suite reste clandestin - graphiquement parlant.

• les expérimentations dont j'ai rendu compte dans la partie B de mon laïus antérieur => montrent qu'en cas d'anomalie du volume Update > il est toujours possible de le supprimer dans le terminal de la session de secours. Il sera alors recréé automatiquement au redémarrage => avec un flag de point de montage : /System/Volumes qui renvoie ce volume à la clandestinité. De cela > je me suis avisé disons trop tard pour que tu aies pu en bénéficier en pratique. Car > comme l'avait bien noté le philosophe Hegel : la raison, comme la chouette de Minerve, prend son envol le soir. Image disant que la compréhension rationnelle intervient toujours après le surgissement des problèmes : en retard donc sur la nouveauté des problèmes.

----------

@ izel mor

Quand on n'est pas ingénieur informaticien mais simplement doté du bon sens cartésien, la compréhension de questions techniques de l'informatique ressemble étrangement à celle de ces entités invisibles dont se plaisait à débattre la scolastique du XIIIè siècle - ce qui a été tourné en dérision par la formule : "discuter du sexe des Anges". La prolifération de ces "entités logiques" avait été proscrite par Guillaume d'Occam dans la sentence : « Il ne faut pas indûment multiplier les "êtres de discours" ». Il préconisait donc d'employer son "rasoir d'Occam" pour retrancher rigoureusement le chiendent des "entités artificielles" inventées par l'entendement humain (comme les Anges donc dans mon exemple - je ne donne pas d'autres exemples pour ne pas effaroucher de lecteur de ces lignes). Nul doute que l'informatique contemporaine n'ait pris la relève de la scolastique du Moyen-Âge dans une version "mise à la page", tant les ingénieurs informaticiens se complaisent à faire proliférer les "entités logiques". Il n'est que de voir la prolifération d'une version à une autre des OS apfs, des "entités logiques" qui viennent peupler grotesquement le Conteneur de démarrage : des 4 volumes logiques initiaux de Mojave aux 6 actuels de Big Sur, pour prendre un exemple qui saute aux yeux. De ce point de vue, Apple ne fait pas exception à la dérive actuelle de prolixité dans la création d'entités logiques, et ne paraît absolument pas relever d'un "think different". Le privilège de ne pas être informaticien alors, mais simplement doté de bon sens, consiste dans le fait de ne pas être impliqué "professionnellement" dans cette fabrication à tout va d'entités logiques qui sont de purs artefacts technologiques. Donc de garder une liberté de jugement capable d'ironie.