10.14 Mojave Mot de passe grisé montage volume

[Gregoryen]

Bonsoir, je reviens car j'ai peut-être trouvé une alternative.

J'ai un HDD de 1TO que j'ai pu libérer, du coup je l'ai formaté en APFS ( normal ). Comme cela je peux essayer de restaurer les volumes dessus.

Alors je suis allé dans utilitaire de disque, je suis allé sur mon HDD externe, j'ai créer un volume APFS.

Ensuite j'ai cliqué sur le bouton '" restaurer " puis " à partir de l'image sans titre "

Restauration de « Sans titre a restaurer » à partir de « Sans titre ».

Mais j'ai reçu ce message :

Validating target...
Validating source...
Validating sizes...
Restoring 
Verifying 
Inverting target volume...
APFS inverter failed to invert the volume - Paramètre invalide
L’opération n’a pas pu s’achever. (OSStatus erreur 22).

L’opération a échoué…

Pareil pour mon volume " Macintosh HD ( ancien mojave ) ".

Ceci dit dans le volume j'ai un fichier qui n'a aucune extension et qui s'appelle : ContainerToInvert

Alors je vais essayer une autre méthode, c'est de restaurer depuis TimeMachine depuis le disque de secours. Mais comme ma sauvegarde est sur le NAS je ne sait pas s'il va réussir à tout connecter. Je fait un retour.

 

[Membre supprimé 1060554]

Gregoryen

Quand tu utilises le bouton "Restaurer" dans le panneau de l'Utilitaire de disque > tu fais appel en coulisse à un utilitaire Apple intitulé asr (apple_software_restore) pour effectuer la tâche. asr était au départ un programme d'usine > qui a été incorporé ensuite parmi les exécutables appelables en ligne de commande d'OS X / macOS. Et par là-même incorporé à la fonction Restaurer de l'Utilitaire de disque.

Cet utilitaire asr a été implémenté récemment d'une fonctionnalité de restauration de l'apfs. Mais les choses se sont beaucoup compliquées avec le format apfs. Je te livre le résultat de mes expérimentations uniquement via un terminal (la limitation des 5000 caractères ne me pemettant pas d'abonder en explications du "pourquoi du comment". C'est donc une sorte de tuto "techniciste" comme je n'aime guère en fournir.

----------

a) il faut d'abord créer une image-disque en lecture seule du Conteneur apfs source > après l'avoir démonté de tous ses volumes. Ce qui implique de n'être ni démarré sur le volume de démarrage de ce Conteneur > ni sur son OS de secours > mais sur un OS indépendant. Je vais supposer que le Conteneur source est disk3 > et que je dispose d'un DDE attaché au Mac dont le volume BROL peut servir de destination à l'image-disque créée (forcément volumineuse s'il y a beaucoup de données dans les volumes du Conteneur source). Voici les commandes pour cette phase :

diskutil umountDisk force disk3
sudo hdiutil create -srcdevice /dev/disk3 -format UDRO /Volumes/BROL/Conteneurdisk3.dmg

• la 1ère démonte de force le Conteneur source disk3 de tous ses volumes

• la 2è appelle hdiutil pour créer une image-disque en lecture seule Conteneurdisk3.dmg dans le volume BROL > dont la source est le device disk3 du Conteneur apfs.

Note : il est crucial que l'image-disque soit une image du Conteneur entier avec ses volumes auxiliaires --> faute de quoi il est impossible de recréer en sortie un Conteneur apfs valide.

----------

b) il faut ensuite incorporer une somme de contrôle (checksum) à l'image-disque Conteneurdisk3.dmg > puis vérifier l'identité de ses volumes dits "inversables" par asr. Voici les commandes pour cette phase :

sudo asr imagescan --source /Volumes/BROL/Conteneurdisk3.dmg
asr info --source /Volumes/BROL/Conteneurdisk3.dmg

• la 1ère utilise asr avec l'argument imagescan --> qui crée la somme de contrôle dans l'image-cible

• la 2è utilise asr avec l'argument info --> qui liste les volumes inversables contenus dans l'image-disque

----------

 

[Membre supprimé 1060554]

c) il faut ensuite préparer le disque de destination (ici une clé USB express - 400 Mo/s en écriture - indexée disk4 > 128 Go de capacité) > en créant sur sa partition principale un Conteneur apfs de stockage avec un seul volume apfs vide. Puis restaurer avec asr l'image-disque à ce volume apfs. Voici les commandes pour cette phase :

