Clé USB bootable Yosemite

Pour le message SUID c'est multi traité
y a même une page dédiée Apple
une banale recherche gougoule avec les termes ATTENTION : le fichier SUID « System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent » a été modifié et ne sera pas réparé et tu tombes pile dessus
( dur dur)
Mac OS X : messages « Réparer les autorisations du disque » d’Utilitaire de disque que vous pouvez ignorer sans risque - Assistance Apple

quant au reste
soit tu recommence , soit tu refais ta clef
 
Oui je veux bien comprendre pour les réparations (je n'ai pas encore cherché) mais je ne pense pas que ce soit la cause du nom lancement du clone et du non lancement du clean install via la clé USB que j'ai faite !
 
jerome écrit: Le seul élément de nouveau dans les réparations de permissions c'est ceci que je n'avais jamais vu auparavant :
ATTENTION : le fichier SUID « System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent » a été modifié et ne sera pas réparé.

Un fichier déclaré "SUID" par l'«Utilitaire de Disque» désigne un fichier exécutable sur lequel se trouve fixé le setuid_bit. Le setuid_bit ("set user ID" --> greffer une identité d'utilisateur admin) est un procédé remarquablement commode, quand on veut invoquer fréquemment en ligne de commande dans le «Terminal» tel ou tel binaire UNIX fourni avec OSX (chmod, chown,chflags etc.) sur des objets (fichiers ou dossiers) a priori réservés au Système (user:root et group:wheel).

En l'absence de
setuid_bit, il faut chaque fois passer par le préfixe sudo pour que l'exécutant du programme devienne le Super-User (root) et qu'il y ait donc légitimité à appliquer le programme à des objets réservés à priori au "Système" - mais qui dit sudo, dit chaque fois se taper à la mimine le mot-de-passe admin pour obtenir les privilèges exécutifs de root. Mon mot-de-passe admin comportant 32 caractères, ça me les "gonfle grave" à l'usage...

