• Bonjour Visiteur. Bienvenue sur les nouveaux forums de MacGeneration. La peinture est encore fraiche, quelques boulons doivent être resserrés, plus d’informations demain !

10.13 High Sierra Images disque et Clones en APFS

Audiotech

Membre junior
16 Janvier 2018
28
1
26
Bonjour,

Je n'ai pas trouvé de topic créé à ce sujet encore donc je me permet de le lancer.

Je suis très souvent amené à gérer les installations de Mac pour des clients et malheureusement de plus en plus confronté à High Sierra aujourd'hui et bientôt Mojave. Or je me servait énormément de l'utilitaire de disque avant pour gérer mes images disques via une clef bootable ou le recovery de l'OS mais je m'aperçois qu'il n'est tout simplement plus possible de faire une image disque (comprimée) du disque système : Il apparaît grisé dans l'utilitaire de disque => fichier => Nouvel Image. Et ce, peu importe si j'utilise l'utilitaire de disque recovery ou celui d'une clef bootable.

Pourtant il semblerait que c'est possible ici ? (ce n'est pas hyper clair) : https://support.apple.com/fr-fr/guide/disk-utility/dskutl11888/16.0/mac/10.13

J'ai tenté de faire une image du disque système APFS avec l'utilitaire disque d'un OS en 10.12.6 et ça marche mais aléatoirement..

Aujourd'hui pour faire une image clean d'un mac en APFS je ne vois pas d'autre solution que d'utiliser Carbon Copy Cloner, mais du coup je n'ai pas d'image comprimée que je peux backuper...je n'ai qu'un clone.

Quels sont vos expériences à ce sujet ? Existe-t-il une méthode gratuite pour créer des images disques comprimées en APFS ?

Merci,
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
58 892
19 602
Forêt de Fontainebleau
Bonjour Audiotech

Dans un autre fil > j'avais fait un tuto sur manière de créer une image-disque valide d'un Conteneur apfs complet avec la commande hdiutil (hard_disk_image_utility). Puis d'utiliser la commande asr (apple_software_restore) pour restaurer un volume apfs de destination (créé vide) > en prenant en source l'image-disque.

Je te donne le lien au fil : ☞Mot de passe grisé montage volume☜ (clique le lien rouge). Mon tuto (avec une variante en apostille) s'étale sur les messages #82 > #83 > #84 > #85 > #86. Il est l'expression finale de nombreuses expérimentations > les autres s'étant soldées par des échecs de restauration.

Tu noteras 2 choses : a) je recours exclusivement au terminal (ayant complètement abandonné l'usage de l'Utilitaire de disque) > b) je fais créer par hdiutil une image-disque en lecture seule : une modification de l'option de format dans la commande pour format d'image compressée est des plus facile.
 

Audiotech

Membre junior
16 Janvier 2018
28
1
26
Merci macomaniac je vais tester ça !!
Juste une précision, pour l'image disque compressée la commande est :

UDCO (UDIF ADC-compressed image) ?

ou

UDZO (UDIF zlib-compressed image) ?

Je ne connais pas la différence entre l'ADC et le zlib.