diskutil eraseDisk apfs TEST gpt disk4
sudo asr restore --s /Volumes/BROL/Conteneurdisk3.dmg --sourcevolumename "Macintosh HD" --t /Volumes/TEST --erase --noprompt

• la 1ère crée un format apfs sur le disque de destination > et exporte un Conteneur portant un unique volume TEST

• la 2è utilise asr pour restaurer l'image-disque non montée (avec mention du volume à inverser) > au volume apfs TEST > avec option de reformatage. Le volume TEST reformaté va héberger un fichier temporaire de restauration > suite à quoi il va être inversé en volume-clone du volume d'inversion sélectionné dans l'image-disque (avec renommage à l'identique du volume-source) > puis les volumes auxiliaires Preboot & Recovery vont être créés d'après la source de l'image-disque > dans le Conteneur de destination.

----------

Comme tu peux le voir à mon descriptif qui implique 6 commandes (dont 3 asr distinctes) --> la gestion de l'apfs est devenue une affaire logiquement compliquée. Compliquée en termes d'appareils aussi > car il en faut 4 au total : l'appareil de démarrage indépendant > l'appareil du Conteneur source > l'appareil du volume de stockage de l'image-disque > l'appareil de destination de la restauration.

Mais le résultat est à la hauteur de la grandeur du programme asr : le Conteneur de destination devient un clone absolu du Conteneur source - conformément au procédé de block_copy ("copie de blocs") d'asr.

Étant donné que ton Conteneur source contient 230 Go de données et que tu disposes d'un DDE de 1 To de capacité > il est possible de le repartitionner en 2 : un volume équivalent de mon BROL (pour héberger l'image-disque) > et un volume apfs de destination équivalent de mon TEST (partie prenante d'un Conteneur apfs exporté d'une autre partition).

Afin que tu puisses démarrer sur un Système indépendant > il te faudrait démarre par internet pour télécharger en RAM un OS de secours 10.14 de Mojave et opérer dans un terminal de sa session de secours.

 

[Membre supprimé 1060554]

Je vais décrire ici une variation dans l'emploi d'asr lorsque la source a un format apfs. Variation issue de multiples expérimentations - étant donné que le man d'asr concernant la gestion de l'apfs manque d'une description suffisante des techniques qui fonctionnent.

Comme dans ma description précédente > je me donne comme source un Conteneur apfs indexé disk3 en tant qu'espace-disque virtuel (exporté d'un magasin de stockage logé dans une partition primaire disk2s2 par exemple). Je vais supposer qu'en destination je dispose du disque vacant d'un DDE indexé disk4. Table GPT du disque > format de départ jhfs+ de la partition principale disk4s2 > montant un volume BROL.

