MacBook Pro Plus de démarrage Mac, juste Windows

  • Créateur du sujet Créateur du sujet fmelle
  • Date de début Date de début

fmelle

Membre confirmé
8 Mai 2018
19
0
50
Je reprends le fil précédent dans celui-ci car en mode recovery internet, l'ancien fil n'est pas accessible du fait du contrôle parental.

C'est donc la suite du sujet : https://forums.macg.co/threads/plus-de-boot-possible-sur-osx-juste-windows.1304665/

Bloc de code:
-bash-3.2# gpt show disk0
      start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6       
         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640  390668248      2  GPT part - DE94BBA4-06D1-4D40-A16A-BFD50179D6AC
  391077888   98232320      3  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  489310208     921600      4  GPT part - DE94BBA4-06D1-4D40-A16A-BFD50179D6AC
  490231808       2911       
  490234719         32         Sec GPT table
  490234751          1         Sec GPT header
 
Dernière édition:
Alors voici ce que je te propose comme démarche -->

  • a) supprimer (par la commande gpt) la partition disk0s2 (macOS) de la table GPT de l'en-tête du disque. Cette suppression > ne touche absolument rien aux écritures des blocs concernés (système fichiers de l'en-tête de la partition et écritures des blocs suivants) - ce n'est donc pas un reformatage > mais efface simplement le descripteur de la partition dans la table GPT du disque. Descripteur qui intègre actuellement un type de partition inapproprié (hex code défectueux)

  • b) recréer (par une nouvelle commande gpt) un descripteur complet de la partition > avec alignements des blocs concernés > rang dans la table (n°2) > et surtout type approprié de la partition (= "Apple_APFS"). Si la recréation du descripteur dans la GPT est correcte - surtout dans le type de la partition --> le Conteneur APFS qui s'exporte de cette partition > devrait instantanément être redéployé par le kernel en exercice (celui de l'OS de secours démarré) - un service diskarbitrationd surveillant constamment les modifications de la table GPT notamment et passant au kernel les tâches correspondantes.

=> est-ce que tu es partant pour cette opération en 2 temps ?

note 1 : j'ai juste besoin d'un confirmation --> tu as bien un SDD > et c'était bien l'OS High Sierra qui était installé dans la partition macOS (donc en format apfs) ?

note 2 : l'exécutable gdisk de Roderick Smith est inutilisable pour cette opération (à supposer qu'il soit appelable dans une commande) > car il ne gère pas le changement de type d'une partition à "Apple_APFS". D'où le procédé que je t'ai proposé : décréation > recréation d'un descripteur de la GPT par la commande gpt.
 
Alors voici ce que je te propose comme démarche -->

  • a) supprimer (par la commande gpt) la partition disk0s2 (macOS) de la table GPT de l'en-tête du disque. Cette suppression > ne touche absolument rien aux écritures des blocs concernés (système fichiers de l'en-tête de la partition et écritures des blocs suivants) - ce n'est donc pas un reformatage > mais efface simplement le descripteur de la partition dans la table GPT du disque. Descripteur qui intègre actuellement un type de partition inapproprié (hex code défectueux)

  • b) recréer (par une nouvelle commande gpt) un descripteur complet de la partition > avec alignements des blocs concernés > rang dans la table (n°2) > et surtout type approprié de la partition (= "Apple_APFS"). Si la recréation du descripteur dans la GPT est correcte - surtout dans le type de la partition --> le Conteneur APFS qui s'exporte de cette partition > devrait instantanément être redéployé par le kernel en exercice (celui de l'OS de secours démarré) - un service diskarbitrationd surveillant constamment les modifications de la table GPT notamment et passant au kernel les tâches correspondantes.

=> est-ce que tu es partant pour cette opération en 2 temps ?

note 1 : j'ai juste besoin d'un confirmation --> tu as bien un SDD > et c'était bien l'OS High Sierra qui était installé dans la partition macOS (donc en format apfs) ?

note 2 : l'exécutable gdisk de Roderick Smith est inutilisable pour cette opération (à supposer qu'il soit appelable dans une commande) > car il ne gère pas le changement de type d'une partition à "Apple_APFS". D'où le procédé que je t'ai proposé : décréation > recréation d'un descripteur de la GPT par la commande gpt.

Oui, je suis partant, je pense aussi depuis le début que c'est mon logiciel PC de partition qui a écrasé le MBR en remplaçant le type des partitions APFS par du Windows Recovery. En plus dans le pire des cas, j'ai mon time machine à jour de la veille du problème.

