10.11 El Capitan Restaurer le système sur une partition de taille différente (tuto)

fbike

Membre confirmé
1 Novembre 2015
57
3
Bonjour

Tout d'abord je tiens à m'excuser pour ce double post qui fait suite à un fil de discution ouvert hier. Que les modérateurs m'excusent ou déplacent ce sujet où bon leur semble.

J'ai été confronté à un problème de restauration de mon image système "Macintosh HD" après avoir réduit la taille de cette partition. J'ai du restaurer mon disque à partir d'une sauvegarde Time Machine, n'ayant d'autre solutions sous la main. En effet, l'utilitaire de disque refuse de restaurer une image bootable sur une partition de taille différente.

Après avoir discuté avec macomaniac, j'ai pu me faire prêter pour tester cette possibilité un DD externe USB 2.0 de 320 Go (eh oui cela existe encore) !!

Information préalable :
mon image s'appelle "Macintosh HD"
mon volume ou elle est stockée "Data 3To"

C'est pour cela que vous verrez apparaitre des '\' suivi d'un espace après les noms de fichiers ou de volume et qui surchargent l'écriture. Le terminal nécessite ce prefixe pour annuler le sens de l'espace pour lui faire comprendre que cela fait partie du nom du fichier ou du volume et non pas un deuxième paramètre pour la commande tapée.

Prérequis :

- Je dispose d'une image du disque de démarrage dans /Volumes/Data\ 3To/Macintosh\ HD.dmg. Cette image a été créée à partir de mon disque de démarrage qui a une partition de 1To en mode récupération (démarrer le mac avec la touche option puis choisir recupération 10.11.6 (dans mon cas) et créeer à l'aide de l'utilitaire de disque l'image dmg de votre macintosh hd.

-Le disque sur lequel je vais restaurer mon macintosh HD (préalablement partitionné grace à l'utilitaire de disque comme je le souhaite (ici /dev/disk5) que j'ai nommé Brol ;)

Bloc de code:
/dev/disk5 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *319.4 GB   disk5
   1:                        EFI EFI                     209.7 MB   disk5s1
   2:                  Apple_HFS Brol                    319.0 GB   disk5s2

Voici mon image système à restaurer : (dmg compressé)

Bloc de code:
christian@imac-de-christian:[~]:ls -l /Volumes/Data\ 3To/Macintosh\ HD.dmg
-rw-r--r--@ 1 christian  staff    50G 23 avr 07:07 /Volumes/Data 3To/Macintosh HD.dmg

Je lance la commande asr (automatic system restore) à partir du terminal. Cette commande nécessite préalablement de vérifier l'intégrité de l'image à restaurer comme l'indique le message

Bloc de code:
christian@imac-de-christian:[~]:sudo asr restore --source /Volumes/Data\ 3To/Macintosh\ HD.dmg --target /Volumes/Brol/ --erase
    Validating target...done
    Validating source...done
Could not find any scan information. The source image needs to be imagescanned before it can be restored.

alors lançons la vérification ! -- vous pouvez prendre un café ;)

Bloc de code:
christian@imac-de-christian:[~]:asr imagescan --source /Volumes/Data 3To/Macintosh\ HD.dmg
Block checksum: ....10....20....30....40....50....60....70...80....90....100
successfully scanned image "/Volumes/Data 3To/Macintosh HD.dmg"

Puis restaurons le système sur /Volumes/Brol en lui indiquant d'effacer /Volumes/Brol. Bon l'étape de vérification est un peu longue, mais vous pouver passer l'option --noverify à la commande asr de manière à sauter cette vérification.

Néanmoins vous pouvez prendre un deuxième café ;) avec un carré de chocolat !
Bloc de code:
christian@imac-de-christian:[~]:sudo asr restore --source /Volumes/Data\ 3To/Macintosh\ HD.dmg --target /Volumes/Brol/ --erase
Password:
    Validating target...done
    Validating source...done
    Erase contents of /dev/disk5s2 (/Volumes/Brol)? [ny]: y
    Retrieving scan information...done
    Validating sizes...done
    Restoring  ....10....20....30....40....50....60....70....80....90....100
    Verifying   ....10....20....30....40....50....60....70....80....90....100
    Remounting target volume...done

Une fois l'opération terminée, le volume restauré est monté sur le bureau et S'appelle "Macintosh HD". A ce moment précis vous aurez deux Macintosh HD sur votre bureau. Afin de ne pas vous tromper, vous faites un clic droit et lire les informations pour bien distinguer les deux. Je renomme le volume restauré en Brol pour plus de sécurité en sélectionnant l'icône et changeant le nom.

Et enfin rendons "bootable" notre Brol à l'aide de la commande bless. Au préalable je lance la commande Bless pour vérifier son caractère "Bootable"

