Windows 7 sur El Capitan venant d'un PC

[Locke]

J'avais testé aussi la première commande qui ne marchait pas non plus chez moi sous Sierra.

Par contre, la deuxième fonctionne correctement.

 

[Membre supprimé 1060554]

Ah ! pardon > j'ai abrégé à GPT la valeur de l'option -layout dans ma saisie de ce fil > alors qu'il faut mentionner GPTSPUD pour que ce soit validé. Donc la commande oiginelle eût dû être :

hdiutil create -size 20g -type UDIF -layout GPTSPUD -fs jhfs+ -volname BROL Downloads/IMG.dmg

=> mais de toute façon on s'en fiche : c'est juste pour créer une image-disque volumineuse... afin de la supprimer ensuite via le mécanisme propre au panneau de Stockage (c'est la raison pour laquelle je l'ai fait créer dans le dossier des Téléchargements > parce que ce dernier est affiché directo dans les options de Passer en revue les fichiers...).

 

[Locke]

Cette fois, la commande est bonne.

 

[fousfous]

Avant:

Après:


Faudra m'expliquer ce qu'il s'est passé la :o
Y a le système qui a maigrit d'un coup!

 

[Membre supprimé 1060554]

Tu en es à 90 Go d'espace libre : 26 Go de libérable et donc 64 Go d'actuellement libre. Je sens qu'on va follement s'amuser (tu as le statut de bêta_testeur ici et moi de bêta_farceur

).

Superbe d'audace, passe alors la commande :

hdiutil create -size 40g -type UDIF -layout GPTSPUD -fs jhfs+ -volname BROL Downloads/IMG.dmg

qui va recréer une image-disque IMG.dmg de 40 Go ce coup-ci dans tes Téléchargements > et une fois créée > répète la démarche précédemment décrite de suppression > re-démarrage > et poste seulement un cliché de l'affichage terminal du panneau Stockage.

 

[fousfous]

Et voila


Purgeable à disparu aussi Et je vais la garder bien précieusement la commande pour me créer des gros fichiers facilement

 

[Membre supprimé 1060554]

Euh ! Quand je disais l'affichage "terminal" > je n'entendais pas l'affichage du «Terminal» > mais un cliché du panneau Stockage dans son état... terminal. Est-ce que tu peux en poster un ici ? Pour parfaire le comparatif [c'est important pour que toutes les informations soient disponibles en vue d'un debriefing ultérieur].

Mais ton cliché de la fenêtre du «Terminal» me donne aussi à réfléchir > car manifestement les manips opérées ont réussi à faire croître l'espace libre actuel (il était de 43 Go au départ > rien que par des jeux de passe-passe il est désormais de 67 Go).

 

[fousfous]

Ah je suis bete ^^ Mais je pensais que c'était aussi pour comparer au début


On voit que l'espace gagné est lié au purgeable qui a disparu

 

[Membre supprimé 1060554]

Il semble que la manip ait compressé au maximum l'espace dit « purgeable » (25 Go au départ) et augmenté d'autant l'espace libre actuel (43 Go au départ) - ce dans les limites globales de ce qui était estimé au départ l'« espace libre global » : 69 Go. On a donc 67 Go d'espace libre actuel et 2 Go de purgeable.

Tu es donc fin prêt pour lancer l'«Assistant BootCamp» > tu as la marge d'espace libre « actuel » suffisante.

[Je me réserve de cogiter à tête reposée sur la précieuse expérience que tu as permis de faire avec une fonctionnalité encore méconnue de «Sierra». Histoire de tenter de cerner en idée le statut de cet espace « purgeable » (libérable)...]

 

[fousfous]

Merci pour tout en tout ca!

Je tente donc l'installation maintenant

Et je pense que cette manip pourrai être intéressante pour beaucoup de monde souhaitant récupérer de l'espace

 

[fousfous]

Vous allez rire mais:


Quand ca veut pas, ca veut pas...
Et évidement dans l'utilitaire de disque je n'ai pas accès au SOS sur la partition bootcamp

 

[Membre supprimé 1060554]

Alors les grands classiques > passe les 2 commandes :

diskutil list
diskutil cs list

qui vont te retourner --> la 1ère le tableau des partitions de ton disque décrites en format > nom > taille > device ; --> la 2è le tableau des instances du format CoreStorage que je soupçonne d'être greffé sur la partition disk0s2 de ton disque => peux-tu poster ces 2 tableaux en copier-coller ici ?