Je te confirme que j'ai bien la version la plus à jour du système d'exploitation Mac, soit High Sierra. Je me rappelle aussi qu'il m'a dit avoir mis à jour mon FS suite à l'upgrade pour un FS plus optimisé SSD ... Mon MBP est late 2013 et est bien équipé d'un SSD.

Je suis donc prêt à tenter le coup, est-ce que pour être certain de ne pas faire de bêtise, tu peux me préciser les commandes exactes à passer ?

Merci.
 
La commande gpt ne peut adresser en écriture la table GPT du disque > que si aucun volume n'est monté sur aucune partition de ce disque (en gros --> la condition est : table de partition oisive - idle). Comme je suspecte le volume BOOTCAMP d'être monté actuellement sur la partition disk0s3 --> passe d'abord la commande :
Bloc de code:
diskutil umount force disk0s3

  • est-ce que tu as bien obtenu un :
Bloc de code:
Volume BOOTCAMP on disk0s3 force-unmounted

  • ou autre chose ?
 
La commande gpt ne peut adresser en écriture la table GPT du disque > que si aucun volume n'est monté sur aucune partition de ce disque (en gros --> la condition est : table de partition oisive - idle). Comme je suspecte le volume BOOTCAMP d'être monté actuellement sur la partition disk0s3 --> passe d'abord la commande :
Bloc de code:
diskutil umount force disk0s3

  • est-ce que tu as bien obtenu un :
Bloc de code:
Volume BOOTCAMP on disk0s3 force-unmounted

  • ou autre chose ?

Oui j’ai bien eu le message que tu attendais :

Bloc de code:
Volume BOOTCAMP on disk0s3 force-unmounted
 
Alors enchaîne par la commande :
Bloc de code:
gpt remove -i 2 disk0

  • la commande supprime le descripteur de la partition de rang 2 (disk0s2) dans la table GPT

Je ne sais plus s'il y a un commentaire du type :
Bloc de code:
disk0s2 removed

S'il n'y a pas eu de message d'erreur > repasse un :
Bloc de code:
diskutil list

  • et poste le tableau pour vérification.

Notes : une action d'écriture à la GPT a dû instantanément faire remonter le volume BOOTCAMP par le kernel ; une suppression de descripteur par la commande gpt laisse toujours l'index de rang vacant dans la table > ce qui permet de le récupérer ensuite pour recréer un descripteur assignant une partition de même rang. Sinon > c'est vraiment assez "relou" pour permuter les rangs de partitions (un reformatage par exemple réassigne les rangs des partitions).
 
Voilà :

Bloc de code:
-bash-3.2# diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:       Microsoft Basic Data BOOTCAMP                50.3 GB    disk0s3
   3:           Windows Recovery                         471.9 MB   disk0s4
 
Parfait ! --> alors après la décréation > la recréation (activité des plus récréative)-
361608_original.png


Commence par repasser la commande :
Bloc de code:
diskutil umount force disk0s3

  • pour redémonter le volume BOOTCAMP qui a été remonté