Merci
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
58 892
19 602
Forêt de Fontainebleau
Tu as 4 options de formats compressés (à partir d'El Capitan) -->
Bloc de code:
            UDCO - UDIF ADC-compressed image
            UDZO - UDIF zlib-compressed image
            ULFO - UDIF lzfse-compressed image (OS X 10.11+ only)
            UDBZ - UDIF bzip2-compressed image (Mac OS X 10.4+ only)
  • UDCO - qui utilise le protocole ADC (Apple_Data_Compression) --> est de tous le + rapide mais le - compressif
  • UDZO a de chances d'être + compressif mais - rapide
  • ULFO - protocole Apple encore --> aussi compressif et même vitesse que UDZO mais 2 x + rapide à décompresser
  • je ne saurais pas situer dans cette grille le format UDBZ --> sinon qu'il est + compressif mais aussi - rapide que le UDCO basique - peut-être une version datée sans être obsolète
 
  • J’aime
Réactions: Audiotech

Audiotech

Membre junior
16 Janvier 2018
28
1
26
Hey macomaniac, donc après essai voici un petit retour :

Ma config :

Bloc de code:
/dev/disk0 (internal):
   #:                       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            103.7 GB   disk1s1
   2:                APFS Volume Preboot                 22.1 MB    disk1s2
   3:                APFS Volume Recovery                515.8 MB   disk1s3
   4:                APFS Volume VM                      2.1 GB     disk1s4

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                  Apple_HFS REMI_APFS               123.3 GB   disk2s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3
   4:       Microsoft Basic Data REMI                    899.9 GB   disk2s4
Ici les commandes pour la première phase que j'ai effectuée :

Bloc de code:
diskutil umountDisk force disk1

sudo hdiutil create -srcdevice /dev/disk1 -format UDCO /Volumes/REMI/image.dmg
Pas de soucis jusque là sinon que la création de l'image a pris 1h30 et l'image compressée fait 120 Go...Bizarre en sachant que la source ne devrait faire que 106 Go non ? Donc en compressé encore moins ?

La phase 2 s'est bien déroulée :

Bloc de code:
sudo asr imagescan --source /Volumes/REMI/image.dmg

asr info --source /Volumes/REMI/image.dmg

En revanche pas la phase 3 ... :

Bloc de code:
diskutil eraseDisk apfs TEST gpt disk0
Started erase on disk0
Unmounting disk
Creating the partition map
Waiting for partitions to activate
Formatting disk0s2 as APFS with name TEST
Mounting disk
Finished erase on disk0
Bloc de code:
sudo asr restore --s /Volumes/REMI/image.dmg --sourcevolumename "Macintosh HD" --t /Volumes/TEST --erase --noprompt
    Validating target...done
    Validating source...done
    Retrieving scan information...done
    Validating sizes...nx_kernel_mount:1359: : checkpoint search: largest xid 57153, best xid 57153 @ 106

Not enough space on /Volumes/TEST/ContainerToInvert to restore
Bizarre, mon disque de destination est le disque interne de destination est de 250 Go...

Merci de ton aide !
 

Audiotech

Membre junior
16 Janvier 2018
28
1
26
Voici donc un petit aperçu de ma config pour la restauration, le disque TEST étant le disque de destination.

Bloc de code:
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         250.8 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +250.8 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Preboot                 22.1 MB    disk1s2
   2:                APFS Volume Recovery                20.5 KB    disk1s3
   3:                APFS Volume TEST                    20.5 KB    disk1s1

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                  Apple_HFS REMI_APFS               123.3 GB   disk2s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3
   4:       Microsoft Basic Data REMI                    899.9 GB   disk2s4
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
58 892
19 602
Forêt de Fontainebleau
Refais l'opération en prenant le format UDRO (lecture seule) pour l'image-disque.

  • tu supprimes l'image-disque que tu as créée > tu réinitialises en apfs avec un seul volume TEST le disk0 > et tu refais le cycle

=> je me demande si le procédé de l'inversion utilisé par asr pour l'apfs n'implique pas une capacité du volume de destination qui fasse plus du double de l'image-disque : la taille de son clone + la taille de sa conversion (avant suppression de l'archive de départ) ?
 

Audiotech

Membre junior
16 Janvier 2018
28
1
26
Hello macomaniac,

Cela ne fonctionne pas non plus car le disque de destination n'est pas assez gros, et pour cause, l'image disque créée en Lecture seule fait 250 Go...
En fait c'est comme s'il faisait une copie de la totalité du conteneur APFS, or moi je n'ai besoin que de VM, Preboot, Recovery et mon volume logique.

Tu vas me dire si j'utilise la bonne commande.

Voici ma config à nouveau :

Bloc de code:
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         250.8 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +250.8 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            44.8 GB    disk1s1
   2:                APFS Volume Preboot                 38.9 MB    disk1s2
   3:                APFS Volume Recovery                1.0 GB     disk1s3
   4:                APFS Volume VM                      2.1 GB     disk1s4

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                 Apple_APFS Container disk3         123.3 GB   disk2s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3
   4:       Microsoft Basic Data REMI                    899.9 GB   disk2s4

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +123.3 GB   disk3
                                 Physical Store disk2s2
   1:                APFS Volume REMI_APFS               48.9 GB    disk3s1
   2:                APFS Volume Preboot                 31.2 MB    disk3s2
   3:                APFS Volume Recovery                523.5 MB   disk3s3
   4:                APFS Volume VM
Je démarre sur mon SSD externe avec le volume REMI_APFS issue du container APFS disk 2s2. Je souhaite faire l'image disque de Macintosh HD et de "ses composants logiques" sur mon volume externe en Exfat REMI : Disk2s4
La commande est donc :

Bloc de code:
sudo hdiutil create -srcdevice /dev/disk1 -format UDCO /Volumes/REMI/image-ps.dmg
Comment faire pour ne pas copier l'intégralité de la capacité du SSD du mac ?

Merci encore pour ton aide...
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
58 892
19 602
Forêt de Fontainebleau
Bonsoir Audiotech

Je pense avoir une solution "en amont". Voici le partitionnement primaire de ton disque "source" -->
Bloc de code:
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         250.8 GB   disk0s2
  • la partition disk0s2 est la génératrice du Conteneur apfs disk1 > lequel a exactement la même capacité que cette partition = 250,8 Go. Dans ce Conteneur > il n'y a en tout que 47 Go de données (grosso modo) réparties sur 4 volumes.

Par la commande :
Bloc de code:
diskutil ap resizeContainer disk1 60g jhfs+ BROL 0b
  • tu rétrécis non destructivement la partition de base disk0s2 à 60 Go (et le Conteneur exporté itou) > et tu crées en-dessous une partition disk0s3 de 190 Go environ > montant un volume BROL au format jhfs+.

Quand tu vas ensuite passer la commande :
Bloc de code:
sudo hdiutil create -srcdevice /dev/disk1 -format UDCO /Volumes/REMI/image-ps.dmg
  • la taille de l'image-disque sera alignée sur les 60 Go de blocs du Conteneur rétréci > étant donné que hdiutil avec l'argument -srcdevice du verbe create (source = device) --> copie les blocs de la partition source (et pas ses fichiers) comme s'il s'agissait d'une commande asr ou dd : c'est une copie en mode "blocs". Étant donné donc la spécificité de l'argument -srcdevice (égalité de taille de l'image créée avec la partition source) --> tu ne peux avoir une image réduite que si tu réduis l'extension en blocs de la partition source au préalable (solution "en amont"). Cette réduction de la taille de blocs de la source est possible au prorata de l'espace de blocs libres de cette partition. Tu remarques qu'avec l'apfs > au lieu d'adresser la partition primaire > c'est le Conteneur qui est pris pour device-source.

- note : s'il existe des snapshots dans le système de fichiers apfs générateur de Macintosh HD > un espace occupé fantôme sera retenu dans le volume > si des fichiers inscrits sur les blocs imagés par les snaphots ont été supprimés ensuite. Car cela ne libère pas les blocs indexés par les snapshots. Si les blocs en question sont dispersés un peu partout dans l'espace du Conteneur > une réduction de taille du Conteneur est impossible. Car le mécanisme logique d'un rétrécissement --> implique un clonage interne des écritures de blocs du "bas" du device => sur des blocs libres du "haut" du device > afin de ménager complètement une bande continue de blocs libres en bas de device. Si des blocs sont "retenus occupés" par des snapshots en bas de device du Conteneur --> ce ménagement d'espace libre continu en bas de device avant repartitionnement est rendu impossible.
 

Audiotech

Membre junior
16 Janvier 2018
28
1
26
Merci macomaniac, j'essaie ça de suite.

Peux-tu me donner la commande pour repartionner le Disk 0 comme à l'origine ? (virer le volume BROL une fois l'image créée).
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
58 892
19 602
Forêt de Fontainebleau
Une fois que tu as créé la nouvelle partition du volume BROL > elle est indexée disk0s3. Le Conteneur restant disk1 > si tu es démarré sur ton volume Macintosh HD (sinon l'index de disque du Conteneur peut varier).

Tu pourras passer la commande concaténée :
Bloc de code:
diskutil eraseVolume free null disk0s3 ; diskutil ap resizeContainer disk1 0b ; diskutil list
  • qui : a) supprime la partition disk0s3 de BROL > b) récupère l'espace libéré au Conteneur apfs disk1 et à la partition disk0s2 de base > c) affiche le tableau des disques

=> le tableau des disques affiché à la fin --> te permet de vérifier si tout est rentré dans l'ordre.
 

Audiotech

Membre junior
16 Janvier 2018
28
1
26
Ok merci,

Toujours coincé à la dernière phase lors de l'opération de restauration...Problème d'inversion...

La commande asr image scan est passée, tout comme asr info,

la commande de création d'un volume logique TEST est passée ce qui fait qu'on se retrouve dans cette configuration avant restauration :

Bloc de code:
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         250.8 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +250.8 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume TEST                    843.8 KB   disk1s1

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                 Apple_APFS Container disk3         123.3 GB   disk2s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3
   4:       Microsoft Basic Data REMI                    899.9 GB   disk2s4

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +123.3 GB   disk3
                                 Physical Store disk2s2
   1:                APFS Volume REMI_APFS               49.4 GB    disk3s1
   2:                APFS Volume Preboot                 31.2 MB    disk3s2
   3:                APFS Volume Recovery                523.5 MB   disk3s3
   4:                APFS Volume VM                      17.2 GB    disk3s4
Maintenant, voici comme se déroule la restauration sur le même volume TEST :

Bloc de code:
sudo asr restore --s /Volumes/REMI/image-ltrp.dmg --sourcevolumename "Macintosh HD" --t /Volumes/TEST --erase --noprompt
Password:
    Validating target...done
    Validating source...done
    Retrieving scan information...done
    Validating sizes...nx_kernel_mount:1359: : checkpoint search: largest xid 371, best xid 371 @ 1
done
    Restoring  ....10....20....30....40....50....60....70....80....90....100
    Verifying  ....10....20....30....40....50....60....70....80....90....100
    Inverting target volume...lookup_topology:1189: raw cont: disk0s2
lookup_topology:1190: synth container: disk1
lookup_topology:1191: synth vol: disk1s1
lookup_topology:1197: encrypted: no
*** Mounting outer volume (/dev/disk1 s1)...
nx_kernel_mount:1359: /dev/disk0s2: checkpoint search: largest xid 85, best xid 85 @ 169
nx_kernel_mount:1423: /dev/disk0s2: sanity checking all nx state... please be patient.
spaceman_metazone_init:476: metazone for device 0 of size 1264776 blocks (encrypted: 0-632388 unencrypted: 632388-1264776)
spaceman_trim_free_blocks:3009: scan took 0.000006 s, trims took 0.000000 s
spaceman_trim_free_blocks:3017: 46408491 blocks free in 16 extents
spaceman_trim_free_blocks:3025: 46408491 blocks trimmed in 16 extents (0 us/trim, 16000000 trims/s)
spaceman_trim_free_blocks:3028: trim distribution 1:3 2+:3 4+:2 16+:0 64+:0 256+:8

*** Getting image dstream info...
    ContainerToInvert: dstream_id=16, size=59999997952

*** Mounting inner volume (ContainerToInvert)...
nx_kernel_mount:1359: : checkpoint search: largest xid 371, best xid 371 @ 1
nx_kernel_mount:1423: : sanity checking all nx state... please be patient.
sanity_check_alloced_blocks:261: fs_alloc_count mismatch: fs root nodes 72573 extent 11 omap 1148 snap_meta 1 er: 0 udata: 11818659 fs_alloc_count 11902417
mount_inner_volume:872: Inner volume has snapshots

APFS inverter failed to invert the volume - Paramètre invalide
*Je précise que j'ai changé le label de mon image disque qui est désormais "image-ltrp"
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
58 892
19 602
Forêt de Fontainebleau
Je me demande si cette mention finale :
Bloc de code:
mount_inner_volume:872: Inner volume has snapshots
  • ne désigne pas le facteur d'échec : l'existence de snapshots pour le volume Macintosh HD

Démarre sur Macintosh HD > passe la commande :
Bloc de code:
tmutil listlocalsnapshots /
  • qui liste les snapshots existants

Poste le retour.

---------

Par ailleurs > je te conseille le format UDRO (lecture seule - pas de compression) pour la création de ton image.
 

Audiotech

Membre junior
16 Janvier 2018
28
1
26
Alors la réponse est oui, il semblerait qu'il y ait des snapshots. Apparemment c'est automatique depuis High Sierra et je n'arrive pas à les enlever. Sont-ils à l'origine du problème ?
J'essaie en lecture seule et je te redis. Je ressaierai avec une image d'un mac réinstallé à neuf pour voir si cela va mieux aussi.

Bloc de code:
tmutil listlocalsnapshots /
com.bombich.ccc.safetynet.44925C4B-3061-4A01-B0A3-96464F0CE3D5.2018-11-13-163626
com.bombich.ccc.44925C4B-3061-4A01-B0A3-96464F0CE3D5.2018-11-13-164608
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
58 892
19 602
Forêt de Fontainebleau
Ce sont des snapshots de Carbon Copy Cloner > pas de Time Machine. Voici comment tu les supprimes le + commodément -->

- démarré sur Macintosh HD > lance Carbon Copy Cloner > dans la colonne de gauche > onglet VOLUMES > sélectionne le volume Macintosh HD :
  • le champ de droite du panneau se modifie. En bas tu as une option : Instantanés CCC --> déplace le curseur pour afficher OFF. En haut > tu vois listé tes snapshots (qui est sont spécifiques de CCC - les snapshots Time Machine sont différents). Sélectionne-les un après l'autre > et presse la touche de suppression du clavier chaque fois. Attends la disparition de l'affichage chaque fois.
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
58 892
19 602
Forêt de Fontainebleau
Je fais une petite mise à jour.

- démarré mon clone de Mojave > j'ai répété l'expérience de créer avec hdiutil une image-disque du Conteneur apfs de mon OS Mojave source > puis de l'utiliser pour cloner avec asr à destination d'un Conteneur apfs ne comportant qu'un volume vide.​

- je me suis rendu compte que la moindre erreur dans l'apfs (système de fichiers générateur du Conteneur et de ses 4 volumes) > se répercutant dans l'image-disque de hdiutil > plantait in fine l'opération asr au moment d'effectuer l'inversion du fichier cloné dans le volume apfs de destination.​

- pour réparer les erreurs que comportait l'apfs de mon Mojave source > j'ai démarré sur un OS de secours indépendant et j'ai lancé une commande de réparation de l'apfs. À la condition stricte d'obtenir ensuite à la vérification un sans faute pour chaque objet de l'apfs (et pas seulement un quitus global du style : exit code 0 : code de sortie global de la vérification = sans faute) --> alors l'image-disque hdiutil est intègre > et l'opération d'inversion finale par asr aboutit. Il ne s'agit donc pas seulement d'incorporer une somme de contrôle correcte à l'image-disque > il faut qu'elle n'intègre aucune erreur dans le système de fichiers imagé.​
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
58 892
19 602
Forêt de Fontainebleau
Réflexions -->

