Salut
cegondaire.
En synthèse de ton tableau de partitionnement : ça roule. Je ferais seulement une remarque nominale : lorsqu'une partition recèle un système de fichiers contenant un
OS X, je trouve qu'il vaut toujours mieux donner au volume (système de fichiers montable) en question un nom en rapport avec la version de l'OS supportée. Personnellement, je préfère
Mavericks, ou
Mavericks-SSD, dont les noms sont évocateurs de la nature de l'objet ; à
M4SSD ou autre
DAXTA dont les intitulés dissimulent au contraire la nature de l'objet.
♢
«Il y a plus [dans l'espace informatique] que n'en rêve ta philosophie, Horatio»
Tu poses des questions qu'il est raisonnable d'envisager - mais auxquelles il n'est pas tout à fait facile de répondre dans le langage du « bon sens ». Tu me passeras alors les quelques longueurs de prose qui suivent, dans lesquelles je m'essaye à cet exercice...
Dans une commande du type :
Bloc de code:
sudo diskutil mergepartitions JHFS+ LIONS disk1s4 disk1s5
sudo passe la requête préalable d'opérer en droits
root ;
diskutil est le «
sujet » de la proposition qu'est la commande : le programme UNIX invoqué ;
mergepartitions est le «
verbe » de cette proposition : le type d'action que va exercer le «
sujet », ici = fusionner des partitions ; tout ce qui suit constitue l'«
objet » de la proposition, qui se trouve ici distribué en une
triplette : le
format, le
nom et le(s)
device(
s).
jhfs+ est le format
Mac OS étendu (journalisé) ;
LIONS est le nom du volume qui va monter à partir de la nouvelle partition créée (ce nom est entièrement
quodlibétique, parce qu'il s'agit d'un "
performatif" : l'annonce nominale de ce que l'action va produire --> tu peux mettre
BROL si tu veux ; et non pas d'un "
indicatif" : le constat d'un état de fait nominal déjà donné) ; enfin
disk1s4 disk1s5 désignent les 2 partitions-cibles dont l'ordre n'est jamais quelconque : la partition numériquement
précédente dans la table des partitions devant toujours précéder la partition numériquement
conséquente, sous peine d'invalidité de la commande.
Car on ne peut pas fusionner des partitions en mode "
régressif" (la partition
disk1s4 à la partition
disk1s5 - ce qui voudrait dire que l'espace désigné par la partition
disk1s4 passerait "
derrière" celui de la partition
disk1s5), mais toujours en mode "
progressif" (la partition
disk1s5 à la partition
disk1s4, ce qui signifie que l'espace de la partition
disk1s5 va se souder
derrière l'espace de la partition
disk1s4 qui le
précède). Car les espaces-disque désignés sont des séries de
blocks qui obéissent à une numérotation fixe, chaque
block (
byte) équivalant à un alignement de 8
cellules physiques du disque chacune porteuse d'un
bit. Les alignements physiques de
cellules dont
fixes, et de même les regroupements en
blocks logiques de 8 cellules, et par suite la numérotation séquencielle des
blocks lesquels constituent l'espace-disque compris dans une partition. Par exemple, la partition
disk1s4 désigne la série des
blocks qui va de 100 000 à 1 999 999 et la partition
disk1s5 désigne la série de
blocks qui va de 2 000 000 à 5 000 000. On peut souder les blocks 2 000 000 à 5 000 000 à la
suite du dernier
block n° 1 999 999 dans un nouveau regroupement logique = partition, mais inversement on ne peut pas souder les
blocks 100 000 à 1 999 999
après le dernier
block 5 000 000, car ils sont indéplaçables.
Il s'ensuit que la partition mentionnée en
tête est toujours forcément celle qui regroupe les
blocks dont la numérotation
précède, et la partition mentionnée en
queue celle qui regroupe les
blocks dont la numération
suit, ce qui correspond à l'ordre numéral de ces partitions dans la table des
devices (supports d'écriture) : la
disk1s4 précède la
disk1s5. Il s'ensuit que la partition de
tête est la
bénéficiaire de la fusion, et la partition de
queue la
perdante, puisque c'est son espace "postérieur" dans l'ordre des
blocks concernés qui va se souder après celui de la partition qui la précède en tant qu'extension de celle-ci. Il s'ensuit que le système de fichiers (montant en volume) de la partition de
tête va se trouve
conservé après "dilatation" de son catalogue désignant les
blocks de référence ; alors que le système de fichiers de la partition de
queue va se trouver
détruit, avec cette partition.
=> en résumé : la partition "du-dessus" est conservée dans son identité tout en étant dilatée - mais la désignation nominale du volume augmenté résultant n'est pas fixée par l'indicatif du nom préexistant, mais fixable quodlibétiquement en mode performatif.
♤
Une commande
mergePartitions ciblant comme partition bénéficiaire une
/dev/disk1s4 (par exemple) n'est pas limitée à désigner comme partition d'apport la seule
immédiatement "en-dessous" dans l'ordre numéral des
devices (donc la
/dev/disk1s5 dans l'exemple), mais peut étirer la désignation jusqu'à la
dernière partition "du-dessous" existante (exemple une
/dev/disk1s11 si celle-ci existait d'après la commande
diskutil list). Dans tous les cas, il ne doit jamais y avoir
listage de la série de toutes les partitions d'apport intermédiaires impliquées entre la bénéficiaire de tête et la dernière qui marque la limite (genre :
disk1s4 disk1s5 disk1s6 disk1s7 disk1s8 disk1s9 disk1s10 disk1s11), mais uniquement mention après la partition
bénéficiaire de tête de la partition d'
apport constituant la
limite, càd. la
dernière (il faudrait donc mentionner uniquement :
disk1s4 disk1s11).
Alors, toutes les partitions comprises "en-dessous" de la partition de
tête bénéficiaire seront supprimées, avec leurs systèmes de fichiers, et leur espace ajouté à celui de la partition bénéficiaire de
tête conservée (dont le catalogue du système de fichiers sera étendu jusqu'à la référence du dernier
block concerné).
Peu importe le
format actuel des partitions d'
apport :
jhfs+,
Apple_Boot (s'il s'agit d'une «
Recovery HD»),
MS-DOS --> c'est logique, puisque leur système de fichiers est détruit par l'activation de la commande, pour libérer les
blocks concernés, lesquels vont être intégrés au catalogue préexistant du système de fichiers de la partition bénéficiaire de tête.
Mais le
format de la partition
bénéficiaire de
tête ne peut pas être quelconque : il doit être exclusivement un
jhfs+ (format Apple
extensible). S'il s'agissait d'un
MS-DOS (par exemple), le fusionnement ne pourrait pas se faire, par caractère inextensible de ce format de fichiers.
♧
Le programme Apple
dmtest mis en œuvre par le logiciel «
Recovery Partition Creator» opère toujours un re-partitionnement de 650 Mo de la partition qui lui donnée comme
cible. Si c'était une
/dev/disk1s2 Apple_HFS Macintosh HD, par exemple, que suivrait régulièrement une
/dev/disk1s3 = Apple_Boot Recovery HD, alors on obtiendrait une suite :
/dev/disk1s2 Apple_HFS Macintosh HD => /dev/disk1s3 = Apple_Boot Recovery HD => /dev/disk1s4 = Apple_Boot Recovery HD. Le programme
dmtest n'est donc pas un
coucou qui s'empare du nid vide (ou préoccupé) d'une partition préexistante, mais un
re-partitionneur qui crée toujours sa partition d'accueil au détriment de la partition-cible, avant de copier dessus le dossier de démarrage
com.apple.recovery.boot d'une partition «
Recovery HD».
Le logiciel «
Recovery Partition Creator» oblige (me semble-t-il) à choisir une partition où est installée une version d'
OS X pour opérer. Telle n'est pas la limitation intrinsèque du programme Apple
dmtest qui, invoqué en ligne de commande, peut créer une partition «
Recovery HD» absolument où l'on veut, même à partir d'une partition-cible de simple
stockage, sur une clé USB ou autre, ce pour autant que le format de cette partition soit
jhfs+ (càd. supporte le re-dimensionnement dynamique, ici par rétrécissement de son espace de référence).
♡