Vous utilisez un navigateur non à jour ou ancien. Il ne peut pas afficher ce site ou d'autres sites correctement. Vous devez le mettre à jour ou utiliser un navigateur alternatif.
10.11 El CapitanVolume de démarrage accessible uniquement via une autre partition
où diskutil est appelé avec le verbe resizeVolume (redimensionner_volume) sur la cible du devicedisk0s2 (partition de HAL 9000) en demandant sa réduction à 960 Go et la création avec le free_space dégagé d'une nouvelle partition au format jhfs+ de nom Untitled avec 0b pour la mention de taille signifiant : "utiliser jusqu'au dernier byte l'espace libre disponible pour sa constitution".
L'opération sera peut-être lente > en sortie, tu devrais voir se réafficher le tableau de partitionnement actualisé de ton disque > peux-tu le reposter histoire qu'on soit sûrs qu'il n'y ait pas de lézard (genre la Recovery HD n°1 bien à sa place) ?
sudo asr restore -s /dev/rdisk0s5 -t /dev/disk0s4 --erase --noprompt
avec password à l'aveugle > l'utilitaire commence par vérifier les tailles et les formats de la "source" et de la "destination" après démontage de chacun de ces volumes > puis il reformate la "destination" > enfin il clone en mode bloc intégral la "source" sur la "destination" (tu as une progression en % d'abord du passage en mode "Restoring", puis en "Validating") > en cas de partition-Système comporant une Recovery HD collatérale (c'est le cas ici : la disk0s6) > il clone aussi cette partition en-dessous de la destination > à la fin, il remonte les 2 volumes > la "destination" est devenue le clone intégral de la "source" au nom près (ce serait SierraBeta aussi) et à l'icône près.
=> quel que soit le procédé que tu choisis > à la fin reposte encore le tableau d'un diskutil list > pas d'inquiétudes s'il y a des redondances et des incalaires > ce sera la tâche des finitions de purger tout ça.
[NB. Les 2 logiciels fixent équitablement le caractère bootable sur le volume de "destination". Tu pourrais opérer la vérification du caractère effectivement démarrable du clone en re-démarrant (avec "alt") sur la partition clonée pour ouvrir ta session miroir : si tu as utilisé «CCC» > le nom du disque à choisir est Untitled ; si tu as utilisé asr > tu as 2 noms de disques identiques : SierraBeta : je ne saurais dire à quel rang sera le SierraBeta cloné.]
Je suis passé par Carbon Copy Cloner (que j'ai installé aujourd'hui mais que je pense acheter car il me rend bien des services), histoire de voir si je m'en sers correctement.
Un diskutil list plus tard :
Bloc de code:
/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_HFS HAL 9000 960.0 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: Apple_HFS Untitled 19.6 GB disk0s4
5: Apple_Boot Recovery HD 650.0 MB disk0s5
6: Apple_HFS SierraBeta 18.7 GB disk0s6
7: Apple_Boot Recovery HD 650.0 MB disk0s7
Tout a l'air toujours impeccable, formellement (il est rapide ton Mac, dis donc !). «CCC» t'a recloné aussi la «Recovery HD» de queue du disque en disk0s5.
Fais un essai de re-démarrage avec "alt" et en choisissant Untitled comme disque de démarrage, pour voir si ça boote et si tu peux ouvrir ta session miroir.
Si (et seulement si) ça démarre bien (si ça boote pas > arrête tout) > tu reviens dans ton HAL 9000 et alors tu passes les commandes de finition :
- a)suppression de la partition disk0s5 (la Recovery HD clonée) :
Bloc de code:
diskutil eraseVolume free NULL1 /dev/disk0s5
- b)suppression de la partition disk0s6 (SierraBeta) :
Bloc de code:
diskutil eraseVolume free NULL2 /dev/disk0s6
- c)récupération de l'espace libre à Untitled en disk0s4 :
Bloc de code:
diskutil resizeVolume /dev/disk0s4 0b
[Tu auras compris que la Recovevery HD disk0s5 ou la disk0s7 : c'est bonnet blanc et blanc bonnet, l'une étant le clone de l'autre. En supprimant le clone > j'évite un énième déplacement sur les blocs qui aurait eu lieu en cas de suppression de la dernière Recovery HD, car la Recovery HD disk0s5 aurait dû alors être déplacée en queue de blocs... à la place de la Recovery HD disk0s7 supprimée --> ce qui aurait été clownesque.]
=> Poste le tableau d'un diskutil list pour vérifier si tout est en ordre en sortie.
--------------------
PS. Je n'avais pas vu ton tableau prévisionnel de commandes à la fin de ton message ci-dessus : impeccables ! J'avais eu le même réflexe que toi - et ça marcherait aussi bien. Mais en réfléchissant : c'est un peu ballot de supprimer la disk0s7 en gardant la disk0s5 pour que la disk0s5 soit redéplacée sur les blocs pile à l'emplacement de la disk0s7. Le Système s'en fiche, en fait - c'est juste « psychologique »
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS HAL 9000 960.0 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: Apple_HFS Untitled 39.6 GB disk0s4
Ça m'a l'air parfait, tout ça. Enfin, il manque un Recovery HD… c'est grave docteur ? disk0s7 n'a visiblement pas apprécié d'être esseulée si brusquement.
Il ne me reste plus qu'à renommer le volume… et repasser en CoreStorage ? Est-ce que ça a le moindre avantage pour moi, sachant que je n'utilise pas FileVault ni FusionDrive ?
Il y a dû avoir un ratage quelque part pour que la «Recovery HD» de Sierra ait sauté. Peut-être as-tu ajouté une commande de suppression de trop ? Ou quoi ?
Pour la re-créer (hé ! hé !) tu connais le procédé (hé ! hé !) > téléchargement de l'installateur de «Sierra» (à moins que tu n'en aies conservé un sous le coude) > ré-installation de SierraBeta si tu as renommé ainsi ton Untitled (tu peux déclencher l'installation depuis ta session dans HAL 9000 si tu veux - en ciblant bien le volume de "destination" pour ne pas mettre-à-niveau HAL 9000 !) > ce qui va te recréer une «Recovery HD» en disk0s5 > mais aussi un CoreStorage sur SierraBeta disk0s4 (qui devrait être de type réversible).
Qu'à cela ne tienne : tu fais un diskutil cs list > qui te retourne le tableau du Logical Volume Group de disk0s4 > tu vas tout en bas du tableau, à la rubrique Logical Volume > tu sélectionnes l'UUID de 32 caractères alpha-numériques de type XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX en regard et tu le copies dans ton presse-papier > tu passes une commande (depuis le «Terminal» de HAL 9000 aussi bien) :
J'ai encore l'historique sous les yeux, et j'ai strictement suivi la procédure. Il a sauté tout seul, comme un grand.
Bref, réinstallation de Sierra via HAL 9000, retour au HFS pour toute la famille (avec en bonus les disques de restauration qui s'affichent de nouveau avec « alt »), et hop :
Bloc de code:
/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_HFS HAL 9000 960.0 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: Apple_HFS SierraBeta 39.0 GB disk0s4
5: Apple_Boot Recovery HD 650.0 MB disk0s5
Cette fois-ci, je crois bien que je n'ai plus aucun prétexte pour monopoliser ton attention :P Je parlais de magie, mais il n'y a pas de tour sans magicien, alors encore merci
Il arrive que des commandes pourtant bien formulées amènent des ratages. Heureusement c'est peu courant.
[ÉDIT. Je pense que j'ai capturé le point : tu as passé mon jeu de commandes, censé épargner la Recovery HD située tout en queue de disque, l'espace libre se situant entre cette dernière petite partition et celle de Untitled en disk0s4 > diskutil au lieu de respecter à la lettre l'instruction, a "sur-interprété" la commande, en supprimant également la Recovery HD en position de serre-file, pour avoir un bloc complet de free_space à réintégrer à Untitled.
La petite taille (650 Mo) de cette partition terminale a joué en sa défaveur. Tu aurais passé ton jeu de commandes (supprimant la Recovery HD de queue et gardant la disk0s5 limitrophe de la Untitled disk0s4 > il y a de fortes chances que cette Recovery HD ait été respectée. Ma préférence « psychologique » était donc un mauvais calcul et c'est toi qui étais probablement dans le vrai.
J'enregistre ce cas de figure : toujours être très prudent, dans un dispositif comme le tien. Personnellement, j'utilise un binaire créé par Apple à l'époque de «Lion 10.7» : dmtest (non natif dans OS X) qui permet de recréer une Recovery HD où l'on veut, à condition d'avoir sauvegardé 2 composants du dossier com.apple.recovery.boot de la Recovery HD : le disque virtuel BaseSystem.dmg et le fichier BaseSystem.chunklist. Je fais toujours ce type de sauvegarde préalable, en cas de manips aventureuses.]
Ton fil a attiré mon attention sur le rôle joué par la «Recovery HD» dans le démarrage de l'OS de la partition du dessus, quand il y a un format CoreStorage en jeu. Si le Volume Logique est chiffré par «FileVault», ça se comprend, car ce volume étant verrouillé par le chiffrement au démarrage, par suite non monté, il faut bien que l'EFI exécute le démarreur boot.efi de la «Recovery HD» pour que ce dernier affiche un écran de déverrouillage permettant de remonter le volume de l'OS. Mais manifestement, avec un CoreStorage standard, le boot.efi de la «Recovery HD» sert aussi de relai - de la manière la plus inutile qui soit, mais aussi la plus plantogène (comme tu en as fait l'expérience).
J'ai l'impression que tu as capturé le sens de pas mal de commande appelant diskutil : vu la ringardise de l'«Utilitaire de Disque» new age (El Capitan > Sierra), il vaut mieux avoir ce genre de cartes dans la manche...
Bonjour, j'ai actuellement le même problème qu'à eu Yohmi, j'ai lu un peu le fil et j'ai tenté les mêmes manipulations. D'abord j'ai donc lancé la commande:
Bloc de code:
diskutil mount /dev/disk0s3
et j'ai reçu la même erreur que Yohmi :
Bloc de code:
Volume on disk0s3 failed to mount
If the volume is damaged, try the "readOnly" option
Puis j'ai redémarré et mon disque de démarrage sous El Capitan n'étais pas visible uniquement celui sous Sierra était visible. J'ai donc redémarré par le démarrage par internet et fait réparer le disque avec "Réparer le disque" avec l'Utilitaire de Disque (celui de Mavericks je crois).
Lors de la réparations j'ai reçu plusieurs messages j'ai marqué ceux qui m'avait l'air d'être importants :
Bloc de code:
The volume 204D6D04-8B32-4C1F-A22F-0EA8B96F3BB8 appears to be OK (message écrit en vert)
Problems were found with the partition map which may prevent booting
Error : unrecognized file system (écrit en rouge)
[...]
Verifying volume "Ouwéis SSD"
[...]
Invalid DiskLabel @212735897600 : cksum mismatch (en rouge)
[…]
Volume 204D6D04-8B32-4C1F-A22F-0EA8B96F3BB8 appears to be OK (en vert)
[…]
The volume Ouwéis SSD appears to be OK
Puis après ça juste quand ça avais l'air d'avoir fini la réparation j'ai eu une alerte dans l'Utilitaire de Disque me disant : "Unrecognized file System"
Mais j'ai pu ensuite sélectionner mon disque "Ouwéis SSD" sans avoir de messages d'erreur (avant la réparation quand je tentais de sélectionner ce disque la je recevais le message "La génération de caches de démarrage sur la partition de l’utilitaire de démarrage a échoué.", mais malgré ça il m'a fait redémarré sous Sierra, et quand je passe dans le menu de boot en appuyant sur ALT j'ai bien mon disque dur qui s'affiche mais quand je le choisi il m'affiche un sens interdit (alors qu'avant ça il ne s'affichais pas du tout).
Puis après avoir fait tout ça j'ai lancé la commande
Bloc de code:
diskutil mount /dev/disk0s3
pour faire afficher la partition "Recovery HD" (qui s'appelle "Boot OS X") mais à l'intérieur il n'y pas de dossier com.apple.recovery.boot il y a juste ceci :
Un dossier System avec à l'intérieur un dossier CoreService avec à l'intérieur 3 fichiers : boot.efi, PlatformSupport.plist et SystemVersion.plist. L'arborescence ressemble à peu près à ça :
-Boot OS X
..... |______ System
.....................|_____ Library
....................................|____CoreService
.................................................|_______ boot.efi
................................................................;PlatformSupport.plist
................................................................;SystemVersion.plist (Les points et les points-virgules sont la uniquement pour faire aligner les noms)
Un "ls -a" à l'intérieur de Boot OS X m'affiche ceci :
Bloc de code:
MacBook-Pro-de-Ouweis:Boot OS X ouweis$ ls -a
. .. .Trashes .VolumeIcon.icns .fseventsd .metadata_never_index System
Du coup comme j'ai eu un truc différent de ce que j'étais censé avoir je ne savais pas trop quoi faire par la suite, du coup je vous demande de l'aide, pouvez vous m'aider ? Merci
dans le «Terminal» de ta session de Sierra > poste ici (en copier-coller) les 2 tableaux qui vont être retournés > que j'ai une idée complète du dispositif actuel du disque de ton Mac.
Bon, je crois que ce qui s'impose en premier > c'est d'opérer la réversion logique du format CoreStorage de la partition disk0s2Ouwéis HD (tu notes, dans le 2è tableau = celui du CoreStorage, à la dernière rubrique : Logical Volume > qu'il est bien mentionné : Revertible: Yes > donc la réversion logique non destructrice est supportée).
(c'est toujours l'UUID du Volume Logique qui est la cible d'une réversion de format CoreStorage) > tu vas voir un déroulement d'affichage jusqu'à complétion > il faut alors que tu re-démarres nécessairement ton Mac (car le kernel ne s'est pas avisé que le disque virtuel du Logical Volume - évalué comme disk1 - n'existe plus et que le système de fichiers jhfs+ de l'OS Ouwéis HD a atterri directement dans le container de blocs bruts de la partition disk0s2 > bref : il est en retard d'une manœuvre...)
Re-démarre sur Sierra pour l'instant. Le but de la manœuvre ci-dessus est de désolidariser complètement le volume Ouwéis HD de la partition disk0s3 (ex Recovery HD et actuellement un Boot OS X pas du tout démarrable) en ce qui concerne ses conditions de démarrage. Tu n'as qu'à reposter le résultat d'un diskutil list une fois re-démarré.
(avec mot-de-passe admin à l'aveugle) > cette commande fixe sur l'en-tête du volume Ouwéis SSD(pas génial ton accent pour un nom de volume) un chemin d'accès au répertoire CoreServices qui contient le boot_loader: boot.efi de l'OS (exécutable par l'EFI) > l'option finale --setBoot inscrit normalement en NVRAM l'instruction pour l'EFI d'aller chercher automatiquement le boot_loader: boot.efi de la partition disk0s2 et de l'exécuter en lancement de l'OS.
Avant de re-démarrer, tu pourrais enchaîner par la commande :
Bloc de code:
nvram -p
qui te retourne le tableau des paramètres de ta NVRAM > peux-tu faire un copier-coller du tableau ici (c'est longuet) > histoire de voir quel est le chemin de boot renseigné à a rubrique efi-boot-device.
Cela fait > tu peux re-démarrer sans options > histoire de voir si tu bootes automatiquement sur ton volume Ouwéis SSD...
Poste ensuite le tableau retourné par la commande nvram -p (la NVRAM n'aura pas été éditée par la commande précédente) que je vois ce qu'il y a actuellement dedans.
Enfin : re-démarre mais en tenant la touche "alt" ce coup-ci > le volume Ouwéis SSD est-il affiché à l'écran de choix du disque de démarrage ? > si tu le choisis > est-ce que tu peux démarrer dessus ?
