# Bootcamp non présent au démarrage (Alt)



## turbine38 (24 Août 2016)

Bonjour a tous,

Hier, alors que ma partition bootcamp fonctionnait depuis un an environ, j'ai voulu augmenter ça partition, en suivant cette précedure  . La, pim ! Au redémarrage plus de partition affiché sur le boot , juste celle de OSX , recorvery et mon time machine .

J'ai eu beau cherché sur le forum mais les seuls sujets qui ressemblait en mon soucis , c'est celui d'avoir installé un lecteur pour disque format NTFS . Ca n'est pas mon cas :/ .

Merci à tous pour votre aide .
Bonne journée a tous

*Edit : pas la bonne section, c'est un problème avec Boot Camp, je déplace.*


----------



## daffyb (24 Août 2016)

un début de réponse :
https://discussions.apple.com/thread/7412535


----------



## turbine38 (24 Août 2016)

daffyb a dit:


> un début de réponse :
> https://discussions.apple.com/thread/7412535


Merci pour cet réponse, mais suis une quiche en Anglais . Auriez vous une solutions plus local  ?
Merci


----------



## daffyb (25 Août 2016)

on va attendre @macomaniac


----------



## macomaniac (25 Août 2016)

daffyb a dit:


> on va attendre @macomaniac


lequel (c'est bien connu) affectionne Windows dont il est un expert notoire alors qu'il ne s'en est jamais servi de sa vie occasion pour la théorie de montrer qu'elle peut se substituer à la pratique...

Bonjour *turbine *_qui che_... rche une _solution plus local_ (loquace ?)






Le tuto de _Bob Dobolino_ que tu as suivi paraît avoir eu des effets controversés sur ses utilisateurs, d'après les messages publiés en retour : attestation de succès de l'opération pour les uns vs avération d'une partition *BOOTCAMP* désormais indémarrable pour d'autres. Tu fais malheureusement partie de ce deuxième lot.

L'intéressante page de discussions Apple citée par *daffyb*  confronte une espèce d'énergumène (l'auteur du fil qui, après avoir perdu son *BOOTCAMP* démarrable, s'était figuré améliorer la situation en se créant un Fusion Drive associant son disque interne à une carte externe 
	

	
	
		
		

		
		
	


	




) et un interlocuteur expert qui lui fait recréer une *hybrid_MBR* sur le secteur *MBR* de boot de son disque (bloc *0*) grâce à l'utilitaire *gdisk* de _Roderick Smith_ > manifestement avec succès au final.

Mais pour ne pas mettre la charrue avant les bœufs > le mieux serait d'avoir une idée exacte de la disposition actuelle des partitions sur le disque de ton Mac. Pour cela va à : _Applications_ > _Utilitaires_ > lance le «Terminal» > qui t'affiche une fenêtre de traitement de texte basique, dans laquelle tu peux passer des commandes en mode texte.

Saisis la commande :

```
diskutil list
```
 et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> cette commande appelle l'utilitaire *diskutil* (*disk*_*util*ity : le même que pilote graphiquement l'«Utilitaire de Disque») avec le verbe *list* (lister) --> en retour, tu vas voir s'afficher le tableau des partitions du disque de ton Mac (et de tout disque attaché à ton Mac en sus) selon les paramètres de format > nom > taille > device (appareil logique).

Peux-tu sélectionner l'ensemble de ce tableau au pointeur > par *⌘C* copier ta sélection dans le presse-papier > par *⌘V* la coller ici en réponse ?​


----------



## litobar71 (25 Août 2016)

daffyb a dit:


> on va attendre @macomaniac








 n'est pas au chômage (sur MacGé) ces temps-ci, il turbine à donf palsambleu!


----------



## turbine38 (26 Août 2016)

merci a tous pour votre aide et vos réponses. Voici le retour de l'opération macomaniac ;D 