[Savoir que le CoreStorage constitue un facteur de plantage coutumier de l'«Assistant BootCamp» - surtout s'il s'agit d'un CoreStorage Chiffré. Mais il peut s'agir simplement d'erreurs dans le système de fichiers jhfs+ terminal > auquel cas il y a plantage concernant tout re-dimensionnement de la partition qu'il gère, par exemple en mode rétrécissement de cette partition afin d'exporter une partition excédentaire dédiée à l'installation de Windows...]

Quand ca veut pas, ca veut pas...

Ceci est une facétie dominicale par le bêta_farceur

☟
​

La question Windows, si l'on survole l'historique de ce forum, se ramène à 2 points : a) = plantage inaugural de l'installation sur une partition ad hoc => b) = plantage terminal de la suppression de la partition ad hoc. Je n'ai jamais su ce qui pouvait bien se passer entre ces 2 avanies ni en quoi cet éphémère état intermédiaire pouvait paraître désirable (je n'ai jamais utilisé Windows) > mais la contemplation distante du cercle vicieux résumant toute l'affaire Windows sur Mac me conduit à l'interrogation suivante :

pourquoi se plonger dans les affres d'une installation qui sera immanquablement suivie par les affres de la désinstallation ? Pourquoi ne pas opter d'entrée pour la somme de ces 2 opérations : +1 & - 1 = 0 ? Personnellement, c'est que j'ai choisi : la « nullité » de Windows > ce qui m'évite aussi bien les tourments du +1 que ceux du -1...

 

[Membre supprimé 1060554]

spéculation dominicale​

Je me risque à quelques spéculations à propos de la nouvelle instance logique : « espace purgeable » (« purgeable space ») introduite avec l'OS «Sierra» - ce à partir du matériau expérimental grâcieusement fourni par le bêta_testeur fousfous.

Voici le panneau inaugural concernant l'espace du volume Macintosh HD de fousfous :

​

Nous notons donc qu'il possède en blanc 68,66 Go de ce qui correspond au nouveau concept de « available space » (espace disponible) - 68,66 Go qui se répartissent en 2 sous-espaces : le « purgeable space » (espace purgeable ou libérable) de 25,66 Go et le « free space » (espace libre actuel) de 43 Go.

Une commande :

df -H

retourne la distribution suivante :

/dev/disk1 250G 207G 43G 83% 1075330 4293891949 0% /

où il apert clairement que l'espace considéré comme libre du point de vue d'une manipulation disque (par exemple repartitionnements) est de 43 Go et correspond strictement à l'espace libre (free space) du volume.

La question qui surgit alors est : qu'est-ce que le « purgeable space » ? Ce n'est clairement pas de l'espace libre actuel (free space), mais bel et bien de l'espace occupé que le Système considère comme libérable par une action de l'utilisateur. C'est ainsi que sur cette page Apple : ☞System Information pour Mac: Afficher l’espace de stockage utilisé et disponible☜ se trouvent explicités ces concepts :

• Purgeable : Contient des fichiers et des documents stockés localement qui peuvent être supprimés lorsque de l’espace est requis, puis téléchargés ou générés à nouveau lorsque vous souhaitez avoir à nouveau accès à ces fichiers sur votre Mac.
  
  
• Libre : Espace disque inutilisé.
  
  Remarque : La quantité totale d’espace disponible affichée en haut de la fenêtre équivaut à un total qui combine l’espace purgeable et l’espace libre.

=> L'espace purgeable correspond donc a priori a de l'espace du volume occupé actuellement par des fichiers > fichiers supprimables par l'utilisateur soit par report sur iCloud et suppression du volume, soit par sauvegarde personnelle (sur un autre disque) et suppression du volume > ce qui devrait conduire à une diminution d'autant de l'espace purgeable > et à une augmentation d'autant de l'espace libre > à l'intérieur des limites constantes de l'espace disponible total.

Or telle n'est pas la constatation initiale de fousfous raison de mon intervention > puisqu'ayant supprimé de son disque dans les 25 Go de données recopiées sur un autre disque et effacées de son volume Macintosh HD > il n'a pas constaté de diminution de l'espace purgeable et d'augmentation de l'espace libre actuel > mais une stagnation de la valeur de l'espace libre et une allocation de l'espace libéré par son effacement à la catégorie d'espace purgeable.

Il était donc soupçonnable, au moment du cliché effectué ci-dessus, que l'espace purgeable ne correspondait nullement à de l'espace réellement occupé par des fichiers, puisque lesdits fichiers avaient été effacés entre temps > et néanmoins cet espace libéré n'avait pas récupéré le statut effectif de free_space, puisque la commande df ne retournait que 43 Go d'espace libre actuel et pas 43 Go + 25 Go de fichiers effacés = 68 Go.

Ma commande de bêta_farceur :

hdiutil create -size 20g -type UDIF -layout GPTSPUD -fs jhfs+ -volname BROL Downloads/IMG.dmg

suivie d'une commande encore plus drastique :

hdiutil create -size 40g -type UDIF -layout GPTSPUD -fs jhfs+ -volname BROL Downloads/IMG.dmg

suivie chaque fois d'une suppression de l'image-diskque IMG.dmg générée dans le répertoire des Téléchargements, 20 Go la première fois et 40 Go la 2è fois > conduit après re-démarrage de la machine à l'affichage de stockage suivant :

​

Si l'on compare au premier cliché présenté auparavant > voici ce qui apert :

- la part de l'espace occupé = 180 Go n'a pas varié (et pas non plus la répartition de cet espace occupé entre Documents > Système > Apps)

- la part de l'espace disponible = 69 Go n'a pas [guère] varié (je néglige une variation de 1 Go dont je n'ai pas l'explication)

- la proportion de l'espace purgeable : de 25,66 Go à 2 Go vs espace libre actuel : de 43 Go à 67 Go a totalement été modifiée.​

Ainsi donc la simple création d'un fichier bidon de 40 Go suivi de sa suppression a suffi à « dégonfler » la prégnance de l'espace purgeable sur l'espace du volume > sans aucune suppression de fichiers de l'utilisateur par ailleurs. Une seule interprétation me paraît se tirer de cette étrangeté : l'espace du volume désigné comme purgeable était de l'espace réellement libre (sans fichiers résidents) > mais indûment accaparé comme « purgeable » par le Système, càd. marqué comme ayant un statut « occupé > libérable ».

Il semble donc que, dans «Sierra» des alignements de blocs considérables de la partition-Système puissent subir un «marquage_logique » comme étant libérables de leurs fichiers sans être considérés comme « blocs libres », alors même qu'il ont été libérés actuellement de leurs fichiers. Il s'agit manifestement d'un conflit d'instructions relativement aux blocs libérés par un effacement de fichiers tel que l'instruction de marquage par l'attribut : « occupé > libérable » overrides (surclasse) à tort l'attribut : « libéré = libre ».

C'est comme si, pour toute action de libération de blocs par effacement > les blocs concernés n'accédaient pas au statut « libérés », mais « libérables ». Le problème étant que ces blocs marqués comme « libérables » sont considérés comme « occupés » par le système de fichiers, ce qui bloque un repartitionnement qui voudrait les inclure dans l'exportation d'une nouvelle partition. Seule, une création farceuse d'un super-fichier d'une taille occupant presque tout l'espace actuellement libre, puis sa suppression inverse > conduisant au marquage d'un espace de blocs considérable par l'attribut : « libre » > semble entraîner dans la foulée la résiliation forcée du pseudo attribut « libérable » affecté à des blocs réellement « libres » > et par suite l'éviction du pseudo espace « purgeable » avec restitution d'un réel statut de : « espace libre actuel ».

=> s'il en est bien ainsi que je viens de le spéculer à partir de l'expérimentation de fousfous > il s'agirait d'un bogue absolument majeur disqualifiant l'OS «Sierra»...

 

[fousfous]

Voici le résultat des 2 commandes:

/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_CoreStorage Macintosh HD 250.1 GB disk0s2

3: Apple_Boot Recovery HD 650.0 MB disk0s3


/dev/disk1 (internal, virtual):

#: TYPE NAME SIZE IDENTIFIER

0: Macintosh HD +249.8 GB disk1

Logical Volume on disk0s2

B7433156-A553-4883-9ADA-C14759CD8FE8

Unencrypted


Et l'autre commande:

CoreStorage logical volume groups (1 found)

|

+-- Logical Volume Group 80F515E9-6B37-4E1F-BD5E-C5F50AFA6F6C

=========================================================

Name: Macintosh HD

Status: Online

Size: 250140434432 B (250.1 GB)

Free Space: 18882560 B (18.9 MB)

|

+-< Physical Volume 2E486036-B29A-49CB-B9E4-056C4BD661FC

| ----------------------------------------------------

| Index: 0

| Disk: disk0s2

| Status: Online

| Size: 250140434432 B (250.1 GB)

|

+-> Logical Volume Family 180801F3-912D-435D-B58C-3D53E1E1786C

----------------------------------------------------------

Encryption Type: None

|

+-> Logical Volume B7433156-A553-4883-9ADA-C14759CD8FE8

---------------------------------------------------

Disk: disk1

Status: Online

Size (Total): 249769230336 B (249.8 GB)

Revertible: Yes (no decryption required)

LV Name: Macintosh HD

Volume Name: Macintosh HD

Content Hint: Apple_HFS



Mais si bogue il y a, ne faudrait-il pas le signaler pour que le problème soit réglé?

 

[Membre supprimé 1060554]

Par acquit de conscience, au cas où il y aurait des erreurs dans le système de fichiers jhfs+ terminal > re-démarre ton Mac en tenant pressées les touches ⌘R après l'écran noir (démarrage en mode Recovery) > dans la fenêtre des 4 Utilitaires OS X > lance l'«Utilitaire de Disque» > sélectionne le volume Macintosh HD > presse le bouton S.O.S. > si tu obtiens à la fin un : "le volume Macintosh HD semble être en bon état" > c'est que le système de fichiers est sans erreurs.

Re-démarre sur ton OS. À présent > comme ton CoreStorage (non chiffré) est réversible (« Revertible: Yes (no decryption required) ») --> il est possible de le déconstruire non destructivement pour ton OS et tes données. Fais un copier-coller de la commande :

diskutil coreStorage revert B7433156-A553-4883-9ADA-C14759CD8FE8

> assure-toi qu'aucun message d'erreur n'est retourné > et alors re-démarre une fois de plus ton Mac > afin que le kernel enregistre la disparition du Volume Logique identifié comme disk1 (absolument nécessaire).

=> tu peux relancer l'«Assistant BootCamp» qui n'a plus aucune excuse de plantage...

 

[fousfous]

En effet il n'y avait plus d'excuse pour planter!

Maintenant il ne trouve juste plus les pilotes qui sont sur la clé... j'essaye bien d'aller les chercher en manuel mais c'est très lent et je sais pas si c'est pas plutot Windows qui a planté...

 

[fousfous]

D'après l'assistant bootcamp je dois installer les pilotes APRÈS l'installation de Windows, mais la il me demande AVANT l'installation de Windows, mais il n'arrive pas à les trouver alors que c'est sur la clé USB, et même sur une autre clé USB.
Et c'est normal que ça mette 1H30 pour arriver au début de l'installation?

 

[Locke]

D'après l'assistant bootcamp je dois installer les pilotes APRÈS l'installation de Windows

Bien sûr et c'est lorsque que tu es sous Windows que ce ne sera que possible. Réfléchis un peu, tu as un dossier dans la clé USB qui contient les drivers, dont un qu'il faut lancer en faisant un double clic dessus et il se nomme Setup.exe. Ce type d'extension est propre au système Windows et ne peut pas être exécuté sous OS X.

 

[fousfous]

Ah oui ça je me doute que sur macOS ça va pas se lancer ^^
Mais moi je parler quand je suis à la procédure d'installation de windows, donc techniquement windows n'est pas encore installé et il me demande les drivers (sachant que le trackpad fonctionne très bien donc ça ne devrait pas poser de problèmes).
Et comme chaque action prend quelque dizaines de minutes ou fait tout planter, mieux vaut trouver la solution avant de tout relancer

 

[Locke]

Mais moi je parler quand je suis à la procédure d'installation de windows, donc techniquement windows n'est pas encore installé et il me demande les drivers

Que ce soit sous Boot Camp ou depuis la fenêtre de l'installeur de Windows, il n'est jamais demandé de drivers. Sous Boot Camp, la seule demande est lors de la copie des drivers dans la clé USB et c'est tout, cette clé contenant les drivers ne sert pas pendant l'installation de Windows.

Tu vois ça à quel moment ? Une copie d'écran serait la bienvenue, même depuis un smartphone.