Prose de (sapin de) Noël ornée de culs-de-lampe en guise de boules
Jean &
zeltron, qui avez (
Ave !) vainement naguère invoqué -
voces clamantes in deserto - le nom de
macomaniac sans que ce dernier fasse acte de présence dans ce fil.
Il y a à cette carence une raison - peut-être pas « excellente » - à tout le moins « dirimante » : il suffit que j'entrevoie dans le titre d'un fil le terme «
Time Machine» pour qu'instantanément je m'en détourne sans l'ouvrir. Je suis « structuraliste » - je n'ai aucun goût pour l'« histoire ». C'est la « géographie logique » des systèmes qui m'importe, non la « succession temporelle de leurs états ». En guise d'effet mineur : je sauvegarde par un clone en écrasant à chaque reclonage les variantes antérieures du système par les actuelles ; je ne sauvegarde pas en mode historiciste une succession de tranches d'époque du système de l'OS dont je n'ai que faire.
Pour les raisons susdites, je suis resté dans une complète ignorance de ce fil, jusqu'à dimanche (hier) où je ne sais quelle erreur de clic
- par l'effet d'inattention de l'oisiveté dominicale - m'a fait ouvrir cet espace livré à la désolation pour découvrir que son auteur était
Jean : un expert, inattendu dans cette position de demandeur. Il n'en fallait pas davantage pour piquer ma curiosité et susciter une première : ma lecture d'un fil consacré à «
TimeMachine» !
Mais en fait la « Main Invisible de la Providence » veillait, car ce fil ne concernait pas «
TimeMachine» dans sa perspective « historiciste », mais dans une perspective « structurale » : une sauvegarde considérée comme un « Système démarrable », càd. assimilée à un clone. J'étais donc en terrain familier...
Eh bien ! J'annonce que le problème est
résolu, aussi bien «
théoriquement » que «
pratiquement »
. Au risque d'étirer ce billet en « longitude », j'expose ma démarche dans un petit morceau de prose « logico-spéculative ».
♤
Ayant un
MacBook Pro Early_2011 dont le SSD interne de 1 To comporte de nombreuses partitions, dont autant de démarrables que d'OS de «
Snow Léopard» à «
El Capitan», et ayant sous la main plusieurs DDE : [SSD x Thunderbolt] permettant des expérimentations express, j'ai donc successivement créé 2 sauvegardes
TimeMachine (en 10' chacune) : une de mon volume
El Capitan sur un de ces DDE, une autre de mon volume
Yosemite sur un autre de ces DDE (en démarrant successivement sur chacun de ces OS).
Cela fait, en re-démarrant avec "
alt", il s'est avéré que la sauvegarde
TimeMachine:
Yosemite démarrait bel et bien ; tandis que la sauvegarde
El Capitan, comme dans l'expérience de
Jean, conduisait au signe
d'interdiction de stationner ∅. Ce qui m'a conduit sur mon terrain d'exercice favori : la « logique spéculative ».
En quoi consistait le mécanisme logique de démarrage de la sauvegarde démarrable : celle de «
Yosemite» ? Facile : une fois le démarrage effectué, s'affiche un écran identique à celui obtenu par le démarrage sur la «
Recovery HD» (la fenêtre des 4
Utilitaires OS X). Une sauvegarde
TimeMachine ne doit pouvoir démarrer
comme une partition de récupération «
Recovery HD», que parce qu'elle doit comporter le même dispositif de démarrage : un dossier de boot
com.apple.recovery.boot contenant les mêmes
Boot_Files. Une inspection du contenu du dossier de sauvegarde
Backups.backupdb sur le volume du DDE m'a révélé 2 répertoires : un répertoire invisible
.RecoverySets et un répertoire visible de l'intitulé du Mac-Hôte (chez moi :
MacBook Pro).
Le répertoire du Mac contient, en descendant de 2 crans dans une arborescence, un dossier du même intitulé que le Volume d'
El Capitan source de la sauvegarde. Ce dossier contient absolument les mêmes éléments (à part quelques exclusions) que le volume
El Capitan en tant que sauvegarde paradigme : c'est donc l'exact équivalent d'un
clone du système.
Le répertoire
.RecoverySets de son côté contient un sous-répertoire
0 qui recèle le dossier classique de démarrage d'une «
Recovery HD» : le
com.apple.recovery.boot. Ce dernier, ouvert, est rigoureusement la copie-conforme dans ses éléments de celui de la «
Recovery HD» : 7 éléments (dans l'ordre alphabétique) =>
BaseSystem.chunklist,
BaseSystem.dmg,
boot.efi,
com.apple.Boot.plist,
kernelcache,
PlatformSupport.plist,
SystemVersion.plist.
Je suis familier de ce dispositif et il ne me pose aucun problème logique. Le fichier
boot.efi est le
boot_loader exécuté par l'
EFI qui lui passe la main. Les fichiers
.plist sont lus par le
boot.efi, à fin préalable de validation de la compatibilité de la machine (
PlatformSupport.plist) avec le Système à démarrer (
SystemVersion.plist) et à fin de charger les chemins de
boot (
com.apple.Boot.plist). Le
kernelcache est le cache de démarrage qui combine un code cloné de l'original du
kernel et le bloc des
kexts => le
boot.efi va lancer le
kernel et l'injection des
kexts dans le
kernel, tout en lui passant une instruction secondaire (chargée à la lecture du fichier
com.apple.Boot.plist) qui est le mode d'accès au Système à démarrer ensuite : il s'agit d'une instruction de montage du disque virtuel
BaseSystem.dmg en un volume
OS X Base System recelant un
OS X allégé, dont le
kernel déclenchera le chargement exactement comme pour le Système d'
OS X. Le fichier
BaseSystem.chunklist, pour sa part, est la liste des ressources (
load ou
chunk) contenues dans le
BaseSystem.dmg : il n'a pas d'usage en terme de
boot, mais s'il s'agit de (re)créer un dossier de
boot :
com.apple.recovery.boot via l'exécutable Apple
dmtest.
Bref : une sauvegarde
TimeMachine dépouillée de sa problématique « historiciste » et ramené à la problématique « structuraliste » d'un « Système démarrable », peut se décrire comme la coexistence d'un
clone du volume d'
OS X qui ne joue aucun rôle en terme de démarrage, mais qui constitue un paradigme autorisant un rétro-clonage + un dossier de
boot identique à celui d'une «
Recovery HD» (
com.apple.recovery.boot) qui constitue exclusivement le dispositif de démarrage : une «
Recovery TM» en quelque sorte.
♧
Il se laisse tirer de cette analyse une conséquence logique stricte : une sauvegarde «
TimeMachine» démarrant uniquement par le dossier de
boot de type «
Recovery TM» =
com.apple.recovery.boot (sans que le clone d'
OS X qui lui coexiste en constituant la source d'une restauration éventuelle ne joue le moindre rôle dans ce démarrage) ; alors si une sauvegarde
Yosemite démarre, tandis qu'une sauvegarde
El Capitan ne démarre pas, cela ne peut découler que du contenu du dossier de
boot :
com.apple.recovery.boot recelé en chacune. Celui de la sauvegarde
Yosemite soit être "
sans erreur ", alors que celui de la sauvegarde
El Capitan doit être "
avec erreur".
Cette erreur ne peut pas affecter le fichier
BaseSystem.chunklist qui ne joue aucun rôle au démarrage. Elle ne peut pas affecter le fichier
boot.efi (car, dans mon expérience de démarrage sur la sauvegarde
El Capitan, j'ai obtenu le logo comme dans celle de
Yosemite (avant le signe d'interdiction de stationner
∅) : signe sans équivoque que l'
EFI a exécuté le
boot_loader trouvé.
[Point besoin de problématique de blessing comme Jean l'a creusée, car le logo prouve que l'EFI n'a aucun problème à trouver le boot_loader et à l'exécuter. Le blessing sert à renseigner sur le header d'un système de fichiers l'adresse à un boot_loader enfoui dans une arborescence ; par contre, un blessing n'est jamais nécessaire, lorsqu'un fichier booter .efi existe dans l'espace-racine d'un volume, car le scan du DiskManager déclenché par la touche "alt" inspecte automatiquement ce 1er degré d'arborescence des volumes montés, à défaut de blessing du header des systèmes de fichiers. Or un fichier de type booter existe au 1er degré du volume d'une sauvegarde : le tmbootpicker.efi (coexistant dans l'espace-racine du volume de sauvegarde avec le dossier Backups.backupdb). Je conjecture, comme son nom l'indique (boot_picker : sélecteur de boot) qu'il s'agit là d'un équivalent du fichier intercepteur de l'EFI qu'est le refind_x64.efi du gestionnaire de démarrage «rEFInd» sur l'EFI System Partition : un relai entre l'EFI (qui l'exécute) et le boot_loader spécifique d'un Système (qu'il exécute à son tour). Ce booter intercalaire tmbootpicker.efi recèle le path: /Backups.backupdb/.RecoverySets/0/com.apple.recovery.boot/boot.efi lui fixant a priori pour cible exécutoire le boot_loader : boot.efi régulier du dossier de boot : com.apple.recovery.boot. La trajectoire de boot est donc la suivante : EFI => [DiskManager] => tmbootpicker.efi [affiché en tant que : EFI_Boot] => boot.efi. Il s'ensuit que l'existence du logo signale bien que le boot.efi a été exécuté et a pris la main en vue de charger le cache-Système d'après lecture des 3 fichiers .plist. et que le plantage intervient après, lorsqu'il s'agit de charger le cache-Système, puisqu'on n'obtient pas la barre de chargement qui signale l'opération du kernel.]
L'erreur ne peut pas affecter le disque virtuel
BaseSystem.dmg, car ce disque est verrouillé en mode :
read_only => il est impossible de l'affecter d'erreurs d'écriture : on peut donc le considérer comme ayant une intégrité standard. Le cache-Système :
kernelcache n'est guère suspectable non plus a priori, étant le produit d'une commande de génération tout à fait basique comme dans le cas du dossier de
boot d'une «
Recovery HD».
Restent les 3 fichiers d'instruction
.plist lus par le
boot.efi avant chargement du cache de démarrage. J'ai examiné la paire de fichiers de « compatibilité » :
PlatformSupport.plist /
SystemVersion.plist pour chaque sauvegarde en la comparant à celle du dossier de
boot :
com.apple.recovery.boot de la «
Recovery HD» correspondant : identité parfaite. Si la «
Recovery HD» de chaque OS démarre sur son dossier de
boot, la «
Recovery TM» devrait démarrer sur un dossier de
boot identique à la virgule près.
♡
Solution théorique
Reste le fichier
com.apple.Boot.plist qui permet au
boot.efi de savoir l'adresse du cache-Système à charger et l'instruction d'accès au Système à déployer à communiquer au
kernel. Examen du
com.apple.Boot.plist de la sauvegarde
Yosemite :
Bloc de code:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Kernel Cache</key>
<string>\Backups.backupdb\.RecoverySets\0\com.apple.recovery.boot\kernelcache</string>
<key>Kernel Flags</key>
<string>rp=file:///Backups.backupdb/.RecoverySets/0/com.apple.recovery.boot/BaseSystem.dmg</string>
</dict>
</plist>
=> rien à redire : logiquement consistant dans l'adressage du
kernelcache à charger et du
BaseSystem.dmg à monter par le
kernel pour charger le Système contenu dans son volume ; analogue au fichier
com.apple.Boot.plist de la «
Recovery HD 10.10» correspondante dans les 2 objets pointés, avec simplement une variante dans les départs d'adresse.
Examen du fichier
com.apple.Boot.plist de la sauvegarde
EL Capitan :
Bloc de code:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Kernel Cache</key>
<string>\Backups.backupdb\.RecoverySets\0\com.apple.recovery.boot\kernelcache</string>
<key>Kernel Flags</key>
<string>rp=file:///Backups.backupdb/.RecoverySets/0/com.apple.recovery.boot/BaseSystem.dmg</string>
</dict>
</plist>
=> eh oui ! c'est
le même à la virgule près, mais justement, étant exactement
le même que celui de la sauvegarde
Yosemite, il est de ce fait
erroné. Comparaison avec le fichier de la «
Recovery HD 10.11» (qui démarre bien elle) :
Bloc de code:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Kernel Cache</key>
<string>\com.apple.recovery.boot\prelinkedkernel</string>
<key>Kernel Flags</key>
<string>rp=file:///com.apple.recovery.boot/BaseSystem.dmg</string>
</dict>
</plist>
=> cherchez l'erreur... Il m'a fallu 1 seconde pour l'apercevoir. L'OS «
El Capitan» ne démarre plus via l'exécution par le
boot.efi d'un cache-Système
Vieille École :
kernelcache, mais d'un cache-Système
New Age :
prelinkedkernel. Il en va de même de la «
Recovery HD 10.11». Il
doit donc logiquement en aller de même de la «
Recovery TM 10.11» (la sauvegarde démarrable). Dans les dossiers de
boot :
com.apple.recovery.boot de ces 2 dernières, il y a bien en effet un
prelinkedkernel comme cache de démarrage, et non plus un
kernelcache.
Or, dans le fichier d'instruction de
boot :
com.apple.Boot.plist de la sauvegarde
TimeMachine 10.11, un bogue d'adressage continue de mentionner comme objet du chargement par le
boot.efi : un
kernelcache qui n'existe plus, ayant été remplacé par un
prelinkedkernel. Donc le
boot.efi prend bien ses fontions, lit l'adresse du cache-Système à charger et... ne rencontre aucun objet logique au nom attendu (
kernelcache) en fin de
path, puisqu'existe à la place un
prelinkedkernel.
♢
Solution pratique
Il suffit donc, dans la sauvegarde
TimeMachine d'
El Capitan, de naviguer sur le DDE à :
Backups.backupdb/.RecoverySets/0/com.apple.recovery.boot/com.apple.Boot.plist, de demander à ouvrir ce fichier par «
TextWrangler» (afin de respecter les droits
root sur le fichier) et d'éditer la ligne
6 :
Bloc de code:
<string>\Backups.backupdb\.RecoverySets\0\com.apple.recovery.boot\kernelcache</string>
en
Bloc de code:
<string>\Backups.backupdb\.RecoverySets\0\com.apple.recovery.boot\prelinkedkernel</string>
et de sauvegarder l'édition.
Happy Christmas Booting (si vous plantez le jour de Noël)
Je considère que
zeltron dans ce diagnostic :
J'ai essayé d'approfondir le problème.
Sur le disque TimeMachine dans le dossier Backups.Backupsdb il y a un dossier invisible recovery qui contient toute la structure de la partition recovery du disque.
Je suppose qu'il y a bien un problème dans un de ces fichiers ou dossiers. Il faudrait pouvoir y réinstaller la structure complète avec le fichier .plist (qui est dedans) correct par rapport à la structure remise en place.
Mais là, cela dépasse mes compétences... C'est peut être un beau dossier à soumettre à notre ami Macomaniac
.
avait entièrement cerné le point problématique et son issue - je n'ai fait qu'apporter à son
Idée l'
exécution de son détail.
⛳︎
Qu'arrivé à la version publique
10.11.2 (et à la développeur
10.11.3) - aucun déboguage de «
TimeMachine» n'ait été fait dans «
El Capitan» pour actualiser dans le fichier
com.apple.Boot.plist l'intitulé
prelinkedkernel du cache spécifique de cet OS (alors que ce fichier est à jour pour la «
Recovery HD» et pour l'OS), personne (parmi les ingénieurs de la ) ne s'étant soit soucié de tenter un démarrage sur une sauvegarde
TM, soit posé la question de savoir pourquoi le
boot_loader :
boot.efi plantait expérimentalement au chargement du cache de démarrage-Système : ça me rend bigrement hilare (version :
risus sardonicus) comme d'aviser qu'ici comme ailleurs les problèmes découlent du
nom des choses et non des
choses en elles-mêmes...