Bloc de code:
christian@imac-de-christian:[~]:bless --info /Volumes/Brol/
finderinfo[0]: 1139307 => Blessed System Folder is /Volumes/Brol/System/Library/CoreServices
finderinfo[1]: 1147646 => Blessed System File is /Volumes/Brol/System/Library/CoreServices/boot.efi
finderinfo[2]:      0 => Open-folder linked list empty
finderinfo[3]:      0 => No alternate OS blessed file/folder
finderinfo[4]:      0 => Unused field unset
finderinfo[5]: 1139307 => OS X blessed folder is /Volumes/Brol/System/Library/CoreServices
64-bit VSDB volume id:  0x97E8CC7C7133FB82

L'information retournée par cette commande montre bien (dans mon cas) que le dossier du système est à l'inode 1139307 et que son chemin d'accès est /Volumes/Brol/System/Library/CoreService. Le Booter se trouve à l'inode (i-noeud) 1147646 et porte bien le nom 'boot.efi'

Et maintenant "Blessons le volume" par mesure de sécurité

Bloc de code:
christian@imac-de-christian:[~]:sudo bless --folder /Volumes/Brol/System/Library/CoreServices
Password:
christian@imac-de-christian:[~]:

Utime étape : démarrer en mode recovery et choisir le disque Brol pour démarrer le mac....et là il redémarre bien sur Brol avec votre macintosh hd transféré. Petite vérification ultime:

Vérification après avoir démarré sur le volume restauré : Le système démarré est bien sur la partition disk4s2 ( /dev/disk4s2 est bien monté sur / après le résultat de la commande mount et /dev/disk4 est
mon volume externe qui s'appelle Brol et qui fait 319.4 Go), ce qui peut se voir a l'aide des commandes suivantes.

Bloc de code:
christian@imac-de-christian:[~]:mount
/dev/disk4s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
/dev/disk5s0s2 on /Volumes/WD SmartWare (hfs, local, nodev, nosuid, read-only, noowners)
/dev/disk2s2 on /Volumes/Data 3To (hfs, local, nodev, nosuid, journaled, noowners)
/dev/disk0s2 on /Volumes/Macintosh HD (hfs, local, nodev, nosuid, journaled, noowners)
/dev/disk3s2 on /Volumes/AluIce Turbo (hfs, local, nodev, nosuid, journaled)
/dev/disk0s4 on /Volumes/Video (hfs, local, nodev, nosuid, journaled, noowners)
/dev/disk0s5 on /Volumes/Vm (hfs, local, nodev, nosuid, journaled, noowners)
christian@imac-de-christian:[~]:diskutil list
/dev/disk0 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *6.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            1.0 TB     disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:                  Apple_HFS Video                   3.9 TB     disk0s4
   5:                  Apple_HFS Vm                      1.1 TB     disk0s5
/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS Mac OS X Basique        40.0 GB    disk1s2
   3:                  Apple_HFS BOOTCAMP                959.7 GB   disk1s3
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *3.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                  Apple_HFS Data 3To                3.0 TB     disk2s2
/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *3.0 TB     disk3
   1:                        EFI EFI                     209.7 MB   disk3s1
   2:                  Apple_HFS AluIce Turbo            3.0 TB     disk3s2
/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *319.4 GB   disk4
   1:                        EFI EFI                     209.7 MB   disk4s1
   2:                  Apple_HFS Brol                    319.0 GB   disk4s2
/dev/disk5 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:        CD_partition_scheme                        *804.4 MB   disk5
   1:     Apple_partition_scheme                         700.4 MB   disk5s0
   2:        Apple_partition_map                         32.3 KB    disk5s0s1
   3:                  Apple_HFS WD SmartWare            237.5 MB   disk5s0s2
christian@imac-de-christian:[~]:

Alors cette manipulation peut intéresser ceux qui souhaitent transférer leur OS de leur disque à plateau vers un SSD sans pour autant utiliser un outil payant comme CCC (que je ne possèdes pas d'ailleurs).
 
Dernière édition:
:coucou: fbike

Donc ça a marché en ligne de commande > alors que ça plantait via l'«Utilitaire de Disque».

Bizarre quand même qu'il ait fallu procéder au préalable au calcul de la somme de contrôle > de manière à stocker ces informations dans la "source" > pour qu'il y ait validation ensuite de la commande de restauration. C'est peut-être ce facteur qui posait problème avec l'«Utilitaire de Disque» ?

Comme le produit de la « checksum » est toujours stockés sur la "source" > qu'est-ce que cela donnerait si tu refaisais un test de restauration via l'«Utilitaire de Disque» ?
 
:coucou:macomaniac
Tout cela pour rien...:eek:
 

Fichiers joints

  • Capture d’écran 2017-04-23 à 15.33.05.jpg
    Capture d’écran 2017-04-23 à 15.33.05.jpg
    75,2 KB · Affichages: 170
Tu veux dire que ça marche avec l'«Utilitaire de Disque» ?

Si c'est le cas > ce serait parce que ta commande antérieure :
Bloc de code:
asr imagescan --source /Volumes/Data 3To/Macintosh\ HD.dmg
a écrit dans l'image-disque cible la somme de contrôle --> ce qui fait qu'elle est disponible désormais lorsque l'«Utilitaire de Disque» lance asr.

Dans les menus de l'«Utilitaire de Disque» --> Images > sous-menu : Ajouter la comme de contrôle... --> cette option doit effectuer la même chose que ta commande de vérification > suite à quoi l'option "Restaurer" doit fonctionner.
 
  • J’aime
Réactions: fbike
Eh oui, comme le montre la photo... la commande asr a effectué l'opération préalable en plaçant les checksum dans l'image disque à mon insu.

Mais la pertinence de ton avant dernier post a dégagé toute la problématique...

Moralité, c'est en forgeant que l'on devient forgeron...

Néanmoins les concepteurs de l'utilitaire de disque auraient pu forcer le checksum lors de la tentative de restauration. Pour autant je ne m'explique pas pourquoi mes autres volumes (vm et videos) se sont restaurés sans aucune encombre et sans checksum.

Cette "anomalie" liée très certainement au fait que ce soit le volume système que je voulais restaurait, m'a induit en erreur ce qui s'est traduit dans mon cas par une restauration de l'os à partir de TM... donc 1/2h au lieu de 5 minutes

ainsi que pas mal de temps pour tester une alternative...et que de poster un tuto

Mais il n'y a pas mort d'homme, tempus fugit, verba fugiunt, scripts matent !

------
Le temps passe, les paroles s'envolent les écrits restent.

 
Pour autant je ne m'explique pas pourquoi mes autres volumes (vm et videos) se sont restaurés sans aucune encombre et sans checksum.

Mon expérience correspond à la tienne > je n'ai jamais rencontré de requête de checksum en préalable à une restauration par asr (que ce soit via le «Terminal» ou l'«Utiltaire de Disque»). Dans le logiciel > l'option Ajouter la somme de contrôle doit débloquer la manœuvre dans ce cas de figure.

Tu n'as pas écrit ton tuto en vain : il décrit clairement les étapes d'une restauration en ligne de commande > en traitant au passage la question éventuelle de la somme de contrôle.

L'intérêt des commandes en mode texte > c'est que par leur biais on « conçoit » les opérations qui s'effectuent > alors que par le recours à des logiciels graphiques on est « content » que ça marche sans rien y comprendre. C'est ce que pensait déjà Jean-Jacques Rousseau : le bonheur est synonyme de crétinisme de l'intelligence (vice-versa : l'intelligence rime avec souffrance) -
361608_original.png
 
  • J’aime
