Impossible de fusionner des partitions
- Créateur du sujet Maxtroopers
- Date de début
D
Deleted member 1099514
Invité
Salut
Pour ta première question : fusion de 2 partitions ça doit pouvoir se faire, mais les données de ALIONS seront perdues.
Dans tous les cas il vaudrait mieux sauvegarder les données des 32 partitions au cas où.
La première chose à faire serait de lister la map du disque :
sudo hdiutil pmap /dev/disk1
et donner les retours.
Pour la deuxième question il faut télécharger la version du système installé (Mavericks dans ton cas), ne pas l'installer bien sûr., puis télécharger Recovery Partition Creator puis l'installer et le lancer. Quand tu seras interrogé sur l'emplacement où installer tu sélectionneras la partition M4SSD puis quand tu seras interrogé sur "Choose the location of your OS X Installer" là il faudra sélectionner dans Applications "Installer OS X Mavericks" et voilà.
Pour Lion sur DAXTA sur /dev/disk1 (et non disk0) il faudrait te servir de ceci : https://jamfnation.jamfsoftware.com/discussion.html?id=10624 post #2
Pour ta première question : fusion de 2 partitions ça doit pouvoir se faire, mais les données de ALIONS seront perdues.
Dans tous les cas il vaudrait mieux sauvegarder les données des 32 partitions au cas où.
La première chose à faire serait de lister la map du disque :
sudo hdiutil pmap /dev/disk1
et donner les retours.
Pour la deuxième question il faut télécharger la version du système installé (Mavericks dans ton cas), ne pas l'installer bien sûr., puis télécharger Recovery Partition Creator puis l'installer et le lancer. Quand tu seras interrogé sur l'emplacement où installer tu sélectionneras la partition M4SSD puis quand tu seras interrogé sur "Choose the location of your OS X Installer" là il faudra sélectionner dans Applications "Installer OS X Mavericks" et voilà.
Pour Lion sur DAXTA sur /dev/disk1 (et non disk0) il faudrait te servir de ceci : https://jamfnation.jamfsoftware.com/discussion.html?id=10624 post #2
D
Deleted member 1099514
Invité
Pas facile à suivre ta prose en rouge. Il vaudrait mieux donner les retours sans rappeler le contexte et hors balises Code.
Première question. "Fusion des partitions" :
Il serait plus sûr de sauvegarder aussi le contenu de LIONS (il fallait comprendre : "sauvegarder les données des 2 partitions" au lieu de "sauvegarder les données des 32 partitions". Millexcuses
Tu tapes la commande :
sudo diskutil mergepartitions JFS+ LIONS disk1s4 disk1s5
Par contre si tu veux agrandir DAXTA la solution serait la suivante :
Sauvegarder les 2 partitions LIONS et ALIONS, les supprimer, agrandir la partition système (DAXTA) depuis Mavericks. Créer la partition Recovery :
Pour l'install de la Recovery, télécharger Lion (comme pour Maverick : la version complète et non la mise à jour) et repasser Recovery Partition Creator. Normalement ça devrait fonctionner depuis Mavericks à condition de bien sélectionner les bonnes partitions.
Si ça cloche le faire depuis Lion.
Enfin créer une partition dans l'espace libre de disk1 et y copier le contenu des 2 partitions précédemment sauvegardées.
Tu as du pain sur la planche.
Première question. "Fusion des partitions" :
Il serait plus sûr de sauvegarder aussi le contenu de LIONS (il fallait comprendre : "sauvegarder les données des 2 partitions" au lieu de "sauvegarder les données des 32 partitions". Millexcuses
Tu tapes la commande :
sudo diskutil mergepartitions JFS+ LIONS disk1s4 disk1s5
Par contre si tu veux agrandir DAXTA la solution serait la suivante :
Sauvegarder les 2 partitions LIONS et ALIONS, les supprimer, agrandir la partition système (DAXTA) depuis Mavericks. Créer la partition Recovery :
Pour l'install de la Recovery, télécharger Lion (comme pour Maverick : la version complète et non la mise à jour) et repasser Recovery Partition Creator. Normalement ça devrait fonctionner depuis Mavericks à condition de bien sélectionner les bonnes partitions.
Si ça cloche le faire depuis Lion.
Enfin créer une partition dans l'espace libre de disk1 et y copier le contenu des 2 partitions précédemment sauvegardées.
Tu as du pain sur la planche.
M
Membre supprimé 1060554
Invité
Jean.Je corrige ta commande de fusion des partitions concernant le verbe => il faut écrire mergePartitions avec un "P" et pas un "p" (la commande étant sensible à la casse sous ce rapport), ce qui donne :
Bloc de code:
sudo diskutil mergePartitions JFS+ LIONS disk1s4 disk1s5En mode "redite" de ta préconisation @cegondaire :
- a) une fois la synthèse des espaces-disque opérée par la commande ci-dessus, sauvegarder le contenu du volume LIONS sur un DDE.
- b) cela fait, dans l'«Utilitaire de Disque» sélectionner le disque physique global (disk1) et le menu "Partitionner" => sélectionner le rectangle du bas LIONS et presser le bouton "-" pour virer son espace au statut de free_space (espace libre non identifié en terme de partition de la Carte GUID) => "Appliquer".
- c) pincer alors le milieu de ligne de base du rectangle supérieur DAXTA et l'abaisser de la valeur voulue pour augmenter ce rectangle (sans perte pour le système de fichiers de cette partition) => "Appliquer".
- d) sélectionner alors l'espace libre de queue affiché en grisé, et choisir le menu "Effacer" en choisissant en sortie : nom = LIONS et format = Mac OS étendu (journalisé) pour recréer une partition LIONS => "Appliquer".
- e) recopier alors les données sauvegardées sur le DDE dans le volume rétréci (mais encore de bonne taille) : LIONS.
- b) cela fait, dans l'«Utilitaire de Disque» sélectionner le disque physique global (disk1) et le menu "Partitionner" => sélectionner le rectangle du bas LIONS et presser le bouton "-" pour virer son espace au statut de free_space (espace libre non identifié en terme de partition de la Carte GUID) => "Appliquer".
- c) pincer alors le milieu de ligne de base du rectangle supérieur DAXTA et l'abaisser de la valeur voulue pour augmenter ce rectangle (sans perte pour le système de fichiers de cette partition) => "Appliquer".
- d) sélectionner alors l'espace libre de queue affiché en grisé, et choisir le menu "Effacer" en choisissant en sortie : nom = LIONS et format = Mac OS étendu (journalisé) pour recréer une partition LIONS => "Appliquer".
- e) recopier alors les données sauvegardées sur le DDE dans le volume rétréci (mais encore de bonne taille) : LIONS.
--------------------
Me sentant en verve, j'en profite pour faire un petit commentaire du tableau des blocks (clusters) du /dev/disk1 :
Bloc de code:
1 EFI 40 409600 EFI System Partition
2 Apple_HFS 409640 313164976 SNOWS
Free 313574616 262144
3 Apple_HFS 313836760 203041024 DAXTA
Free 516877784 3179240
4 Apple_HFS 520057024 241021952 LIONS
Free 761078976 262144
5 Apple_HFS 761341120 215169864 ALIONS
Free 976510984 262151Pour chaque partition mentionnée dans l'ordre, le 1er nombre désigne le n° du block de départ et le 2è nombre le nombre total de blocks de la partition. Ce qui fait qu'additionner au n° du block de départ le nombre des blocks solidaires donne le n° du block de départ de la partition qui suit. Exemple pour la partition /dev/disk1s1 de l'EFI : 40 est le n° du block de départ ; le nombre de blocks solidaires est de 409600 (très petite partition) => le n° du block de départ de la partition qui suit est donc : 40 + 409600 --> 409640.
On note une légère complication : l'intercalement de bandes intitulées Free (= free_space : espace libre hors partitionnement) entre les partitions 2-3, 3-4, 4-5, et après 5. C'est entièrement normal du point de vue Apple : les partitions identifiées sont régulièrment séparées entre elles par une zone d'espace libre hors partionnement qui joue un rôle de tampon. On notera que la taille de ces zones tampons de free_space oscille de 262144 blocks (2 fois : c'est la taille standard) à 262151 blocks (une fois pour la zone de queue) => dans les 100 Mo. L'exception est de 3179240 blocks pour la bande de free_space tampon après la partition démarrable DATA, soit 12 fois plus que la taille régulière => dans les 1,3 Go. Sans doute la trace de la suppression de la «Recovery HD» qui avait été créée au départ juste en-dessous, après une séparation régulière d'environ 262144 blocks d'espace_libre.
Cet espace libre excédentaire devrait être régularisé par les manips de repartitionnement décrites ci-dessus.
--------------------
Pour la recréation des «Recovery HD» => je te renvoie, cegondaire, aux préconisations de Jean.
Par rapport à ton inquiétude concernant ta partition «BootCamp» sur le /dev/disk0 => il y aura d'abord un repartitionnement qui n'affectera que la partition du dessus : la 2: Apple_HFS M4SSD 135.9 GB disk0s2 qui sera légèrement rétrécie pour permettre la création d'une partition de 650 Mo. Tout cela s'opèrera purement et simplement à l'intérieur de la série de blocks de la partition n°2, sans aucun empiètement sur la partition n°3 = 3: Microsoft Basic Data BOOTCAMP 119.8 GB disk0s3. De plus, comme souligné dans le § ci-dessus, une zone tampon d'espace libre d'au moins 262144 blocks sépare les partitions n°2 (OS X) et n° 3 (Windows) => la partition «BootCamp» ne sera donc nullement affectée par le repartitionnement.
Enfin, tu peux opérer depuis l'OS que tu veux. «Recovery Partition Creator» a pompé entièrement un programme Apple : dmtest (présent dans ses Resources) créé à l'époque de «Lion 10.7» pour créer une partition «Recovery HD» absente et qui a une fonctionnalité universelle : il est opératif quelque soit l'OS hôte («Lion 10.7» minimum), et quelle que soit la version de la «Recovery HD» à créer d'après un installateur d'OS X. J'ajoute que le repartitionnement en mode "live" étant parfaitement supporté, tu peux exécuter dmtest (via «Recovery Partition Creator» qui n'en est qu'une enveloppe graphique) sous l'OS M4SSD démarré à destination de sa propre partition d'accueil en vue de rétrécissement et de création d'une «Recovery HD» en-dessous : no problemo.
=> je te conseillerais seulement de faire les choses avec « ordre et méthode » en commençant par régler ton problème de repartitionnement en premier lieu...
--------------------
Dernière édition par un modérateur:
D
Deleted member 1099514
Invité
@macomaniac
Il me semble que la commande :
sudo diskutil mergepartitions
fonctionne avec ou sans majuscules.
Tu peux faire un essai.
Il me semble que la commande :
sudo diskutil mergepartitions
fonctionne avec ou sans majuscules.
Tu peux faire un essai.
M
Membre supprimé 1060554
Invité
Tu as raison : non sensible à la casse (je viens de tester). C'est comme pour CoreStorage, corestorage, coreStorage... Donc mergePartitions et mergepartitions = bonnet blanc & blanc bonnet...
... autant pour moi (il m'était venu la réminiscence de je ne sais plus quelle commande pointilleuse concernant la majuscule - mais finalement, diskutil (comme hdiutil) : c'est un bon gars pas trop regardant à la graphie).
D
Deleted member 1099514
Invité
Désolé de répondre tardivement. En fait je suis surpris de ne pas voir ma réponse que j'avais rédigée hier pour jeanjd63 ! J'ai probablement omis de cliquer sur "Poster votre réponse" avant de rebooter. Comme le sujet s'est étoffé avec un nouvel intervenant, je réponds conjointement à jeanjd63 et macomaniac.
Merci Jeanjd63 pour tes suggestions. Mais j'ai manqué de patience et surtout eu la flemme de sauvegarder aussi le contenu de LIONS sur un DDE. Je suis donc passé par Utilitaire de Disque avec lequel j'ai supprimé ALIONS puis agrandi LIONS en récupérant l'espace libre libéré par ALIONS, et finalement j'ai recopié le contenu de ALIONS précédemment sauvegardé sur la nouvelle partition LIONS.
J'ai pu, avec Utilitaire de Disque, récupérer à peine plus de 1 Go, m'a-t-il semblé, d'espace supplémentaire pour DAXTA en tirant vers le bas la ligne de basedu rectangle.
J'ai également utilisé la version 3.8 de Recovery Partition Creator pour créer la partition de Recovery. J'ai un peu galéré car je disposais de 2 versions de l'instal de Lion (10.7 Lion build 11A511 et 10.7.4 Lion build 11E53). J'ai fais 2 tentatives en alternant les versions, mais sans succès. A la troisième ça a marché. Seulement, au reboot (en mode verbose), j'ai un message qui m'annonce que "la plateforme
n'est pas celle attendue, ne correspondant pas à la partition Recovery installée" (traduction à la louche) et ça reste scotché là (obligé de redémarrer à la sauvage). Je pense que c'est probablement dû au fait que j'étais sous Mavericks quand j'ai fait les manips, car après vérifications via Utilitaire de Disque la nouvelle partition de Recovery est bien située sous M4SSD, juste avant BOOTCAMP. Je sais bien, macomaniac que tu considères [certainement à bon droit, je n'entends pas discuter ton expérience en la matière] que l'on peut opérer depuis n'importe quel OS pour créer une partition de restauration, poputant je ne vois pas quelle autre cause rationnelle pourrait expliquer cet échec.
Je vais donc rebooter sous Lion et procéder aux mêmes manips. Bien sûr, il fait préalablement que j'efface la partition Recovery non fonctionnelle. Puisque Utilitaire de Disque ne permet pas l'effacement de RecoveryHD (même avec le menu Déboguer) je pensais utiliser iPartiton, mais ma version est trop vieille (problème de licence). Je vais utiliser un CD Gparted Live, meilleur outil de repartitionnement d'après ce qui se dit, et je reviens avec le résultat dans quelque temps.
A plus...
Merci Jeanjd63 pour tes suggestions. Mais j'ai manqué de patience et surtout eu la flemme de sauvegarder aussi le contenu de LIONS sur un DDE. Je suis donc passé par Utilitaire de Disque avec lequel j'ai supprimé ALIONS puis agrandi LIONS en récupérant l'espace libre libéré par ALIONS, et finalement j'ai recopié le contenu de ALIONS précédemment sauvegardé sur la nouvelle partition LIONS.
J'ai pu, avec Utilitaire de Disque, récupérer à peine plus de 1 Go, m'a-t-il semblé, d'espace supplémentaire pour DAXTA en tirant vers le bas la ligne de basedu rectangle.
J'ai également utilisé la version 3.8 de Recovery Partition Creator pour créer la partition de Recovery. J'ai un peu galéré car je disposais de 2 versions de l'instal de Lion (10.7 Lion build 11A511 et 10.7.4 Lion build 11E53). J'ai fais 2 tentatives en alternant les versions, mais sans succès. A la troisième ça a marché. Seulement, au reboot (en mode verbose), j'ai un message qui m'annonce que "la plateforme
n'est pas celle attendue, ne correspondant pas à la partition Recovery installée" (traduction à la louche) et ça reste scotché là (obligé de redémarrer à la sauvage). Je pense que c'est probablement dû au fait que j'étais sous Mavericks quand j'ai fait les manips, car après vérifications via Utilitaire de Disque la nouvelle partition de Recovery est bien située sous M4SSD, juste avant BOOTCAMP. Je sais bien, macomaniac que tu considères [certainement à bon droit, je n'entends pas discuter ton expérience en la matière] que l'on peut opérer depuis n'importe quel OS pour créer une partition de restauration, poputant je ne vois pas quelle autre cause rationnelle pourrait expliquer cet échec.
Je vais donc rebooter sous Lion et procéder aux mêmes manips. Bien sûr, il fait préalablement que j'efface la partition Recovery non fonctionnelle. Puisque Utilitaire de Disque ne permet pas l'effacement de RecoveryHD (même avec le menu Déboguer) je pensais utiliser iPartiton, mais ma version est trop vieille (problème de licence). Je vais utiliser un CD Gparted Live, meilleur outil de repartitionnement d'après ce qui se dit, et je reviens avec le résultat dans quelque temps.
A plus...
D
Deleted member 1099514
Invité
Un peu tard peut être, mais le terminal permet de supprimer la partition Recovery bancale.
S'il n'est pas trop tard il faudrait donner les retours de :
diskutil list
S'il n'est pas trop tard il faudrait donner les retours de :
diskutil list
Bonjour j'ai un petit pb, il m'ait impossible du supprimer une partition de disque via l'utilitaire de disque en effet on peut supprimer une partition en cliquant sur le petit ( - ) mais j'ai une partition qui fait 137mo que j'arrive pas a supprimer le petit ( - ) étant grisée je ne peux la supprimer si quelqu'un veut bien m'éclaircir je suis preneur merci
Au temps pour moi(¹).
J'ai eu la bonne idée, avant de booter sur Gparted Live, de vérifier si je pouvais accéder à la RecoveryHD de Lion, et cette fois ça s'est passé sans problème... sauf que le raccourci Pomme-R ne fonctionnait pas, j'avais une succession rapide de "pages d'accueil" à l'écran. Mais en lâchant le raccourci je basculais immédiatement sur l'interface de ReFind (v0.9.2), où je pouvais choisir l'une des 2 icônes de boot Recovery. J'ai testé les 2 et ça a marché dans les 2 cas. Pour lever toute spéculation, j'ai rebooté en passant cette fois-ci par le raccourci de démarrage classique "Option" qui offrait, entre autres, les options Recovery (avec l'indication "10.9") [partition qui n'avait auparavant jamais posé de problème] et Recovery (sans précision). Là aussi le démarrage sur les 2 Recovery a fonctionné. Pourtant, ce n'est pas faute d'avoir essayé hier à plusieurs reprises de booter sur la Recovery créée à partir de Lion, en vain. Je ne m'explique pas pourquoi, sans que rien de notable n'ait changé dans la configuration des Systèmes et des partitions, ça marche aujourd'hui ! Cela dit, je vais pas m'en plaindre.
Puisque j'ai en quelque sorte "sous la main" 2 experts, je voudrais savoir si (dans) la commande :
a) sudo diskutil mergepartitions JFS+ LIONS disk1s4 disk1s5
1- LIONS désigne le nom de la nouvelle partition fusionnée ou bien le nom de la première partition à partir de laquelle s'effectue la fusion ?
2- vaut aussi, si on ajoute, par exemple, une 3ème partition contigüe ? genre :
sudo diskutil mergepartitions JFS+ LIONS disk1s4 disk1s5 disk1s6
b) et est-ce qu'elle fonctionne si entre disk1s4 et disk1s5 se trouve intercalée une Recovery HD ?
Je me suis demandé après coup est-ce que plutôt que chercher à supprimer la partition Recovery (que je croyais) défaillante (avec iPartition ou Gparted) j'aurais pu effacer son contenu (avec Utilitaire de Disque) et essayer d'en installer une nouvelle (avec Recovery Partition Creator) qui se serait, tel un coucou, nichée dans la Recovery vide ?
Sinon, je trouve "tactiquement" plus logique d'installer un Recovery HD dans chacun des 2 disques durs internes d'un ordi plutôt que dans un seul en cas de panne mécanique de l'un ou l'autre des disques. Ça se tient ? Ou bien ?
Merci pour toutes les réponses de votre part, passées ou à venir.
(1) "Au temps pour moi" exprime la reconnaissance d'une erreur, généralement suivie de sa correction si elle n'a pas déjà été exprimée (oralement ou noir sur blanc). Elle signifie que celui qui parle (ou écrit) reconnaît que la faute vient de lui, de même que la graphie, plus tardive, "autant pour moi", qui est de plus en plus admise quoique l'académie française la considère comme fautive.
J'ai eu la bonne idée, avant de booter sur Gparted Live, de vérifier si je pouvais accéder à la RecoveryHD de Lion, et cette fois ça s'est passé sans problème... sauf que le raccourci Pomme-R ne fonctionnait pas, j'avais une succession rapide de "pages d'accueil" à l'écran. Mais en lâchant le raccourci je basculais immédiatement sur l'interface de ReFind (v0.9.2), où je pouvais choisir l'une des 2 icônes de boot Recovery. J'ai testé les 2 et ça a marché dans les 2 cas. Pour lever toute spéculation, j'ai rebooté en passant cette fois-ci par le raccourci de démarrage classique "Option" qui offrait, entre autres, les options Recovery (avec l'indication "10.9") [partition qui n'avait auparavant jamais posé de problème] et Recovery (sans précision). Là aussi le démarrage sur les 2 Recovery a fonctionné. Pourtant, ce n'est pas faute d'avoir essayé hier à plusieurs reprises de booter sur la Recovery créée à partir de Lion, en vain. Je ne m'explique pas pourquoi, sans que rien de notable n'ait changé dans la configuration des Systèmes et des partitions, ça marche aujourd'hui ! Cela dit, je vais pas m'en plaindre.
Puisque j'ai en quelque sorte "sous la main" 2 experts, je voudrais savoir si (dans) la commande :
a) sudo diskutil mergepartitions JFS+ LIONS disk1s4 disk1s5
1- LIONS désigne le nom de la nouvelle partition fusionnée ou bien le nom de la première partition à partir de laquelle s'effectue la fusion ?
2- vaut aussi, si on ajoute, par exemple, une 3ème partition contigüe ? genre :
sudo diskutil mergepartitions JFS+ LIONS disk1s4 disk1s5 disk1s6
b) et est-ce qu'elle fonctionne si entre disk1s4 et disk1s5 se trouve intercalée une Recovery HD ?
Je me suis demandé après coup est-ce que plutôt que chercher à supprimer la partition Recovery (que je croyais) défaillante (avec iPartition ou Gparted) j'aurais pu effacer son contenu (avec Utilitaire de Disque) et essayer d'en installer une nouvelle (avec Recovery Partition Creator) qui se serait, tel un coucou, nichée dans la Recovery vide ?
Sinon, je trouve "tactiquement" plus logique d'installer un Recovery HD dans chacun des 2 disques durs internes d'un ordi plutôt que dans un seul en cas de panne mécanique de l'un ou l'autre des disques. Ça se tient ? Ou bien ?
Merci pour toutes les réponses de votre part, passées ou à venir.
(1) "Au temps pour moi" exprime la reconnaissance d'une erreur, généralement suivie de sa correction si elle n'a pas déjà été exprimée (oralement ou noir sur blanc). Elle signifie que celui qui parle (ou écrit) reconnaît que la faute vient de lui, de même que la graphie, plus tardive, "autant pour moi", qui est de plus en plus admise quoique l'académie française la considère comme fautive.
@jeanjd63
Un peu tard effectivement (j'ai trainé), c'est pas grave pour autant car, comme tu pourras le lire dans mon précédent post, je n'ai pas eu à effectuer cette suppression.
Mais, si tu veux m'indiquer la commande sous Terminal pour supprimer une partition Recovery, je suis preneur (je suppose que c'est la mêm commande pour une partition "ordinaire").
Voici résultat de diskutil list :
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *256.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS M4SSD 135.4 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: Microsoft Basic Data BOOTCAMP 119.8 GB disk0s4
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_HFS SNOWS 160.3 GB disk1s2
3: Apple_HFS LIONS 104.9 GB disk1s3
4: Apple_Boot Recovery HD 650.0 MB disk1s4
5: Apple_HFS DAXTA 233.7 GB disk1s5
[Il faut savoir qu'hier j'ai modifié l'emplacement des Systèmes (Lion qui était sur M4SSD est maintenant sur LIONS, inversement Mavericks qui était sur DAXTA est passé sur M4SSD) d'une part et, de l'autre, j'ai changé-déplacé le nom de certaines partitions (DAXTA est le nom de la nouvelles partition fusionnée et LIONS a pris le nom de DAXTA. Seule SNOWS est à la même place avec le même nom et le même Système.]
Un peu tard effectivement (j'ai trainé), c'est pas grave pour autant car, comme tu pourras le lire dans mon précédent post, je n'ai pas eu à effectuer cette suppression.
Mais, si tu veux m'indiquer la commande sous Terminal pour supprimer une partition Recovery, je suis preneur (je suppose que c'est la mêm commande pour une partition "ordinaire").
Voici résultat de diskutil list :
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *256.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS M4SSD 135.4 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: Microsoft Basic Data BOOTCAMP 119.8 GB disk0s4
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_HFS SNOWS 160.3 GB disk1s2
3: Apple_HFS LIONS 104.9 GB disk1s3
4: Apple_Boot Recovery HD 650.0 MB disk1s4
5: Apple_HFS DAXTA 233.7 GB disk1s5
[Il faut savoir qu'hier j'ai modifié l'emplacement des Systèmes (Lion qui était sur M4SSD est maintenant sur LIONS, inversement Mavericks qui était sur DAXTA est passé sur M4SSD) d'une part et, de l'autre, j'ai changé-déplacé le nom de certaines partitions (DAXTA est le nom de la nouvelles partition fusionnée et LIONS a pris le nom de DAXTA. Seule SNOWS est à la même place avec le même nom et le même Système.]
D
Deleted member 1099514
Invité
Si tu veux supprimer la partition Recovery du HDD tu tapes la commande :
diskutil erasevolume free space /dev/disk1s4
Ensuite si tu veux récupérer cet espace tu peux taper la commande :
diskutil resizevolume /dev/disk1s3 0b
diskutil erasevolume free space /dev/disk1s4
Ensuite si tu veux récupérer cet espace tu peux taper la commande :
diskutil resizevolume /dev/disk1s3 0b
M
Membre supprimé 1060554
Invité
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.
Dans une commande du type :
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).
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...«Il y a plus [dans l'espace informatique] que n'en rêve ta philosophie, Horatio»
Dans une commande du type :
Bloc de code:
sudo diskutil mergepartitions JHFS+ LIONS disk1s4 disk1s5Car 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).
♡
Dernière édition par un modérateur:
Ok, merci. Je suis encore néophyte en matière de lignes de commande, mais je me soigne.
Si j'ai bien capté, le première commande [diskutil erasevolume free space /dev/disk1s4] supprime la partition qu'occupe la Recovery HD (que je pensais à tort défaillante) ; la seconde [diskutil resizevolume /dev/disk1s3 0b] fusionne en quelque sorte avec l'espace libéré par la suppression de disk1s4. Mais que signifie " 0b" situé en fin de ligne ?
D
Deleted member 1099514
Invité
Le 0b signifie de prendre l'espace libéré même s'il n'est pas contiguë à la partition à agrandir.
C'est intéressant ça. Mais alors on peut agrandir une partition en pompant des l'espace libre (récemment libéré par la commande précédente) où que ce dernier se trouve (« même s'il n'est pas contiguë à la partiton à agrandir »), par exemple sur disk1s7 ? Je pensais qu'une partition ne pouvait être que d'un seul tenant !
D
Deleted member 1099514
Invité
Peut être pas aussi simple que ça. Si c'est une partition de Recovery qui se trouve intercalé entre la partition à agrandir et l'espace libre il n'y aura pas de problème. Dans les autres cas, il faut tester.
Notre @macomaniac maître es partitions (et autres) se fera un plaisir d'éclairer ta lanterne sur le sujet.
Notre @macomaniac maître es partitions (et autres) se fera un plaisir d'éclairer ta lanterne sur le sujet.
M
Membre supprimé 1060554
Invité
Je ne sais pas si ma prose a le pouvoir combustible d'enflammer des lanternes - comme Jean lui en prête aimablement la vertu ; espérons du moins qu'elle donne une version "humainement lisible " (human_readable) de "protocoles imbittables illisibles"
de l'informatique.
Un « partitionnement », c'est la « matière » de l'espace-disque interprétée dans l'abstraction d'une « forme » logique (comme aurait dit le scolastique St Thomas d'après son maître Aristote).
La « matière » de l'espace-disque est constituée par une succession linéaire de cellules physiques contiguës porteuses chacune d'un bit.
Le « partitionnement » commence par faire correspondre à chaque suite de 8 cellules de l'espace-disque l'unité formelle d'un « byte », bytes qui sont regroupés à leur tour par séries de 512 dans l'unité d'un « block » logique, ou « cluster ». Ces blocks logiques sont numérotés de 1 à n en congruence avec la succession linéaire des cellules physiques contiguës. Il y a donc parallélisme strict entre la succession linéaire des cellules physiques et la numérotation des blocks logiques.
Les blocks logiques, à leur tour, sont regroupés dans des « partitions » : suite de blocks numérotés de manière continue comprise entre 2 limites : le block de départ et le block de fin, qui constitue un secteur logique. Les « partitions » sont elles-mêmes numérotées de manière continue (de 1 à n) dans une table des devices : disk0s1, disk0s2 etc.
Chaque secteur logique d'une partition est géré par un dispositif formel spécifique qui est un filesystem : système de fichiers. Un système de fichiers se caractérise entre autres par un format (exemple : jhfs+). Un « volume » est le produit de la combinaison : suite de blocks d'une partition x système de fichiers, qui a pour propriété de "monter" comme interface d'opérations de lecture et d'écriture.
Dans ce contexte, la commande de type : diskutil eraseVolume affecte directement le « volume » d'une partition prise pour cible, en le soumettant à une transformation décrite par un triplet : format name device => affecter le secteur logique d'un device en supprimant son système de fichiers pour le remplacer par un neuf conforme à tel format et à tel nom. Par exemple : diskutil eraseVolume jhfs+ BROL /dev/disk0s4.
Mais cette commande autorise une exception : choisir en guise de "format" free (ou free\ space, ou encore "Free Space") => ce format est en fait un non-format, qui suspend le remplacement du système de fichiers supprimé par un nouveau => le secteur logique du device-cible va donc se trouver libéré de sa gestion par un système de fichiers. Par suite, la partition concernée n'étant plus gérée en un volume montable, cesse d'avoir une valeur logique et disparaît de la table des devices.
Mais la série des blocks logiques qui constituait le secteur de cette partition demeure la même continuité de clusters qu'auparavant, occupant le même rang (de x à x+n) dans la numérotation totale des blocks du disque. Seulement, c'est une série numérale à laquelle ne correspond plus de système de fichiers lui donnant la forme d'un volume.
Le programme diskutil n'a pas la compétence pour recréer directement une partition, avec un système de fichiers produisant un volume, à partir d'une zone d'espace libre prise pour cible. Car, pour cela, il faudrait pouvoir lister la série numérotée des blocks du disque, de manière à connaître le n° du 1er block libre et le n° du dernier block libre, en vue de passer une commande de recréation d'une partition par renseignement de ces n° de blocks disponibles. Cette fonctionnalité n'est pas dans les attributions de diskutil, mais relève d'un autre programme qui est gpt.
Mais le programme diskutil peut ré-intégrer de l'espace-libre au secteur logique d'une partition déjà constituée, de manière à augmenter sa taille. Ce type d'opération est soumise à 3 conditions strictes, avec une exception. La 1ère condition est que la partition "bénéficiaire" de la récupération de l'espace libre doit toujours précéder (du point de vue de la numérotation des blocks impliqués) l'espace libre. La 2è condition est que le format du système de fichiers de la partition bénéficaire doit être le format Apple : HFS(+), seul susceptible d'extensivité. La 3è condition est qu'aucune partition déjà constituée (avec un système de fichiers produisant un volume) ne doit se trouver intercalée entre la partition désignée comme bénéficiaire et l'espace libre, toujours du point de vue de la numérotation des blocks impliqués.
À supposer des partitions disk0s5, disk0s6 et disk0s7 (volumes de stockage au format jhfs+), et à supposer que la partition disk0s7 ait été virée à de l'espace libre, la partition disk0s5 ne peut jamais être la bénéficiaire de sa récupération, car une partition disk0s6 existe sur le chemin. Ce qui revient à dire qu'une partition ne peut correspondre qu'à une série continue de blocks d'un seul tenant, et ne peut pas fédérer des séries de blocks discontinus dans leur numérotation. Dans le contexte de cet exemple, c'est la partition disk0s6 qui seule peut être la bénéficiaire de la récupération de l'espace libre existant juste en-dessous d'elle. La commande régulière pour qu'elle récupère l'espace libre serait donc : diskutil resizeVolume jhfs+ BROL /dev/disk0s6 -R (l'option -R, abrégé de "recursive", ciblant toute la profondeur de l'espace libre disponible juste en-dessous de la limite de la partition bénéficiaire, jusqu'à la butée constituée éventuellement par le commencement d'une autre partition).
J'ai annoncé une exception : elle est constituée par le type de partition : «Recovery HD» dont le système de fichiers possède un format absolument exceptionnel : le format Apple_Boot. Lorsqu'une partition au format Apple_Boot s'intercale entre une partition au format jhfs+ et de l'espace libre (dans mon exemple, on supposera que la disk0s6 est en Apple_Boot), alors cette partition ne constitue pas un obstacle à la capacité pour la partition qui la précède de récupérer de l'espace libre présent en-dessous de la partition Apple_Boot (emplacements toujours conformes à la numération absolue des blocks impliqués, qui sont invariants numéralement).
J'ai déjà dit qu'une partition ne peut pas fédérer dans un secteur logique unique 2 séries numérotées de blocks discontinues. La partition disk0s5 (dans mon exemple) ne peut donc pas venir fédérer les blocks de la ci-devant disk0s7 virée à de l'espace libre, puisqu'ils sont en discontinuité de numérotation à cause de la série intercalaire correspondant à la «Recovery HD». Alors comment est-ce possible ?
C'est possible, uniquement si le système de fichiers de la partition Apple_Boot intercalaire se trouve cloné sur la série de blocks libres de queue avec recréation d'une partition spécifique, suite à quoi les blocks précédemment affectés à la partition /dev/disk6 se trouvent libérés du système de fichiers primitif et virés à de l'espace libre => alors l'espace libre se trouvant directement en-dessous de la partition bénéficiaire peut lui être ajouté.
Une série de commandes complexe en sous-main se trouve donc passée par le programme diskutil qui a la particularité d'être un « wrapper » : un "enveloppeur de commandes subalternes" (ou un gestionnaire de programmes élémentaires) : [en mode exception] au programme gpt pour inventaire de blocks et création d'une partition de 650 Mo, au programme asr pour clonage du système de fichiers Apple_Boot de la «Recovery HD», au programme diskutil pour effacement au format free_space de la ci-devant partition /dev/disk0s6, enfin au même diskutil pour redimensionnement de la partition bénéficaire à tout l'espace libre en-dessous d'elle désormais. Cette suite complexe est abrégée dans l'option : 0b (zéro byte) : « récupérer tout l'espace libre jusqu'au dernier byte disponible, ce sans obstacle d'une partition au format Apple_Boot éventuellement sur le chemin mais par déplacement de cette partition sur les derniers blocks vacants afin de dégager une série continue de blocks libres juste en-dessous de la partition bénéficiaire ».
[NB. L'utilisateur qui, suite à des suppressions anarchiques de partitions, se retrouve avec n bandes d'espace libre, ne sait pas a priori quels sont les emplacements de ces espaces libres dans la séquence continue de la numérotation des blocks. L'«Utilitaire de Disque» de la Vieille École avait la courtoisie de toujours passer une commande d'affichage de l'emplacement de l'espace libre (via hdiutil ou gpt), ce qui lui permettait de l'afficher, et ainsi l'utilisateur pouvait savoir quelles étaient les partitions bénéficiaires possibles de la récupération de l'espace libre, et entreprendre les manœuvres graphiques de cette réallocation. L'infâme caricature de ce qui fut un grand logiciel qu'est l'«Utilitaire de Disque» d'«EL Capitan» - détail qui suffirait à lui seul à condamner cet OS indûment encensé par une réclame d'avant la lettre - ne montre plus rien du tout et ne permet plus aucune manipulation graphique sur de l'espace libre. Il faut donc passer des commandes du type hdiutil pmap ou gpt show pour discerner où sont les bandes d'espace libre dans la série numérotée totale des blocks du disque. Une situation d'inégalité - synonyme d'injustice - est donc créée entre les spécialistes de la « ligne de commande » et les utilisateurs « graphiques », lesquels sont obligés de recourir à des forums d'aide pour parvenir à ce que l'«Utilitaire de Disque» de la Vieille École mettait directement à la disposition de leur entendement.]
[[Jean aura noté mon impasse volontaire sur le format spécial Apple_CoreStorage, équivalent en « extensivité » au format HFS(+) - mon topo étant déjà suffisamment longuet pour que je n'aille pas m'enliser dans l'examen de la plus complexe des créations d'Apple en matière de gestion des disques...]]
lui en prête aimablement la vertu ; espérons du moins qu'elle donne une version "humainement lisible " (human_readable) de "protocoles
Un « partitionnement », c'est la « matière » de l'espace-disque interprétée dans l'abstraction d'une « forme » logique (comme aurait dit le scolastique St Thomas d'après son maître Aristote).
La « matière » de l'espace-disque est constituée par une succession linéaire de cellules physiques contiguës porteuses chacune d'un bit.
Le « partitionnement » commence par faire correspondre à chaque suite de 8 cellules de l'espace-disque l'unité formelle d'un « byte », bytes qui sont regroupés à leur tour par séries de 512 dans l'unité d'un « block » logique, ou « cluster ». Ces blocks logiques sont numérotés de 1 à n en congruence avec la succession linéaire des cellules physiques contiguës. Il y a donc parallélisme strict entre la succession linéaire des cellules physiques et la numérotation des blocks logiques.
Les blocks logiques, à leur tour, sont regroupés dans des « partitions » : suite de blocks numérotés de manière continue comprise entre 2 limites : le block de départ et le block de fin, qui constitue un secteur logique. Les « partitions » sont elles-mêmes numérotées de manière continue (de 1 à n) dans une table des devices : disk0s1, disk0s2 etc.
Chaque secteur logique d'une partition est géré par un dispositif formel spécifique qui est un filesystem : système de fichiers. Un système de fichiers se caractérise entre autres par un format (exemple : jhfs+). Un « volume » est le produit de la combinaison : suite de blocks d'une partition x système de fichiers, qui a pour propriété de "monter" comme interface d'opérations de lecture et d'écriture.
Dans ce contexte, la commande de type : diskutil eraseVolume affecte directement le « volume » d'une partition prise pour cible, en le soumettant à une transformation décrite par un triplet : format name device => affecter le secteur logique d'un device en supprimant son système de fichiers pour le remplacer par un neuf conforme à tel format et à tel nom. Par exemple : diskutil eraseVolume jhfs+ BROL /dev/disk0s4.
Mais cette commande autorise une exception : choisir en guise de "format" free (ou free\ space, ou encore "Free Space") => ce format est en fait un non-format, qui suspend le remplacement du système de fichiers supprimé par un nouveau => le secteur logique du device-cible va donc se trouver libéré de sa gestion par un système de fichiers. Par suite, la partition concernée n'étant plus gérée en un volume montable, cesse d'avoir une valeur logique et disparaît de la table des devices.
Mais la série des blocks logiques qui constituait le secteur de cette partition demeure la même continuité de clusters qu'auparavant, occupant le même rang (de x à x+n) dans la numérotation totale des blocks du disque. Seulement, c'est une série numérale à laquelle ne correspond plus de système de fichiers lui donnant la forme d'un volume.
Le programme diskutil n'a pas la compétence pour recréer directement une partition, avec un système de fichiers produisant un volume, à partir d'une zone d'espace libre prise pour cible. Car, pour cela, il faudrait pouvoir lister la série numérotée des blocks du disque, de manière à connaître le n° du 1er block libre et le n° du dernier block libre, en vue de passer une commande de recréation d'une partition par renseignement de ces n° de blocks disponibles. Cette fonctionnalité n'est pas dans les attributions de diskutil, mais relève d'un autre programme qui est gpt.
Mais le programme diskutil peut ré-intégrer de l'espace-libre au secteur logique d'une partition déjà constituée, de manière à augmenter sa taille. Ce type d'opération est soumise à 3 conditions strictes, avec une exception. La 1ère condition est que la partition "bénéficiaire" de la récupération de l'espace libre doit toujours précéder (du point de vue de la numérotation des blocks impliqués) l'espace libre. La 2è condition est que le format du système de fichiers de la partition bénéficaire doit être le format Apple : HFS(+), seul susceptible d'extensivité. La 3è condition est qu'aucune partition déjà constituée (avec un système de fichiers produisant un volume) ne doit se trouver intercalée entre la partition désignée comme bénéficiaire et l'espace libre, toujours du point de vue de la numérotation des blocks impliqués.
À supposer des partitions disk0s5, disk0s6 et disk0s7 (volumes de stockage au format jhfs+), et à supposer que la partition disk0s7 ait été virée à de l'espace libre, la partition disk0s5 ne peut jamais être la bénéficiaire de sa récupération, car une partition disk0s6 existe sur le chemin. Ce qui revient à dire qu'une partition ne peut correspondre qu'à une série continue de blocks d'un seul tenant, et ne peut pas fédérer des séries de blocks discontinus dans leur numérotation. Dans le contexte de cet exemple, c'est la partition disk0s6 qui seule peut être la bénéficiaire de la récupération de l'espace libre existant juste en-dessous d'elle. La commande régulière pour qu'elle récupère l'espace libre serait donc : diskutil resizeVolume jhfs+ BROL /dev/disk0s6 -R (l'option -R, abrégé de "recursive", ciblant toute la profondeur de l'espace libre disponible juste en-dessous de la limite de la partition bénéficiaire, jusqu'à la butée constituée éventuellement par le commencement d'une autre partition).
J'ai annoncé une exception : elle est constituée par le type de partition : «Recovery HD» dont le système de fichiers possède un format absolument exceptionnel : le format Apple_Boot. Lorsqu'une partition au format Apple_Boot s'intercale entre une partition au format jhfs+ et de l'espace libre (dans mon exemple, on supposera que la disk0s6 est en Apple_Boot), alors cette partition ne constitue pas un obstacle à la capacité pour la partition qui la précède de récupérer de l'espace libre présent en-dessous de la partition Apple_Boot (emplacements toujours conformes à la numération absolue des blocks impliqués, qui sont invariants numéralement).
J'ai déjà dit qu'une partition ne peut pas fédérer dans un secteur logique unique 2 séries numérotées de blocks discontinues. La partition disk0s5 (dans mon exemple) ne peut donc pas venir fédérer les blocks de la ci-devant disk0s7 virée à de l'espace libre, puisqu'ils sont en discontinuité de numérotation à cause de la série intercalaire correspondant à la «Recovery HD». Alors comment est-ce possible ?
C'est possible, uniquement si le système de fichiers de la partition Apple_Boot intercalaire se trouve cloné sur la série de blocks libres de queue avec recréation d'une partition spécifique, suite à quoi les blocks précédemment affectés à la partition /dev/disk6 se trouvent libérés du système de fichiers primitif et virés à de l'espace libre => alors l'espace libre se trouvant directement en-dessous de la partition bénéficiaire peut lui être ajouté.
Une série de commandes complexe en sous-main se trouve donc passée par le programme diskutil qui a la particularité d'être un « wrapper » : un "enveloppeur de commandes subalternes" (ou un gestionnaire de programmes élémentaires) : [en mode exception] au programme gpt pour inventaire de blocks et création d'une partition de 650 Mo, au programme asr pour clonage du système de fichiers Apple_Boot de la «Recovery HD», au programme diskutil pour effacement au format free_space de la ci-devant partition /dev/disk0s6, enfin au même diskutil pour redimensionnement de la partition bénéficaire à tout l'espace libre en-dessous d'elle désormais. Cette suite complexe est abrégée dans l'option : 0b (zéro byte) : « récupérer tout l'espace libre jusqu'au dernier byte disponible, ce sans obstacle d'une partition au format Apple_Boot éventuellement sur le chemin mais par déplacement de cette partition sur les derniers blocks vacants afin de dégager une série continue de blocks libres juste en-dessous de la partition bénéficiaire ».
[NB. L'utilisateur qui, suite à des suppressions anarchiques de partitions, se retrouve avec n bandes d'espace libre, ne sait pas a priori quels sont les emplacements de ces espaces libres dans la séquence continue de la numérotation des blocks. L'«Utilitaire de Disque» de la Vieille École avait la courtoisie de toujours passer une commande d'affichage de l'emplacement de l'espace libre (via hdiutil ou gpt), ce qui lui permettait de l'afficher, et ainsi l'utilisateur pouvait savoir quelles étaient les partitions bénéficiaires possibles de la récupération de l'espace libre, et entreprendre les manœuvres graphiques de cette réallocation. L'infâme caricature de ce qui fut un grand logiciel qu'est l'«Utilitaire de Disque» d'«EL Capitan» - détail qui suffirait à lui seul à condamner cet OS indûment encensé par une réclame d'avant la lettre - ne montre plus rien du tout et ne permet plus aucune manipulation graphique sur de l'espace libre. Il faut donc passer des commandes du type hdiutil pmap ou gpt show pour discerner où sont les bandes d'espace libre dans la série numérotée totale des blocks du disque. Une situation d'inégalité - synonyme d'injustice - est donc créée entre les spécialistes de la « ligne de commande » et les utilisateurs « graphiques », lesquels sont obligés de recourir à des forums d'aide pour parvenir à ce que l'«Utilitaire de Disque» de la Vieille École mettait directement à la disposition de leur entendement.]
[[Jean aura noté mon impasse volontaire sur le format spécial Apple_CoreStorage, équivalent en « extensivité » au format HFS(+) - mon topo étant déjà suffisamment longuet pour que je n'aille pas m'enliser dans l'examen de la plus complexe des créations d'Apple en matière de gestion des disques...]]
Dernière édition par un modérateur:
Sujets similaires
10.12 Sierra
Réinstallation mac Sierra