Voici la commande à passer à présent -->
Bloc de code:
gpt add -b 409640 -s 390668248 -t 7C3457EF-0000-11AA-AA11-00306543ECAC -i 2 /dev/disk0

  • voici comment tu vas t'y prendre pour saisir commodément cette commande : par un "copier-coller à rebours" --> viens d'abord ici avec Safari > copie la commande (jusqu'au disk0 final) > quitte Safari (les applications se lancent en mode "alternatif" et pas "parallèle" dans la session de secours) > relance le Terminal > colle la commande > exécute-la
  • la commande recrée un descripteur de partition dans la table GPT > reprenant l'exact alignement de blocs (au bloc près) de la précédente > assigne un type correspondant à l'UUID universel du type "Apple_APFS" = 7C3457EF-0000-11AA-AA11-00306543ECAC > récupère le rang2 toujours vacant > avec le disk0 en cible

Si tout a été comme prévu rationnellement > le Conteneur apfs a dû être ré-exporté instantanément (avec tous ses volumes) par le kernel > depuis la partition recréée disk0s2. Donc passe la commande test :
Bloc de code:
diskutil list

  • et poste le tableau.
 
Et hop (pour l'instant aucune erreur ...) :

Bloc de code:
-bash-3.2# diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk21        200.0 GB   disk0s2
   3:       Microsoft Basic Data BOOTCAMP                50.3 GB    disk0s3
   4:           Windows Recovery                         471.9 MB   disk0s4
 
Cette mention -->
Bloc de code:
   2:                 Apple_APFS Container disk21        200.0 GB   disk0s2

  • montre que la partition est de nouveau identifiée comme de type APFS > avec un magasin de stockage physique Physical Store exportant un Conteneur disk21

Repasse la commande :
Bloc de code:
diskutil list

  • et va chercher tout en bas de tableau l'affichage du Conteneur exporté disk21 --> poste ce sous-tableau ici qui devrait montrer les 4 volumes apfs.
 
Il y a effectivement le détail du container avec les 4 partitions :

Bloc de code:
/dev/disk21 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +200.0 GB   disk21
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            172.0 GB   disk21s1
   2:                APFS Volume Preboot                 22.5 MB    disk21s2
   3:                APFS Volume Recovery                517.8 MB   disk21s3
   4:                APFS Volume VM                      1.1 GB     disk21s4
 
En guise de vérification > passe la commande :
Bloc de code:
bless --info /Volumes/Mac*

  • la commande affiche le chemin de démarrage inscrit sur l'en-tête du volume Macintosh HD

Poste ce tableau > histoire de vérifier si le volume est bien actuellement démarrable.
 
En fait le volume ne s'appelle pas Mac* ...

Bloc de code:
-bash-3.2# bless --info /Volumes/OS\ X\ Base\ System
finderinfo[0]:     34 => Blessed System Folder is /System/Library/CoreServices
finderinfo[1]:  45165 => Blessed System File is /System/Library/CoreServices/boot.efi
finderinfo[2]:      2 => 1st dir in open-folder list is /
finderinfo[3]:      0 => No alternate OS blessed file/folder
finderinfo[4]:      0 => Unused field unset
finderinfo[5]:     34 => OS X blessed folder is /System/Library/CoreServices
64-bit VSDB volume id:  0xB12555E4A5E9623E
 
Non ! non ! le volume OS X Base System est le volume monté d'une image-disque BaseSystem.dmg > téléchargée en RAM depuis le serveur du Mac App Store > et recelant l'OS de secours 10.13 actuellement démarré.

Voici ton volume macOS -->
Bloc de code:
   1:                APFS Volume Macintosh HD            172.0 GB   disk21s1

  • il est membre (avec 3 autres) du Conteneur apfs qui a été réexporté.

Donc repasse la commande :
Bloc de code:
bless --info /Volumes/Mac*

  • qui adresse bien le bon volume Macintosh HD (avec l'astérique * jouant le rôle d'abréviation de saisie)

Poste le tableau retourné.
 
La commande ne renvoie rien et si je vais dans /Volumes, il n'y a pas de "Macintosh HD" ...

Bloc de code:
-bash-3.2# bless --info /Volumes/Mac*
No mount point for /Volumes/Mac*
Can't get mount point for /Volumes/Mac*
 
Tu avais peut-être activé FileVault -->

  • dans la fenêtre des 4 Utilitaires macOS > lance l'Utilitaire de Disque > sélectionne le volume Macintosh HD qui doit être grisé (= non monté) > bouton : "Monter" > ton mot-de-passe d'ouverture de session dans le panneau qui le demande --> le volume Macintosh HD doit être affiché en noir plein, si remonté

=> est-ce le cas ?
 
Bon, le disque n'était pas monté, mais je n'avais pas installé FireVault, du coup, pas besoin de mdp pour le monter.

Bloc de code:
-bash-3.2# bless --info /Volumes/Macintosh\ HD/
        1915 => Blessed System File is <Preboot>/24C82FD7-B2C1-3E4E-AC74-86EC3AEA6133/System/Library/CoreServices/boot.efi
          29 => Blessed System Folder is <Preboot>/24C82FD7-B2C1-3E4E-AC74-86EC3AEA6133/System/Library/CoreServices
The blessed volume in this APFS container is "/Volumes/Macintosh HD"
-bash-3.2#
 
Parfait !

Allez ! les finitions --> passe les commandes :
Bloc de code:
kextcache -u /Volumes/Mac*
diskutil ap updatePreboot disk21s1

  • la 1ère met à jour le cache prelinkedkernel > chargé par le boot_loader boot.efi au démarrage ; elle passe sans commentaire
  • la 2è met à jour les informations de prédémarrage du volume Preboot > chargées par l'EFI en prédémarrage ; elle passe avec un affichage kilométrique

Cela fait --> va à : Menu  > Disque de démarrage > sélectionne Macintosh HD > redémarre dessus -->

  • je te souhaite une bonne ré-ouverture de session dans High Sierra.
 
Merci beaucoup pour ton aide et surtout ta pédagogie qui m'a permis de progresser tout en résolvant mon problème.

Là j'écris ce message depuis ma session OSX High Sierra !

Juste une question, pour avoir autant de pédagogie et ces compétences sur OSX, quel est ton parcours ?