10.12 Sierra CMD+R ne fonctionne pas

Comme on est en période d'oisiveté estivale > que mokuchley (l'auteur de ce fil) est rentré dans sa Caverne platonicienne rassuré quant à la normalité de sa configuration > je m'avise que cette incitation de r e m y :
Il serait amusant d'analyser ainsi que tu l'as fait, le système de contournement imaginé par Apple pour réussir à installer BootCamp sur les iMac avec FusionDrive 3 To qui pendant longtemps sont restés incompatibles avec l'installation de BootCamp
m'avait échappé dans le feu de l'action.

Je me fais un plaisir d'y répondre.

Disque de 3 To voulait dire HDD d'un iMac associé à un SSD dans une configuration Fusion Drive. Dans une telle configuration > c'est toujours sur le HDD que la Recovery HD se trouve créée (en-dessous de la partition HDD du CoreStorage) > et c'est encore en-dessous que se trouve créée une partition BOOTCAMP pour Windows (après réduction de la partition CoreStorage du même HDD).

À supposer un iMac un peu récent supportant l'installation de Windows-10 > cette configuration ne pose aucun problème > parce que Windows-10 est un OS UEFI comportant un boot_loader .efi exécutable par l'EFI et impliquant une table de partition GUID sur l'en-tête du disque. Or une table de partition GUID (disons GPT pour abréger) ne comporte pas de limitation du nombre de blocs logiques sur un disque qu'elle peut gérer. Elle gère donc sans aucun problème une partition BOOTCAMP commençant (supposons-le) à la limite des 2800 Go et allant jusqu'à la marque terminale des 3000 Go.

S'il y a eu un problème qui a tarabusté les ingénieurs de la  > ça été concernant les versions Legacy de Windows, Windows-7 par exemple, qui était des OS BIOS_based : càd comportant un boot_loader vintage inexécutable par l'EFI mais par un Programme Interne de type BIOS. Logiciel BIOS strictement incapable de lire une GPT pour obtenir l'adresse à la partition BOOTCAMP > mais requérant strictement une MBR lui décrivant l'adresse de la partition selon le schéma "Enregistrement de Démarrage Principal".

Or la limitation d'une table MBR est qu'elle n'a jamais pu gérer plus de 2,2 To de blocs logiques sur un disque - tout ce qui se situait au-delà ayant statut d'espace neutre inadressable comme espace de partition. D'où le problème épineux : comment faire   pour qu'une partition BOOTCAMP puisse être créée sur un disque de 3 To sans que sa localisation au-delà des 2,2 To de blocs logiques ne la rende inindexable par une table MBR? Sous-problème technique d'un problème plus général  qui se posait quelle que soit la taille du disque : comment faire sur un Mac pour booter un OS Legacy comme Windows-7 > càd. avoir un logiciel BIOS activable > qui disposerait sur l'en-tête du disque d'une table MBR pour obtenir l'adresse de la partition BOOTCAMP  ?

La réponse à cette dernière question a donné lieu à un bricolage invraisemblable sur les Mac (qui étaient des EFI_based computers à l'époque où les si vantés PC étaient de minables bécanes BIOS_based en retard d'une génération). Comme quoi ce bricolage invraisemblable était entièrement destiné à ramener les Mac "en-arrière" pour leur faire émuler ces machines du passé qu'étaient les PC.

L'EFI des Mac a donc été implémentée d'une fonctionnalité secondaire : la capacité à émuler un BIOS. Pour que ce BIOS_émulé puisse trouver à lire une MBR sur l'en-tête d'un disque Mac > une double distribution a été mise-en-place telle que : sur le seul bloc 0 (ou premier bloc) des disques Mac > une table de partition secondaire MBR se trouve toujours incrite > tandis que sur la série suivante des blocs allant de 1 à 32 > une table GPT principale se trouve inscrite.

Avec un mécanisme logique automatique qui était le suivant : aussi longtemps qu'aucune partition dans un format Windows n'existait sur le disque > mais seulement des formats Apple > la MBR du bloc 0 était du type Protective_MBR (PMBR) = table MRB neutre > ne décrivant strictement aucune partition sur le disque qui puisse être adressée par un BIOS. Ainsi > l'EFI dans le temps de boot n'avisant aucune MBR décrivant des partitions > l'implémentation BIOS_émulé se trouvait neutralisée.

Mais dès qu'une partition dans un format Windows se trouvait créée (comme une partition BOOTCAMP dans un format préalable FAT-32) > alors automatiquement la PMBR du bloc 0 se trouvait convertie à un type Hybrid_MBR (HMBR) = MBR hybridée de la description des partitions actuelles du disque par la GPT principale. Il s'agissait donc de la génération automatique d'une MBR effective > décrivant les mêmes exactes partitions que la GPT en écho direct de celle-ci > selon le schéma "Enregistrement de démarrage principal".

Une première limitation de ce mécanisme ingénieux était que seulement 3 partitions déjà décrites dans la GPT pouvaient être répercutées en écho (echoed) dans la HMBR.