Réactions: fbike
Mon expérience correspond à la tienne > je n'ai jamais rencontré de requête de checksum en préalable à une restauration par asr (que ce soit via le «Terminal» ou l'«Utiltaire de Disque»). Dans le logiciel > l'option Ajouter la somme de contrôle doit débloquer la manœuvre dans ce cas de figure.

Tu n'as pas écrit ton tuto en vain : il décrit clairement les étapes d'une restauration en ligne de commande > en traitant au passage la question éventuelle de la somme de contrôle.

L'intérêt des commandes en mode texte > c'est que par leur biais on « conçoit » les opérations qui s'effectuent > alors que par le recours à des logiciels graphiques on est « content » que ça marche sans rien y comprendre. C'est ce que pensait déjà Jean-Jacques Rousseau : le bonheur est synonyme de crétinisme de l'intelligence (vice-versa : l'intelligence rime avec souffrance) -
361608_original.png


Sans faire de flooding, j'ai maintes et maintes fois restauré mon "macintosh hd" sur sa partition initiale (je suppose que tu as du en faire de même) et ce sans qu'il me soit nécessaire de débloquer la manoeuvre par l'option ajouter la somme de contrôle. Par raisonnement hypothético-déductif, j'en déduis que la somme de contrôle doit être systématiquement ajoutée lorsque l'on restaure le disque système ET que l'on a changé la taille de sa partition. Pourquoi ce comportement ? Les ingénieurs apple doivent connaitre la réponse. Mais pour ma part il ne s'agit pas d'un garde fou permettant d'éviter qu'un utilisateur lambda restaure un dmg de 100 Go sur une partition qui en fait 50 Go, créant ainsi un débordement sur les autres filesystems (puisque tout est fichier). Pour preuve : la restauration de dmg non systèmes sur une partition rétrécie et une autre plus grande n'a pas eu ce comportement...

Bizarre Bizarre vous avez dit Bizarre comme c'est Bizarre !