Or si tu fixes a priori le
setuid_bit sur tel ou tel binaire d'emploi fréquent, ça revient à fixer en mode permament un passe-droit tel que : ce n'est pas le "déclencheur" du programme (= l'utilisateur admin) qui est identifié comme son "exécutant", mais c'est toujours le Super-User:root qui est identifié comme cet exécutant, quand bien ce ne serait pas lui qui aurait lancé le programme. Grâce au setuid_bit fixé à demeure sur un binaire, root est donc toujours l'avatar_exécutif du commanditaire_admin. En conséquence, tu peux faire tous les chown ou les chmod directs que tu veux dans le «Terminal» en prenant pour cibles des fichiers protégés a priori possédés par root, la commande passe immédiatement parce que le programme est considéré comme exécuté par root.

L'établissement du
setuid_bit s'opère en préfixant du chiffre 4 le triplet des permissions d'une commande chmod en valeur octale (ce qui, bien entendu, implique le préfixe sudo cette fois-là), ce qui donnerait par exemple un :

Bloc de code:
sudo chmod 4755 /bin/chmod

chmod se trouve pris récursivement pour objet de sa propre opération
361608_original.png
[pour instaurer le
setgid_bit : set group ID --> greffer une identité de groupe admin, il suffit de préfixer le triplet des permissions en valeur octale par le chiffre 2 - ce qui donne la forme initiale : sudo chmod 2755 --> ainsi, les membres du groupe admin seront a priori identifiés comme des exécutants ressortissant du groupe-Système wheel en ce qui concerne le programme affecté du setgid_bit].

La vérification de la présence d'un
setuid_bit sur un binaire s'opère en passant une commande ls -al qui, pour le cas où un setuid_bit existe, renvoie un : -rwsr-xr-x root wheel au lieu d'un classique : -rwxr-xr-x root wheel - le symbole de l'executable_bit : x se trouvant viré au symbole du setuid_bit : s.


☞ vu les ravages qui peuvent résulter de l'utilisation à tort et à travers de programmes porteurs du
setuid_bit ou du setgid_bit (parce qu'il s'exécutent d'emblée à tous les niveaux d'une arborescence-Système sans aucune espèce d'avertissement sur les dangers encourus), il paraît évident que ce devrait être réservé à des utilisateurs qui savent un mimimum ce qu'ils font quand ils le font et qui gardent en mémoire quels binaires UNIX ou autres programmes se trouvent modifiés quant à l'identité de l'exécutant.

L'exécutable
ARDAgent fait partie des grands classiques parmi les "bénéficiaires" du setuid_bit sans pour le coup que cela résulte disons d'une "bidouille" de l'utilisateur --> je n'ai jamais creusé le point, pour savoir quel est l'acteur responsable de cette fixation d'un setuid_bit sur un programme RemoteManagement qui relève des CoreServices ni à quelle fin.

Quoi qu'il en soit, lorsqu'un ou plusieurs programmes d'
OSX "bénéficient" du setuid_bit (voire du setgid_bit d'occurrence plus rare), à chaque demande de Réparation des permissions demandée à l'«Utilitaire de Disque», lesdits programmes se trouvent infailliblement identifiés comme des fichiers de type SUID (= porteurs du setuid_bit en abrégé) et l'«Utilitaire de Disque» respecte cet état de choses sans jamais le modifier en se contentant de dire que le fichier «SUID ... ne sera pas réparé» (heureusement ! sinon il faudrait se retaper à la mimine la restauration de ces privilèges exécutifs sur les programmes après chaque réparation des permissions).

en conséquence : RAS sur le front du fichier ARDAgent et de son setuid_bit.

--------------------

Pour le reste - càd. ce qui concerne ton installation de «Yosemite» sur un HDD grâce au bundle d'installation téléchargé de l'AppStore :

jerome écrit: J'ai la poisse ou bien c'est toujours la galère comme ça ???

--> tu as la poisse, c'est évident
447773_original.gif
et je te remets à la préconisation de Pascal...
 
Dernière édition par un modérateur:
Merci Messieurs.

Alors je ne sais pas la bidouille que j'ai faite pour avoir le message SUID etc... mais c'est en relation avec la création de la clé je pense car avant je ne l'avait pas.
Bref, je voulais faire une clé bootable pour faire un clean install sur un disque externe puis ensuite en faire un clone (propre donc) résultat cela s'arrête en permanence.

Je dispose encore dans le répertoire Application de "Installer OS X Yosemite.app" comme celui de Maverick et de Montain Lion d'ailleurs.
DiskMaker X ne veut pas ou ne veut rien faire depuis le passage à la version 10.10.2 de l'OS.
Donc je vais à nouveau passer par la solution terminal pour refaire la clé et tenter à nouveau de booter sur la clé pour lancer l'installation sur un HDD externe USB.
Ceci est une solution OK.

Par contre ce que je ne comprends toujours pas c'est pourquoi le clone via CCC sur mon SSD ne veut pas s'ouvrir il s'arrête à mi parcours de la barre de défilement sur l'écran gris de la pomme au démarrage ! (j'ai fait le test en le laissant démarrer toute la journée de 7h00 à 18h00)

Voilà le retour de la création de clé USB Bootable :
Erasing Disk: 0%... 10%... 20%... 30%...100%...
Copying installer files to disk...
Copy complete.
Making disk bootable...
Copying boot files...
Copy complete.
Done.

En toute logique cela devrait fonctionner comme il faut non ?
Je dois pouvoir lancer mon Mac sur la clé et en faire l'installation derrière sur un HDD (250 Go)
et je ne devrais pas avoir de message de ce genre :
Une erreur s'est produite pendant l'extraction des fichiers du paquet "Essentials.pkg"
Quitter le programme d'installation pour redémarrer votre ordinateur, puis réessayez.
 
Dernière édition:
Je serais toi, jerome, je commencerais par refeuilleter les «Maximes» d'Épictète : se retremper dans l'atmosphère du Stoïcisme permet de décaler l'angle selon lequel on aperçoit les événements informatiques - par exemple cette déclaration : «Ce ne sont pas les événements qui troublent le cœur des hommes, mais les jugements qu'ils portent sur ces événements»
433994_original.gif
- parce qu'il semble évident que tu n'es pas épargné par le sort...

Les problèmes que tu rencontres avec ta clé me déconcertent, je l'avoue. Que «DiskMaker X» ait des soucis avec «Yosemite», je le conçois : comme j'en avais fait la remarque plus haut, je me suis moi-même heurté à des fins de non-recevoir avec ce logiciel, dès lors que c'est le : «Install OS X Yosemite.app» (téléchargé tout ce qu'il y a de plus régulièrement depuis l'AppStore) que je lui indiquais comme 'Source'. Par contre, je n'ai jamais essuyé d'échec d'ustensilité d'une clé créée à partir de la commande ad hoc dans le «Terminal».

Si tu me permets de creuser un peu le sujet --> la commande dans le «Terminal» commence par l'invocation suivante :

Bloc de code:
sudo /Applications/Install\ OS\ X\ Yosemite.app/Contents/Resources/createinstallmedia

où le createinstallmedia est un programme exécutable sui generis, grâcieusement fourni par Apple dans le sous-dossier Resources du bundle d'installation --> ce programme offre donc toutes les garanties de pertinence pour la création d'un 'Média' d'installation, dès lors qu'on lui indique l'adresse d'un volume 'cible' suivi de celle du bundle 'source' avec l'option : --nointeraction - toutes choses, à n'en pas douter, que tu n'as pas manqué de faire. Le retour d'affichage que tu obtiens dans le «Terminal» :

Bloc de code:
Erasing Disk: 0%... 10%... 20%... 30%...100%...
Copying installer files to disk...
Copy complete.
Making disk bootable...
Copying boot files...
Copy complete.
Done.

est typique d'une opération parfaitement réussie. Ta clé paraît d'ailleurs tout à fait bootable, et l'erreur à laquelle tu te heurtes (si je n'erre pas dans mon interprétation des événements) paraît intervenir une fois le démarrage opéré sur la clé et le programme d'installation qu'elle supporte lancé (il s'agit du programme recelé dans le bundle à l'adresse :
/Volumes/Nom_de_la_clé/Install\ OS\ X\ Yosemite.app/Contents/MacOS/InstallAssistant) --> c'est ce programme natif encore qui gère l'emploi des packages d'installation de «Yosemite» pour en copier le contenu sur le volume désigné comme 'cible' (ressources résidant à l'adresse : /Volumes/Nom_de_la_clé/Install\ OS\ X\ Yosemite.app/Contents/SharedSupport/InstallESD.dmg --> /Volumes/OS\ X\ Install\ ESD/Packages).

Si tu scrutes l'adresse que je viens de donner, tu t'aperçois qu'elle mène le programme d'installation
InstallAssistant à monter en volume un disque virtuel : le InstallESD.dmg - ce, afin de pouvoir exploiter le contenu du dossier : Packages qui contient la série des paquets d'installation .pkg (dont précisément le Essentials.pkg qui, comme son nom le suggère, recèle l'essentiel des ressources de l'OS à installer = 3 Go à lui tout seul !).

Il me paraît clair que, dès lors que tu as une clé
bootable effectivement, le programme natif InstallAssistant se trouve démarré, et sa première opération consiste donc à monter en volume le disque virtuel InstallESD.dmg qui recèle les ressources d'installation de l'OS --> contenues dans ce .dmg directement téléchargé depuis l'AppStore avec le bundle global, a priori je dirais que leur intégrité se trouve par là garantie. Une fois ce disque monté en volume, tout ce que le programme d'installation InstallAssistant a à faire, c'est de gérer sériellement les .pkg, lesquels, en tant que "paquets d'installation", comportent nativement tous les "organes" logiques nécessaires : un fichier BOM de listage des composants élémentaires à installer, un fichier PackageInfo décrivant le comportement et l'identité du paquet, une archive Payload qui contient la "cargaison" à installer et enfin un dossier Scripts contenant les divers outils (programme de preinstall, programmes d'actions secondaires spéciales, programme de postinstall) que le programme d'installation doit utiliser pour performer une "copie organisée" sur le disque-cible.

Certes, je ne te le cache pas, moi qui ne suis en aucune manière un développeur non plus qu'un ingénieur de l'informatique, mais un simple porteur du «bon sens» (qui est, d'après Descartes, la faculté de raisonner également partagée en tous les hommes) entendant l'exercer d'après le modèle de l'«honnête homme» qu'on aurait tort de croire désuet - la contemplation de ces étranges objets que sont les paquets d'installation .pkg a quelque chose de déroutant, de par le caractère ténébreux de son dispositif logique. Je m'en remets donc bêtement à la compétence des ingénieurs de la Pomme, pour savoir fabriquer ces espèces de boîtes noires logicielles que sont les .pkg de manière à ce que "ça opère correctement en sortie" pour permettre l'installation de l'OS sur un disque.

Que tu rencontres le message d'erreur :
Une erreur s'est produite pendant l'extraction des fichiers du paquet "Essentials.pkg" - ça voudrait dire, en bref, que le programme de preinstall chargé d'exploiter les ressources incluses dans la "cargaison" du Payload plante quelque part à l'extraction de la série. Alors qu'un bundle d'installation régulièrement téléchargé depuis l'AppStore et ses ressources d'installation soigneusement protégées par le disque virtuel .dmg normalement fait ses preuves à l'installation - comme les innombrables installations réussies par des usagers utilisant des copies conformes de ce bundle sont là pour le prouver.

Je n'arrive donc pas à concevoir qu'il y ait une
erreur logique intrinsèque à l'Essentials.pkg. Si j'ai sur-abondamment scruté la question ci-avant, c'était pour établir que, «les mêmes causes produisant logiquement les mêmes effets» dans des contextes matériels identiques, l'erreur que tu rencontres ne doit pas être de nature logique. Je suis amené à conjecturer chez toi un problème matériel, conjecture renforcée par les diffcultés que tu rencontres à démarrer un DDE correctement cloné logiquement par «CCC» par ailleurs à partir d'un Système source intrinsèquement démarrable. Je ne saurais, dans l'état des choses, plus précisément cerner ce problème matériel que je conjecture par l'imagination.

☞ je te suggère un simple test : reformate le volume de ton DDE qui supporte actuellement le clone effectué par «CCC» et qui ne veut pas démarrer, de manière à avoir un volume vierge au format
jhfs+ (Mac Os étendu journalisé) --> si tu déclenches l'installateur de «Yosemite» toujours recelé dans les Applications de l'OS de ton SSD en lui donnant pour cible le volume de ton DDE : 1° est-ce que l'installation s'opère jusqu'à complétion? 2° Est-ce que tu es capable de re-démarrer sur le «Yosemite» installé en Clean Install de ce DDE?

<NB. Tu aurais peut-être intérêt à mettre à jour l'installateur de «Yosemite» recelé dans tes Applications, au cas où ce serait encore la version «10.10.1», en re-téléchargeant de frais depuis l'AppStore (section : Achats) le nouveau bundle «10.10.2»...>
 
Dernière édition par un modérateur:
@macomaniac

Bonjour à toi,

J'adore avec quelle poésie tu m'expliques les méandres et les problèmes que je rencontre.
Voici en moins poétique car je n'ai pas ce sens de l'écriture ce que j'ai réalisé hier soir.

J'ai créé à nouveau une clé USB bootable via le terminal sur laquelle j'ai pu effectivement bossé après un démarrage en appuyant sur la touche "ALT".
J'ai sélectionné ensuite un démarrage sur la clé "Install OS X Yosemite" pour pouvoir enfin sélectionner "Installer OS X" parmi l'ensemble des propositions.
J'ai aussi connecté le wifi en haut à droit car je crois qu'il y a besoin d'une connexion internet en court de route (mais ça je n'en suis pas certain)
Après plusieurs minutes d'attentes j'obtiens maintenant le message : impossible de vérifier la copie etc...

Donc agacé encore une fois, et je pense que du coup je ne réfléchi plus comme il faut vis à vis de la situation, j'ai décidé de lancer une installation via time machine sur mon SSD.
Cette opération a duré tout la nuit, enfin s'est déroulé pendant mon sommeil. Et ce matin, même avec mes yeux semi collés le système fonctionnait parfaitement bien sur mon disque SSD branché en USB.

Donc au final, je ne suis pas certain que cela vienne du matériel SSD Crucial MX100.

Mais je suis du genre têtu voir aussi un peu tête de mule donc je vais essayer encore un clean install mais sur un autre HDD cette fois.
Alors ok cela ne sera pas représentatif des tests précédent mais je ne veux pas casser la restauration système via time machine que j'ai faite et qui marche pour le moment.

La victime de ces tests va être un HDD Western Digital 2,5'' MyPasseport de 250 Go.
Cela permettra de se faire une idée complète sur la partie matériel.

Je vais donc sur la session ouverte lancer l'utilitaire de disque afin de refaire la partition (1 partition) et n'oubliant pas de sélectionner "Mac OS étendu (journalisé)".
Dans les options je vérifie que "Tableau de partition GUID" soit sélectionné et je cliques ensuite sur "appliquer".
Pour être certain de bien voir mon disque par la suite je lui donne le nom suivant "MP250Go" mais ceci n'a aucun intérêt particulier dans le test.

L'opération vient de se réaliser sans encombre.

Je vais donc brancher ma clé USB et redémarrer ma machine en appuyant sur "ALT" afin de sélectionner ma clé USB et voir ce qui va se passer par la suite.

Je vais donc quitter le forum un instant et revenir via l'ipad si besoin.
à tout à l'heure
 
Bien me revoilà à nouveau avec des nouvelles plutôt bonne en fait.

Après avoir réalisé les opérations précédentes et bien voilà que mon clean install sur mon disque HDD Western Digital 2,5'' MyPasseport de 250 Go est faite !!!

Un différence aussi lors de cette manipulation c'est le branchement du câble internet plutôt que le wifi.
Est-ce que cela joue un rôle peut être que oui.
 
Je me demandais si tu n'avais pas des problèmes d'USB. Mais à présent - après cet inscrutable pataquès - te voilà tiré d'affaire grâce à ta persévérance...
450622_original.gif


Il ne te resterait plus qu'à cloner par «CCC» l'OS de ton SSD restauré grâce à «TimeMachine» sur l'OS installé en Clean Install de ton DDE Western Digital pour vérifier si tu obtiens bien par là une sauvegarde démarrable.
 
Oui je ne sais pas si c'est de la persévérance ou bien de l'acharnement mais j'ai gagné par usure au point :hurting:

Je ne peux pas cloner mon SSD restauré via Time Machine sur mon Western Digital car il y a un différence de taille occupée notable.

Par contre je finalise les sauvegardes de la semaine afin d'avoir vraiment tout au chaud.
Ensuite soit je clone mon Western Digital (Clean Install) sur mon SSD puis je monte mon SSD dans mon iMac late 2009, soit je garde mon Western Digital pour avoir un Clean Install Ok et opérationnel pour un clonage futur et je relance un Clean Install cette fois ci sur mon SSD et ensuite je le monte en lieu et place de mon disque à plateau de mon iMac late 2009. :zen:

Il est vrai que je considère souvent que la victoire isolée n'est pas gage de réussite pour la suite donc je pencherais bien pour refaire un Clean Install sur le SSD afin de voir si la procédure est bien acquise;)
 
Et bien après avoir travaillé sur le sujet tout la soirée et toute la matinée le résultat est pour le moins étonnant.
Avec la même clé USB et en changeant le disque dur (de HDD Western Digital à SSD Crucial MX100) et bien c'est le plantage à chaque tentative.

La clé USB se lance bien après un démarrage via la touche ALT.
Je passe par l'utilitaire disque pour refaire la partition juste avant de faire l'installation OS X.
Ensuite je lance l'installation OS X, j'accepte les conditions générales, je choisi ensuite mon disque de destination (le SSD). Je cliques ensuite sur "Installer", l'info de ce nouvel écran : "préparation de l'installation. Votre ordinateur redémarra automatiquement" puis je peux lire "il reste environ 10 minutes".
A la quasi fin du défilement de la barre je reste bloqué "il reste environ 1 secondes", au bout de quelques minutes supplémentaires le message suivants apparaît et mets fin a l'installation :
"Impossible de vérifier cette copie de l'application Installer OS X Yosemite. Elle peut avoir été endommagee ou altérée au cours de l'installation. "

Par rapport à mon opération indentique d'hier sur mon western digital rien n'a changé à part le disque qui est devenu SSD !!
 
Bien bien, après avoir fait un clone bootable de mon disque western digital sur mon SSD j'ai pu entre la nuit dernière et aujourd'hui remettre en route mon mac
Une bonne sauvegarde Time machine à faire ensuite car je n'ai pas de disque de capacité suffisante pour cloner ma nouvelle installation.

Maintenant je me pose la question si je ne vais pas remplacer mon HDD de mon portable sony vaio VPCF13E1E.
 
Tu sembles parvenu à bon port, avec un «Yosemite» en Clean Install à la fois sur ton HDD et sur ton SSD, et une sauvegarde «TimeMachine» d'un Système «Yosemite» avec données.

Non sans ratés expérimentaux que je n'arrive pas à interpréter : échecs variés pour créer une clé USB d'install supportant l'«Install OS X Yosemite.app» ou pour parvenir au terme de l'installation sur le SSD une fois démarré sur elle ; échec à un moment donné pour démarrer sur un clone réalisé par «CCC» sur le SSD.

Il semble, concernant la clé, que l'installateur téléchargé depuis l'AppStore ne passe pas l'examen de "vérification" soit au départ («DiskMaker X»), soit au début de son utilisation (échec d'extraction d'Essentials.pkg), soit à la fin de son utilisation (message d'erreur de la dernière seconde).

Je m'étais demandé s'il n'y avait pas un problème matériel quelque part (clé, USB) - mais cette piste paraît controversée. J'avais exclu a priori un problème logiciel de l'ordre du "contenu", en assumant que les
packages de l'installateur téléchargé normalement depuis l'AppStore n'incluaient pas d'erreurs. Mais alors pourquoi cette récurrence d'un "échec de la vérification de la copie"? Se pourrait-il qu'il s'agisse, non d'un problème de "contenu" des packages recelés dans le InstallESD.dmg (mais alors que dire du cas de figure : "échec d'extraction du Essentials.pkg"?), mais du fichier Install OS X Yosemite/Contents/_MASreceipt/receipt? L'examen qui avait été fait de ce cas de figure dans ce fil : Macbook Upgradé, sous SL, que faire ?... ne semblait pas militer en faveur d'un tel cas de figure, néanmoins.

Je suis déconfit...
413669_original.gif
 
Bonjour,
je ne pense pas publié au bon endroit, mais je n'est pas trouvé de post (à part celui-ci) qui présentait des problèmes similaire au mien. Je m'explique :
j'ai démarré mon ordi comme tous les jours, sauf qu'il est resté bloqué sur un écran gris après avoir affiché la pomme avec al roue qui tourne.
j'ai donc fait un démarrage sans extension (en maintenant shift au démarrage) l'ordi a démarré, ce qui m'a permis de faire une sauvegarde plus récente. La sauvarde terminé, j'ai démonté le disque dur pour le brancher à un autre mac pour faire une réparation via l'utilitaire de disque, mais rien à faire. Un message me dit que la réparation a échoué, que je doit sauvegarder et reformater. De peur que le problème recommence plus tard, j'ai acheté un disque dur pour le remplacer. Je le monte dans l'ordinateur, je branche mon disque dur externe avec ma sauvegarde time machine, je maintien "alt" pour sélectionner mon disque dur externe. La pomme s'affiche avec la roue qui tourne, et après 1 ou 2 minutes de chargement, écran bleu avec de fines lignes noir verticales.
Pensant que le problème venait de mon disque dur j'ai prit une clé USB bootable, même écran.
J'ai fait un reset SMC : le probleme persiste
Je n'est pas de partition recovery, car je suis resté sur un système antérieur à lion.
J'ai également essayé de démarrer via le disque dur d'origine branche en externe à mon mac pour pouvoir lancé l'installation, depuis le bureau. Ce qui a fonctionné jusqu'a redémarrage, ou l'ordinateur a freezé sur un écran gris.
Maintenant l'écran bleu apparait sans rien faire, avec le disque dur d'origine branché en interne.

Je précise que la carte mère a été changé il y a 2 ans environ, et qu'il s'agit d'un macbook pro late 2011, A1286

Pour moi le disque dur était en faute, et le changement était nécessaire. Mais j'ai peur que la carte mère soit encore en faute. qu'en pensez-vous ?

merci d'avance pour votre aide :)
 
Bien j'ai fait un clone de mon HDD sur mon SSD hier soir.
J'ai aussi demandé à ce que la machine redémarre sur le SSD comme indiqué.

J'ai fait le test pour voir si cela marchait ou pas donc en laissant le SSD dans son boîtier USB j'ai relancé la machine mais là blocage sur la pomme avec la barre d'avancement environ à 50%.

Du coup j'ai un doute sur le fait que mon clone fonctionne vraiment.
Je voulais faire un essai avant de passer au démontage pour ne pas avoir de surprise et j'ai pour le moment bien fait.

Bonjour, j'ai exactement le même problème : blocage barre d'avancement à +/- 50%.
Mon but est de pouvoir lancer OS X Yosemite sur mon MacBook Pro (Retina 2012) à partir d'un disque dur externe, pour pouvoir repartionner mon Macintosh HD avec iPartition (problème de place pour une partition windows BootCamp saturée).
J'ai essayé :
1) clonage de mon HD (SSD) avec CloneX4 sur un disque USB externe
2) système minimal avec CloneX4 sur une clef USB 16Go
3) installation de Yosemite à partir de "Installer OS X Yosemite" sur une clef USB 16Go
4) installation de Yosemite via DiskMaker (nb: cette solution ne m'arrange pas car il installe si j'ai bien compris un support bootable USB ... pour, une fois lancé, réinstaller Yosemite sur le disque dur de la machine)
Les partitions sont chaque fois en GUID.
Toujours la même chose : lorsque je lance mon MacBook Pro, la barre de progression avance (assez lentement), à 25% elle se bloque un peu, la souris apparaît, elle avance à nouveau jusque 40%, puis très lentement jusque 50% puis plus rien (même après 1 heure).