Last login: Fri Aug 26 15:04:33 on ttys000
trubine-pc:~ trubine$ diskutil list
/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_HFS Macintosh HD            350.4 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:                  Apple_HFS Sans titre              37.7 GB    disk0s4
   5:       Microsoft Basic Data BOOTCAMP                111.0 GB   disk0s5
/dev/disk1 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS HDD_PERSO               999.9 GB   disk1s2
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:       Microsoft Basic Data HDD_MOVIES              1000.0 GB  disk2s2
/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk3
   1:                        EFI EFI                     209.7 MB   disk3s1
   2:                  Apple_HFS Time Machine            499.8 GB   disk3s2
trubine-pc:~ trubine$ 

Merci encore


----------



## macomaniac (26 Août 2016)

*turbine* (ou *trubine* ?)

État des lieux​
Si j'isole le tableau qui décrit le partitionnement de ton disque interne de 500 Go > voici ce qui apparaît :


```
/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_HFS Macintosh HD   350.4 GB    disk0s2
3:            Apple_Boot Recovery HD    650.0 MB    disk0s3
4:             Apple_HFS Sans titre      37.7 GB    disk0s4
5:  Microsoft Basic Data BOOTCAMP       111.0 GB    disk0s5
```

Comme tu le peux le remarquer > tu as en tête de partitionnement la triplette classique d'un disque sur lequel OS X est installé : la partition *ESP* (*E*FI *S*ystem *P*artition) de 209 Mo qui est le départ régulier d'une *GPT* (*G*UID *P*artition *T*able) > la partition *Macintosh HD* de 350 Go (chez toi) où réside OS X > la partition *Recovery HD* de 650 Mo où réside le Système de récupération.

En-dessous de cette triplette réglementaire > je constate non pas une partition comme attendu (la partition *BOOTCAMP* où réside Windows) > mais 2 partitions - en ce sens qu'une partition *Sans titre* de 37 Go est venue s'intercaler en 4è position en-dessous de la *Recovery HD* et précède désormais la partition *BOOTCAMP* de 111 Go de  Windows qui se trouve reléguée en 5è position dans la table *GPT*.

Interprétation : manifestement, tu as réduit la partition *Macintosh HD* n°*2* de 37 Go > ce qui a permis de créer la néo-partition *Sans titre* en n°*4* en-dessous de la *Recovery HD* (toujours préservée à sa place dans ce genre de manœuvres) > mais contrairement aux allégations du sieur _Bob Dobolino_ (avec un nom de pitre pareil : personnellement je serais méfié) le logiciel mis en œuvre sous Windows : «Mini Tool Partition Wizard» a été incapable d'agréer l'espace de cette partition n°*4 Sans titre* à la partition *BOOTCAMP* n°*5* (que cet agrandissement se puisse "par le haut" de la partition *BOOTCAMP* : ça me laisse sceptique - mais passons).

♤

Intermède herméneutique​
_Mézalors_ => pourquoi mon *BOOTCAMP* a-t-il le boot qui a fichu le camp ? Pour une obscure raison que je tente de remonter de son puits d'ombre :

L'espace d'un disque est logiquement distribué en *blocs* (de 512 octets de 8 bits chacun) - blocs constituant une série numérique linéaire de *0* à *n*.

