10.13 High Sierra Création image système High Sierra

alexandredemarseille

Membre confirmé
27 Septembre 2017
11
0
46
Je viens d'installer High Sierra sur ma machine et je n'arrive pas à créer une image disk de ma partition système comme je le faisais avant avec les versions antérieures à High Sierra. La fonction création image de mon disk est grisée, je précise que je boot sur l'utilitaire pour faire cette image d'habitude ... Quelqu'un sait pourquoi ?

On dirait que la fonction n'est plus disponible avec High Sierra !

Merci
 
D

Deleted member 1099514

Invité
Salut

Pareil chez moi.
Seuls les volumes HFS sont dispo pour la création d'une image.
Les Volumes APFS sont eux "grisés" dans cette fonction.
 
D

Deleted member 1099514

Invité
@macomaniac :coucou:

Perso je parle de la partie Création d'une image du système (que j'utilise régulièrement au lieu des "cloner" bien connus) :
Sélection de la partition système APFS, puis Fichier/Nouvelle image et là "Macintosh HD" est grisé.
Aussi bien depuis le boot "normal" (ça parait logique) que depuis le boot en mode Recovery (ce qui l'est moins).;)
 
  • J’aime
Réactions: alexandredemarseille

alexandredemarseille

Membre confirmé
27 Septembre 2017
11
0
46
Je parle bien de la création de l'image via l'utilitaire High Sierra sur lequel on boot au démarrage qui permet de créer une image disk d'une partition et de la restaurer à tout moment, c'est très pratique et je faisais cela souvent avec les versions antérieures à High Sierra.
Je mets une capture d'écran ici pour mieux comprendre (la ligne est grisée)
Donc je ne comprends pas pourquoi la fonction création image du disque système n'est plus possible, c'est très gênant.
 

Fichiers joints

  • Capture d’écran 2017-09-27 à 10.51.51.png
    Capture d’écran 2017-09-27 à 10.51.51.png
    70,4 KB · Affichages: 324

r e m y

Membre vénérable
Club MacG
4 Novembre 2000
41 521
4 324
59
St Germain en Laye - FRANCE
Probablement qu'à la différence de Mike Bombich, l'utilitaire d'Apple n'est pas encore prêt pour cloner un disque APFS...
 

r e m y

Membre vénérable
Club MacG
4 Novembre 2000
41 521
4 324
59
St Germain en Laye - FRANCE
C'est un comble.:cool:

Juste une hypothèse de ma part!
En même temps, quand on lit la doc technique publiée par Apple sur APFS, on se dit que leur compréhension du fonctionnement de leur nouveau FileSystem est encore très très légère...
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
86 342
26 237
Forêt de Fontainebleau
Apparemment > l'équivalent suivant est disponible :

[pas de sélection de départ utile] > Fichier > Nouvelle image > Image d'un dossier > naviguer au volume > Choisir --> ce qui donne accès au panneau : Enregistrer sous [nom] > Destination [volume] > Chiffrement [choix] > Format d'image [choix] => Enregistrer.

Pour quelle raison par contre le procédé : sélection du volume > Fichier > Nouvelle image > débouche-t-il sur une option : Image de « [volume] » grisée ? - la conjecture que je pourrais proposer est la suivante -->

pour créer une image-disque d'après une source > diskutil appelle hdiutil > avec le verbe create > et une divergence d'argument possible :

  • -srcdevice --> la source est un device = l'identifiant d'appareil d'une partition (par exemple disk0s2) > la destination peut-être une image-disque à créer dans un volume monté. La condition pour l'emploi de srcdevice > c'est que le volume de la partition doive être démonté. Cette exigence témoigne d'un processus de copie en mode bloc (ce qui l'apparenterait à asr).

=> j'ai tenté via le «Terminal» de créer une image-disque d'un volume APFS démonté identifié par son device (par exemple disk11s1) --> la commande est rejetée par le message :
Bloc de code:
hdiutil: create failed - Autorisation refusée

  • -srcfolder --> la source est un volume monté = l'équivalent d'un répertoire recelant des fichiers (par exemple /Volumes/BROL) --> la destination peut-être une image-disque à créer dans un volume monté. Il n'y a pas de condition restrictive pour l'emploi de srcfolder (sinon que le volume source doit être monté) > ce qui témoigne d'un procédé de clonage tout à fait différent de scrdevice : une recopie en mode fichiers (ce qui l'apparente à cp > rsync > ou ditto).

=> j'ai tenté via le «Terminal» de créer une image-disque d'un volume APFS monté adressé en tant que volume (par exemple : /Volumes/BROL) --> la commande est validée sans aucune difficulté et l'image-disque se trouve créée en tant qu'enveloppe à la destination > puis "remplie" progressivement.

----------

Cette expérimentation me permet les conclusions suivantes :

dans l'«Utilitaire de Disque» > l'option : Nouvelle image > image de [volume] correspond à l'argument -scrdevice de hdiutil : copie en mode bloc de la partition du volume - impliquant le démontage du volume ; l'option : Nouvelle image > Image de [dossier] correspond à l'argument -scrfolder de hdiutil : copie en mode fichier du contenu du volume monté (et pas des blocs de sa partition).

Cette discrimination établie > pourquoi l'alternative qui marchait avec une partition dotée d'un système de fichiers JHFS+ sur laquelle montait un volume (on pouvait créer une image aussi bien en mode bloc qu'en mode fichiers avec hdiutil) --> n'est-elle plus supportée avec un volume APFS (on ne peut pas créer une image en mode bloc > seulement en mode fichiers) ?

C'est qu'un volume APFS > s'il est bien associé à un identifiant de device dans un Container APFS (par exemple, si le Container est disk1 > le volume-Système Macintosh HD sera disk1s1) --> n'est une partition qu'en apparence. Le Container APFS n'est pas un disque réel > dont le volume Macintosh HD occuperait une partition réelle. Le Container APFS est un pseudo-disque (son identification comme disk1 est purement symbolique) --> par voie de conséquence logique > le Volume APFS Macintosh HD qu'il recèle, bien qu'identifié comme un device disk1s1 > n'est qu'une pseudo-partition. Aucun alignement continu de blocs tel que dans une partition réelle ne correspond à la pseudo partition disk1s1 du Volume APFS. Or un clonage en mode bloc requiert nécessairement de pouvoir parcourir une alignement continu de blocs dans l'ordre de leur numérotation arithmétique entre 2 limites fixes.

Je pense que c'est ce changement de statut du Volume APFS : non plus volume montant sur une partition réelle de disque > mais volume résidant dans un Container virtuel avec une identification de pseudo-partition > qui invalide l'argument -scrdevice de hdiutil et son procédé de copie en mode blocs. Il faut donc se rabattre sur l'autre branche de l'alternative : l'argument -scrfolder de hdiutil et un procédé de copie en mode fichiers. Càd. dans l'interface graphique de l'«Utilitaire de Disque» le procédé : Fichier > Nouvelle image > Image de dossier > [répertoire du volume APFS monté].
 
Dernière édition:

r e m y

Membre vénérable
Club MacG
4 Novembre 2000
41 521
4 324
59
St Germain en Laye - FRANCE
Super Maco a encore frappé!

Reste plus qu'à tester la création de l'image-disque (en mode fichiers, donc), puis la restauration d'une telle image sur un disque vierge pour s'assurer qu'on obtient bien un volume bootable opérationnel.
 
D

Deleted member 1099514

Invité
Super Maco a encore frappé!

Reste plus qu'à tester la création de l'image-disque (en mode fichiers, donc), puis la restauration d'une telle image sur un disque vierge pour s'assurer qu'on obtient bien un volume bootable opérationnel.
C'est pas encore fait????:D
 

alexandredemarseille

Membre confirmé
27 Septembre 2017
11
0
46
Merci Marco pour ta réponse.
Alors, j'ai essayé ce que tu as dit et effectivement, ça semble fonctionner pour faire une image, sauf que ça prend 10x plus de temps qu'avant !
Ensuite gros problème, j'ai essayé de restaurer mais la fonction est grisée, impossible donc de restaurer l'image crée ! :/

Une idée ?
Merci
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
86 342
26 237
Forêt de Fontainebleau
Salut Alexandre

En consultant le man de diskutil mis-à-jour pour High Sierra > à la rubrique APFS > dans la présentation générale inaugurale > section dédiée au : + Volume --> il est mentionné dans le § final -->
Bloc de code:
Although it has a device node, an APFS Volume's data
may only be accessed through its files; you cannot
open an APFS Volume device node to "directly" access
its on-disk bytes.

Quoique le volume en question soit doté d'un « device node » (nœud d'appareil), les données d'un Volume APFS ne peuvent être "accédées" que par l'intermédiaire des fichiers (affichés dans ce volume) ; vous ne pouvez pas ouvrir le « device node » (nœud d'appareil) d'un Volume APFS pour accéder directement les bytes du disque qui supportent les écritures des données.

Cette stipulation correspond absolument à ce que j'ai essayé d'expliquer dans mon précédent message.

Sur un disque classique > tu as une partition qui va du bloc logique n° tant au bloc logique n° tant > et ce découpage de tranche logique (slice) est enregistré exactement dans la table de partition GUID de l'en-tête du disque.

Sur l'en-tête de la partition > tu as le système de fichiers JHFS+ classique. Ce système de fichiers fait en sorte que tout l'espace de blocs de la partition se trouve défini comme un volume : un espace logique montable par le kernel et exhibant les données d'écritures des blocs sous forme de fichiers interprétables. Le point de génération de cet espace-volume est le « dev node » : le "nœud d'appareil" ou point de montage du volume. C'est à ce dev node que se réfère le kernel pour monter le volume sur la partition-disque.

Dans cette situation classique > quand tu voulais cloner les données correspondantes (par exemple dans une image-disque) > tu avais 2 possibilités : le clonage de la partition ou clonage du volume.

Ce sont des procédés distincts dans leurs approches :

  • le clonage du volume accepte comme a priori le mécanisme logique par lequel le kernel a monté en volume exhibant des fichiers l'espace de la partition - ce en se référant au dev node (point de montage) fourni par le système de fichiers. La source étant constituée par des fichiers exhibés dans l'espace d'un volume monté > la destination est également l'espace d'un autre volume monté (géré par le système de fichiers de la partition de destination).

  • le clonage de la partition transgresse ce montage du volume par le kernel > en outrepassant le dev node (le point de montage du volume) > pour adresser les blocs logiques bruts de la partition. Cet accès à l'espace primaire de la partition implique le démontage du volume par le kernel et donc la neutralisation du dev node. Suite à quoi > les blocs de la partition peuvent être clonés à partir de leur n° initial > càd. que le système de fichiers lui-même de l'en-tête de la partition va être cloné.

C'est à cet état de choses que le système de fichiers APFS met fin. Même si le Volume APFS monté l'est à partir d'un point de montage (un dev node) > il n'est plus possible de traverser ce dev node pour accéder l'espace brut des blocs d'une partition qui serait le plan primaire de sustentation du volume.

Car le Volume APFS contenu dans le Conteneur APFS n'est plus le corollaire logique d'une section de disque déterminée. Càd. d'un alignement de blocs de A à Z qu'il suffirait de cloner pour emporter sur la destination l'ensemble du dispositif, système de fichiers y compris. Il y a bien un magasin de stockage physique (le Physical Store) qui correspond à la partition du disque - mais ce Physical Store sustente 4 Volumes APFS concomitants (celui des données et 3 auxiliaires) sans que le volume des données ait pour assignation une série continue de blocs logiques. Les blocs qui lui correspondent sont partout où ça peut dans la série des blocs du Physical Store.

Bref : le Volume APFS de données a bien un point de montage logique (un dev node) qui lui permet d'être monté par le kernel > mais ce dev node est verrouillé > car il ne correspond plus à une partition-disque de blocs continus classique.

Le procédé de clonage en mode blocs est donc forclos.

----------

Quand tu dis à présent qu'après avoir cloné en mode fichiers ton Volume APFS dans une image-disque > tu ne peux plus prendre cette image-disque comme source pour une restauration --> c'est le même problème mais à l'envers.

Car la fonction de "restauration" de l'«Utilitaire de Disque» appelle l'exécutable asr (apple_software_restore - une ancienne gloire de l'ingéniérie Apple) - exécutable qui ne sait faire qu'une chose : cloner en mode bloc.

Donc tu peux bien monter le volume de ton image-disque et la prendre en source pour asr = comme ton image-disque dmg est un disque physique virtuel de type mono-partitionné > le volume monté l'est via un dev node qui est traversable de façon classique > donc asr peut accéder aux blocs bruts de la partition du disque physique virtuel source.

Mais pas sur la destination ! Car la destination est un Volume APFS dont le dev node, comme j'ai tenté de l'expliquer, n'est plus traversable pour livrer accès aux blocs d'une partition de résidence fixe. Donc asr échoue en ce qui concerne la destination.

En résumé : le système de fichiers APFS est incompatible avec le clonage en mode blocs traditionnel --> aussi bien la commande hdiutil create -srcdevice que la commande asr restore. Il faut abandonner ce procédé. Il ne reste que le procédé de clonage en mode fichers.

La question ouverte serait : est-ce que dd (data_doubler) - qui clone uniquement par blocs - serait capable de cloner la partition de résidence totale du Physical Store (la disk0s2) ? Ce qui impliquerait de pouvoir adresser ses blocs ? Si c'était le cas > il faudrait envisager une commande du style :
Bloc de code:
sudo dd if=/dev/rdisk0s2 of=/[pathtovolume]/Image.dmg
(en rajoutant les options qui vont bien). L'ennui étant que ça n'en finit pas comme opération.

=> je conseille de passer à «Carbon Copy Cloner».
 
Dernière édition:
  • J’aime
Réactions: litobar71

alexandredemarseille

Membre confirmé
27 Septembre 2017
11
0
46
Salut Macomaniac
Merci pour ton implication.
Je trouve dommage de proposer des fonctions et de les griser et en tout cas, il aurait été bien qu'apple propose une solution de substitution qui pourrait exister puisque d'autres comme Carbon copy cloner savent le faire d'après ce que tu dis.
Concernant cette dernière solution, je vais la tester tout à l'heure, mais je doute qu'elle me satisfasse.
Je te tiendrai au courant.

Merci
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
86 342
26 237
Forêt de Fontainebleau
«Carbon Copy Cloner» clone le contenu d'un volume "source" dans un volume de "destination". Il s'agit d'un clonage en mode fichiers.

Tu peux très bien te créer dans un volume de destination une image-disque extensible dans un type SPARSEBUNDLE > monter son volume > et l'indiquer en destination du clonage de «CCC». Vice-versa > tu peux monter ton image-disque > et prendre son volume en source d'un clonage à rebours par «CCC». Il s'agira toujours d'un clonage en mode fichiers de volume monté à volume monté.

Clonage incrémentiel : seule les différences sont copiées, passé le premier clonage. Donc ça va vite à l'usage.

Je trouve dommage de proposer des fonctions et de les griser et en tout ca

Je pense que la fonction est maintenue > car le système de fichiers classiques JHFS+ est toujours supporté. Si tu as en source un volume JHFS+ > tu peux toujours opérer une clonage en mode bloc via l'«Utilitaire de Disque» à destination d'une image-disque. Tu peux aussi restaurer ton image-disque (= clonage en mode bloc encore) > si le volume de destination est encore un JHFS+.

On a affaire à une situation hybride où ça marche dans les cas classiques (JHFS+) et où ça ne marche plus dans le nouveau cas (APFS).
 

alexandredemarseille

Membre confirmé
27 Septembre 2017
11
0
46
Alors peut-être que je m'y prend mal mais Carbon Copy Cloner n'est pas vraiment intuitif.
J'arrive à créer une image, en revanche je n'arrive pas à trouver comment la restaurer.
J'ai lu sur un forum qu'il fallait redémarrer sur la partition Carbon Copy Cloner dans les préférences démarrage pour faire cela mais il n'apparait pas.
Si CCC est la seule alternative au clone via l'utilitaire OSX, alors, High sierra sera une nouvelle fois une mise à jour qui sur certains aspect, nous aura fait reculer.
 
D

Deleted member 1099514

Invité
Alors peut-être que je m'y prend mal mais Carbon Copy Cloner n'est pas vraiment intuitif.
J'arrive à créer une image, en revanche je n'arrive pas à trouver comment la restaurer.
J'ai lu sur un forum qu'il fallait redémarrer sur la partition Carbon Copy Cloner dans les préférences démarrage pour faire cela mais il n'apparait pas.
Si CCC est la seule alternative au clone via l'utilitaire OSX, alors, High sierra sera une nouvelle fois une mise à jour qui sur certains aspect, nous aura fait reculer.
Pour démarrer sur le clone, il faut appuyer sur la touche alt lors du boot et choisir la partition de clonage.
 

r e m y

Membre vénérable
Club MacG
4 Novembre 2000
41 521
4 324
59
St Germain en Laye - FRANCE
Pour démarrer sur le clone, il faut appuyer sur la touche alt lors du boot et choisir la partition de clonage.

Si le clone a été fait dans une image-disque (c'est ce que je comprends...), on ne peut pas booter sur une image-disque.
 

alexandredemarseille

Membre confirmé
27 Septembre 2017
11
0
46
En fait, mon disque principal est un SSD que j'ai partitionné en 2.
La première partition pour le système et la deuxième comme endroit ou je mets la copie clone. Ainsi, habituellement, je restaure à souhait en quelques secondes mon système et j'ai toujours un truc flambant neuf et speed avec mes sauvegardes perso sur un disque dur externe (et une copie enterrée dans le jardin de ma grand mère, on sait jamais)

Bref, CCC me permet de faire une copie de ma partition système dans un dossier sur ma deuxième partition mais je ne peut pas la restaurer, je ne sais pas comment faire. Je ne peux pas bosser dessus, ni via Alt (au démarrage) ni via l'utilitaire.

Je m'y prends mal ?
 
Dernière édition par un modérateur: