10.11 El Capitan Restauration image disque sur partition

[fbike]

Bonjour

J'ai modifié la taille des partitions de mon disque (Lacie 6To Thunderbolt d2), sur lequel il y avait ma partition de démarrage

J'ai créé une image disque de mon macintosh hd ainsi que de toutes les autres partitions. Mieux vaut être prudent...

J'ai donc retaillé mes partitions et recréé la partition de ce disque pour être plus propre sur mes filesystem. (Je sais j'aurai pu agrandir et rétrécir avec le l'utilitaire de disque...mais...)

Lorsque j'ai voulu restaurer l'image de mon macintosh hd (dmg) sur la nouvelle partition, l'utilitaire de disque m'a envoyé dans les roses en me disant que les disques avaient une taille différente. Néanmoins, ce ne sont pas les 100 Go de l'image de mon macintosh HD qui ne pouvaient pas tenir dans sa nouvelle partition qui est de 800Go.

Cela est d'autant plus curieux que les autres partitions sauvegardées en dmg ont été restaurées sans encombres vers leur nouvelle destination...qui n'étaient pas de la même taille.

Si quelqu'un pourrait m'expliquer pourquoi un tel comportement ? car je n'ai pas eu d'autre solution que de restaurer mon Macintosh HD à partir du dernier backup time machine.

En vous remerciant par avance...

Christian

 

[Membre supprimé 1060554]

Salut fbike

La fonctionnalité "Restaurer" de l'«Utilitaire de Disque» pilote l'utilitaire asr (apple_software_restore) qui peut tout aussi bien se commander dans le «Terminal».

La spécificité foncière de l'utilitaire asr > est de ne pas copier en mode "fichiers" (comme par exemple les utilitaires cp > ou ditto > ou rsync) --> c'est-à-dire des "données" contenues dans le volume monté par un système de fichiers > mais de copier en mode "blocs" (comme par exemple dd) --> càd. de copier la série de blocs logiques correspondant à la "source" sur la "destination".

Mais une particularité d'asr (qui le distingue en cela de dd) > c'est d'être capable de retailler ("resize") le système de fichiers de la "source" > de manière à ce que seuls soient copiés les blocs porteurs d'écriture de la "source" sur les blocs du volume de la "destination" > sans pour autant que cela n'implique une réduction forcée de la taille de la "destination" à l'échelle d'une "source" plus étroite.

Cette "souplesse adaptative" fait que les volumes "source" et "destination" n'ont absolument pas à être congruents en taille totale a priori > tant que le nombre de blocs écrits sur le "source" n'excède pas le nombre de blocs disponibles sur la "destination". Ainsi > un grand volume (1 To) contenant 100 Go de blocs de données > peut être copié dans un petit volume de 200 Go de blocs disponibles. Inversement > un petit volume de 150 Go de blocs (dont 100 Go écrits) > peut être copié dans un grand volume de 1 To de blocs disponibles > sans que cela implique une réduction de taille logique de la destination qui serait rétrécie à 150 Go de blocs (100 écrits + 50 disponibles à congruence de la "source") > avec 850 Go de blocs neutralisés (marqués par des astérisques *).

Cette brève description pour te dire que l'échec que tu as expérimenté est logiquement incompatible avec le fonctionnement de l'utilitaire asr. Reste à savoir si la façon dont l'«Utilitaire de Disque» (sa version récente - du moins) le pilote > ne surimpose pas des limitations à asr. Ou si n'entre pas en jeu une disparité de systèmes de fichiers.

Tu n'as qu'à monter l'image-disque dmg qui constitue ta "source" > aller à : Applications > Utilitaires > pour lancer le «Terminal». Dans la fenêtre ouverte > saisis (l'une après l'autre) les 2 commandes simplement informatives :

diskutil list
df -H