J'ai essayé ma clef sur un MacBook Air... même scénario. Alors que je pensais que c'était mon Macbook pro qui posait problème, je me dis donc que c'est la clef / le disque dur externe USB qui pose problème. Pourtant, l'essai n°3 ci-dessus est la procédure expliquée chez Apple : https://support.apple.com/fr-fr/HT202796

Est-ce que quelqu'un a déjà rencontré le problème ?

Je vais tenter un démarrage mode cible avec câble Thunderbolt entre ordis, ne fût-ce que pour pouvoir repartionner mon disque HD, mais j'aimerais tant savoir comment démarrer mon clone avec toutes mes programmes/données au cas où la procédure de repartition échouerait...

Thibaut - MacBook Pro Retina 2012 - SSD 256 Go 16Go Ram
 
Salut Thibaut (aka: teoooooo).

Ton message soulève d'intéressants problèmes méthodologiques : j'espère que tu ne m'en voudras pas de les aborder conformément à la « patience de la prose » qui m'est coutumière, càd. en "longitude"...
361608_original.png


Pour réaliser cette « fin » :

repartionner mon Macintosh HD ... (problème de place pour une partition windows BootCamp saturée)

tu envisages ces « moyens » :

lancer OS X Yosemite ... à partir d'un disque dur externe