Mais la limitation cruciale intervenait avec les rares disques de 3 To  : au cas où une partition BOOTCAMP serait créée dans la table GPT au-delà des 2,2 To de blocs logiques > alors elle ne pourrait pas être « echoed  » (reflétée) dans la HMBR du bloc 0 > à cause de la limitation intrinsèque d'une MBR de ne pas pouvoir gérer plus de 2,2 To de blocs logiques.

La solution à ce problème était beaucoup plus enfantine que celle de permettre un boot BIOS_based --> elle consistait à partitionner a priori le disque de 3 To en une partition principale de 2,2 To et une partition secondaire de 800 Go. Dans ce cas le Fusion Drive était une association de 3 partitions : la principale du SSD et les 2 du HDD - ce qui ne pose aucun problème a priori au système de stockage CoreStorage particulièrement adaptable.

Le raffinement logiciel était alors le suivant : dans cette configuration à 2 partitions sur le HDD > la Recovery HD était toujours créée en intercalaire des 2 partitions CoreStorage qui étaient donc séparées par la partition de secours. On avait donc sur le HDD --> disk1s1 = partition EFI > disk1s2 = partition CoreStorage > disk1s3 = partition Recovery HD > disk1s4 = partition CoreStorage.

Dans cette configuration > toute demande de rétrécissement de la taille globale du CoreStorage Fusion Drive > adressait exclusivement la partition CoreStorage disk1s2 de 2,2 To du HDD (celle précédant la Recovery HD) > de telle sorte que la partition BOOTCAMP créée à partir de l'espace libéré par cette partition disk1s2 se trouvait toujours créée juste en-dessous de la Recovery HD disk1s3 mais toujours en-dessus de la partition CoreStorage disk1s4.

On obtenait donc une distribution : disk1s1 = EFI > disk1s2 = CoreStorage > disk1s3 = Recovery HD > disk1s4 = BOOTCAMP > disk1s5 = CoreStorage.

En quoi il s'agit d'une solution suffisante au problème de la limitation d'une MBR à 2,2 To de blocs saute aux yeux --> la partition CoreStorage disk1s2 étant créée a priori jusqu'à la limite des 2,2 To de blocs logiques > toute repartition de cette partition pour créer une BOOTCAMP générait toujours cette partition Windows dans la limite des 2,2 To de blocs logiques. Par suite > la conversion automatique de la PMBR neutre du bloc 0 à une HMBR de type descriptif faisait « écho » à une distribution de partitions GPT qui admettait en n°1 un équivalent de l'EFI disk0s1 > en n°2 un équivalent de la CoreStorage disk0s2 > échappait la description de la disk0s3 Recovery HD > et admettait en n°3 la description de la BOOTCAMP disk0s4. Ainsi la double limite des 2,2 To de blocs et de pas plus de 3 partitions GPT « echoed » en mode MBR était respectée.

