# Problème de format de la partition bootcamp



## Lagdaril (14 Février 2019)

Bonjour,

J'ai vu un problème analogue à celui que je rencontre, mais je ne retrouve pas le message.
Voici donc ce problème :
Je lance Bootcamp et tout se passe bien, le disque destiné à bootcamp est formatté, la partition est créée, le mac redémarre sur le DVD d’installation Windows 10, et là, patatras, impossible de faire l'installation car la partition Bootcamp n'a pas le bon format (apparemment, il faudrait NFTS).

L'option "formatter" étant disponible, je la lance et ça mouline. a la fin, Bootcamp perd son nom, mais je ne peux toujours pas lancer l'installation de W10 : "le style de la partition est GPT"
Une idée pour résoudre cela ?


----------



## Locke (15 Février 2019)

Lagdaril a dit:


> Une idée pour résoudre cela ?


Vu la description tu dois avoir un vieux Mac pour utiliser un DVD. Que dis /A propos de ce Mac ? Une copie écran serait la bienvenue.

Le processus d'Assistant Boot Camp est toujours le même, *téléchargement des pilotes/drivers dans un support USB, clé ou disque dur, création d'une partition temporaire en FAT32 avec une demande de la taille pour une partition Windows. Puis Assistant Boot Camp passe la main à l'installateur de Windows, à un moment donné il faut en effet formater en NTFS la partition qui porte le nom de BOOTCAMP _(en majuscules)_ en sélectionnant l'option Formater...





...un clic sur Sauivant, la partition ayant pour nom BOOTCAMP aura changée de nom, on ne s'en préoccupe pas et on continue l'installation qui ira jusqu'au bout.

Dans le cas _(ton cas)_ d'utilisation d'un DVD, il ne faut surtout pas utiliser un DVD-RW, donc réinscriptible. Comme il sera non finalisé l'installateur de Windows va cafouiller. Il faut que ce DVD soit une copie Disk-at-Once, soit sans interruption en vitesse lente. De plus cette copie doit être faite depuis un vrai PC et vérifier qu'il soit bootable sous PC, sinon Assistant Boot Camp ne le verra pas.

Par curiosité, relances Assistant Boot Camp et fais la suppression de la partition Windows. Puis tu lances le Terminal et tu fais un Copier/Coller de cette commande...

```
diskutil list
```
...tu valides avec la touche Entrée et tu donnes le résultat.

Petit rappel...


> Pour diffuser un rapport EtreCheck ou un retour de commandes via le Terminal dans les forums, dans votre réponse, un clic sur cette icône ⊞, sélectionnez les Balises </> Code, dans la fenêtre qui s’ouvrira faites un Copier/Coller du rapport et/ou du résultat du Terminal, un clic sur Insérer et validez votre réponse.








Attention : il ne faut jamais utiliser Utilitaire de disque pour supprimer une partition Windows, sous peine de devoir passer par le Terminal pour faire des réparations.

*Si Assistant Boot Camp ne propose pas de support USB, clé ou disque dur, le téléchargement se fera automatiquement dans une partition virtuelle qui sera supprimée une fois l'installation de Windows entièrement terminée.


----------



## Lagdaril (15 Février 2019)

Locke a dit:


> Vu la description tu dois avoir un vieux Mac pour utiliser un DVD. Que dis /A propos de ce Mac ? Une copie écran serait la bienvenue.
> 
> Le processus d'Assistant Boot Camp est toujours le même, *téléchargement des pilotes/drivers dans un support USB, clé ou disque dur, création d'une partition temporaire en FAT32 avec une demande de la taille pour une partition Windows. Puis Assistant Boot Camp passe la main à l'installateur de Windows, à un moment donné il faut en effet formater en NTFS la partition qui porte le nom de BOOTCAMP _(en majuscules)_ en sélectionnant l'option Formater...
> 
> ...




_____________________________________________________________________________________________________
Bonjour et merci pour cette réaction rapide.