Eh bien ! sache que tu n'as absolument pas besoin de démarrer sur le Système d'un disque externe pour re-dimensionner les partitions de ton SSD interne, car le re-partitionnement en mode "live" (re-dimensionnement de la partition /dev/disk0s2 d'OS X, et re-dimensionnement conséquent de la partition /dev/disk0s4 de Windows à partir de la session d'OS X démarré) est parfaitement supporté par le framework : DiskManagement.framework sollicité par le programme diskutil en ligne de commande, ou par le même piloté graphiquement par l'«Utilitaire de Disque».

Je te propose en exemple l'expérimentation suivante que je viens d'effectuer sur mon MacBook Pro Early_2011. Suppose au départ la Carte de Partition suivante d'un SSD de 500 Go (obtenue par la commande diskutil list dans le «Terminal») :

Bloc de code:
/dev/disk0 (internal, physical):
  #:                       TYPE NAME                    SIZE       IDENTIFIER
  0:      GUID_partition_scheme                        *512.1 GB   disk0
  1:                        EFI EFI                     209.7 MB   disk0s1
  2:                  Apple_HFS Macintosh HD            411.3 GB   disk0s2
  3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
  4:        Microsoft User Data Windows                 100 GB     disk0s4

=> suppose encore que la partition Windows de 100 Go me paraisse trop étriquée et que je veuille la dilater à 200 Go, ce qui implique de rétrécir la partition Macintosh HD d'OS X de 411.3 Go à 311.3 Go. Alors, depuis la session de mon Macintosh HD démarré (peu importe la version d'OS X : de «Lion 10.7» à «El Capitan 10.11» : nil obstat !), je passe d'abord la commande suivante dans le «Terminal» :