=> je pense qu'il faut saluer comme il se doit l'ingéniosité de l'ingéniérie Apple dans la gestion du cas « Windows » sur Mac. Windows était vraiment un OS du passé > booté par des ordinateurs du passé : il fallait toute une série invraisemblable de « patches » logiques pour qu'un EFI_based computer comme le Mac > utilisant une GPT comme table de partition > puisse booter un OS Legacy comme Windows-7 > particulièrement sur des iMac utilisant un disque géant de 3 To associé en Fusion Drive à un SSD. Le raffinement de procédés permettant de repêcher Windows sur Mac (aujourd'hui inutiles) me paraît un exploit d'ingéniérie d'une générosité louable.
 
Dernière édition par un modérateur:
  • J’aime
Réactions: r e m y
Merci de cette explication détaillée! C'est beau comme du Ronsard, je trouve...


Et si je peux me permettre une question complémentaire, qu'est-ce qui rend si complexe le passage à APFS d'un FusionDrive ainsi constitué?
 
Étant donné l'état encore en chantier de l'APFS > je ne sais pas encore me prononcer clairement & distinctement sur l'étendue (ou les limites) de ses capacités. Mes dernières expérimentations, notamment, de re-dimensionnement d'un Container APFS en vue de créer une partition de type BOOTCAMP ayant échoué (interminable vérification du système de fichiers du Volume APFS > puis pfuittt ! avortement de la commande).

Ce que je sais est qu'il n'y a pas de difficulté a priori pour convertir un CoreStorage Fusion Drive à 2 partitions (1 sur le SSD et 1 sur le HDD) en un APFS Fusion Style > le système de stockage APFS admettant, à l'image du CoreStorage, une distribution multiple de magasins de stockage physique sur plusieurs partitions de disques.

J'ai l'impression que la difficulté spécifique pour convertir un CoreStorage Fusion Drive à 3 partitions (1 sur le SSD et 2 sur le HDD - configuration que j'ai décrite dans mon message précédent) en un APFS Fusion Style > est que le système de stockage APFS n'admet pas une distribution multiple de magasins de stockage physique sur plusieurs partitions d'un même disque. Ce qui est le cas par contre avec un CoreStorage Fusion Drive à 3 partitions > où il y a 2 magasins de stockage Physical Volumes sur 2 partitions du même HDD.

Je ne sais pas si cette limitation de l'APFS à une seule partition de résidence d'un magasin de stockage physique par disque est provisoire ou définitive : en l'état du chantier > elle rend impossible la conversion adéquate d'un CoreStorage Fusion Drive à 3 partitions dont 2 sur le HDD > puisque l'APFS ne pourrait pas reproduire 2 magasins de stockage physique sur le seul HDD.
 
Help ! Il m’arrive là même chose, ma petite sœur m’a confié son mac en passant que je pouvais rattraper la merde qu’elle a fait. Bref

Écran noir avec cadenas, elle ne se souvient plus du mdp à essayé de le redéfinir en rebootant avec cmd+r et elle l’a mal fait.

Résultat je ne peux plus accéder au menu en faisant cmd+r ou opt+cmd+r
J’aime droit à l’allumage qu’à lecran noir avec le cadenas
 
Bonjour Alesio

Un cadenas affiché à l'écran lors d'une tentative de démarrage du Mac autre qu'un démarrage direct sur le volume interne => signale un verrouillage du programme interne de la carte-mère (l'EFI) par un mot-de-passe. Il faut renseigner le mot-de-passe qui a été défini pour l'EFI afin de déverrouiller le cadenas.

Ce verrouillage a été mis en place dans la session de secours > via une application intitulée Sécurité au démarrage. Lors de la saisie du mot-de-passe de l'EFI dans cette application => le clavier est régulièrement AZERTY. Mais à l'écran de déverrouillage (cadenas) => le clavier logique est toujours QWERTY. Cette différence des claviers n'est pas documentée.

Donc : pour déverrouiller le cadenas > il faut absolument que ta sœur se souvienne du mot-de-passe qu'elle a défini dans la session de secours (peut-être le même que le mot-de-passe de session ?) => mais il faut que tu tapes ce mot-de-passe par conversion de tous les caractères variables pour les adapter au QWERTY. Les chiffres notamment se frappent directement sur les touches correspondantes (sans le shift ou maj).

Si vous n'arrivez pas à déverrouiller le cadenas > la case Apple Store s'impose : il faut une preuve de propriété du Mac et le deverrouillage de l'EFI coûte environ 15€.
 
  • J’aime
Réactions: Fullcrum
Bonjour,
Je dois refaire une installation propre de Catalina mais ma commande : cmd + R ne fonctionne plus, ni les autres commandes avec alt, maj etc... Mon "Recovery" aurait-il disparu? (Macbook Pro, mi 2012)

Merci!
 
Bonsoir alessmuse

Voici comment tu vas pouvoir fournir les informations de base -->

- va à : Applications > Utilitaires > lance le «Terminal». Dans la fenêtre ouverte > saisis la commande informative (ce qui est inscrit sous Bloc de code) :​
Bloc de code:
diskutil list internal
et ↩︎ (presse la touche "Entrée" du clavier pour exécuter la commande)

  • tu vas voir s'afficher la configuration interne seule

Poste le retour en copier-coller > en veillant à faire le coller dans une fenêtre de code (c'est plus lisible !) par le procédé suivant -->

- utilise le menu ...▾ (à droite de la bobine souriante) dans la barre de menus au-dessus du champ de saisie d'un message > sous-menu : </> Bloc de code => tu fais ton coller dans la fenêtre de code et Continuer.

=> ces informations montreront la configuration du disque.
 
Bonsoir @macomaniac ,
Bloc de code:
Last login: Thu Jan  2 19:14:58 on console
sandra@macbook-pro-de-sandra ~ % diskutil list internal
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         499.9 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +499.9 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume mac                     11.1 GB    disk1s1
   2:                APFS Volume Preboot                 27.5 MB    disk1s2
   3:                APFS Volume Recovery                525.4 MB   disk1s3
   4:                APFS Volume VM                      1.1 GB     disk1s4
   5:                APFS Volume mac - Données           210.1 GB   disk1s5

sandra@macbook-pro-de-sandra ~ %
 
Voici le volume de secours -->
Bloc de code:
   3:                APFS Volume Recovery                525.4 MB   disk1s3

  • interne au Conteneur apfs. La distribution de Catalina a bien 5 volumes (la règle pour cet OS). Je ne vois aucune anomalie formelle.

Qu'est-ce que tu as comme clavier ?
 
Salut,

Récupère tout ""simplement"" le fichier d’installation de Catalina, fait une clé avec Keylifornia ( lien rouge, ma signature )et c’est tout, tu éviteras de te retrouver bloqué avec ce Mac.

PS : Je ne suis pas un grand fan de cette fonction d’effacement Made in Apple, j’aime faire mes clés ...
 
Ok, merci! Je vais tenter la clé! J'observe d'abord si le bug qui m'amène à reformater et tout réinstaller continue (clic gauche qui se transforme en clic droit, problème que je tente de résoudre via un autre fil, mais qui peut, peut-être, être aussi à l'origine du non fonctionnement de cmd + R... ), une réinsitallation propre me permettra de voir si mon bug continue, et si le problème est matériel...
 
Dans Préférences Système/Clavier tu as quoi de sélectionner ? Moi, je n'ai que le clavier français.