Les blocs *0* à *32* de tout disque portant une *GPT* correspondent au *secteur de boot* de disque (ou : *secteur d'amorçage* par le *Programme Interne* du Mac ou *EFI*). Mais sur le disque d'un Mac Intel > ce secteur de boot est bicéphale (et pas monocéphale comme on le le figure couramment) :

- les blocs *1* à *32* supportent les fichiers de la *GPT* proprement dite : càd. les descripteurs logiques de l'espace du disque conforme à la norme *GUID*. Une redondance des écritures de ces *32* premiers blocs réside toujours sur les *32* derniers blocs du disque, qui constituent le *backup* (sauvegarde) de la *GPT*. Cette table de partition *GPT* écrite sur les *32* premiers blocs est la table principale.

- mais sur le bloc unique absolument initial qui est le bloc *0* résident les fichiers descripteurs d'une *MBR* : un table *M*aster *B*oot *R*ecord de type Windows. Sur les disques des PC > c'est toujours aussi sur le bloc *0* que réside la *MBR* ; le disque d'un Mac n'y fait pas exception et porte donc sur son bloc liminaire *0* une *MBR* qui précède la *GPT*. Cette table de partition *MBR* du bloc *0* est la table secondaire du disque d'un Mac (disque-Système tablé en *GPT*).​
Ce bref aperçu donné > montrant qu'il y a toujours sur le disque d'un Mac dualité de tables de partitions : *MBR* sur le bloc *0* + *GPT* sur les bloc *1-32* > il devient intéressant de scruter d'un peu plus près la table secondaire *MBR* du bloc *0*.

--------------------​
En quoi consiste-t-elle et pourquoi la retrouve-t-on sur le disque d'un Mac (contrairement à toute attente) ?

Régulièrement parlant : la table *MBR* résidant sur le bloc *0* du disque d'un Mac est une table conforme au type : "*Protective*" > c'est donc une « *Protective_MBR* ». Comme cet intitulé invite à le penser > sa présence avant la table *GPT* a pour fonction de "protéger" la table *GPT* principale contre les atteintes logiques que des programmes non Apple (= Windows) pourraient induire. Car pour ces programmes les descripteurs d'une *GPT* ne font pas sens > ce qui pourrait amener des tentatives d'effacement ou de reformatage logique pour approprier l'espace du disque d'une manière qui fasse sens en mode Windows.

C'est là qu'intervient la "*Protective_MBR*" du bloc *0* : elle décrit d'une manière "compréhensible en mode Windows" l'espace du disque > avec une spécificité absolue du mode "*Protective*" : aucun sous-partitionnement de l'espace total du disque n'est représenté par les descripteurs de cette table "*Protective*" > mais l'espace total du disque est représenté comme constituant une seule et unique partition non-repartitionnable. Pour prendre une image : si le disque était comparé à la France > du point de vue *GPT* on aurait une carte géographique montrant le découpage de grandes régions administratives > du point de vue de la "*Protective_MBR*" on aurait une carte monolithique montrant l'espace national impartagé de l'État Français.

--------------------​
Que se passe-t-il alors lorsqu'il s'agit d'installer un OS non Apple en alternative d'OS X sur une partition du disque d'un Mac ? Il convient de modifier le statut de la *MBR* du bloc *0* pour que ses descripteurs représentent, dans le mode *MBR*, plusieurs partitions pré-constituées dans la *GPT* principale - ce, afin que l'installateur de Windows puisse "voir" la partition dédiée à Windows comme une partition localisée (de tel bloc à tel bloc), càd. en avoir une représentation logique selon le mode *MBR*. Sans quoi, il ne pourrait pas cibler l'espace d'installation de Windows de manière congruente avec le partitionnement *GPT*.

La "*Protective_MBR*" du bloc *0* est donc transformée en un autre mode de *MBR* : une "*Hybrid_MBR*" dans laquelle se trouve représentées au plus 3 partitions du disque. Ces partitions ne sont absolument pas créées en mode *MBR* > mais "échoées" (si je puis dire) à partir de partitions pré-définies dans la *GPT* principale. Il s'agit donc d'une redondance logique : les mêmes partitions prédéfinies dans la *GPT* se trouvent représentées en écho en mode *MBR*, ce dans leurs exactes limites de blocs.

Lors de la constitution de cet "*écho_MBR*" des partitions *GPT* dans la "*Hybrid_MBR*" > un *boot_flag* (indicateur de partition démarrable) se trouve apposé à chacune > ce qui fait en dernière instance que la partition d'accueil de Windows est vue comme démarrable.

♧

Interprétation du problème​
Si j'interromps ici mon effort herméneutique > on peut dire en résumé que l'intercalement d'une partition n°*4 Sans titre *de 37 Go dans la *GPT* a ruiné la mise en correspondance des partitions clés dans la table "*Hybrid_MBR*".

Supposons que dans cette *Hybrid_MBR* on avait : la partition *GPT1=HMBR1* (*EFI*) > la partition *GPT2=HMBR2* (*Macintosh HD*) > la partition *GPT4=HMBR3* (*BOOTCAMP* dans le dispositif primaire, où *BOOTCAMP = GPT4* interprétée par la *Hybrid_MBR* comme *HMBR3*).

Le décalement *GPT* dû à l'intercalaire *Sans titre* = *GPT4*, repoussant *BOOTCAMP* en *GPT5* > fait que, dans la *Hybrid_MBR* qui n'a absolument pas été mise-à-jour en écho > l'ancienne correspondance logique *GPT4=HMBR3* demeure : c'est donc la partition actuellement *Sans titre* n°*4* dans la *GPT* qui est représentée comme la n°*3* de la *HMBR* à la place de la *BOOTCAMP* décalée en n°*4*. Exit donc  *BOOTCAMP* qui n'est plus "vu" comme un volume démarrable.

♡

Opération de repartitionnement​
Plutôt que de laisser en place la partition inutile *Sans titre* de 37 Mo en position *GPT4* comme l'avait fait l'intervenant expert du fil des discussions Apple (parce que l'énergumène créateur du fil avait créé un Fusion Drive bloquant après sa boulette, comme pour embrouiller encore plus la situation) > je te propose, *turbine*, de la supprimer afin d'en réallouer l'espace à la partition d'origine la *GPT n°2 Macintosh HD*. Ce qui est parfaitement possible chez toi, vu la parfaite limpidité du tableau.

Tu relances donc le «Terminal» et :

*- a)* fais un copier-coller de la commande suppressive de la partition *GPT n°4 Sans titre* :

```
diskutil eraseVolume free NULL disk0s4
```
 et ↩︎ [si jamais, étant sous une version ancienne d'OS X, l'utilitaire *diskutil* te retournait un message du style :

```
Error: 2: POSIX reports: No such file or directory
```
 > sache que c'est un bogue qui prétend que la cible ne se trouve pas - pour la bonne raison que la commande vient d'effacer cette partition !]. Tu peux repasser après la commande un :

```
diskutil list
```
 qui devrait te montrer que la partition n° *4 Sans titre* n'est plus listée sur le disque.

*- b)* fais alors un copier-coller de la commande qui redimensionne la partition *GPT n°2 Macintosh HD* en lui faisant récupérer l'espace libéré de l'ancienne *Sans titre* :

