10.11 El Capitan gros soucis maj mac osx a el capitan
- Créateur du sujet creaclaire
- Date de début
J'espère qu'à ce prix ils garantissent le retour des données.
Si ça se trouve ce blocage n'est une bête histoire de Core Storage. Ça se règle avec quelques lignes de commande qu'on trouve sur le forum. Macomaniac fait ça presque tous les jours.
Désolé, pas pu rester en ligne, j'avais à faire in real life.
Si ça se trouve ce blocage n'est une bête histoire de Core Storage. Ça se règle avec quelques lignes de commande qu'on trouve sur le forum. Macomaniac fait ça presque tous les jours.
Désolé, pas pu rester en ligne, j'avais à faire in real life.
M
Membre supprimé 1060554
Invité
Bonjour creaclaire
Pendant que tu craquais le Mac
moi je me promenais dans les bois où l'on n'entend craquer que des branches...
Comme ton Mac est chez un réparateur, j'interviens évidemment trop tard pour l'action - mais non pour la spéculation. Comme le disait Hegel : «La chouette de Minerve prend son envol le soir» (une fois donc qu'une journée de la vie s'est déjà accomplie > ce qui revient à constater que : la raison arrive toujours après la bataille...).
Il y a quelque chose qui m'intringue dans cette histoire assez embrouillée : c'est la suivante -->
à supposer que l'installateur d'«El Capitan» ait bien été présent après téléchargement dans les Applications de l'OS «Mountain Lion» > lorsque d'un double-clic on déclenche le programme d'installation > un dossier d'installation intitulé OS X Install Data se trouve créé à la racine du volume de destination (ici Macintosh HD contenant déjà l'OS «Mountain Lion»).
Dans ce volume OS X Install Data > une recopie s'opère du composant d'installation essentiel recelé dans l'installateur des Applications (le disque virtuel InstallESD.dmg de 6,2 Go) > mais en plus se trouve créés dans l'espace de ce dossier les boot_files (fichiers de démarrage) qui vont permettre le re-démarrage du Mac (il y a un boot_loader boot.efi = lanceur > un cache de démarrage prelinkedkernel > un fichier de vérification de conformité de la bécane pour l'install > et un fichier d'instructions de boot enjoignant au kernel de monter le disque InstallESD.dmg en un volume OS X Install ESD dans lequel se trouve à son tour le disque virtuel BaseSystem.dmg d'une Recovery > que le kernel va monter à son tour de manière à ce que les fichiers-Système d'un Système Recovery puissent démarrés.
Une fois donc le Mac re-démarré en mode Recovery sur le Système recelé dans le dossier global de boot OS X Install Data à la racine du volume Macintosh HD > le programme d'installation reprend l'initiative et commence par mettre à jour la partition de récupération Recovery HD collatérale (ou la créer si elle n'existait pas encore) à la version conforme à celle de l'OS à installer > ce qui nous donne donc une Recovery HD 10.11.6.
Or voici qu'il est dit qu'après 24 minutes d'un prétendu "processus d'installation" (censé donc être l'opération de recopie des fichiers du Système «El Capitan» depuis les ressources du volume monté OS X Install ESD en mise-à-niveau des fichiers déjà présents de «Mountain Lion» dans le volume Macintosh HD > serait intervenu un plantage tel que :
- le volume Macintosh HD est désormais indémarrable sinon en reprise d'un processus d'installation qui bloque.
- le mode Recovery par contre est toujours démarrable > mais si l'option "Ré-installer OS X" est déclenchée > alors c'est toujours «Mountain Lion 10.8» qui est proposé à l'installation.
Ce qui me paraît la preuve que le programme d'installation d'«El Capitan», après re-démarrage du Mac sur les ressources de démarrage du dossier d'install OS X Install Data > n'a pas eu le temps de mettre à niveau la partition de récupération Recovery HD 10.8 à la version 10.11.6 > tâche qui est toujours la préalable du lancement de la recopie des fichiers du Système.
Il est donc conjecturable qu'aucune atteinte n'a été faite au Système «Mountain Lion» du volume Macintosh HD, puisque la mise-à-niveau toujours précédente de la Recovery HD n'a pas été accomplie. Donc le Système 10.8 serait intact.
À quoi alors s'est occupé pendant 24' le Programme d'installation, s'il n'a pendant ce laps de temps rien opéré en terme d'écritures, puisque, si cela avait été le cas, une réécriture de la Recovery HD aurait été effectuée en préalable en pas plus d'une minute ? Est-il possible qu'il ait indéfiniment ratatouillé à vérifier l'intégrité du système de fichiers du volume cible (Macintosh HD) - mais comment alors est-ce possible pendant 24' ? - une barre de progression s'est-elle jamais affichée avec progression réelle de l'affichage ou aucune progression réelle de l'affichage ?
Ce point me déconcerte hautement, car ces 24' d'un processus dans le vide me paraissent peu plausibles > et pourtant inversement le fait que la Recovery HD soit restée une 10.8 (la preuve : la version «Mountain Lion» offerte en ré-installation) est une preuve qu'aucune écriture n'a été engagée par le Programme d'installation.
Si ma conjecture d'un travail d'écriture d'«El Capitan» inexistant était valide > alors le blocage du démarrage sur le Système intègre de «Mountain Lion» ne proviendrait que d'un seul facteur : le dossier d'installation OS X Install Data présent à la racine du volume Macintosh HD > lequel, recelant actuellement un Système alternatif démarrable, avec arguments de démarrage sur lui renseignés en NVRAM pour l'EFI, et éventuellement même blessing (bénédiction) de l'en-tête du volume Macintosh HD traçant le chemin exécutif pour l'EFI au boot_loader boot.efi du dossier OS X Install Data > joue un rôle d'écran du Système (repoussé à l'arrière-plan) : «Mountain Lion». Bref : le dossier démarrable OS X Install Data aurait une fonction d'overriding du Système toujours potentiellement démarrable «Mountain Lion» mais bloqué de démarrage par ce dossier bootable.
La solution à ce problème est l'enfance de l'art : à partir du «Terminal» de la Recovery > après commande ls destinée à vérifier l'existence d'un dossier OS X Install Data à la racine du volume Macintosh HD > commande rm de suppression récursive de ce dossier > puis commande bless réinscrivant le chemin au boot_loader boot.efi recelé dans le répertoire /Volumes/Macintosh\ HD/System/Library/CoreServices de «Mountain Lion» sur l'en-tête du volume Macintosh HD > ce qui opérerait un reset de l'argument efi-boot-device en NVRAM en éliminant l'argument de boot obsolète > logiquement re-démarrage automatique sur «Mountain Lion» délivré de l'ombre du Système écran.
Mais... il y a un « mais » encore : le volume Macintosh HD est verrouillé en cas de démarrage alternatif en Recovery > ce qui m'évoque un chiffrement dû à une activation de «FileVault» qui aurait été effective sur le volume Macintosh HD dès «Mountain Lion». Il aurait fallu vérifier dans le «Terminal» de la Recovery le statut logique du volume Macintosh HD. Volume en principe déverrouillable et donc montable depuis ce Système alternatif > afin de pouvoir y supprimer le dossier écran OS X Install Data.
En cas de verrouillage de Macintosh HD par un chiffrement > un dispositif CoreStorage sophistiqué existerait > tel que le démarrage sur le volume verrouillé a priori Macintosh HD s'opère via le démarreur classique (détourné de sa fonction de démarreur de la récupération) de la Recovery HD. Le dossier de démarrage de cette partition n'ayant manifestement pas été mis à niveau > tout porte à penser que le dispositif de démarrage du CoreStorage Chiffré recelé dans un dossier d'instructions collatéral est intact > et que seul donc le contenu du Volume Logique une fois monté est affecté par l'existence du dossier OS X Install Data jouant un rôle de Système de boot écran.
Je peux demander ici une vérification orale de cette conjecture d'un chiffrement : au démarrage du Mac > un écran de login était-il proposé tout de suite (preuve du chiffrement) ou bien n'intervenait-il qu'en fin de démarrage de l'OS après l'affichage de la puis d'une roue crantée giratoire (preuve d'absence de chiffrement) ? Et encore : en cas de démarrage avec "alt" > un volume de secours Récupération 10.8 était-il affiché (preuve d'absence de CoreStorage) ou non (preuve d'existence d'un CoreStorage) ?
Pendant que tu craquais le Mac
Comme ton Mac est chez un réparateur, j'interviens évidemment trop tard pour l'action - mais non pour la spéculation. Comme le disait Hegel : «La chouette de Minerve prend son envol le soir» (une fois donc qu'une journée de la vie s'est déjà accomplie > ce qui revient à constater que : la raison arrive toujours après la bataille...).
--------------------
Il y a quelque chose qui m'intringue dans cette histoire assez embrouillée : c'est la suivante -->
à supposer que l'installateur d'«El Capitan» ait bien été présent après téléchargement dans les Applications de l'OS «Mountain Lion» > lorsque d'un double-clic on déclenche le programme d'installation > un dossier d'installation intitulé OS X Install Data se trouve créé à la racine du volume de destination (ici Macintosh HD contenant déjà l'OS «Mountain Lion»).
Dans ce volume OS X Install Data > une recopie s'opère du composant d'installation essentiel recelé dans l'installateur des Applications (le disque virtuel InstallESD.dmg de 6,2 Go) > mais en plus se trouve créés dans l'espace de ce dossier les boot_files (fichiers de démarrage) qui vont permettre le re-démarrage du Mac (il y a un boot_loader boot.efi = lanceur > un cache de démarrage prelinkedkernel > un fichier de vérification de conformité de la bécane pour l'install > et un fichier d'instructions de boot enjoignant au kernel de monter le disque InstallESD.dmg en un volume OS X Install ESD dans lequel se trouve à son tour le disque virtuel BaseSystem.dmg d'une Recovery > que le kernel va monter à son tour de manière à ce que les fichiers-Système d'un Système Recovery puissent démarrés.
Une fois donc le Mac re-démarré en mode Recovery sur le Système recelé dans le dossier global de boot OS X Install Data à la racine du volume Macintosh HD > le programme d'installation reprend l'initiative et commence par mettre à jour la partition de récupération Recovery HD collatérale (ou la créer si elle n'existait pas encore) à la version conforme à celle de l'OS à installer > ce qui nous donne donc une Recovery HD 10.11.6.
Or voici qu'il est dit qu'après 24 minutes d'un prétendu "processus d'installation" (censé donc être l'opération de recopie des fichiers du Système «El Capitan» depuis les ressources du volume monté OS X Install ESD en mise-à-niveau des fichiers déjà présents de «Mountain Lion» dans le volume Macintosh HD > serait intervenu un plantage tel que :
- le volume Macintosh HD est désormais indémarrable sinon en reprise d'un processus d'installation qui bloque.
- le mode Recovery par contre est toujours démarrable > mais si l'option "Ré-installer OS X" est déclenchée > alors c'est toujours «Mountain Lion 10.8» qui est proposé à l'installation.
Ce qui me paraît la preuve que le programme d'installation d'«El Capitan», après re-démarrage du Mac sur les ressources de démarrage du dossier d'install OS X Install Data > n'a pas eu le temps de mettre à niveau la partition de récupération Recovery HD 10.8 à la version 10.11.6 > tâche qui est toujours la préalable du lancement de la recopie des fichiers du Système.
Il est donc conjecturable qu'aucune atteinte n'a été faite au Système «Mountain Lion» du volume Macintosh HD, puisque la mise-à-niveau toujours précédente de la Recovery HD n'a pas été accomplie. Donc le Système 10.8 serait intact.
À quoi alors s'est occupé pendant 24' le Programme d'installation, s'il n'a pendant ce laps de temps rien opéré en terme d'écritures, puisque, si cela avait été le cas, une réécriture de la Recovery HD aurait été effectuée en préalable en pas plus d'une minute ? Est-il possible qu'il ait indéfiniment ratatouillé à vérifier l'intégrité du système de fichiers du volume cible (Macintosh HD) - mais comment alors est-ce possible pendant 24' ? - une barre de progression s'est-elle jamais affichée avec progression réelle de l'affichage ou aucune progression réelle de l'affichage ?
Ce point me déconcerte hautement, car ces 24' d'un processus dans le vide me paraissent peu plausibles > et pourtant inversement le fait que la Recovery HD soit restée une 10.8 (la preuve : la version «Mountain Lion» offerte en ré-installation) est une preuve qu'aucune écriture n'a été engagée par le Programme d'installation.
Si ma conjecture d'un travail d'écriture d'«El Capitan» inexistant était valide > alors le blocage du démarrage sur le Système intègre de «Mountain Lion» ne proviendrait que d'un seul facteur : le dossier d'installation OS X Install Data présent à la racine du volume Macintosh HD > lequel, recelant actuellement un Système alternatif démarrable, avec arguments de démarrage sur lui renseignés en NVRAM pour l'EFI, et éventuellement même blessing (bénédiction) de l'en-tête du volume Macintosh HD traçant le chemin exécutif pour l'EFI au boot_loader boot.efi du dossier OS X Install Data > joue un rôle d'écran du Système (repoussé à l'arrière-plan) : «Mountain Lion». Bref : le dossier démarrable OS X Install Data aurait une fonction d'overriding du Système toujours potentiellement démarrable «Mountain Lion» mais bloqué de démarrage par ce dossier bootable.
La solution à ce problème est l'enfance de l'art : à partir du «Terminal» de la Recovery > après commande ls destinée à vérifier l'existence d'un dossier OS X Install Data à la racine du volume Macintosh HD > commande rm de suppression récursive de ce dossier > puis commande bless réinscrivant le chemin au boot_loader boot.efi recelé dans le répertoire /Volumes/Macintosh\ HD/System/Library/CoreServices de «Mountain Lion» sur l'en-tête du volume Macintosh HD > ce qui opérerait un reset de l'argument efi-boot-device en NVRAM en éliminant l'argument de boot obsolète > logiquement re-démarrage automatique sur «Mountain Lion» délivré de l'ombre du Système écran.
Mais... il y a un « mais » encore : le volume Macintosh HD est verrouillé en cas de démarrage alternatif en Recovery > ce qui m'évoque un chiffrement dû à une activation de «FileVault» qui aurait été effective sur le volume Macintosh HD dès «Mountain Lion». Il aurait fallu vérifier dans le «Terminal» de la Recovery le statut logique du volume Macintosh HD. Volume en principe déverrouillable et donc montable depuis ce Système alternatif > afin de pouvoir y supprimer le dossier écran OS X Install Data.
En cas de verrouillage de Macintosh HD par un chiffrement > un dispositif CoreStorage sophistiqué existerait > tel que le démarrage sur le volume verrouillé a priori Macintosh HD s'opère via le démarreur classique (détourné de sa fonction de démarreur de la récupération) de la Recovery HD. Le dossier de démarrage de cette partition n'ayant manifestement pas été mis à niveau > tout porte à penser que le dispositif de démarrage du CoreStorage Chiffré recelé dans un dossier d'instructions collatéral est intact > et que seul donc le contenu du Volume Logique une fois monté est affecté par l'existence du dossier OS X Install Data jouant un rôle de Système de boot écran.
Je peux demander ici une vérification orale de cette conjecture d'un chiffrement : au démarrage du Mac > un écran de login était-il proposé tout de suite (preuve du chiffrement) ou bien n'intervenait-il qu'en fin de démarrage de l'OS après l'affichage de la puis d'une roue crantée giratoire (preuve d'absence de chiffrement) ? Et encore : en cas de démarrage avec "alt" > un volume de secours Récupération 10.8 était-il affiché (preuve d'absence de CoreStorage) ou non (preuve d'existence d'un CoreStorage) ?
Dernière édition par un modérateur:
Sujets similaires
10.11 El Capitan
a propos de disk utility
