10.13 High Sierra Problème Partitions et Installation MacOS

[Deleted member 1099514]

Merci Jean, ça a marché !
A+

Content pour toi.

 

[Membre supprimé 1060554]

Si on regarde ceci : #22 ta théorie sur la manière de gérer la Recovery APFS par High Sierra me parait sujette à interrogations.

Exact. J'ai découvert ça tout à l'heure avec dépit, en effet. Le volume Recovery est manifestement monté et indémontable > parce que : ressource employée par le kernel.

Pourtant > à chacun de mes tests (de démarrage en mode Recovery local > mais pas d'effacement) avec High Sierra --> la commande :

hdiutil info

me retourne l'existence d'une image-disque ramfile de 2,14 Go qui me paraissait le signe d'un démarrage sur la RAM.

=> il faut que je ré-examine la question.

 

[Deleted member 1099514]

Exact. J'ai découvert ça tout à l'heure avec dépit, en effet. Le volume Recovery est manifestement monté et indémontable > parce que : ressource employée par le kernel.

Pourtant > à chacun de mes tests (de démarrage en mode Recovery local > mais pas d'effacement) avec High Sierra --> la commande :

hdiutil info

me retourne l'existence d'une image-disque ramfile de 2,14 Go qui me paraissait le signe d'un démarrage sur la RAM.

=> il faut que je ré-examine la question.

L'informatique est loin d'être une science exacte.

 

[Membre supprimé 1060554]

Le seul OS à partir de «Lion 10.7» compris > avec lequel un démarrage en mode Recovery local (⌘R) induisait la création d'un clone en RAM du dossier de boot du volume Recovery HD --> donc le démarrage du Mac purement en RAM (comme dans un démarrage par internet) et la possibilité d'effacer entièrement le disque => a été «Yosemite 10.10».

Il existe donc un précédent historique qui ne rend pas inintelligible le concept d'un démarrage en mode Recovery local sur un clone en RAM. Je m'étais donc persuadé par analogie que le démarrage en mode Recovery local avec High Sierra reprenait ce concept de «Yosemite». Preuve à l'appui d'une ramfile de plus de 2 Go.

Comme je dispose de pas mal de SSD > je vais prendre le temps de faire un test de mon côté pour voir si je peux effacer le disque entier après un démarrage en mode Recovery local. Déjà > la simple possibilité de démonter le volume Recovery prouverait cette possibilité.

 

[Membre supprimé 1060554]

e pur si muove​

J'ai démarré en mode Recovery local (⌘R) - OS High Sierra APFS.

Une commande :

hdiutil info

• me retourne l'existence d'un: ramfile de 2,14 Go. Lorsque le démarrage en mode Recovery local s'opère sur un volume Recovery HD du disque > au lieu d'un ramfile > on a mention d'un: file > avec chemin à une image-disque BaseSystem.dmg. Ce n'est pas le cas ici > par conséquent je suis « théoriquement » parlant démarré sur un RecoveryOS en RAM.

Une commande :

diskutil list

• me retourne le tableau des disques > partitions > Conteneur apfs > Volumes apfs. Le Volume apfs Recovery est disk2s3.

Une commande :

diskutil umount force disk2s3

• me retourne le message :

Volume disk2s3 was already unmounted

=> il est prouvé ici que je ne suis pas démarré en mode Recovery local sur un volume sustenté par le disque > puisque le volume Recovery disk2s3 du Conteneur apfs disk2 est démonté. Je suis donc bien démarré sur un clone en RAM du RecoveryOS (clonage qui a pris pour source le dossier de boot du volume Recovery du disque - lequel a été automatiquement re-démonté après démarrage du Mac sur le clone en RAM).

Je n'ai pas tenté d'effacer le disque parce que je n'ai pas envie de tout remettre ensuite. Mais je pense avoir prouvé que le démarrage en mode Recovery local par ⌘R > si se trouve installé un Conteneur APFS à 4 volumes > s'opère bien sur un clone en RAM conformément au concept inauguré par l'OS «Yosemite» seul auparavant.

J'en conclus que l'échec de démonter le volume Recovery après démarrage en mode Recovery dans cet autre fil : ☞Besoin d'aide installation bootcamp sur MacBook (13 pouces, fin 2009)☜ (messages #22 à #24) n'est pas exemplaire mais aberrant. Il s'agirait alors de rendre compte d'une aberration > non d'une règle.

 

[Deleted member 1099514]

Faut aller jusqu'au bout.
Et puis une Recovery, c'est facile à réinstaller.

 

[Locke]

C'est affolant le nombre de messages concernant des problèmes de partition avec le nouveau format APFS !

Bon, vous deux, ça ne vous dérange pas, vous adorez tapez des lignes de commande via le Terminal, mais quand même.

 

[Deleted member 1099514]

C'est affolant le nombre de messages concernant des problèmes de partition avec le nouveau format APFS !

Bon, vous deux, ça ne vous dérange pas, vous adorez tapez des lignes de commande via le Terminal, mais quand même.

Je suis tout à fait d'accord avec toi et je pense que ce système de fichiers est absolument pas fini, ni maitrisé.
J'aurais une exploitation sur Mac, je refuserai cette migration et pourtant Apple l'impose sur les SSD.
C'est un peu "léger" quand même.
Quand je vois que certains l'attendent impatiemment sur les disques classiques et les Fusion drive, ça me fait rire doucement.

 

[Membre supprimé 1060554]

Faut aller jusqu'au bout.

⬇︎

e pur si muove (Acte II)
​

J'ai ouvert mon MacBook Pro 2011 > enlevé le SSD Crucial installé à l'emplacement-disque régulier + enlevé le boîtier contenant le 2è SSD Crucial à l'emplacement Super-Drive.

J'ai installé à l'emplacement-disque un SSD Crucial ne comprenant qu'une partition principale > et l'OS High Sierra installé dessus en APFS. Je n'ai pas reconnecté le câble Wi-Fi --> pas de connexion internet suprebtice.

Je démarre une fois normalement : j'ai bien une session que j'avais semi-personnalisée. L'OS fonctionne.

Je démarre par ⌘R = en mode Recovery local.

Une commande :

hdiutil info

• me révèle l'existence (attendue de moi) d'un: ramfile de 2,14 Go --> je suis donc bien théoriquement démarré sur un RecoveryOS en RAM et pas sur celui du volume apfs Recovery.

Une commande :

diskutil list

• me confirme que le Conteneur APFS est identifié comme disk2 (internal, virtual) et que le volume Recovery est identifié comme disk2s3.

Une commande :

diskutil umount force disk2s3

• retourne un :

disk2s3 was already unmounted

• la partition disk2s3 était déjà démontée de son volume = Recovery.

Ce serait déjà la preuve suffisante que le Mac ne peut absolument pas être démarré sur le RecoveryOS recelé dans une image-disque Base-System.dmg du volume Recovery > car dans ce cas-là > le volume Recovery devrait être maintenu monté et être indémontable.

Mais je n'ai pas fait cette manipulation pour m'en tenir là --> une commande :

diskutil ap deleteContainer disk2 BROL

• se trouve entièrement honorée : les 4 volumes apfs --> Macintosh HD > Preboot > Recovery > VM sont confirmés démontés > puis le Conteneur apfs est supprimé > un reformatage de la partition support du disque disk0s2 confirmé > et le remontage d'un volume vide au format jhfs+ intitulé BROL.

Qu'à cela ne tienne > remettons-en une couche --> une commande :

diskutil partitiondisk disk0 gpt jhfs+ BROL 100

• détruit la table de partition GPT du disque 0 (SSD interne) > en remet une neuve > décrivant une partition principale de type Apple_HFS > dans laquelle un système de fichiers jhfs+ se trouve injecté et génère un volume intitulé BROL.

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

Interprétation : je considère cet exemple comme canonique ou exemplaire de la règle --> le démarrage en mode Recovery local (⌘R) dans les conditions d'un OS High Sierra APFS installé sur le disque interne > détermine un démarrage sur un clone en RAM du RecoveryOS du volume Recovery utilisé uniquement comme "source" > une image-disque (ramfile) créée en RAM pour l'occasion montant un volume Untitled qui est la "destination" de ce clonage à la volée.

Le Mac démarre donc absolument sur la RAM - mode de démarrage de secours repris du concept du démarrage Recovery local de «Yosemite 10.10». Ce type de démarrage doit permettre à l'utilisateur de réparer l'ensemble du système de fichiers apfs générateur du Conteneur et de ses 4 volumes. Voire de supprimer le Conteneur et d'effacer le disque entier.

Le cas rencontré dans le fil que j'ai cité précédemment d'un démarrage en mode Recovery local ne permettant pas le démontage du volume apfs Recovery - parce que l'opération est :

dissented by kernel

• (proscrite par le kernel du RecoveryOS démarré) --> je l'interprète comme une aberration pure et simple du démarrage en mode Recovery local de High Sierra apfs. Je n'ai pas d'autre explication que celle-ci (vague) : erreur pure et simple à l'installation de cet OS. Une de plus ! - ce qui ferait louper le protocole de démarrage sur un clone en RAM et restaurerait le démarrage classique sur le volume Recovery du disque.

Note : depuis l'origine du démarrage en mode Recovery (OS «Lion 10.7») > une kyrielle de petits disques sont listés par la commande :

diskutil list

• dans un Terminal du RecoveryOS > en sus du volume OS X Base System recelant cet OS.

Ces petits disques correspondent dès le début à de micro-images-disques en RAM dans le volume desquelles sont montés comme des "pseudo-volumes" des dossiers déterminés du RecoveryOS. Cette multiplication de points de montage en RAM de dossiers du RecoveryOS ne doit pas occulter la question de fond : le RecoveryOS lui-même, en tant que Système opérateur d'ensemble, est-il le résident du disque ou de la RAM ?

--> la réponse me paraît être : toujours du disque (impliquant un volume Recovery HD monté) pour tous les OS à 2 exceptions près : l'exception «Yosemite 10.10» (démarrage sur un clone en RAM indépendant du disque) et l'exception «High Sierra APFS» (et pas JHFS+ flanqué d'une Recovery HD) = démarrage aussi sur un clone en RAM indépendant du disque.

 

[Deleted member 1099514]

Belle manœuvre. Mais qui supporte quelques exceptions. Si le système APFS continue à faire des ravages dans les cœurs d'enfants lors des mises à jours, nous aurons l'occasion de tester ça sur le terrain.