Bonjour
Vapor &
alii
J'ai été intrigué par cette déclaration :
J'ai tenté une réinstallation ... Pomme R, utilitaire de disque, effacer les disques et ré installer mac OS
Et j'ai formaté donc les deux partitions présentes
Seulement en continuant il fallait que je me connecte au mac App store ... Or ... pas moyen de me connecter ... Du coup j'abandonne me disant que je ré essayerai plus tard
Mais par curiosité je l'allume et maintenant je n'ai plus qu'un écran gris (impossible de retourner sur l'écran d'avant avec pomme R) avec un bruit bizarre mécanique ,est ce normal?
Il n'y a qu'une interprétation possible aux phénomènes décrits ici : à partir d'un démarrage par
⌘R en mode
Recovery >
Vapor a été capable d'effacer entièrement le disque interne de son Mac > càd. non seulement les partitions qui étaient affichées visiblement par l'«
Utilitaire de Disque» > mais aussi la partition de récupération «
Recovery HD» non affichée par ce logiciel. Bref : il a ré-initialisé le disque entier > en d'autres termes : effacé la table de partition
GUID de l'en-tête du disque > pour y recréer une nouvelle table de partition vide > montant un volume neuf complètement vide.
En résultat : aucun Système démarrable n'existe plus sur son disque > ni celui du «
Yosemite» qui était installé dans un volume > ni celui de la «
Recovery HD» qu'il avait utilisé en premier.
--------------------
Pourquoi ai-je été intrigué par cette déclaration ?
Parce que cet enchaînement d'événements n'a qu'une seule et unique explication : la commande de démarrage
⌘R utilisée par
Vapor > a fait démarrer son Mac sur un Système
Recovery résidant purement en
RAM (donc volatile) > Système
Recovery en
RAM totalement indépendant du disque du Mac (et de sa partition
Recovery HD y compris) > ce qui lui a rendu possible la capacité d'effacer le disque entier du Mac - partition
Recovery HD y compris.
Or dans mes expérimentations récentes de démarrage par
⌘R sur le
Recovery OS solidaire : soit de l'OS «
El Capitan 10.11» > soit de l'OS «
Sierra 10.12» => il m'a au contraire été absolument impossible d'effacer le disque entier du Mac.
Pour en avoir le cœur net > démarré donc par
⌘R en mode
Recovery 10.11 («
El Capitan») ou
10.12 («
Sierra») > j'ai :
- passé dans le «
Terminal» la commande :
qui a renvoyé (en autre) ceci :
Bloc de code:
image-path : file:///com.apple.recovery.boot/BaseSystem.dmg
blockcount : 2600084
> ce qui s'interprète ainsi : le support du volume monté et démarré
OS X Base System (1,3 Go) du
Recovery OS est un fichier
indépendant de la
RAM :
BaseSystem.dmg recelé dans un dossier
com.apple.recovery.boot.
- une commande :
retourne (entre autre) un :
et un :
Bloc de code:
diskutil info /Volumes/Image\ Volume
retourne (entre autre) ceci :
Bloc de code:
device identifier : disk0s3
Device /Media Name : Recovery HD
Mount Point : /Volumes/Image Volume
Ejectable : No
=> résumé : la commande
⌘R fait démarrer sur la
partition du disque du Mac
disk0s3 > volume monté :
Recovery HD > dossier :
com.apple.recovery.boot > fichier-disque virtuel :
BaseSystem.dmg > volume monté :
OS X Base System > recelant le
Recovery OS. Il est donc impossible de scier la branche sur laquelle on est assis : une tentative d'effacer le disque entier me retourne un message d'échec : impossible de démonter le disque. Pour cause : le volume
Recovery HD de la partition
disk0s3 est monté et «
utilisé ».
--------------------
Comment alors
Vapor a-t-il pu « scier la branche sur lequel il était assis » ?
Je suis parti d'une conjecture : et si le comportement induit par la commande
⌘R était
différent avec une
Recovery 10.10 de celui des
Recovery 10.11 &
10.12 ?
J'ai donc installé «
Yosemite» sur un SSD vide > avec donc une
Recovery HD 10.10. J'ai ouvert un de mes
MacBook Pro_2010 expérimentaux > enlevé son disque > loggé le SSD en question > et opéré successivement 2 types de démarrage :
- a) démarrage avec "
alt" > choix du volume
Recovery HD 10.10.5.
Le résultat de mes commandes d'information est strictement le même que celui que j'ai mentionné ci-dessus pour le démarrage
Recovery 10.11 ou
10.12 avec
⌘R : démarrage ayant pour point d'appui la
partition disk0s3 Recovery HD du disque --> impossibilité stricte d'effacer le disque entier.
- b) démarrage avec
⌘R.
Le résultat de mes commandes d'information est totalement changé -->
retourne un :
Bloc de code:
image-path : ramfile://xxxxxxxxxx
blockcount : 2600084
et un :
ne révèle aucun volume
Image Volume monté.
J'ai noté dans ce démarrage l'obligation de tenir pressées
très longuement les 2 touches
⌘R avant que la signalant l'exécution du
boot_loader : boot.efi du
Recovery OS ne s'affiche.
Il n'y a qu'une seule et unique interprétation : le démarrage par
⌘R en mode
Recovery 10.10 > opère le
clonage en
RAM du Système
Recovery recelé dans le volume
Recovery HD du disque > puis démarre le Mac sur ce Système
cloné uniquement sustenté en
RAM => il est donc possible depuis ce système indépendant du disque du Mac > d'effacer entièrement le disque. C'est ce que
Vapor (malheureusement pour lui) a fait. Il a « scié » les Systèmes installés sur le disque > parce qu'il n'était pas assis sur une branche de l'arbre du disque > mais sur une branche de la
RAM.
--------------------
Extrapolation à partir de ces expériences :
- le démarrage en mode
Recovery 10.10 avait
2 significations bien distinctes selon qu'on utilisait
⌘R ou "
alt" >
Recovery 10.10. Dans le 1er cas > démarrage sur la
RAM et possibilité d'effacer le disque ; dans le 2è cas > démarrage sur le
disque et impossibilité d'effacer le disque.
- le démarrage en mode
Recovery 10.11 ou
10.12 n'a plus qu'
1 seule & unique signification > que l'on utilise
⌘R ou "
alt" >
Récupération 10.11 ou
10.12 --> le démarrage s'opère toujours sur le
disque avec impossibilité d'effacer le disque.
Pourquoi ce changement stratégique ?
On pourrait conjecturer qu'un superviseur Apple aurait hululé à l'oreille de l'équipe d'ingénieurs chargés de cette branche de fonctionnement logique : « Non mais ça va pas la tête ?!! - l'utilisateur qui démarre par
⌘R > sur la
RAM donc et efface son disque entier > en échouant ensuite à ré-installer depuis l'AppStore > et qui éteint son Mac en effaçant la
RAM > et qui a un Mac antérieur à 2010 ne supportant pas le démarrage par internet (
⌘⌥R) - on m'a signalé un cas justement : un nommé
Vapor qui a effacé son disque entier après un démarrage sur la
RAM par
⌘R --> cet utilisateur n'a plus de système démarrable avec son
MacBook 2008. Le « bon berger » de la parabole se soucie d'un seul cas de brebis qui puisse s'égarer > donc vous allez fissa me supprimer ce démarrage sur la
RAM commandé par
⌘R et ramener cette commande à un démarrage sur le
disque comme "
alt" >
Récupération 10.x... »
Je ne crois pas une seule seconde à une cette scène d'indignation morale
-
Non > mais à l'intervention d'un « contre-coup logiciel ». À partir d'«
El Capitan 10.11» > un format
CoreStorage est généré par l'installateur sur la partition
disk0s2 de l'OS. Ce qui favorise l'activation de «
FileVault» requérant un tel format
CoreStorage.
Or un dispositif
CoreStorage -
même non chiffré - induit un démarrage toujours «
médiat » et jamais « immédiat » de l'OS porté par le
Volume Logique CoreStorage. Càd. ? --> le volume
CoreStorage affiché à l'écran de choix (
alt) > n'est
pas le volume de la partition
disk0s2 > c'est le volume
Recovery HD exclusivement > dans la mesure où a été créé dans ce volume > en plus du dossier de démarrage
Recovery :
com.apple.recovery.boot > un dossier de démarrage du volume du
CoreStorage :
com.apple.Boot.P > avec un
boot_loader > dossier qui a l'
hégémonie logistique sur celui du
Recovery OS.
Dès qu'un
CoreStorage existe sur la partition de l'OS > alors la
Recovery HD devient
prioritairement le
moyen de démarrer l'OS > le volume
Recovery HD donc s'affiche comme
lieu-tenant du volume de l'OS > le volume
Récupération 10.11 ou
10.12 ne peut plus donc être affiché. Donc le démarrage avec "
alt" ne permet plus le choix d'un démarrage
Recovery.
Il n'y a plus que la commande
⌘R pour démarrer en mode
Recovery. Ce démarrage par
⌘R > purement
secondaire par rapport à la fonction "
démarreur du volume CoreStorage" de la
Recovery > a récupéré la signification de démarrage de secours sur le
disque initié par "
alt" (option qui n'est plus disponible) > en perdant la signification de
clonage d'un Système
Recovery en
RAM et démarrage sur la
RAM.
--------------------
=> Je suis conscient que ce laïus de week-end ne fait pas avancer le dépannage de
Vapor : «
en pratique ». «
En théorie » du moins >
Vapor peut avoir la satisfaction de se dire que son cas a une valeur expérimentale exemplaire > illustrant une spécificité de l'OS «
Yosemite 10.10» --> le démarrage par
⌘R y diffère du démarrage par "
alt" >
Recovery 10.10 en ce qu'il s'opère sur la
RAM et pas sur le
disque.
Était-ce déjà le cas pour les OS antérieurs (de «
Lion 10.7» à «
Mavericks 10.9») ? Ou s'agit-il d'une aberration logicielle strictement cantonnée au mode
Recovery de «
Yosemite 10.10» ? - je n'ai pas eu le loisir de tester les 3 cas de figure impliqué pour en juger...