Bloc de code:
sudo diskutil resizeVolume /dev/disk0s2 311.3g 1 jhfs+ WIN 100g
et j'obtiens en retour (après pas mal de moulinage) :

Bloc de code:
/dev/disk0 (internal, physical):
  #:                       TYPE NAME                    SIZE       IDENTIFIER
  0:      GUID_partition_scheme                        *512.1 GB   disk0
  1:                        EFI EFI                     209.7 MB   disk0s1
  2:                  Apple_HFS Macintosh HD            311.3 GB   disk0s2
  3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
  4:                  Apple_HFS WIN                     100 GB     disk0s4
  4:        Microsoft User Data Windows                 100 GB     disk0s5

[tu noteras, ici et dans la suite, que la partition de récupération «Recovery HD» au format Apple_Boot n'est jamais compromise dans ces va-et-vient d'espace-disque, son emplacement sur les blocks étant chaque fois mis-à-jour]. Il convient à présent de passer la commande de fusion de la partition Windows /dev/disk0s5 de 100 Go à la néo-partition WIN /dev/disk0s4 de 100 Go :

Bloc de code:
sudo diskutil mergePartitions jhfs+ WIN /dev/disk0s4 /dev/disk0s5
et j'obtiens en sortie la Carte de Partition suivante :

Bloc de code:
/dev/disk0 (internal, physical):
  #:                       TYPE NAME                    SIZE       IDENTIFIER
  0:      GUID_partition_scheme                        *512.1 GB   disk0
  1:                        EFI EFI                     209.7 MB   disk0s1
  2:                  Apple_HFS Macintosh HD            311.3 GB   disk0s2
  3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
  4:                  Apple_HFS WIN                     200 GB     disk0s4