```
diskutil resizeVolume disk0s2 0b
```
 > suite à quoi le tableau du nouveau partitionnement devrait t'être retourné, qui devrait ressembler à ceci :

```
/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_HFS Macintosh HD   388.2 GB    disk0s2
3:            Apple_Boot Recovery HD    650.0 MB    disk0s3
4:  Microsoft Basic Data BOOTCAMP       111.0 GB    disk0s4
```

=> comme tu peux le voir, la partition *BOOTCAMP* a récupéré sa position *GPT4* initiale > je te propose de re-démarrer ton Mac avec "_alt_" > histoire de vérifier si les conjectures logiques les plus élémentaires sont respectées par l'informatique : normalement, il devrait y avoir de nouveau congruence entre la distribution des partitions *GPT* et leur écho représentatif dans la *Hybrid_MBR* du bloc *0*, soit pour la partition qui nous intéresse : *BOOTCAMP GPT4=HMBR3*.

Si l'ordre des choses était aussi limpide qu'on le souhaite toujours (en imagination) > la partition *BOOTCAMP* devrait être "vue" de nouveau comme démarrable par le *boot_manager* de l'*EFI*...

Si ce n'est pas le cas (comme on peut toujours le craindre en informatique) > il faudra recourir à l'utilitaire *gdisk* de _Roderick Smith_ pour mettre à jour la table *Hybrid_MBR* du bloc *0* de ton disque.

♢​


----------