Voici une technique d'emploi direct d'asr (par "direct' j'entends : faisant l'économie de la création d'un média = une image-disque .dmg de la source > comme dans la description de mon message précédent). Il y a 2 conditions strictes du succès de l'opération asr : a) que le Conteneur disk3 source soit démonté de tous ses volumes (il est donc exclu d'être démarré sur son volume-Système principal ou sur l'OS de secours de son volume Recovery) > b) que la partition de destination du DDE (disk4s2 dans mon exemple) soit convertie à l'apfs par une commande qui crée un Conteneur vide de volume apfs (Conteneur vide indexé disk5).

Je suppose donc un démarrage sur un volume indépendant de la source et de la destination. Voici les 2 commandes qui réalisent les conditions requises décrites ci-dessus -->

diskutil umountDisk force disk3
diskutil ap createContainer disk4s2

• la 1ère démonte de force le Conteneur source disk3 de tous ses volumes

• la 2è convertit la partition primaire du DDE disk4s2 en réceptacle d'un Physical Store (magasin de stockage physique apfs) > et exporte en tant que disk5 un Conteneur apfs sans volume (un espace-disque virtuel vacant)

----------

Voici alors la commande asr directe qui assure le clonage de la source = Conteneur disk3 => sur la destination = Conteneur disk5 :

sudo asr restore --s /dev/disk3 --t /dev/disk5

• s'il n'y a pas d'erreur dans le filesystem apfs de la source > cette commande toute simple est honorée > et le Conteneur de destination disk5 se trouve implémenté des volumes apfs de la source pour en devenir le clone exact : volume de démarrage principal + les 2 volumes auxiliaires Preboot (prédémarrage) & Recovery (secours). Le volume VM (archivage RAM) se crée automatiquement en cas de démarrage sur le volume de démarrage du clone.

 

[Membre supprimé 1060554]

J'ajoute quelques considérations rhétoriques assorties d'un caveat dans l'emploi d'asr.

Le système de fichiers apfs pourrait être décrit comme un virtualiseur d'espace-disque général (= Conteneur) > avec des sous-systèmes de fichiers définissant des volumes qui se partagent cet espace-disque. L'emploi de l'espace-disque général d'un Conteneur apparaît d'une grande plasticité. En effet > il est tout à fait possible d'avoir un volume de démarrage contenant un OS Mojave 10.14 > voisinant sur l'espace du Conteneur avec un autre volume de démarrage contenant l'OS High Sierra 10.13. Ou avec d'autres contenant des versions beta de ces OS.

Comme un volume-Système apfs n'est un volume "valide" qu'à la condition d'être flanqué de 2 volumes auxiliaires : un Preboot contenant les informations de prédémarrage du volume-Système (comme son chemin de démarrage pointant au lanceur boot.efi) & un Recovery contenant l'OS de secours (permettant une réinstallation mais aussi des opérations de réparation ou encore de définition d'options comme la désactivation du SIP ou encore celle du kext-consent) --> il faut donc qu'il y ait un Preboot & un Recovery sur l'espace du Conteneur. Une condition stricte de l'apfs étant qu'il ne puisse y avoir qu'un seul Preboot et un seul Recovery par Conteneur.

En cas de multiplication des volumes démarrables dans un même Conteneur (comme dans mon exemple un 10.14 & un 10.13) > chacun nécessitant pour être valide des informations de prédémarrage & un OS se secours dédié > mais un seul Preboot & un seul Recovery pouvant exister dans un même Conteneur --> les 2 volumes auxiliaires stockent des dossiers intitulés de l'UUID du volume de démarrage de référence > dans lesquels existent respectivement les informations de prédémarrage et l'OS de secours du volume de démarrage de référence. Dans mon exemple de 2 volumes de démarrage apfs (10.14 & 10.13) => il y aura donc 2 dossiers distincts dans Preboot & 2 dossiers distincts dans Recovery.

 

[Membre supprimé 1060554]

Voici le caveat dans l'emploi d'asr découlant de cette situation de coexistence concurrentielle de Systèmes démarrables distincts. Il apparaît dans tout cela que l'informatique ne fait jamais qu'appliquer techniquement des présupposés de départ de type idéologique : ici politiques (coexistence d'États = OS) & économiques (libre concurrence pour l'expansion dans un espace commun de partage). Si les prémisses idélogiques étaient d'une nature différente > il est évident que l'ingéniérie informatique réalisant techniquement ces prémisses serait d'ordre différent. Ici nous avons affaire à la réalisation technique d'une espèce d'utopie capitaliste : cantonner à une libre concurrence économique la coexistence politique de Systèmes différents.

Lorsqu'on passe dans ces conditions une commande de clonage asr --> il est impossible de cloner un Conteneur source avec tous ses volumes de démarrage en simultané. Il faut nécessairement choisir dans le Conteneur source un volume de démarrage privilégié > qui sera seul cloné dans le Conteneur de destination > avec génération d'un Preboot & d'un Recovery contenant ses seuls dossiers de référence. À supposer en exemple que le nom du volume de démarrage privilégié soit TEST-10.14 sur le Conteneur disk3 source > et qu'il y ait d'autres volumes de démarrage comme un TEST-10.13 => alors la commande asr doit être nécessairement :

sudo asr restore --s /dev/disk3 -sourcevolumename TEST-10.14 --t /dev/disk5

• l'introduction dans la séquence de base d'un -sourcevolumename TEST-10.14 désignant le seul volume TEST-10.14 comme volume de démarrage à cloner.

Que faire alors pour cloner aussi l'autre volume de démarrage intitulé TEST-10.13 dans mon exemple ? --> il faut effectuer une 2è passe d'asr par une commande de la forme :

sudo asr restore --s /dev/disk3 -sourcevolumename TEST-10.13 --t /dev/disk5

• où cette fois-ci l'option -sourcevolumename se trouve définie par le nom de l'autre volume de démarrage = TEST-10.13. Voici ce qui se passe alors : le Conteneur source complet (disk3) se trouve là encore cloné dans un volume temporaire intitué ASRVolumexxxxx > puis seul le volume désigné (ici TEST-10.13) se trouve pris comme source de l'inversion du volume temporaire en un volume clone TEST-10.13 > enfin les dossiers de référence de ce volume dans les 2 volumes auxilaires Preboot & Recovery du Conteneur source --> se trouvent clonés dans les 2 volumes Preboot & Recovery déjà existants du Conteneur de destination > en mode coexistant des dossiers déjà créés pour le volume TEST-10.14 cloné préalablement.

=> il s'opère donc une espèce de "création d'entreprise" seconde > dans le respect de l'entreprise primaire déjà déployée sur l'espace commun du Conteneur de destination.

 

[Gregoryen]

Salut merci pour tes réponses.

Alors j'ai branché un HDD externe, j'ai restauré via TimeMachine "Macintosh HD (ancien mojave)" sauf que il manque quelques GO de données puisque ce n'était une sauvegarde qui datait du moment du bug.

Et je n'ai pas trouvé " sans titre " dans TImeMachine a moins qu'il soit bien planqué !

Sinon la actuellement j'ai démarré sur mon HDD externe sur ma session que j'ai restauré.

Si je fait disktuil list voici le retour :

Last login: Sat Oct 20 18:18:01 on ttys000
macbookethernet:~ gregoryen$ diskutil list
/dev/disk0 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk3         1000.0 GB  disk0s2

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                 Apple_APFS Container disk2         250.8 GB   disk1s2

/dev/disk2 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +250.8 GB   disk2
                                 Physical Store disk1s2
   1:                APFS Volume Macintosh HD ( ancie... 143.8 GB   disk2s1
   2:                APFS Volume Preboot                 110.5 MB   disk2s2
   3:                APFS Volume Recovery                3.1 GB     disk2s3
   4:                APFS Volume VM                      1.1 GB     disk2s4
   5:                APFS Volume Sans titre              55.0 GB    disk2s5
   6:                APFS Volume macOS Mojave            83.5 GB    disk2s6

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +1000.0 GB  disk3
                                 Physical Store disk0s2
   1:                APFS Volume **Macintosh HD (anci... 249.4 GB   disk3s1
   2:                APFS Volume Preboot                 106.0 MB   disk3s2
   3:                APFS Volume Recovery                1.6 GB     disk3s3
   4:                APFS Volume Sans titre TM *****     250.3 GB   disk3s4
   5:                APFS Volume Macintosh HD            188.1 GB   disk3s6
   6:                APFS Volume VM                      1.1 GB     disk3s7

macbookethernet:~ gregoryen$

Cependant tu dis dans ton message #82 qu'il faut que je soit sur un HDD externe ( j'y suis ) et démonter disk3.

Sauf que c'est disk3 mon HDD externe, donc avant de faire les manipulation je voulais être sur.

Cependant.. J'ai trouvé sur le SSD interne du mac le volume Preboot : Peut-on faire un truc pour remettre les choses ?

 

[Membre supprimé 1060554]

Gregoryen

Je te répondrai tout à l'heure (pour l'instant je vais faire une pause). Attention ! les index de disques donnés dans mes tutos d'asr précédents ne sont que des exemples imaginaires. Il faut bien entendu adapter aux disques réels.

 

[Membre supprimé 1060554]

Je vois donc que tu es démarré sur un des volumes du disque de 1 To externe. Il y a en tout 503 Go de données dans le Conteneur apfs de la partition disk0s2 > ce qui laisse 497 Go d'espace libre. Il est donc possible de rétrécir (non destructivement) ce Conteneur > pour créer en-dessous une partition disk0s3 de 450 Go (disons) montant un volume standard BROL.

Comme tu as 286,6 Go (taille prétendue car impossible sur un disque de 250 Go) dans le Conteneur apfs du disque interne --> il doit donc être possible de tester une commande asr de clonage du disque disk2 de ce Conteneur interne démonté de ses volumes (source) => à destination d'un Conteneur apfs qu'on générera sur la nouvelle partition du volume BROL externe.

=> est-ce que tu es d'accord avec cette tentative > qui implique donc un rétrécissement (non destructeur) du Conteneur apfs du disque de 1 To externe en préalable ?

=> ou bien est-ce que tu voudrais qu'on tente de ne cloner que le volume Sans titre du Conteneur apfs interne --> dans le Conteneur apfs externe actuel ?

 

[Gregoryen]

Alors je ne vois pas de soucis pour l'option numéro 1.

On peux faire ce que l'on veux dans le HDD externe actuel, puisque ce n'était juste qu'une restauration de Time Machine donc même si je perd des données ce n'est pas grave c'est qu'une restauration que je pourrais refaire.

Mais j'ai envie de tester l'option numéro 2 qui me semble être plus courte pour voir si cela va marcher. Je peux aussi formater mon HDD externe, y installer Mojave et avoir presque la totalité de mes 1TO !

 

[Membre supprimé 1060554]

Testons le repartitionnement. Car ton démarrage sur un des volumes du Conteneur externe bloque cette destination. Pas si on crée un volume indépendant.


Passe la commande (copier-coller) :

caffeinate -dimsu &

• la commande va empêcher le Mac de dormir (au cas où le repartitionnement traînerait en longueur)

Passe la commande (copier-coller) :

diskutil ap resizeContainer disk3 550g jhfs+ BROL 0b

• la commande rétrécit le Conteneur apfs externe à 550 Go > et crée une partition en-dessous d'environ 450 Go : format jhfs+ > volume BROL

Poste l'affichage retourné par la commande > quand tu auras récupéré l'invite de commande macbookethernet:~ gregoryen$.

 

[Gregoryen]

Donc voici le retour:

caffeinate -dimsu &

Last login: Sat Oct 20 18:18:04 on ttys002
macbookethernet:~ gregoryen$ caffeinate -dimsu &
[1] 10313
macbookethernet:~ gregoryen$
macbookethernet:~ gregoryen$ diskutil ap resizeContainer disk3 550g jhfs+ BROL 0b

Error starting APFS Container resize: There is not enough free space in the APFS Container for this operation (-69605)
macbookethernet:~ gregoryen$
macbookethernet:~ gregoryen$

 

[Membre supprimé 1060554]

Il n'y a pas assez d'espace libre dans le Conteneur (soi-disant). Passe la commande :

df -H /

• qui mesure l'occupation du volume démarré > mais surtout donne l'espace disponible total dans le Conteneur

Poste le tableau.

 

[Gregoryen]

df -H /
Last login: Sat Oct 20 21:51:59 on ttys000
macbookethernet:~ gregoryen$ df -H /
Filesystem     Size   Used  Avail Capacity iused               ifree %iused  Mounted on
/dev/disk3s6   1.0T   191G   307G    39% 2121723 9223372036852654084    0%   /
macbookethernet:~ gregoryen$

 

[Membre supprimé 1060554]

Il n'y a que 307 Go de libres dans le Conteneur. Càd. beaucoup moins que l'espace libre laissé théoriquement par la taille des fichiers que j'avais calculée.

Passe la commande :

tmutil listlocalsnashots /

• qui liste les snapshots éventuels du volume

Poste le retour.

 

[Gregoryen]

Last login: Sat Oct 20 22:03:49 on ttys002
macbookethernet:~ gregoryen$ tmutil listlocalsnashots /
listlocalsnashots: Unrecognized verb.
macbookethernet:~ gregoryen$

Alors après. ce que je peux faire :

J'avais créer deux volumes sur ce HDD externe. Un pour " ancien Mojave " et un autre pour " sans titre ". A l'intérieur j'avais un fichier " ContainerToInvert " ce fichier avait été créer quand j'avais fait " restaurer " . Alors je peux supprimer ces deux volumes pour faire de la place ?

 

[Membre supprimé 1060554]

Pardon : j'ai fait un lapsus vespéral en oubliant le p de snapshots. Voici la commande éditée :

tmutil listlocalsnapshots /

 

[Gregoryen]

Il ne me dit rien :

Last login: Sat Oct 20 22:10:42 on ttys001
macbookethernet:~ gregoryen$ tmutil listlocalsnapshots /
macbookethernet:~ gregoryen$

Après comme j'ai dit plus haut, je peux supprimer mes deux volumes ou la restauration avait échoué.

 

[Membre supprimé 1060554]

Sur quel volume es-tu actuellement démarré ? - quel est le volume dans lequel il y a le fichier ContainerToInvert qui doit avoir une taille respectable ?

 

[Gregoryen]

La je suis sur mon HDD externe. Je suis démarré sur un volume que j'avais restauré depuis TimeMachine.

Les deux autres volumes de ce HDD externe concerne la restauration depuis le bouton " restauration " de utilitaire de disque. Je l'avais fait pour mes deux volumes bloqués, et à chaque fois il me mettait le fichier sans extension nommé " ContainerToInvert ". Donc à la limite je peux supprimer ces deux volumes ça fera de la place.