Pour finir, il ne me reste plus qu'à re-formater en MS-DOS la néo-partition WIN de 200 Go en jhfs+ par la commande :

Bloc de code:
sudo diskutil eraseVolume MS-DOS WIN /dev/disk0s4
et le tour est joué [tu noteras que la partition WIN jusqu'ici avait supporté un format Mac OS étendu journalisé (aka: jhfs+) : c'est parce que ce format de système de fichiers est requis pour pouvoir re-dimensionner une partition, le format MS-DOS ne le supportant pas, et devant donc être instauré seulement in fine].

=> le système de fichiers de mon Macintosh HD dont la partition a été rétrécie de 100 Go en mode "live" a toujours été démarré pendant ces 3 opérations et n'a subi aucun dommage, ni en perte de données ni en démarrabilité. Je n'ai donc absolument pas eu besoin d'utiliser «iPartition» pour cette opération non plus qu'un démarrage sur le système d'un disque externe.

Or, à supposer que tu trouves quelque peu "abstrus" ce type de manipulation en mode texte dans le «Terminal» (alors qu'il est parfaitement parlant et limpide logiquement pour l'esprit) ; eh bien ! sache encore que l'«Utilitaire de Disque» de ton OS «Yosemite» (résidant dans le système de fichiers démarré de la partition /dev/disk0s2) peut très bien effectuer cette même manipulation "live" en mode graphique.

