MacArthur macomaniac - le retour !
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 - 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 - 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» :
2° Arborescence de la clé «createinstallmedia» :
3° Arborescence de la clé «DiskMaker X» :
♧
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» :
Bloc de code:
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).
♢
