Je profite de la résolution « pratique » des problèmes (restituer à la mère d'
Alex un Mac restauré à l'identique dans sa table de partition pour qu'elle n'y voie que du feu) > pour revenir sur une question « théorique » soulevée par le message
#21.
Voici la table de partition du disque du Mac "vue" depuis l'OS
El Capitan démarré du volume
Macintosh HD :
Bloc de code:
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *480.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 399.3 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: 7C3457EF-0000-11AA-AA11-00306543ECAC 80.0 GB disk0s4
On note évidemment que la partition n°
4 se trouve bien identifiée en taille (
80 Go) et en appareil (
disk0s4) --> mais ni en type de partition ni en nom de volume : à la place on a un UUID
7C3457EF-0000-11AA-AA11-00306543ECAC.
Faut-il en tirer l'interprétation :
Autrement dit, la partition
High
Sierra est... HS
Non. C'est simplement que l'utilitaire
diskutil d'
El Capitan ne sait pas lire le type :
Apple_APFS qui caractérise la partition n°
4. Car c'est une version de cet utilitaire solidaire du
format JHFS+ qui ignore encore tout de l'
APFS. Il se débrouille donc comme il peut pour rendre compte de la partition n°
4 > en remplaçant les paramètres qu'il ne sait pas lire par l'
UUID de la partition. Rien ne permet donc de conclure qe la partition n°
4 est HS : elle est simplement au-delà de la "compréhension logique" du
diskutil d'
El Capitan.
----------
lorsque je veux entrer la commande "diskutil partitionDisk disk0 gpt jhfs+ "Macbook HD" 100%" depuis le terminal du clône, j'ai une erreur, il n'est pas capable de démonter le disque.
Je suppose ici qu'
Alex a un
clone du volume
Macintosh HD dans celui d'un DDE USB > et qu'il soit démarré sur ce clone au moment de cette tentative de commande.
Une commande :
Bloc de code:
diskutil partitionDisk disk0 gpt jhfs+ "Macbook HD" 100%
adressée au disque n°
0 (premier disque) qui est le disque interne du Mac dont la table de partition correspond au tableau cité en premier ici --> est syntaxiquement (formellement) parlant correcte.
Régulièrement, l'utilitaire
diskutil démonte tous les volumes montés sur les partitions d'un disque-cible > afin de
désactiver les
systèmes de fichiers correspondants, pour pouvoir
effacer /
recréer une
table de partition. Car si un seul des systèmes de fichiers de partition est activé --> alors la table de partition
GPT est considérée comme «
busy » (occupée) et ne peut pas être effacée. La table
GPT est «
busy », parce que le
kernel de l'OS démarré a monté les volumes sur les partitions correspondantes --> il charge donc pour ce faire la personnalité des systèmes de fichiers qui fondent ces volumes et pour charger cette personnalité > il emprunte l'entrée correspondante de la table de partition
GPT. Donc le
kernel refuse de lâcher prise, en somme.
Bon d'accord sur le
principe général --> mais en quoi s'applique-t-il au
cas particulier de ce disque-ci : le
disk0, au vu de sa table de partition ?
- le volume de la partition n°1 EFI n'est pas monté à cause du type Apple_Boot --> donc le système de fichiers FAT-32 de cette partition n'est pas actif
- le volume de la partition n°2 Macintosh HD se laisse démonter sans difficulté --> donc le système de fichiers JHFS+ de cette partition se laisse désactiver
- le volume de la partition n°3 Recovery HD n'est pas monté encore à cause du type Apple_Boot --> donc le système de fichiers JHFS+ de cette partition n'est pas actif
- aucun volume High Sierra n'est monté sur la partition n°4 parce que le format du système de fichiers APFS n'est pas identifié. Donc ? --> donc : aucun système de fichiers n'est activé sur cette partition > occupant la table GPT parce que le kernel emprunte une entrée pour charger les données de la partition ? => apparemment oui > mais le service diskarbirationd de l'OS chargé de la probation des systèmes de fichiers des partitions (avant de refiler au kernel la tâche du montage en cas de probation réussie) n'a pas l'air de l'entendre ainsi : il doit se demander en boucle (ce qui est le propre d'un « daemon » : de tourner comme un derviche tourneur) quelle est l'identité du système de fichiers de la partition n°4 afin de lui faire passer l'examen. Ce qui suffit à occuper la table de partition GPT, puisque une de ses entrées reste empruntée par un processus d'accès à une partition. Donc même si aucun volume n'est monté sur la partition n°4 > un processus reste en accès continu à la partition et la table de partition ne peut pas être désactivée (càd : le disque entier ne peut pas être "démonté").
Pas de veine : ça y était presque. Il aurait suffi de
reformater d'abord ou de
supprimer la partition n°
4 pour libérer la possibilité d'un retablage du disque. Mais une intervention bien lourde (
retablage du disque >
rétro-clonage du clone) > puisqu'à partir du moment où la partition n°
4 est
supprimée (= supprimée comme entrée de la table
GPT et virée à de l'
espace libre) --> la partition n°2
Macintosh HD peut récupérer cet espace.
À condition que le système de fichiers
JHFS+ de cette partition soit
sans erreur (sans quoi il ne peut pas être
étiré pour s'étendre aux blocs libérés et les inclure dans la partition gérée.
----------
Oui, mais (dira l'« entomologiste » informatique) --> il y une
partition intercalaire : la
Recovery HD disk0s3 ! Comment il fait, le système de fichiers
jhfs+ ancré sur l'en-tête de la partition
disk0s2 > pour
s'étirer aux
80 Go de blocs de l'ex-partition
disk0s4 > puisqu'existe sur le chemin une espèce de mur logique : la partition
disk0s3 de
650 Mo ?
Les ingénieurs informatiques sont fertiles en ruses apprises dans l'enfance, genre ici le
jeu de pousse-pousse permettant de permuter la position de cases en plastique dans un cadre doté d'un espace vide. Application informatique du principe du pousse-pousse -->
- diskutil crée en queue de disque un clone de la partition Recovery HD (donc un device disk0s4) > puis supprime l'original Recovery HD disk0s3 > de telle manière que les 80 Go de blocs libres constituent une bande continue allant du pied immédiat de la partition disk0s2 au commencement du clone Recovery HD disk0s4 > le système de fichiers jhfs+ de la partition disk0s2 est alors étiré pour couvrir les 80 Go de blocs libres contigus et les annexer à la partition disk0s2 dilatée > suite à quoi le clone Recovery HD disk0s4 se trouve recollé au pied de la partition disk0s2 aggrandie. Un re-démarrage permettant au kernel de renuméroter la partition Recovery HD comme disk0s3.