Il suffit de sélectionner le disque physique global du SSD et le menu "Partitionner", de sélectionner le rectangle supérieur Macintosh HD et de presser le bouton "+" pour opérer un premier repartitionnement rétrécissant le rectangle de l'OS et créant une néo-partition WIN de 100 Go au format jhfs+ provisoirement requis (conformément à mon exemple). Ensuite, il suffit de sélectionner le rectangle inférieur de la partition Windows et de presser le bouton "-" pour supprimer cette partition en virant son espace au mode « espace libre ». Puis, il suffit d'abaisser la ligne de base du rectangle médian de la néo-partition WIN pour lui faire absorber l'espace libre signalé en grisé dans le bas et on obtient une partition WIN de 200 Go en jhfs+, qu'il ne restera plus qu'à reformater en MS-DOS - tout comme en ligne de commande. Et pour cause ! Car ces manipulations graphiques activent les commandes en mode texte que j'ai mentionnées en premier lieu...

--------------------
Le problème impliqué dans ce re-partitionnement (qu'il soit effectué en mode "live" ou à partir d'un démarrage externe ; qu'il soit effectué en mode texte ou en mode graphique => cela ne change rien à l'affaire) : c'est que le système de fichiers démarrable de Windows va forcément être détruit dans la manœuvre. Car on ne peut augmenter cette partition de queue, qu'en créant d'abord au-dessus d'elle une partition bénéficiaire (que j'ai intitulée WIN) et en allouant ensuite l'espace de la partition de queue Windows à la partition WIN qui la précède dans la Carte de Partition => cette opération implique toujours le suppression du système de fichiers de la partition du dessous, et la conservation de celui de la partition du dessus.

Si donc tu veux sauvegarder le système de fichiers démarrable de ta partition Windows (avec ses données), il te faut utiliser le logiciel de clonage «Winclone» (payant). Alors => a) tu sauvegardes une archive du système de fichiers Windows dans une image-disque grâce à «Winclone» : puis b) tu re-partitionnes complètement pour créer une partition WIN de 200 Go au format MS-DOS ; enfin c) tu re-clones l'image-disque de Windows sur ta néo-partition WIN de 200 Go («Winclone» re-formatera la partition WIN de MS-DOS en NTFS).

