Ce forum est en partie financé par l’affichage de publicités. Merci de désactiver votre bloqueur de publicités pour nous permettre de continuer à fournir ce service.

Comment mettre à jour son OS de Lion à Mavericks ?

Discussion dans 'macOS' créé par LilyInWonderland, 6 Février 2015.

Modérateurs: Aliboron, bompi, daffyb
  1. Anonyme

    Anonyme Invité

    Le premier message que tu montres est je crois (de mémoire) celui que tu obtiens après avoir fait : démarrage sur Cmd + r, "Réinstaller OS X".
    Le message est cohérent avec ce cas : OS X va être téléchargé, et "restauré" (Recovery...)

    En revanche quand tu lances l'installateur depuis une clé USB, tu n'as pas ce message puisque ça ne dépend pas d'un téléchargement, l'installation se fait hors connexion Internet.

    Donc pour moi, ton ami t'as fourni une copie de Recovery HD, ce que tu devrais pouvoir vérifier d'après le poids de la clé (moins de 1 Go pour Recovery HD).
     
  2. Sly54

    Sly54 Acrobate de l'espace
    Modérateur Club MacG

    Inscrit:
    31 Janvier 2005
    Messages:
    33 057
    J'aime reçus:
    3 678
    Pourtant la clef pèse environ 6 Go…
    Et après examen attentif, ma clef ressemble à la copie d'écran de ton post#19 :


    [​IMG]
     
  3. Anonyme

    Anonyme Invité

    Ce qui m'intrigue est que ta clé a un "Safari", comme la partition Recovery, alors qu'un installateur de Mavericks n'a pas de Safari.
    Alors comment une clé faite avec DMX pourrait-elle comporter un Safari ??
    (aucune des miennes n'en a)
    (ou alors une récente version de DMX agirait différemment ?)

    D'autre part, je ne sais pas si tu fais une clean install ou non.
    Si non (mise à jour simple), tu n'as pas besoin de booter sur la clé, lancer "Installer OS X Mavericks" suffit.
    Et alors tu ne devrais avoir aucun message relatif à un "téléchargement", l'installation doit commencer direct.

    Edit : je viens de trouver ça :
    "C’est vraiment aussi simple que cela ! Diskmaker Lion prend soin du reste…
    Comme avec Lion, le disque d’installation comprend les mêmes options que la partition de récupération d’urgence créée lorsque vous installez Lion ou Mountain Lion. Ainsi, avec ce dernier vous serez en mesure d’utiliser Safari pour trouver des informations de dépannage",

    Bon donc DMX mettrait un Safari sur les clés bootables faites grâce à lui.
    Mais alors pourquoi mes clés n'ont pas de Safari ?
    Comprends plus rien.Ou alors les différentes versions de DiskMaker Lion puis DiskmakerX ne font pas exactement la même chose.
     
    #23 Anonyme, 10 Février 2015
    Dernière édition par un modérateur: 10 Février 2015
  4. Sly54

    Sly54 Acrobate de l'espace
    Modérateur Club MacG

    Inscrit:
    31 Janvier 2005
    Messages:
    33 057
    J'aime reçus:
    3 678
    Pas de clean install : je mets la clef, je double clique sur Installer Mac OS X Mavericks et j'ai les copies d'écran précédemment postées…


    Je partage la même incompréhension !
     
  5. pascalformac

    pascalformac Légende
    Club MacG

    Inscrit:
    23 Novembre 2003
    Messages:
    58 699
    J'aime reçus:
    1 815
    j'ai demandé à macomaniac de passer ( il aime experimenter , il a peut etre déjà vu ca)
     
  6. Anonyme

    Anonyme Invité

    Bonjour,

    j'ai poursuivi l'enquête sur la première piste qui m'était venue à l'esprit hier : si le lancement de "Installer OS X Mavericks" produit l'apparition du message : "Pour télécharger et installer OS X, l'admissibilité de votre ordinateur sera vérifiée auprès de Apple", c'est parce qu'on utilise une copie d'une partition Recovery et non pas l'application installateur de Mavericks.

    1. sur un Macbook Late 2009 sous SL, volontairement laissé connecté à Internet par Ethernet, j'ai lancé depuis ma clé USB Mavericks faite avec DiskmakerX 3.0.4 l'installation de l'OS : je n'ai PAS eu le message.

    2. sur mon MBP 2011 sous Mavericks, j'ai monté la partition Recovery depuis Utilitaire de disque :
    En voici le contenu :
    [​IMG]

    J'ouvre le BaseSystem.dmg, voici le contenu :

    [​IMG]

    Il y a donc un "Installer OS X Mavericks", pesant 23 Mo (contre 5,35 Go pour l'installateur de Mavericks).
    Et il y a le fameux Safari visible sur ta capture !!

    Je lance Installer OS X Mavericks, et j'obtiens :

    http://hpics.li/2fee83a

    Pour moi, C.Q.F.D : ta clé est une copie d'une partition Recovery.

    Regarde quel est le poids de ton "Installer OS X Mavericks" : 23 Mo, ou 5,35 Go ?

    Pour info, contenu d'une clé USB Mavericks faite avec DiskmakerX 3.0.4 :

    [​IMG]
     
    #26 Anonyme, 10 Février 2015
    Dernière édition par un modérateur: 10 Février 2015
    macomaniac, Sly54 et Mobyduck aiment ça.
  7. Sly54

    Sly54 Acrobate de l'espace
    Modérateur Club MacG

    Inscrit:
    31 Janvier 2005
    Messages:
    33 057
    J'aime reçus:
    3 678
    20,5 Mo…

    Donc ma clef est mal faite ?
     
  8. Anonyme

    Anonyme Invité

    Ta clé a été faite par restauration du BaseSystem d'une partition Recovery, ou restauration de cette partition, je ne sais pas, mais pas à partir d'un installateur de Mavericks, qui pèse 5,35 Go et que tu dois retrouver sur la clé.

    Et en passant ta clé de... Mavericks s"appelle "Yosemite install disk 10.9.5", bug d'une version récente de DiskmakerX, je l'ai eu il y a une semaine aussi.
     
    #28 Anonyme, 10 Février 2015
    Dernière édition par un modérateur: 10 Février 2015
  9. Anonyme

    Anonyme Invité

    Ce qui m'intrigue est que ta clé a été faite avec DiskmakerX, puisqu'elle s'appelle "Yosemite install disk 10.9.5".

    Or, quand on essaie de faire la clé avec DiskmakerX (j'ai testé avec 3.0.4 et 4b4) en sélectionnant "Installer OS X Mavericks" de OS X Base System de la partition Recovery, on obtient le message :

    [​IMG]

    Alors, ta clé, que contient-elle exactement ?
    Pourquoi pèse-t-elle 6 Go si l'installateur de Mavericks n'y est pas ?
    Pourquoi montre-t-elle le même contenu qu'une partition Recovery ?

    Le suspense est insoutenable, reviens-nous vite....
     
    #29 Anonyme, 11 Février 2015
    Dernière édition par un modérateur: 11 Février 2015
  10. macomaniac

    macomaniac Ouroboros
    Club MacG

    Inscrit:
    20 Septembre 2012
    Messages:
    54 478
    J'aime reçus:
    18 353
    Je réponds à l'aimable invitation de Pascal de venir jouer les trublions dans ce colloque [​IMG]

    Même si parfois j'ergote dans des fils dont il est le protagoniste, Renaud sait bien que c'est, en toute amitié, pour l'amour intellectuel de la vérité - pour autant que je puisse en juger. J'admire ici l'argumentation incisive par laquelle il a démontré que le volume de la clé de Sly ne peut pas contenir la copie classique de l'installateur de «Mavericks», mais doit receler par contre l'arborescence d'une «Recovery HD».

    Reste au moins un point en suspens : où sont donc recelés les 4,8 Go (environ) qui doivent s'ajouter aux 1,2 Go du volume monté d'une «Recovery HD» pour aboutir aux 6 Go de poids global de la clé?

    Voici une conjecture que je soumets à l'assistance : ayant moi-même customisé de 36 façons des «Recovery HD» (installées où qu'on veuille : disque du Mac ou DDE), j'ai notamment pratiqué l'art de fabriquer de toutes pièces un disque virtuel vide d'environ 6 Go : BaseSystem.dmg par l'«Utilitaire de Disque», avant de restaurer sur son volume monté intitulé : OS\ X\ Base\ System celui du BaseSystem.dmg d'une vraie «Recovery» intitulé du même nom. Cela fait, quelqu'un qui veut avoir une «Recovery» ne ré-installant pas OSX par lancement d'un téléchargement, mais recelant en interne les ressources d'installation comme les anciens OS X Install DVD, doit procéder à des bidouilles drastiques sur le volume restauré OS\ X\ Base\ System du .dmg.

    D'abord en naviguant dans son arborescence à : /System/Installation --> pour supprimer le lien symbolique ⤻Packages (qui, a priori, ne mène à aucun dossier réel Packages puisque dans une «Recovery HD» lesdits Packages (de 4,8 Go environ) sont absents, et ne viennent remplir le chemin attendu du lien symbolique qu'à la complétion d'un téléchargement depuis les serveurs Apple) et mettre à sa place le réel dossier des Packages (4,8 Go) copié ce coup-ci à partir des ressources de l'installateur complet de «Mavericks» (at: Installer\ OS\ X\ Mavericks/Contents/SharedSupport/Install\ ESD.dmg --> /Volumes/OS\ X\ Install\ESD/Packages).

    Cela fait, il convient d'éditier un fichier at: OS\ X\ Base\ System/System/Installation/CDIS/OS\ X\ Utilities/Contents/Resources/Utilities.plist en faisant sauter les paramètres d'une "key" - sans quoi le programme d'installation : le Installer\ OS\ X\ Mavericks.app (de quelques 20 Mo) ne comprendrait pas qu'il ne lui faut pas lancer un téléchargement des Packages mais aller directement chercher dans le dossier Packages déjà présent les ressources requises des .pkg.

    Ce bidouillage éhonté du BaseSystem.dmg opéré, il faut créer sur le volume censé jouer un rôle de «Recovery HD» le dossier de boot complet com.apple.recovery.boot d'une réelle «Recovery» contenant le boot.efi, le kernelcache et les fichiers de vérification de la version de l'OS à installer et de la version du Mac supporté - en substituant au BaseSystem.dmg ordinaire de 450 Mo le BaseSystem.dmg de 6 Go bidouillé.

    Ce tripotage manuel est susceptible de nombreuses bévues et/ou lacunes en cours de route...

    Logiquement, si la clé de Sly correspondait à un bidouillage analogue, alors les 4,8 Go en souffrance devraient se trouver, après montage du BaseSystem.dmg, at: OS\ X\ Base\ System/System/Installation/Packages où un dossier chargé de .pkg devrait remplacer le lien symbolique ⤻Packages. Mais ce qui me chiffonne, c'est que d'après sa capture on ne voit pas de dossier System nulle part - y a-t-il même d'entrée sur la clé un dossier de boot : com.apple.recovery.boot recelant un BaseSystem.dmg + les fichiers de démarrage du Système un fois le volume du .dmg monté?

    Il est supputable qu'un tripatouillage sans queue ni tête ait pu être effectué... [​IMG]
     
    #30 macomaniac, 11 Février 2015
    Dernière édition: 11 Février 2015
  11. Sly54

    Sly54 Acrobate de l'espace
    Modérateur Club MacG

    Inscrit:
    31 Janvier 2005
    Messages:
    33 057
    J'aime reçus:
    3 678
    [​IMG]

    Je ne sais pas si ça va aider :
    Il y a bien 6,5 Go occupés sur ma clef :

    [​IMG]



    principalement par le System :

    [​IMG]


    Je ne voudrais pas que les enfants soient choqués, mais je souhaite établir clairement que je n'ai tripatouillé ni la tête, ni même la queue, de ma clef USB.
    :D
     
  12. Sly54

    Sly54 Acrobate de l'espace
    Modérateur Club MacG

    Inscrit:
    31 Janvier 2005
    Messages:
    33 057
    J'aime reçus:
    3 678
    voilà voilà :

    [​IMG]
     
  13. Anonyme

    Anonyme Invité

    Donc le dossier System de ta clé contient un sous-dossier "Installation" contenant toutes les ressources (Packages) pour l'installation.

    Pour comparaison voici le contenu de System de ma clé faite avec DiskmakerX.
    Pas de "Installation" :

    [​IMG]

    macomaniac saura tirer une conclusion je suppose ;)

    PS : si tu veux une clé je peux t'en faire une (une vraie).
    Edit : j'en ai même une d'avance qui est prête, celle des captures postées.
    SanDisk Cruzer Blade 8 Go.
     
    #33 Anonyme, 11 Février 2015
    Dernière édition par un modérateur: 11 Février 2015
  14. pascalformac

    pascalformac Légende
    Club MacG

    Inscrit:
    23 Novembre 2003
    Messages:
    58 699
    J'aime reçus:
    1 815
    on le sait bien puisque plus haut tu dis bien en #16 que c'est ton pote qui a fait cette clef

    et c'est sans doute dans les manips du pote qu'll y a la clef ( de l'énigme)
     
  15. Sly54

    Sly54 Acrobate de l'espace
    Modérateur Club MacG

    Inscrit:
    31 Janvier 2005
    Messages:
    33 057
    J'aime reçus:
    3 678
    With pleasure… Je te contacte en MP.



    Même pas… Il l'a faite devant moi, avec LionDisk Maker téléchargé sur le site de Guillaume; et juste après avoir téléchargé Mavericks…
     
  16. macomaniac

    macomaniac Ouroboros
    Club MacG

    Inscrit:
    20 Septembre 2012
    Messages:
    54 478
    J'aime reçus:
    18 353
    MacArthur macomaniac - le retour ! [​IMG]

    Le sujet d'une clé d'install "maison" d'OSX, remplaçante des DVD d'install auparavant fournis par Apple, m'intéresse autant que Renaud. Mais (à chacun son idiosyncrasie !) comme je me singularise par une hypertrophie de l'imagination spéculative (qui s'exprime dans un usage rhétorique de la prose), càd. par une espèce d'aventurisme intellectuel ami de la question oiseuse autant que de la conjecture farfelue [​IMG] - je me suis donc posé, abstraction faite de toute urgence pragmatique de l'ordre d'un dépannage, une question théorique principale :

    Comment se fait-il que le volume d'une clé d'install, au lieu de se comporter comme un simple volume de stockage qui monte sans être démarrable, monte en tant que système de fichiers démarrable? Càd. pour injecter une dignité philosophique à ce sujet technique : en quoi consiste l'«essence démarrable» ("ousia") d'une clé d'install d'OSX?

    J'ai choisi pour tenter de mettre à jour l'idée d'une réponse, de me concentrer sur 3 cas exemplaires (càd. formellement réguliers et non pas constitutifs d'une exception) de disques externes de secours démarrables : 1° - à tout seigneur tout honneur, le modèle créé par Apple avec l'abandon des DVD d'install = la «Recovery HD» ; 2° - à tout féal serviteur toute confiance, le résultat produit par le programme créé par Apple pour fabriquer soi-même un disque d'installation = le programme createinstallmedia introduit par Apple at: Install\ OS\ X\ [Version].app/Contents/Resources uniquement à partir de «Mavericks 10.9» (programme absent des ressources des installateurs de «Lion 10.7» et de «Mountain Lion 10.8») et invocable en ligne de commande dans le «Terminal» ; 3° - à tout franc-tireur luttant pour la bonne cause tout respect, le résultat produit par le logiciel «DiskMaker X» de Guillaume Gète à partir de la présupposition qu'avec cette version 3 évoluée, on tient un logiciel "exemplaire" et non plus "balbutiant".

    Comme je suis enclin à abuser d'une forme longue à l'écrit qui n'est pas sans crucifier l'esprit des adeptes du SMS [​IMG] - j'ai choisi de m'inspirer du conseil de Bonaparte : «Un court croquis vaut mieux qu'une longue explication». Sauf que, croquis faisant, lesdits se sont avérés tout aussi "longs" que l'explication qu'ils sont censés abréger. Tant pis! s'il est vrai, comme le remarque perfidement Emmanuel Kant (qui aimait tirer en longueur à l'écrit), que : «Beaucoup de textes seraient beaucoup plus courts - s'ils n'étaient pas si courts»...



    Voici donc 3 illustrations successives de l'arborescence du volume de la «Recovery HD», de celui d'une clé d'install produite par le programme Apple createinstallmedia et enfin d'une autre produite par le programme de Guillaume Gète «DiskMaker X 3.0.4» (chaque fois la version d'OSX impliquée est «Mavericks 10.9.5» puisque tel est l'objet débattu dans ce fil) -->

    1° Arborescence de la «Recovery HD» :

    [​IMG]

    2° Arborescence de la clé «createinstallmedia» :

    [​IMG]

    3° Arborescence de la clé «DiskMaker X» :

    [​IMG]



    Si j'abrège les considérations oiseuses, j'ai été frappé en exerçant mon esprit de comparaison par le dénominateur commun de ces trois "disques démarrables". Ces 3 disques sont, en effet, démarrables, parce qu'ils montent équitablement des volumes qui :

    1° - comportent un "démarreur" reconnaissable et exécutable par l'EFI : un Boot_Loader : boot.efi présent dans un dossier de la racine du volume qui se trouve "béni" (blessed).

    2° - comportent un "moteur" démarrable par le
    boot.efi : un "bloc-moteur" qui n'est pas un kernel (noyau) solitaire, mais un "ensemble-cache" kernelcache solidarisant un clone du code du kernel avec le bloc des kexts (extensions du noyau).


    3° - comportent une "structure" mobilisable par le kernel d'après les mêmes instructions de boot : un "système" qui a nécessairement la structure formelle d'un OS, càd. d'un Système d'Exploitation Complet


    De ce point de vue, l'arborescence de la «Recovery HD» est l'ensemble : "démarreur" + "moteur" + "structure" (
    boot.efi --> kernelcache --> OS) qui se retrouve dans les 3 cas. On en conclut logiquement que toute clé d'install d'OSX est démarrable, parce qu'elle fait démarrer le système d'une «Recovery HD». C'est toujours une «Recovery HD» qui démarre en tant que Système, et ses lanceurs sont toujours les mêmes : un "démarreur" boot.efi chargeant un "moteur" kernelcache.

    La seule différence fondamentale entre une «Recovery HD» stricto sensu et une «Recovery HD» de type install est l'inhérence des
    packages d'installation sur le volume de la 2è et leur absence sur le volume de la 1ère (ce qui implique la nécessité d'une connexion internet pour les télécharger). Mais à part cette différence de "ressources" d'install, il n'y a aucune différence essentielle entre une «Recovery HD» et une «clé d'install» --> le démarrage se fait pareillement, le Système démarré est strictement le même (la même version allégée d'OSX) et les utilitaires disponibles graphiquement sont en essence les mêmes.

    Ce qui s'affiche comme "environnement graphique" équivalent à un Bureau à l'écran est purement et simplement commandé par un fichier de préférences : le
    Utilities.plist dont les instructions sont chargées par le même processus launchd au même moment et par référence à la somme des mêmes "Utilitaires" disponibles. Que «Safari» soit ou ne soit pas affiché en mode "fenêtre" à l'écran, qu'il y ait une fenêtre à 4 utilitaires ou que la fenêtre du programme d'installation soit seule affichée - cela ne pourrait provenir que d'une manipulation des instructions d'affichage du fichier .plist si c'était le cas (j'ai 36 fois pris plaisir à bidouiller la structure de la «Recovery HD» en injectant des applications qui ne font pas partie en mode standard des ressources, et en customisant le fichiers Utilities.plist pour avoir par exemple le «Terminal» affiché en mode fenêtre et pas en mode menu --> ces bidouillages logiques m'ont montré qu'il n'y a là que variations valant comme exceptions par rapport au modèle régulier toujours constitué par le standard de la «Recovery HD» version Apple).

    De ce point de vue, la clé issue du programme
    createinstallmedia déploie au final exactement le même environnement graphique que celui de la «Recovery HD» (fenêtre d'accueil des 4 Utilitaires OS X). Et il en va strictement de même pour la clé produite par «DiskMaker X 3.0.4» (d'après mon expérience). La seule différence avec la «Recovery HD» d'Apple, je le redis, est que activer l'utilitaire : Ré-installer OS X dans le cas de la «Recovery HD» d'Apple fait que le programme d'installation lance un téléchargement sur le Net, et dans le cas des «Recovery HD» des 2 clés fait que le programme d'installation récupère directement les .pkg présent dans le dossier packages du volume.


    À partir de ce constat de l'unicité d'essence des disques d'install d'OSX - unicité d'essence qui doit être considérée comme la règle et pas l'exception - le type de clé produit chez Renaud par «DiskMaker X» qui se singularise par l'absence de «Safari» et par l'absence de fenêtre de choix d'utilitaires OSX affichée, mais par une exclusivité de la fenêtre du programme d'installation, me paraît l'effet d'une version de «DiskMaker X» qui fait exception à ce que j'ai pointé comme règle : le modèle fourni par Apple avec le createinstallmedia qui, lui-même, se calque à l'identique sur le modèle de la «Recovery HD».

    Je le soupçonnerais humoristiquement d'avoir voulu faire court - Gète dans certaines des versions de jeunesse de son logiciel, et d'avoir "découvert" le "standard" Apple seulement à partir de la publication du programme natif Apple : le
    createinstallmedia fourni à partir de «Mavericks». Puisque dans mon essai avec la version évoluée «DiskMaker X 3.0.4» postérieure à «Mavericks» sa clé affiche désormais les mêmes 4 Utilitaires OS X qu'une «Recovery HD» standard ou la clé createinstallmedia.

    Je me demande même si ce n'est pas le remord d'avoir fait trop court - Gète qui le pousse dans la clé dont j'ai examiné l'arborescence à introduire à la racine du volume un dossier d'utilitaires strictement redondant de ce que déploie le volume monté de la «Recovery HD» :
    OS X Base System et donc parfaitement inutile. Mon sentiment en résumé : depuis qu'Apple a publié le programme createinstallmedia qui instaure le standard régulier d'une clé d'install, la commande qui l'invoque dans le «Terminal» fait 36 fois l'affaire.

    J'ai constaté que l'emploi de «DiskMaker» est beaucoup trop sensible à l'environnement logiciel : impossible pour moi de créer avec lui une clé d'install de «Mavericks» sous «Yosemite» (j'ai constamment des messages d'erreurs futiles : paire de fichiers de vérification non trouvée, alors qu'elle est présente dans l'installateur). Il semble que pour l'utiliser il faille chaque fois réunir 3 conditions : opérer dans l'environnement du même OS que celui de l'installateur avec la version de «DiskMaker» strictement contemporaine. J'ai essayé sous «Mavericks» d'utiliser «Diskmaker 3.0.b3» et la clé produite générait à tous les coups des
    kernel_panic. Alors que la commande dans le «Terminal» s'exécute partout et toujours en donnant une clé toujours démarrable et exécutable.

    Je n'ai pas scruté plus avant le problème de Sly dont la clé répond pourtant au standard d'une «Recovery HD» comme attendu. Je conseille d'utiliser (pour «Mavericks» seul) la commande dans le «Terminal» :

    Code (Text):
    sudo /Applications/Install\ OS\ X\ Mavericks.app/Contents/Resources/createinstallmedia --volume /Volumes/CLE --applicationpath /Applications/Install\ OS\ X\ Mavericks.app --nointeraction
    et ↩︎ + mot-de-passe
    admin à l'aveugle + ↩︎ en prenant soin si on ne veut pas adapter le chemin à l'installateur de «Mavericks» de le loger a priori dans le dossier des Applications et d'intituler le volume monté de la clé a priori : CLE --> le programme prend un bon quart d'heure pour achever l'installation de la clé (mais celui de Gète est tout aussi lent).

     
    #36 macomaniac, 14 Février 2015
    Dernière édition: 14 Février 2015
  17. Moonwalker

    Moonwalker Dark Star
    Club MacG

    Inscrit:
    22 Avril 2006
    Messages:
    20 602
    J'aime reçus:
    3 007
    Il serait intéressant de comparer tout cela avec l'arborescence d'un DVD de Snow Leopard.
     
  18. Anonyme

    Anonyme Invité

    Bonsoir à tous,

    j'ai le même problème que Sly54 : une clé d'install faite avec DiskMakerX (DMX), qui ne fonctionne pas normalement.

    Il s'agit d'une clé de Yosemite, faite sous Yosemite avec la dernière version DMX.
    Quand on veut l'utiliser (boot dessus, ou lancement de l'installateur qu'elle contient à la racine), on a le droit au message : "Pour télécharger et restaurer OS X, l'admissibilité de votre ordinateur sera vérifiée auprès d'Apple".

    Et comme il s'agissait ce soir de faire une installation hors connexion, eh bien c'est raté.
    (aide à distance, par téléphone, galère...)

    Que se passe-t-il ? DiskMakerX est-il HS depuis sa dernière version ??

    D'avance merci.

    Signé : bibi, qui persiste à penser que dépendre d'une connexion Internet pour installer un système d'exploitation, c'est débile.

    Edit : deuxième raté de la soirée : Carbon Copy Cloner 4 m'a fait une clone non bootable !!
    (testé sans succès plusieurs démarrage par Alt ou par Préf syst/Disque de démarrage)
    Rattrapé le coup avec un :
    sudo bless -mount /Volumes/"Macintosh HD" -setBoot
     
    #38 Anonyme, 23 Février 2015
    Dernière édition par un modérateur: 23 Février 2015
  19. Anonyme

    Anonyme Invité

    J'ai fait une deuxième tentative de création d'une clé USB d'install de Yosemite, avec un autre Mac, un autre téléchargement, et une autre clé USB :

    Même résultat, la clé obtenue ne fonctionne pas : "Pour télécharger et restaurer OS X, l'admissibilité de votre ordinateur sera vérifiée auprès d'Apple".
    Impossible d'installer hors connexion.

    J'ai effacé la clé, et créé l'installateur bootable depuis le Terminal : succès, la clé fonctionne.
    http://support.apple.com/fr-fr/HT201372

    Ma conclusion provisoire est que DiskMakerX 4.0b4 est buggé et inutilisable.
    (échec pour Sly54 ci-dessus pour Mavericks, deux échecs pour moi avec Yosemite).
     
  20. macomaniac

    macomaniac Ouroboros
    Club MacG

    Inscrit:
    20 Septembre 2012
    Messages:
    54 478
    J'aime reçus:
    18 353
    [​IMG] Renaud.

    Pour ce qui est de ton 2è point (l'édition concernant un clone de «Carbon Copy Cloner») --> tu signales une lacune de finalisation du clonage qui a tout d'une exception difficile à interpréter.

    En effet, Mike Bombich a toujours veillé, quelle que soit la version de son logiciel «CCC», à ce qu'une instruction de blessing ("bénédiction") intervienne une fois finie la re-copie des fichiers du volume d'un OS, afin de signaler à l'EFI au (re-)démarrage avec l'option "alt" la présence d'un Boot_Loader : boot.efi dans le dossier CoreServices de l'arborescence de l'OS X cloné. En effet, à ce qu'il me semble, «CCC» procède au blessing selon le FOLDER MODE - ce qui équivaut à établir sur l'en-tête ("header") du filesystem cloné un path_to_folder (/System/Library/CoreServices) ouvrant une porte au scan de l'EFI lors du démarrage avec "alt", ce qui lui permet de reconnaître l'existence d'un boot.efi dans le dossier terminal et par voie de conséquence d'afficher le volume d'inhérence comme démarrable. Le seul et unique critère utilisé par l'EFI pour distinguer un "volume démarrable" d'un "volume de stockage" étant, en effet, l'existence ou la non-existence d'un fichier boot.efi sur le volume - quand bien même aucun Système chargeable ne l'accompagnerait (j'ai fait l'expérience de copier un boot.efi solitaire sur une clé USB --> lors d'un démarrage avec "alt", le disque de la clé est affiché comme "volume démarrable" à partir de ce seul critère).

    Je ne me figure qu'un incident (mais je ne vois pas lequel) pour neutraliser cette instruction de
    blessing d'après le FOLDER MODE que, régulièrement parlant, «CCC» exécute toujours en finalisation d'un clonage (à côté de sa mise-à-jour du kernelcache du clone que le boot.efi chargera directement au démarrage sur le clone).

    Personnellement parlant, je pense que rattraper le coup par une commande
    bless selon le MOUNT MODE avec l'option -setBoot va "trop loin" --> car tu fixes par là l'option de démarrage automatique sur le clone (-setBoot = fixation d'une préférence de boot qui manipule directement les arguments de la mémoire statique NVRAM de la Carte-Mère que lit l'EFI lors du pré-boot). Lors de mes manipulations expérimentales, je m'en suis régulièrement tenu à invoquer le programme bless conformément au FOLDER MODE qui n'affecte pas la NVRAM, mais seulement le filesystem du clone en assurant une "visibilité" à l'EFI du boot.efi dans les CoreServices lors d'un démarrage avec l'option "alt". Je pense que la commande :

    Code (Text):
    sudo bless --folder /Volumes/Nom_du_Volume_du_Clone/System/Library/CoreServices
    fait exactement ce qui est requis (et que «CCC» aurait dû régulièrement assurer) --> permettre l'affichage du clone comme "volume démarrable" à l'écran de choix du disque de démarrage, et par là le démarrage sur ce volume.


    Comme tu vois, je suis allé directement au terrain facile [​IMG] (à part la raison de la panne de «CCC» lors de la finalisation du clone - que je ne m'explique pas). Pour ce qui est, à présent, de ta clé, tu as réussi à répéter l'erreur de la clé produite par le pote de Sly - ce avec l'installateur d'une version différente d'OSX (10.10.2 vs 10.9.5) et dans un environnement différent («Yosemite» vs «Mavericks»), mais probablement avec la même version du logiciel «DiskMaker X». Erreur grave, car elle conduit à faire fonctionner la clé d'install comme une «Recovery HD» standard (appel à un téléchargement sur internet des Packages après vérification en ligne de l'admissibilité du Mac) - ce qui est absurde, puisque lesdits Packages sont présents dans l'arborescence d'une clé d'install, qui est une «Recovery HD» pour ce qui est du mécanisme de boot et des Utilitaires locaux, mais qui doit avoir un comportement off-line pour ce qui est de la ré-installation. Sur une clé d'install, lorsqu'on active le Programme d'installation OS X, ce programme doit immédiatement et directement trouver les Packages sur le volume et la connexion à internet doit être forclose, exactement comme quand on lance un «Installer OS X Yosemite» téléchargé de l'AppStore dans le dossier des Applications du Mac - ce qui déclenche immédiatement la procédure d'install parce que les Packages présents dans l'«Installer» sont immédiatement pris en charge. La seule vérification - normale - de l'admissibilité du Mac à l'installation doit rester une affaire technique purement locale (off-line) et n'a pas à en référer à des instances on-line.

    Quant aux raisons de ce déraillage de la clé produite par le logiciel de Gète, va savoir si ça relève d'une erreur déterminante dans les écritures du programme «DiskMaker X» (dans ce cas, elle devrait produire la même bévue toujours et partout) ou s'il s'agit d'un conflit d'instructions dans ce programme susceptible de ne se déclencher que dans des conditions accidentelles données (et alors, la même bévue de devrait pas se produire toujours et partout de manière déterminée, mais circonstanciellement = bogue). Il faudrait faire de la "spéléo-logie" : scruter l'arborescence de la clé et notamment les fichiers d'instructions du programme d'installation intégré pour déceler où est l'erreur. Ce qui ne concernerait que le produit final, sans révéler ce qui, dans le programme de Gète, a généré cette erreur.

    Personnellement, j'ai tellement été douché par des blocages de son programme que j'en suis venu à ne plus lui faire confiance a priori. J'utilise donc la commande dans le «Terminal» qui n'est en rien abstruse mais qui est au contraire limpide (il n'y a que l'allure d'écriture à rallonges qui crée la fausse apparence d'une commande compliquée). Dans les faits, il y a 3 points : 1° invocation du programme ; 2° désignation de la cible ; 3° désignation de la source. Une fois le préfixe
    sudo donné, il suffit d'aller chercher graphiquement le programme inclus dans l'«Installer» (at : Contents/Resources/createinstallmedia) et de faire un glisser-déposer au pointeur dans la fenêtre du «Terminal» ce qui renseigne le chemin au programme et le nom du programme (en créant un espace en queue) ; annoncer la "destination" par l'option : --volume et marquer l'espace, puis faire un glisser-déposer au pointeur du volume de la clé dans la fenêtre du «Terminal» pour renseigner automatiquement le chemin à la clé et le nom du volume de la clé (ce qui crée encore un espace en queue) ; annoncer la "source" par l'option : --applicationpath et marquer l'espace puis faire un glisser-déposer au pointeur de l'«Installer» (où qu'il soit) dans la fenêtre du «Terminal» pour renseigner automatiquement encore son chemin et son nom (ce qui marque un espace en queue) ; reste à conclure par l'option --nointeraction pour écarter les embrouilles.

     
    #40 macomaniac, 24 Février 2015
    Dernière édition: 24 Février 2015
Modérateurs: Aliboron, bompi, daffyb
Chargement...

iOccasion - Achetez un produit Apple d'occasion

refurb Apple