Tout d'abord, mon mac est un MacPro 5.1 et j'ai dû bidouiller le fichier info.plist pour 'autoriser à se lancer. Bootcamp ne me propse pas l'option clé USB (j'en ai une) mais réclame un DVD
En fait, le principal problème n'est pas la partition en MS-DOS FAT qui ressort de la première phase bootcamp, mais le fait que le disque SSD interne est en GUID après sortie de bootcamp et qu'il faudrait qu'il soit en GPT. Le reformater de MS-DOS en NFTS ne change donc rien.
Je vais relancer Bootcamp et te communiquer les renseignements demandés


----------



## Locke (15 Février 2019)

Lagdaril a dit:


> Tout d'abord, mon mac est un MacPro 5.1


C'est bien ce qu'il faut mentionner depuis le début, car c'est très différent, mais je ne te serais pas d'en grand secours, je n'ai jamais essayé sur un Mac Pro.


Lagdaril a dit:


> et j'ai dû bidouiller le fichier info.plist


C'est parfaitement inutile et ça n'a marché que très peu temps et uniquement que sur une gamme de matériel _(en fait l'année et la version d'Assistant Boot Camp)_ et jamais avec un Mac Pro.


Lagdaril a dit:


> En fait, le principal problème n'est pas la partition en MS-DOS FAT qui ressort de la première phase bootcamp, mais le fait que le disque SSD interne est en GUID après sortie de bootcamp


Ca, c'est un protocole immuable d'Assistant Boot Camp qui préparera toujours une partition temporaire en FAT32 dans une partition en Table de partition GUID.


Lagdaril a dit:


> Le reformater de MS-DOS en NFTS ne change donc rien.


Eh non, dans un disque dur interne, il faut impérativement que macOS possède sa partition de base en Table de partition GUID, car c'est le boot EFI qui cherchera au démarrage la partition macOS et/ou la partition Windows en NTFS.

Il y a eu en effet un membre qui a rencontré un problème similaire et si je me souviens bien c'est macomaniac qui a trouvé une solution en faisant faire une table de partition hybride. Reste à attendre qu'il fasse un petit passage par ici.


----------



## Lagdaril (15 Février 2019)

Locke a dit:


> C'est bien ce qu'il faut mentionner depuis le début, car c'est très différent, mais je ne te serais pas d'en grand secours, je n'ai jamais essayé sur un Mac Pro.
> 
> C'est parfaitement inutile et ça n'a marché que très peu temps et uniquement que sur une gamme de matériel _(en fait l'année et la version d'Assistant Boot Camp)_ et jamais avec un Mac Pro.
> 
> ...


Bonsoir,
Voici néanmoins les écrans qui s'affichent quand l'installateur Windows se lance :
1- Avant reformattage de la partition bootcamp


2- Après reformattage en NFTS 



J'ai fait un lapsus précédemment : le schéma de partition fourni par Bootcamp est en GUID (GPT) mais l'installeur Windows n'en veut pas et réclame du MBR .
En quoi est-ce différent sur un Mac "normal" ? L'installeur Windows accepte-t-il le schéma GUID ?


----------



## macomaniac (16 Février 2019)

Bonjour *Lagdaril
*
Voici quelques éléments d'explication -->

- la version de Windows qu'il s'agissait d'installer sur les vieux Mac était Windows-7. Or cet OS boote en mode dit "*Legacy*" : par l'action d'un programme interne de type *BIOS* > qui a besoin d'accéder au disque de destination par une table de partition de type *MBR* (*M*aster_*B*oot_*R*ecord) > afin d'y lire le descripteur de la partition dédiée à Windows > et de pouvoir exécuter son *boot_loader* (démarreur d'OS) "old_school" = *bootmgr*.​
- or sur un Mac - même déjà les vieux Mac de type Intel - le programme interne est de type *EFI* et pas *BIOS* > et la table de partition des disques est de type *GPT* (*G*UID_*P*artition_*T*able) et pas *MBR* > le *boot_loader* (démarreur d'OS X - macOS) étant un *boot.efi*. Le problème posé aux ingénieurs de la  consistait donc à résoudre une impossibilité : faire booter un OS Windows-7 *Legacy* (*BIOS* > *MBR* > *bootmgr*) sur une base Mac incompatible (*EFI* > *GPT* > *boot.efi*).​
- la solution trouvée a été un modèle d'ingéniosité digne du concours Lépine. La table *GPT* des disques Mac étant portée par les blocs *1* à *32* --> le bloc *0* (ou 1er bloc) a été réservé d'office à une table alternative *MBR*. Par défaut > une *MBR* "bidon" dite *PMBR* (*P*rotective_*MBR*) qui recelait un unique descripteur assimilant l'entièreté du disque à une partition de type *EFI* (*hex code* : *0xEE*). Mais ! une implémentation logicielle faisait que > dès qu'une partition se trouvait créée sur le disque dans un type Windows (type *Microsoft_Basic_Data*) --> alors automatiquement la table alternative *PMBR* du bloc *0* => se trouvait convertie à une *HMBR* (*H*ybrid_*MBR*) : table décrivant cette fois-ci au plus 3 partitions sur le disque dont les localisations se trouvaient empruntées à la *GPT* principale. Ainsi > la partition *BOOTCAMP* > dès sa création préparatoire avec un volume au format *FAT-32* --> se trouvait-elle automatiquement désignée par un descripteur de la *HMBR*.​
- à partir de là > une implémentation de l'*EFI* (programme interne du Mac) --> la rendait capable d'émuler à la volée un *BIOS* dans le temps du boot > si une table *HMBR* se trouvait détectée sur le disque du Mac. Ainsi > le schéma de boot de type *Legacy* requis par Windows 7 se trouvait reconstitué artificiellement sur une base Mac : *BIOS* émulé de l'*EFI* > table *HMBR* du bloc *0* > *boot_loader* "old_school" : *bootmgr*.​
=> cette prouesse d'ingéniérie informatique a fait les beaux jours de Windows sur Mac > tant que Windows n'est pas passé (avec la version 10) au schéma : *EFI* > *GPT* > *boot_loader* : *bootmgr.efi*. Sans que les utilisateurs de Mac ne sachent jamais rien de cette sophistication de coulisses assez affolante.

----------


----------



## macomaniac (16 Février 2019)

Voyons ton cas à présent dans la lumière des explications précédentes -->

- tu as un vieux Mac : Mac Pro 5.1 = 2010. Mac qui était totalement adapté au mécanisme du boot *Legacy* artificiel de Windows 7 que j'ai décrit. Alors qu'est-ce qui coince ?​
- tu as installé l'OS moderne High Sierra. Peu importe qu'il soit installé en format *jhfs*+ (HDD) ou *apfs* (SDD) : ça ne change rien. Or à partir de l'OS Sierra 10.12 inclus --> le mécanisme logiciel effectuant une conversion automatique de la table *PMBR* du bloc *0* du disque => à une *HMBR* a été abandonné comme rendu obsolète par la contemporanéité de Windows 10. Tu as beau créer une partition préparatoire de type Windows (*Microsoft_Basic_Data* contenant un système de fichiers *FAT-32*) --> ça ne change rien. La *PMBR* du bloc *0* reste une *PMBR* : une table bidon assimilant l'entièreté du disque à une pseudo partition *EFI* de type *0xEE*. Càd. ne décrivant pas en mode *MBR* la partition *BOOTCAMP*.​
- quand tu lances l'installation de Windows 10 après démarrage sur ton DVD > ton problème est que > ayant un vieux Mac --> tu ne peux installer Windows qu'en mode *Legacy* - même s'il s'agit de Windows 10. Une implémentation de cet OS permet de l'installer et de le démarrer marginalement en mode *Legacy* (sur les vieux PC ayant encore un *BIOS*). Donc ton Mac aussi impose une installation de Windows 10 en mode *Legacy* : *BIOS* émulé de l'*EFI *> lecture d'une *HMBR* sur le bloc *0* > exécution d'un *boot_loader* rétrograde de type *bootmgr*.​
- or sur le bloc *0* de ton disque > le *BIOS* émulé de l'*EFI* ne rencontre qu'une table bidon : une *PMBR* à la place de la *HMBR* attendue. La seule table fonctionnelle comme adressage de partitions est donc la *GPT*. Donc le programme d'installation de Windows 10 qui est l'alternative *Legacy* adaptée à ton vieux Mac déclare : la partition qu'on me désigne comme cible d'installation (partition *BOOTCAMP*) relève pour sa description d'une table *GPT* que le *BIOS* (émulé) ne peut pas lire --> il faut une *HMBR* sur le bloc *0* qui sache lui décrire cette partition en mode *MBR* > mais cette table est absente.​
=> un exécutable de tierce partie dû à Roderick Smith (le développeur de rEFInd) = *gdisk* (installable dans High Sierra) --> est seul capable de convertir la *PMBR* du bloc *0* de ton disque en *HMBR* de type "old_school" > en lui faisant décrire la partition *BOOTCAMP* en mode *MBR*. Càd. en jetant au programme d'installation *Legacy* de Windows 10 l'os qu'il attend. On peut si tu veux effectuer cette opération via le *terminal*.


----------



## Lagdaril (16 Février 2019)

Bonjour Macomaniac,

Tout d'abord, merci beaucoup de ton aide très détaillée.
Je suis actuellement sous Mojave (carte graphique AMD Radeon 7800)
Je t'écris à partir d'une installation de Windows 10 que j'ai réussi tant bien que mal à réaliser :
- J'ai converti  ma partition GUID en MBR à l'aide d'un logiciel PC sur Parallels Desktop (en sortant le SSD)
- je l'ai remonté en interne, la partition EFI et apparue séparée de la partition bootcamp
- j'ai lancé le DVD d'installation Windows et il a fonctionné jusqu'au bout
- j'ai récupéré les drivers bootcamp grâce au logiciel brigadier.exe, et du coup, tout fonctionne (notamment le son qui ne passait pas)
- j'ai juste la partition EFI dont je ne sais que faire.
Je veux bien tenter ta solution à partir du terminal Mac (je le ferai sur un autre disque dur HDD)..
Merci encore


----------



## macomaniac (16 Février 2019)

Tu as ton volume de macOS sur le même disque que celui de Windows ou sur un autre ?


----------



## Lagdaril (16 Février 2019)

J'ai Mojave sur un SSD en AFPS et Windows 10 sur un autre SSD interne SATA lui aussi


----------



## macomaniac (16 Février 2019)

Ah ! je comprends alors. Eh bien ! puisque ça fonctionne : que demander d'autre ?


----------



## Lagdaril (16 Février 2019)

Lagdaril a dit:


> J'ai Mojave sur un SSD en AFPS et Windows 10 sur un autre SSD interne SATA lui aussi


----------



## Lagdaril (16 Février 2019)

Il y a juste quelques détails qui me semblent clocher :

1- A quoi sert la partition EFI qui apparait maintenant à part et est vide ?
2 - La partition Bootcamp n'apparait pas dans les préférences système "Disque de démarrage"
3 - Parallels Desktop refuse de monter cette partition en VM


----------



## macomaniac (16 Février 2019)

Je vois que sur ton *disk2* (où tu as le volume *Bootcamp*) --> tu as carrément un table de partition *MBR* (désignée comme *FDisk_partition_scheme*) et zéro *GPT*. Alors forcément tu n'as plus eu de message d'erreur à l'installation (comme quoi la partition *Bootcamp* était de type *GPT*) > puisqu'il n'y a plus de *GPT* sur ce disque.

Il est possible que la partition *EFI* recréée au rang n°*1* (alors qu'il n'y a pas de table *GPT*) puisse jouer un rôle. À moins qu'elle n'ait été créée accidentellement à l'installation. Ce qui te gêne > c'est que son volume *EFI* soit monté ?


----------



## Lagdaril (16 Février 2019)

macomaniac a dit:


> Je vois que sur ton *disk2* (où tu as le volume *Bootcamp*) --> tu as carrément un table de partition *MBR* (désignée comme *FDisk_partition_scheme*) et zéro *GPT*. Alors forcément tu n'as plus eu de message d'erreur à l'installation (comme quoi la partition *Bootcamp* était de type *GPT*) > puisqu'il n'y a plus de *GPT* sur ce disque.
> Cela ne me gène pas vraiment, c'est plutôt esthétique que fonctionnel. Mais j'ai peur de tout casser si je joue sur les partitions...


----------



## Lagdaril (16 Février 2019)

Comme tu dis, ça fonctionne et c'est déjà bien. Tant pis pour les problèmes mineurs.
J'ai trouvé le fil de discussion avec utilisation de fdisk 
https://forums.macg.co/threads/installation-windows-impossible-formatage-gpt-erreur.1305497/page-2
J'essaierai peut-être cette solution un de ces jours.


----------



## macomaniac (16 Février 2019)

Avec la table *MBR* seule sur le *disk2* --> je ne peux pas t'aider à des manipulations de types de partitions.

Ce qui est possible > c'est d'inscrire une instruction dans un fichier de l'OS pour que le volume *EFI* ne soit pas monté par défaut : ainsi > il serait préservé tel quel mais tu ne le verrais pas...


----------



## Lagdaril (16 Février 2019)

Que faut-il faire pour cela ?


----------



## macomaniac (16 Février 2019)

D'abord passe la commande :

```
csrutil status
```


qui affiche le statut du *SIP* (protocole de sécurisation)

Poste le retour. Fais-le en copier-coller > le coller dans une fenêtre de code par le procédé suivant -->

dans la page de ce fil de MacGé > presse le bouton 
	

	
	
		
		

		
		
	


	




 ici : 
	

	
	
		
		

		
		
	


	



menu  : *</> Code* > par *⌘V* colle dans la fenêtre *Code* > presse le bouton *Insérer* (ce procédé permet un affichage fenêtré qui économise l'espace de page en respectant la mise en forme des tableaux du «Terminal» --> d'où une plus grande lisibilité)

Note : l'activation du *SIP* bloquerait les opérations.


----------



## Lagdaril (16 Février 2019)

```
Last login: Sat Feb 16 16:10:14 on ttys000
You have mail.
MacPro:~ algaillard$ csrutil status
System Integrity Protection status: enabled.
MacPro:~ algaillard$
```


----------



## macomaniac (16 Février 2019)

Le *SIP* est activé.

Pour désactiver le *SIP* > redémarre > les 2 touches *⌘R* (*cmd R*) tenues pressées de l'écran noir => à la  = démarrage sur l'OS de secours. Tu obtiens un écran affichant une fenêtre de 4 *Utilitaires macOS*. Va à la barre de menus supérieure de l'écran > *Menu Utilitaires* > sous-menu : *Terminal*.

Lance-le et passe la commande :

```
csrutil disable
```


qui désactive le *SIP*

Cela fait > quitte le Terminal > va à : *Menu*  > *Disque de démarrage* > sélectionne *MacPro* > redémarre dessus.

=> préviens quand tu seras de retour dans ta session...


----------



## Lagdaril (16 Février 2019)

C'est fait : le terminal affiche SIP status disabled


----------



## macomaniac (16 Février 2019)

Alors passe la commande (copier-coller) :

```
sudo ls -al /etc/fstab
```


à validation une demande de *password* s'affiche (commande *sudo*) --> tape ton mot-de-passe de session admin en aveugle - aucun caractère ne se montrant à la frappe - et revalide

la commande affiche une ligne d'autorisations si un fichier intitulé *fstab* existe déjà dans le répertoire */etc* ; sinon un "*no such file or directory*"

=> poste le retour (dans une fenêtre de code toujours - inutile de me citer).


----------



## Lagdaril (16 Février 2019)

le "quote" est par défaut...

```
System Integrity Protection status: disabled.
MacPro:~ algaillard$ sudo ls -al /etc/fstab
Password:
-rw-r--r--@ 1 root  wheel  183  5 déc 19:06 /etc/fstab
MacPro:~ algaillard$
```


----------



## macomaniac (16 Février 2019)

Le fichier existe donc déjà (il n'existe pas par défaut : c'est une création d'utilisateur).

Passe la commande :

```
sudo cat /etc/fstab
```


qui affiche le contenu du fichier

Poste le retour.


----------



## Lagdaril (16 Février 2019)

```
MacPro:~ algaillard$ sudo cat /etc/fstab
Password:
#
# Warning - this file should only be modified with vifs(8)
#
# Failure to do so is unsupported and may be destructive.
#
UUID=AEDACC1F-B070-3B30-9BA0-FB1049B2C876 none hfs rw,noautoMacPro:~ algaillard$
```


----------



## macomaniac (16 Février 2019)

Il y a donc déjà une instruction de non montage automatique concernant un volume dont l'*UUID* est : *AEDACC1F-B070-3B30-9BA0-FB1049B2C876*.

Il convient à présent de connaître l'*UUID *du volume *EFI* concerné. Passe encore commande préalable :

```
diskutil list
```


et poste le tableau --> histoire de voir s'il n'y aurait pas eu des permuations d'index de disques suite à ton redémarrage pour désactiver le *SIP*.


----------



## Lagdaril (16 Février 2019)

```
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk3         1000.0 GB  disk0s2

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *240.1 GB   disk1
   1:                 DOS_FAT_32 EFI                     209.7 MB   disk1s1
   2:               Windows_NTFS Bootcamp                239.8 GB   disk1s2

/dev/disk2 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *1.0 TB     disk2
   1:                  Apple_HFS HD2                     1.0 TB     disk2s1

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +1000.0 GB  disk3
                                 Physical Store disk0s2
   1:                APFS Volume MacPro                  433.7 GB   disk3s1
   2:                APFS Volume Preboot                 23.6 MB    disk3s2
   3:                APFS Volume Recovery                513.9 MB   disk3s3
   4:                APFS Volume VM                      20.5 KB    disk3s4

/dev/disk4 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *2.0 TB     disk4
   1:                  Apple_HFS SVG                     2.0 TB     disk4s1
```


----------



## macomaniac (16 Février 2019)

Hé ! hé ! --> c'est le *disk1* à présent (il faut toujours vérifier).

Passe la commande :

```
diskutil info disk1s1
```


qui affiche un tableau d'informations sur la partition *EFI* du *disk1* et son volume

Poste le retour.


----------



## Lagdaril (16 Février 2019)

```
MacPro:~ algaillard$ diskutil info disk1s1
   Device Identifier:         disk1s1
   Device Node:               /dev/disk1s1
   Whole:                     No
   Part of Whole:             disk1

   Volume Name:               EFI
   Mounted:                   Yes
   Mount Point:               /Volumes/EFI

   Partition Type:            DOS_FAT_32
   File System Personality:   MS-DOS FAT32
   Type (Bundle):             msdos
   Name (User Visible):       MS-DOS (FAT32)

   OS Can Be Installed:       No
   Media Type:                Generic
   Protocol:                  SATA
   SMART Status:              Verified
   Volume UUID:               0E239BC6-F960-3107-89CF-1C97F78BB46B
   Partition Offset:          20480 Bytes (40 512-Byte-Device-Blocks)

   Disk Size:                 209.7 MB (209715200 Bytes) (exactly 409600 512-Byte-Units)
   Device Block Size:         512 Bytes

   Volume Total Space:        206.5 MB (206472192 Bytes) (exactly 403266 512-Byte-Units)
   Volume Used Space:         980.0 KB (979968 Bytes) (exactly 1914 512-Byte-Units) (0.5%)
   Volume Free Space:         205.5 MB (205492224 Bytes) (exactly 401352 512-Byte-Units) (99.5%)
   Allocation Block Size:     512 Bytes

   Read-Only Media:           No
   Read-Only Volume:          No

   Device Location:           Internal
   Removable Media:           Fixed

   Solid State:               Yes
   Hardware AES Support:      No
   Device Location:           "Bay 1"
```


----------



## macomaniac (16 Février 2019)

Voici la réponse :

```
Volume UUID:               0E239BC6-F960-3107-89CF-1C97F78BB46B
```


À présent > je me demande si le fichier *fstab* en place va s'avérer malléable à une commande d'écriture directe. Passe la commande (copier-coller) :


```
sudo echo 'UUID=0E239BC6-F960-3107-89CF-1C97F78BB46B none msdos rw,noauto' >> /etc/fstab ; sudo cat /etc/fstab
```


la commande inscrit une instruction de non montage du volume *EFI* dans le fichier */etc/fstab* > à la ligne en-dessous de la 1ère instruction ; puis affiche le contenu du fichier

Poste l'affichage retourné.


----------



## Lagdaril (16 Février 2019)

```
-bash: /etc/fstab: Permission denied
#
# Warning - this file should only be modified with vifs(8)
#
# Failure to do so is unsupported and may be destructive.
#
UUID=AEDACC1F-B070-3B30-9BA0-FB1049B2C876 none hfs rw,noautoMacPro:~ algaillard$
```


----------



## macomaniac (16 Février 2019)

Il ne s'est rien passé. Cette inscription à la fin de l'instruction déjà en place :

```
MacPro:~ algaillard$
```


invalide complètement l'instruction qui ne peut pas fonctionner.

On va s'y prendre autrement. Passe la commande (copie-la bien jusqu'au bout) :

```
touch ~/Desktop/fstab ; echo 'UUID=0E239BC6-F960-3107-89CF-1C97F78BB46B none msdos rw,noauto' > ~/Desktop/fstab ; cat ~/Desktop/fstab
```


la commande crée un fichier *fstab* sur ton Bureau > inscrit l'instruction de non montage du volume *EFI* > affiche le contenu du *fstab* du Bureau

Poste l'affichage retourné.


----------



## Lagdaril (16 Février 2019)

UUID=0E239BC6-F960-3107-89CF-1C97F78BB46B none msdos rw,noauto

Bizarre, c'est la bonne


----------



## macomaniac (16 Février 2019)

On peut si tu sais à quel volume il s'adresse.

Passe la commande :

```
echo 'UUID=AEDACC1F-B070-3B30-9BA0-FB1049B2C876 none hfs rw,noauto' >> ~/Desktop/fstab ; cat ~/Desktop/fstab
```


le double *>>* fait que la nouvelle instruction va s'ajouter à la 1ère une ligne en-dessous comme il convient

Poste l'affichage retourné.


----------



## Lagdaril (16 Février 2019)

```
MacPro:~ algaillard$ echo 'UUID=AEDACC1F-B070-3B30-9BA0-FB1049B2C876 none hfs rw,noauto' >> ~/Desktop/fstab ; cat ~/Desktop/fstab
UUID=0E239BC6-F960-3107-89CF-1C97F78BB46B none msdos rw,noauto
UUID=AEDACC1F-B070-3B30-9BA0-FB1049B2C876 none hfs rw,noauto
MacPro:~ algaillard$
```


----------



## macomaniac (16 Février 2019)

Ça marche.

À présent on ne va pas prendre de gants. Enchaîne les commandes (l'une après l'autre) :

```
sudo rm -f /etc/fstab
sudo cp ~/Desktop/fstab /etc
sudo chown 0:0 /etc/fstab
sudo cat /etc/fstab
```


la 1ère supprime le fichier *fstab* de */etc* (contenant une instruction invalide d'ailleurs)

la 2è copie le fichier *fstab* du Bureau => dans */etc* où il va remplacer le *fstab* supprimé

la 3è restaure les accédants au fichier */etc/fstab* à : *user=root* & *primary group=wheel*

la 4è lit le contenu du fichier */etc/fstab*

Poste le retour de la 4è.


----------



## Lagdaril (16 Février 2019)

C'est bon !

```
MacPro:~ algaillard$ sudo cat /etc/fstab
#
# Warning - this file should only be modified with vifs(8)
#
# Failure to do so is unsupported and may be destructive.
#
UUID=0E239BC6-F960-3107-89CF-1C97F78BB46B none msdos rw,noauto
UUID=AEDACC1F-B070-3B30-9BA0-FB1049B2C876 none hfs rw,noauto
MacPro:~ algaillard$
```


----------



## macomaniac (16 Février 2019)

Le fichier attendu est en place dans */etc*.

Tu n'as qu'à redémarrer une fois --> et dire si le volume *EFI* (du disque de *Bootcamp*) ne s'affiche plus une fois ta session réouverte... Voire si l'autre instruction n'a pas un effet indésirable...


----------



## Lagdaril (16 Février 2019)

C'est fait et c'est bon, EFI ne se monte plus au démarrage.
Ouf !
J'aurais beaucoup appris aujourd'hui encore.
Merci de tout ce temps passé.


----------



## macomaniac (16 Février 2019)

Content pour toi ! 

- un petit succès tactique...​


----------



## Lagdaril (16 Février 2019)

Je testerais quand même un jour la solution que tu as donnée a tibochamp en juin 2018 avec gdisk
Au revoir et merci encore.


----------



## spirius (11 Mai 2019)

Bon c’était le chiffrement du disque dur pour le premier échec et ensuite avec bootcamp c’était une clé USB restée dans le port malgré l’avoir virtuellement éjectée…
Reste une question : comment faire en sorte que le boot soit lancée sur macos automatiquement plutôt que sur W10?


----------



## macomaniac (11 Mai 2019)

Dans ta session de macOS > tu vas à : *Menu*  > *Préférences Système* > *Disque de démarrage* -->

- déverrouille le cadenas > sélectionne *Macintosh HD* > referme le cadenas > quitte les *Préférences Système*​
=> cette action inscrit en *NVRAM* une préférence de démarrage automatique sur *Macintosh HD*. Donc redémarrer sans option au clavier --> fait démarrer sur le volume de macOS.


----------



## spirius (11 Mai 2019)

Super, merci! C’est bon pour moi!


----------