Mais au cas où tu ne tiendrais pas du tout à préserver les données de ton système de fichiers Windows actuel, mais où tu voudrais réinstaller un Windows vierge grâce à «BootCamp», alors il ne serait pas du tout besoin de re-partitionner comme je l'ai décrit ci-dessus, mais il suffirait de supprimer la partition «Windows» pour réallouer en mode "live" son espace à celui de la partition Macintosh HD du dessus. Cette opération est parfaitement supportée en mode texte via les 2 commandes successives :

Bloc de code:
sudo diskutil eraseVolume free space /dev/disk0s4
sudo diskutil resizeVolume /dev/disk0s2 0b

ou graphiquement dans l'«Utilitaire de Disque» en commençant par sélectionner dans le menu "Partitionner" le rectangle du dessous Windows pour lui appliquer la suppression (bouton "-") ce qui vire son espace au mode « espace libre », avant de déplacer vers le bas la ligne de base du rectangle Macintosh HD du dessus pour lui faire récupérer l'espace libre grisé de la ci-devant partition Windows => dans les 2 cas, on reviendrait au partitionnement standard :

Bloc de code:
/dev/disk0 (internal, physical):
  #:                       TYPE NAME                    SIZE       IDENTIFIER
  0:      GUID_partition_scheme                        *512.1 GB   disk0
  1:                        EFI EFI                     209.7 MB   disk0s1
  2:                  Apple_HFS Macintosh HD            511.3 GB   disk0s2
  3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

que requiert l'«Assistant BootCamp» pour opérer.

--------------------​

Pour ce qui est de ton dernier problème : l'échec pour créer un système externe démarrable, ce n'est absolument pas normal.

Mais déjà il faut relever qu'une clé USB de 16 Go n'offre pas un bon volume pour installer OS X : connexion trop lente pour avoir un démarrage opératoire et volume trop étriqué malgré les apparences, car un OS X vierge requiert environ 17 Go d'espace et ton volume, une fois soustrait la partition EFI et la «Recovery HD», doit être d'environ 15.2 Go.

Utilise un DDE USB (ou Thunderbolt de préférence), disque en table GUID et volume au format jhfs+, et la démo (gratuite un mois) de ☞Carbon Copy Cloner☜ pour cloner ton Macintosh HD sur le volume de ton DDE et tu auras un clone démarrable.

Ou installe un OS X vierge sur le volume d'un DDE et tu auras encore un Système démarrable.

Ou enfin crée une clé USB supportant un installer bootable d'OS X via la commande dans le «Terminal» en t'inspirant de cette page Apple : ☞Création d’un programme d’installation amorçable d’OS X☜ - car le programme de Gète : «DiskMaker X» est sujet à erreur à partir de «Mavericks 10.9» et n'est donc pas fiable...

[NB. Dans ce cas, utiliser l'«Utilitaire de Disque» (ou le «Terminal») de cette clé démarrée pour le re-partitionnement, sans lancer la fonctionnalité : "Ré-installer OS X" - mais pourquoi faire, puisque, comme expliqué, le re-partitionnement en mode "live" est parfaitement supporté depuis la session de l'OS démarré ?]

--------------------​
 
Dernière édition par un modérateur:


Écrivez votre réponse...