et ↩︎ (presse la touche "Entrée" du clavier après chaque commande pour l'activer)

• la première va retourner le tableau des disques attachés à ton Mac (en interne / externe - physiques / virtuels) > avec leurs tables de partition > et leurs partitions décrites en format > nom > taille > appareil ;
• la seconde > va scanner les volumes actuellement montés > et mesurer leurs espaces : total > occupé > libre.

=> tu n'as qu'à poster ces 2 tableaux ici en copier-coller > en indiquant quel est le nom du volume "source" (dmg) et quel est le nom du volume qui aurait dû être sa "destination". Histoire de voir à quoi ressemble le tableau...

 

[fbike]

Salut fbike

La fonctionnalité "Restaurer" de l'«Utilitaire de Disque» pilote l'utilitaire asr (apple_software_restore) qui peut tout aussi bien se commander dans le «Terminal».

La spécificité foncière de l'utilitaire asr > est de ne pas copier en mode "fichiers" (comme par exemple les utilitaires cp > ou ditto > ou rsync) --> c'est-à-dire des "données" contenues dans le volume monté par un système de fichiers > mais de copier en mode "blocs" (comme par exemple dd) --> càd. de copier la série de blocs logiques correspondant à la "source" sur la "destination".

Mais une particularité d'asr (qui le distingue en cela de dd) > c'est d'être capable de retailler ("resize") le système de fichiers de la "source" > de manière à ce que seuls soient copiés les blocs porteurs d'écriture de la "source" sur les blocs du volume de la "destination" > sans pour autant que cela n'implique une réduction forcée de la taille de la "destination" à l'échelle d'une "source" plus étroite.

Cette "souplesse adaptative" fait que les volumes "source" et "destination" n'ont absolument pas à être congruents en taille totale a priori > tant que le nombre de blocs écrits sur le "source" n'excède pas le nombre de blocs disponibles sur la "destination". Ainsi > un grand volume (1 To) contenant 100 Go de blocs de données > peut être copié dans un petit volume de 200 Go de blocs disponibles. Inversement > un petit volume de 150 Go de blocs (dont 100 Go écrits) > peut être copié dans un grand volume de 1 To de blocs disponibles > sans que cela implique une réduction de taille logique de la destination qui serait rétrécie à 150 Go de blocs (100 écrits + 50 disponibles à congruence de la "source") > avec 850 Go de blocs neutralisés (marqués par des astérisques *).

Cette brève description pour te dire que l'échec que tu as expérimenté est logiquement incompatible avec le fonctionnement de l'utilitaire asr. Reste à savoir si la façon dont l'«Utilitaire de Disque» (sa version récente - du moins) le pilote > ne surimpose pas des limitations à asr. Ou si n'entre pas en jeu une disparité de systèmes de fichiers.

Tu n'as qu'à monter l'image-disque dmg qui constitue ta "source" > aller à : Applications > Utilitaires > pour lancer le «Terminal». Dans la fenêtre ouverte > saisis (l'une après l'autre) les 2 commandes simplement informatives :

diskutil list
df -H

et ↩︎ (presse la touche "Entrée" du clavier après chaque commande pour l'activer)

• la première va retourner le tableau des disques attachés à ton Mac (en interne / externe - physiques / virtuels) > avec leurs tables de partition > et leurs partitions décrites en format > nom > taille > appareil ;
• la seconde > va scanner les volumes actuellement montés > et mesurer leurs espaces : total > occupé > libre.

=> tu n'as qu'à poster ces 2 tableaux ici en copier-coller > en indiquant quel est le nom du volume "source" (dmg) et quel est le nom du volume qui aurait dû être sa "destination". Histoire de voir à quoi ressemble le tableau...

Bonjour macomaniac

Effectivement je ne pensais pas que ce soit une limitation d'ASR.... En vieux unixien je pensais qu'il ne faisait rien de plus particulier qu'un cpio ou un tar.... ce n'est pas le cas. Existe t-il une possibilité autre que de restaurer via une TM.. ou que de retailler les partitions en recovery, ce que je ne tiens pas trop à faire à cause des décalages...

Je suis preneur de commandes salvatrice dans ce cas particulier et en mode terminal !!!

christian@imac-de-christian:[~]: diskutil list | grep disk1
/dev/disk1 (external, physical):
   0:      GUID_partition_scheme                        *6.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS Macintosh HD            1.0 TB     disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3
   4:                  Apple_HFS Video                   3.9 TB     disk1s4
   5:                  Apple_HFS Vm                      1.1 TB     disk1s5

Voici le détail de l'image montée :

christian@imac-de-christian:[~]: diskutil list | grep disk4
/dev/disk4 (disk image):
   0:                            Macintosh HD           +2.0 TB     disk4

Et sa taille :

christian@imac-de-christian:[~]:df -H|grep disk4
/dev/disk4      2.0T    76G   1.9T     4%  18468759 469686565    4%   /Volumes/Macintosh HD 1

@macomaniac

Est ce que cette séquence de restauration aurait permis de solutionner le soucis:

En effet, en parcourant la page man d'asr, il y a une option : restoreexact qui permet d'agrandir ou rétrécir une partition ?

En supposant que fichierimage.dmg contienne une image dmg d'un volume bootable.

sudo asr restoreexact --source fichierimage.dmg  --target /Volumes/volume_a_restaurer

suivi de la commande bless permettant de rendre bootable le nouveau volume :

sudo bless --folder "/Volumes/volume_a_restaurer/System/Library/CoreServices" --bootinfo --bootefi

 

[Membre supprimé 1060554]

Christian

Pour tester une commande > il conviendrait que les noms des volumes "source" & "destination" ne soient pas identiques au préalable. Comme la commande asr renomme le volume de destination du nom de la source > et que le nom de la source = Macintosh HD convient > il suffirait de renommer le volume de destination (celui qui monte sur la partition disk1s1 de 1 To) en (par exemple) --> Brol.

Une fois monté le volume Macintosh HD de l'image-disque > la commande serait :

sudo asr restore --s /Volumes/"Macintosh HD" --t /Volumes/Brol --erase --noprompt

• une validation préalable de la source et de la destination s'opère (type de système de fichiers > taille)
• en cas de validation > une passe de recopie s'opère (affichée par tranches de 10%) > suivie d'une passe de validation (par tranches de 10% encore - très rapide).

Lorsque la "source" est un volume-Système qui monte sur une partition flanquée d'une Recovery HD subalterne > alors asr crée automatiquement une Recovery HD miroir sur le disque de destination > clone le dossier de démarrage de cette partition > clone par ailleurs les données de la "source" sur la "destination" > effectue la bénédiction du volume de destination. Un utilitaire vraiment très serviable.

Lorsque la "source" est le volume d'une image-disque dmg > pas de Recovery HD créée > quant au blessing : j'avoue que je n'en sais rien (je n'ai jamais testé ce cas de figure --> cloner une image-disque de volume-Système).

Personnellement > le volume de destination ayant été renommé Macintosh HD (en écho de nom du volume de l'image-disque) > je démonterais d'abord le volume de l'image-disque pour ne laisser qu'un volume Macintosh HD adressable > et je passerais la commande :

sudo bless --folder /Volumes/"Macintosh HD"/System/Library/CoreServices

Dans mon expérience > il suffit de pointer au répertoire CoreServices qui recèle le boot_loader : boot.efi > et cela suffit comme chemin à inscrire sur le header du volume (avec le flag "démarrable") --> l'EFI suivra sans difficulté le chemin lors du boot > et repèrera illico le boot.efi à exécuter.

 

[fbike]

macomaniac

Merci de toutes ces précisions. Il est sage en effet de renommer le volume destination, cependant effectivement le diskimagemounter lorsqu'il monte un dmg dont le nom correspond à un volume déjà monté lui ajoute un n° "Macintosh HD 1" dans mon cas.

Pour l'Automatic System Recovery:

Evidemment je n'ai pas testé ayant retaillé et réimporté la configuration avant de poser la question sur mon post. En effet, j'ai été surpris par le comportement de la restauration de l'image. Prudence et sagesse m'ont fait restaurer sur mon disk1s2 le dernier backup time machine.

Mais la question reste ouverte, faisant des dmg toutes les semaines environ de mon macintosh HD, dès que je dispose d'un disque pour tester cette opération, je vais essayer de m'y atteler.

En effet, je ne comprends pas ce qui dérange l'OS de devoir restaurer une image de 76 Go sur un nouveau slice de 1To au lieu de 2 To initialement - si ce n'estque le dmg doit avoir en information les paramètre de la taille de la partition, et que lorsque le new_hfs est imploré par l'utilitaire de disque et tente de créer un filesystem à la même taille en blocs. Or, il est très rare de créer une partition avec deux fois la taille identique... Ce que j'ai essayé de faire initialement en recréant un macintosh HD de 2 To.

Or, si l'on passe en ligne de commande, on outrepasserait cette étrangeté puisque - et a priori - la commande asr prévoit une option restoreexact.

Je suis d'autant plus dubitatif sur ce retour d'expérience, car venant du pc, les images systèmes crées via norton ghost permettaient de retailler les partitions.. et ce d'autant qu'unix et à plus forte raison darwin, sont très souple sur ce point: "Tout est fichier". Le dmg n'est qu'une enveloppe dont à l'intérieur se trouve le système de fichier.

Ainsi quelles seraient les chances de faire cette manipulation en passant passer par exemple les commandes suivantes (simulées)

christian@imac-de-christian:[~]hdiutil attach -noverify "Macintosh HD.dmg"
/dev/disk4                                               /Volumes/Macintosh HD 1
christian@imac-de-christian:[~]diskutil mount /dev/disk4
Volume Macintosh HD on /dev/disk4 mounted
christian@imac-de-christian:[~]:cd /Volumes/Macintosh\ HD 1
christian@imac-de-christian:[/Volumes/Macintosh HD]:tar cvf -. | (cd /Volumes/brol ; tar xvf - .)
........

christian@imac-de-christian:[/Volumes/Macintosh HD]:sudo bless --folder /Volumes//brol/System/Library/CoreServices
christian@imac-de-christian:diskutil umount /dev/disk4

et enfin:

christian@imac-de-christian:hdiutil detach /dev/disk4
"disk4" unmounted.
"disk4" ejected.
[

je tenterai donc, dès que je dispose d'un DD externe (même usb) de créer un système de fichier selon ce que nous venons de discuter, mais via asr et non pas un tar ou cpio...