- la commande asr dans son usage classique (source = format jhfs+ ou CoreStorage) --> est une commande simple à manier et non-sensible à l'erreur dans la source. Il suffit de prendre en source un volume démontable et en destination un volume également démontable. Alors s'effectue une copie des seuls blocs porteurs d'écritures de fichiers > et jamais de tous les blocs de la partition source. Copie absolue créant une partition de destination identique à celle de la source.​

- la commande asr dans son usage dernier cri (source : format apfs) --> est une commande exagérément compliquée à gérer > et totalement sensible à l'erreur dans la source. Compliquée car il faut passer par un intermédaire qui est la création d'une image-disque via hdiutil. Mais surtout totalement sensible à l'erreur dans la source > car le plus petit blème local dans l'apfs du Conteneur source est cause d'échec d'inversion finale du fichier cloné dans la destination.​

- dans les tutos que j'avais faits pour Gregoryen > j'avais fini par trouver une variante qui fonctionne sans intermédiaire et qui retrouve la simplicité d'usage de l'asr d'antan. En effet > une commande :
Bloc de code:
sudo asr restore --s /dev/disk2 --t /dev/disk4
disk2 = disque virtuel d'un Conteneur apfs source > et disk4 = disque virtuel d'un Conteneur apfs destination (ne comportant qu'un seul volume vide) se trouve marcher convenablement > mais... ... mais la condition sine qua non demeure une absolue absence d'erreur dans l'apfs de la source.​

- cette dernière méthode revenant à la simplicité de l'asr classique n'est absolument pas documentée dans le man d'asr > dont la mise-à-jour concernant un clonage de source apfs offre un spectaculaire exemple de verbiage impraticable.​

En résumé : la trop grande sensibilité à l'erreur dans l'apfs source (totalement non documentée dans le man d'asr) de la part de la commande asr + la complication du procédé canonique passant par l'intermède d'une image-disque de hdiutil --> ont pour conséquence un caractère quasi inutilisable d'asr pour ce qui est de l'apfs. Le caractère péniblement décevant de cette commande lorsque l'apfs est impliqué --> est qu'elle paraît fonctionner pour ne s'avérer planter qu'à la toute dernière extrémité. Ce qui fait qu'il y a une perte grave de temps et d'efforts pour tout ce qui est de la mise-en-œuvre des maillons préparatoires qui ne se révèle qu'a posteriori. Alors que l'asr classique implique une vérification a priori de la source et de la destination (en tailles et formats) > suite à quoi le processus engagé s'effectue toujours sans faute en n'avortant jamais sur un plantage a posteriori.
 

Audiotech

Membre junior
16 Janvier 2018
28
1
26
Macomaniac,

Grand merci pour toutes ces pistes de réflexion. Voici pour ma part un petit update de la situation :

Après suppression des snapshots sur la source à imager et verification via la commande
Bloc de code:
tmutil listlocalsnapshots /
, la commande as restore est passée sans problème avec une image disque en lecture seule. Dès que j'ai 5min, je refais le test en UDC0 (parce que quand même j'aime bien la compression :p).

-

Par contre je vais créer un topic concernant la ré-instal d'un OS en fusion drive parce que j'ai eu une belle galère hier...Pourtant on parle de JHFS+ et de Sierra...
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
58 892
19 602
Forêt de Fontainebleau
Content pour toi !

- tu pourrais à titre de vérification > démarré sur Macintosh HD > passer la commande :
Bloc de code:
diskutil verifyVolume /
  • qui vérifie l'apfs

Poste le tableau retourné --> il ne devrait pas y avoir d'erreurs locales.
 

Audiotech

Membre junior
16 Janvier 2018
28
1
26
Seems to be good ?

Bloc de code:
diskutil verifyVolume /
Started file system verification on disk1s1 Macintosh HD
Verifying file system
Volume could not be unmounted
Using live mode
Performing fsck_apfs -n -l -x /dev/rdisk1s1
Checking volume
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the object map
Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots
Verifying allocated space
The volume /dev/rdisk1s1 appears to be OK
File system check exit code is 0
Restoring the original state found as mounted
Finished file system verification on disk1s1 Macintosh HD