Disque externe illisible après tentative de repartitionnage (pour installer El Capitan, arf)

[iDanny]

Hi,

J'ai un disque externe Firewire de 1,5 To avec 2 partoches :
- 500 Go pour Time Machine
- 1 To pour des données diverses, avec 500 Go libre dessus environ

J'ai voulu créer une nouvelle partition de 250 Go pour y installer El Capitan, en réduisant celle de 1 To sur laquelle il reste donc assez de place.

Après avoir vérifié vite fait sur les internets que l'Utilitaire de Disque de mon bon vieux Snow Leo permet bien de réduire une partition sans supprimer son contenu, j'ai envoyé la sauce, et ça a commencé à mouliner.

Après un moment, je me suis rendu compte que j'étais en train d'écouter de la musique avec iTunes dont la librairie est sur la partition de 1 To. Du coup j'ai quitté iTunes, histoire de laisser l'Utilitaire de Disque faire son travail sur cette partition (quoique ça n'avait pas l'air de le déranger).

Ensuite j'ai laissé tout ça tourner, et environ 1h après le début des opérations, je suis revenu voir et le processus semblait bloqué à l'étape "Réduction du disque" : la barre de progression ne bougeait plus, et il n'y avait plus d'activité disque. L'Utilitaire de Disque reste "bloqué", càd qu'il ne me donne la main sur rien puisque tous ses boutons sont grisés et que je ne peux cliquer nulle part (enfin je peux mais ça ne fait aucune action). Mais l'appli répond bien et je n'ai pas de roue de la mort, ça semble juste arrêté tout bêtement. Il n'y a pas de message d'erreur dans le log, juste ça :

2015-10-08 10:23:18 +0200: Préparation de la partition du disque : « WD »
2015-10-08 10:23:18 +0200: Schéma de partition : Tableau de partition GUID
2015-10-08 10:23:18 +0200: 3 partitions seront créées
2015-10-08 10:23:18 +0200:
2015-10-08 10:23:18 +0200: Partition 1
2015-10-08 10:23:18 +0200: Nom : « Time Machine »
2015-10-08 10:23:18 +0200: Taille : 429,5 Go
2015-10-08 10:23:18 +0200: Système de fichiers : Mac OS étendu (journalisé)
2015-10-08 10:23:18 +0200: Ne pas effacer le contenu
2015-10-08 10:23:18 +0200:
2015-10-08 10:23:18 +0200: Partition 2
2015-10-08 10:23:18 +0200: Nom : « 1 To »
2015-10-08 10:23:18 +0200: Taille : 819,62 Go
2015-10-08 10:23:18 +0200: Système de fichiers : Mac OS étendu (journalisé)
2015-10-08 10:23:18 +0200: Ne pas effacer le contenu
2015-10-08 10:23:18 +0200:
2015-10-08 10:23:18 +0200: Partition 3
2015-10-08 10:23:18 +0200: Nom : « El Capitanos »
2015-10-08 10:23:18 +0200: Taille : 250 Go
2015-10-08 10:23:18 +0200: Système de fichiers : Mac OS étendu (journalisé)
2015-10-08 10:23:18 +0200:
2015-10-08 10:23:18 +0200: Début des opérations de partitionnement
2015-10-08 10:23:18 +0200: Verification du disque
2015-10-08 10:23:37 +0200: Réduction du disque

Et dans le log global du système, j'ai repéré ça :

08/10/15 10:23:34fseventsd[43]Events arrived for /Volumes/1 To after an unmount request! Re-initializing.

Par contre ce qui est + flippant c'est que dans le Finder (et Path Finder), je ne peux plus voir les fichiers sur les 2 partitions du disque externe ! (la 3ème, que j'étais en train d'essayer de créer, n'est pas visible.)

J'ai voulu relancer le Finder; il s'est arrêté mais ne se relance plus du tout et me donne le message "Impossible d'ouvrir l'application Finder (-10810)".

Mais en passant par le Terminal, j'ai toujours apparemment accès à mes fichiers. Enfin plus ou moins, car je ne peux pas faire de listing (avec la commande ls) de certains dossiers ! Mais sur ceux que je peux, je constate que tous les fichiers appartiennent à "_unknown". J'ai donc essayé de les copier tous sur un disque externe (avec la commande cp -r), histoire d'essayer de tout récupérer avant de tenter autre chose. J'ai commencé par exemple par ma bibliothèque iTunes... mais au bout d'un moment la copie s'est aussi arrêtée, et je ne peux même pas killer le process cp (même avec kill -9 en root).

On dirait qu'il y a certains fichiers qui sont vraiment inaccessibles, alors que d'autres sont toujours lisibles.

Par exemple j'ai pu copier sur le disque externe certains dossiers du style iTunes Music/Music/[nom de l'artiste], car je peux retrouver les noms des artistes d'après la musique synchro dans mon iPhone, heureusement ! Mais sinon, pas possible de faire un listing du dossier iTunes Music/iTunes directement en ligne de commande !

Bref, je continue à essayer de copier ce que je peux pour le moment, mais est-ce que qqun a des conseils à me donner ?

J'ai essayé de remettre un owner connu à la place de _unknown sur un fichier pour tester : la commande ne retourne pas d'erreur, mais l'owner reste _unknown !

 

[iDanny]

Autre précision: en étant connecté en root dans le terminal, même quand je crée un nouveau fichier sur la partition de 1 To, il est créé avec comme propriétaire _unknown !

 

[Membre supprimé 1060554]

Bonjour iDanny.

Le cas que tu soumets me paraît assez difficile à interpréter, parce que ce n'est pas seulement ton disque dur externe « WD » qui se trouve impliqué, mais concomitamment des applications graphiques lancées dans ta session («Finder» impossible à relancer, «Utilitaire de Disque» inopérant) et des processus lancés en ligne de commande (processus cp bloqué notamment).

Je me demande si une opération sur le disque « WD » (re-partitionnement) n'est pas en stase, au point d'entraîner dans son blocage les processus d'applications ou de commandes qui viennent à être ciblés sur cette destination (un effet "trou noir", quoi, càd. un effet d'« aspiration » dans la débâcle...

).

Cette impression me fait dire qu'il te faut essayer de dissocier tout d'abord "problèmes du disque WD" et "processus actifs de Snow Léopard", afin de libérer ces derniers de l'emprise du premier.

- a) Est-ce que tu peux éteindre ton Mac, détacher ton DDE « WD », re-démarrer ton Mac et ouvir ta session habituelle ? => alors : est-ce que ton Finder répond normalement (si tu choisis de le relancer, par exemple, est-ce qu'il obtempère ?) ? Est-ce que ton «Utilitaire de Disque» a récupéré ses fonctionnalités d'affichage (si tu connectes une clé USB banale - mais pas ton « WD » ! - est-ce que l'affichage est normal ? Est-ce que tu peux la reformater ?) ?

- b) Va de ta session à : Menu /Préférences Système/Comptes et crée un utilisateur admin expérimental = toto (mot-de-passe : toto). Quitte ta session, et loge-toi dans la session toto. Demande au Finder d'afficher les disques durs. Connecte à présent seulement ton DDE « WD » au port FireWire. Qu'est-ce que tu constates, en ouvrant dans le Finder les volumes : « Time Machine » et « 1 To » ? Les fichiers que tu ne voyais pas sont-ils visibles ?

- c) Si tu fais ⌘I sur l'icône de chaque volume, est-ce que la case de la rubrique tout en bas "Ignorer les autorisations de ce volume" est cochée (= "Ownership disabled" => c'est l'utilisateur qui a ouvert une session et qui accède de là au volume externe qui est considéré comme le "propriétaire relatif" des objets contenus) ou décochée (= "Ownership enabled" => c'est le créateur en titre des objets contenus qui reste leur propriétaire en titre et aucunement l'utilisateur ayant ouvert une session qui accède au volume externe) ? Si tu coches la case (au cas où elle serait décochée), est-ce que tous les objets (dossiers et fichiers) s'affichent avec ton username comme propriétaire (relatif) ? <pour la "théorie", voir mes messages récents #3 & #6 dans ce fil : ☞Permissions utilisateurs Disque Dur Externe Thunderbolt 2☜ - messages qui ne paraissent pas avoir atteint l'«oreille de l'entendement» de l'intéressé empressé de trouver midi à quatorze heures...>

- d) Est-ce que l'«Utilitaire de Disque» a récupéré ses fonctionnalités sur la cible de ton DDE ? Est-ce qu'une commande ls -R sur chaque volume parcourt récursivement le lot de tous les éléments contenus sans blocage ni échappement ? Que te donne un diskutil list ? Et un diskutil info ciblé sur /dev/disk1s2 (présumablement = la partition de « Time Machine »), puis sur /dev/disk1s3 (présumablement la partition de « 1 To ») ?​

--> Si ça n'allait pas fort dans cette nouvelle session non plus, est-ce que tu pourrais (ton DDE détaché), télécharger et appliquer à ton OS la ☞Mise à jour combinée Mac OS X v10.6.8 v1.1☜ afin de remettre d'aplomb ton «Snow Léopard» ? Est-ce que dans ta session (le DDE « WD » détaché), le Finder est libéré ? Idem pour l'«Utilitaire de Disque» : est-ce qu'il est réglo ? - l'idée générale est de libérer ton fonctionnement Système / session d'abord, pour revenir ensuite au problème du disque externe isolément...

 

[iDanny]

Merci macomaniac pour toutes tes suggestions très pertinentes (et pour le coup de l'option Ownership que je ne connaissais pas ).

J'ai en effet très envie de relancer ma session, peut-être que ça va permettre de tout arranger + rapidement ensuite, mais pour le moment comme j'ai eu chaud hier je reste en mode "sauvegarde de ce que je peux en ligne de commande", et c'est seulement quand j'aurai vraiment fini de copier tout ce que je peux que j'essaierai autre chose...
Donc affaire à suivre, ce w-e je pense.

Merci encore

 

[iDanny]

Re,

Alors après m'être bien fait ch... à presque tout copier à la main en ligne de commande vers un autre disque externe, j'ai enfin tenté de redémarrer le Mac, et... Tout est revenu à la normale !
Arf :meh:

Ensuite j'ai fait une petite vérif / réparation sur mon disque externe puis là je viens de relancer le partitionnement comme prévu au départ.

Et ça a l'air reparti comme avant; la barre de progression est à nouveau bloquée à l'étape "réduction du disque", et je ne vois aucun signe d'activité disque. Sauf que cette fois elle est bloquée plus tôt, m'enfin.

Normalement un "repartitionnement" de ce genre devrait aller assez vite, non ? :bored:

 

[iDanny]

Tiens je me demande si y a pas une réponse dans cet article (qui date de 10.4) : http://www.macworld.com/article/1055274/marchgeekfactor.html

Dans ce passage :

The resizeVolume command occasionally fails. If it encounters any disk problems, it will stop, and you’ll need to run Disk Utility or another disk-maintenance program. If you have any system or special metadata files—which can’t be moved—in the section of your partition that you wish to reallocate, the command will also fail. Unfortunately, the error messages won’t go into any detail.​

 

[Membre supprimé 1060554]

Salut iDanny.

Le re-partionnement d'un volume via l'«Utilitaire de Disque» équivaut à une commande invoquant le programme diskutil avec le verbe resizeVolume et les arguments ad-hoc dans le «Terminal». L'avantage du «Terminal» dans ce cas précis, est qu'il est plus bavard que l'«Utilitaire de Disque» en te décrivant par le menu la série des opérations effectuées.

Je te propose un exemple de re-partitionnement. J'ai un DDE (comme toi) offrant le schéma de partitionnement initial suivant (retourné par la commande diskutil list) :

/dev/disk1 (external, physical):
  #:                       TYPE NAME                    SIZE       IDENTIFIER
  0:      GUID_partition_scheme                        *512.1 GB   disk1
  1:                        EFI EFI                     209.7 MB   disk1s1
  2:                  Apple_HFS Capitan (clone)         107.4 GB   disk1s2
  3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3
  4:                  Apple_HFS LIBRE                   403.6 GB   disk1s4

--> /dev/disk1 est un SSD externe en connexion Thunderbolt-2. /dev/disk1s1 est l'ESP (EFI System Partition) qui constitue le secteur-disque initial par défaut d'une Table de Partition GUID (quoique, sur un disque de stockage, son emploi soit nul). /dev/disk1s2 Capitan (clone) est la partition qui porte le clone de l'OS du SSD interne de mon Mac. /dev/disk1s3 Recovery HD est la partition qui porte le clone de la partition de récupération du SSD interne de mon Mac encore. /dev/disk1s4 LIBRE est un volume de stockage pour l'instant inutilisé. J'ai l'intention de re-partitionner expérimentalement la partition /dev/disk1s2 Capitan (clone) de 107.4 GB (occupée pour 56 GB par mon clone) pour la rétrécir à 80 GB et rejeter une néo-partition de 27.4 GB en-dessous de la /dev/disk1s3 Recovery HD et en-dessus de la /dev/disk1s4 LIBRE. L'«Utilitaire de Disque» d'«El Capitan» est si "craignos" que j'ai décidé de ne jamais plus lui confier aucune tâche de gestion des disques. Je vais donc passer par le «Terminal», qui en plus me racontera dans le détail ses procédés.

Je passe donc la commande (sans le moindre état d'âme qui proviendrait de ce que je re-partitionne une partition supportant des données, ni du fait qu'il y a une partition de récupération juste en-dessous - j'ai par ailleurs l'ownership sur le volume, donc je n'ai pas besoin de passer sudoer) :

diskutil resizeVolume /dev/disk1s2 80g 1 jhfs+ brol 27.4g

--> comme tu peux voir, j'invoque diskutil avec le verbe resizeVolume (redimensionner_Volume) et l'identifiant du device comme cible = /dev/disk1s2 en précisant par 80g (= 80 GB) la taille d'arrivée que je souhaite pour cette partition. J'ajoute comme argument 1 (qui indique que je veux rejeter une seule partition additionnelle) et je la décris par un triplet : [format] = jhfs+ (Mac OS étendu journalisé) [nom] = brol [taille] = 27.4g (27,4 GB). En retour, j'obtins le descriptif suivant de l'opération :

Resizing to 80000000000 bytes and adding 1 partition
Started partitioning on disk1s2 Capitan (clone)
Verifying the disk
Verifying file system
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
The volume Capitan (clone) appears to be OK
File system check exit code is 0
Resizing
Waiting for the disks to reappear
Formatting disk1s4 as Mac OS Extended (Journaled) with name brol
Initialized /dev/rdisk1s4 as a 26 GB case-insensitive HFS Plus volume with a 8192k journal
Mounting disk
Finished partitioning on disk1s2 Capitan (clone)
/dev/disk1 (external, physical):
  #:                       TYPE NAME                    SIZE       IDENTIFIER
  0:      GUID_partition_scheme                        *512.1 GB   disk1
  1:                        EFI EFI                     209.7 MB   disk1s1
  2:                  Apple_HFS Capitan (clone)         80.0 GB    disk1s2
  3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3
  4:                  Apple_HFS brol                    27.4 GB    disk1s4
  5:                  Apple_HFS LIBRE                   403.6 GB   disk1s5

--> je pense que cet affichage plus le minutage que j'ai fait de l'opération répondent à tes questions. Tu noteras qu'avant toute opération de re-dimensionnement, le programme diskutil (qui est un "wrapper" : un "enveloppeur de commandes" = un programme capable de solliciter d'autres programmes pour des tâches auxiliaires) lance le programme fsck_hfs (filesystem_check format_HFS+) avec une option de vérification du système de fichiers inclus dans la partition. Toutes les opérations particulières (portant sur le catalogue, les attributs étendus etc.) s'adressent à l'ensemble des fichiers qui résident sur l'en-tête du système de fichiers et qui en constituent les ressources gestionnaires (comme le catalogue B-tree, par exemple, qui indexe toutes les données écrites à la suite selon une arborescence dotée de clés permettant l'effectuation de processus de recherche, de modification et de suppression).

Tu noteras que c'est uniquement parce que ce processus de vérification d'intégrité retourne un code de sortie 0 (= 0 errors) que le processus principal de "resizing" (repartitionnement) s'engage. Au cas où le code de sortie est 1 (= errors found), comme le programme auxiliaire fsck_hfs lancé en mode précurseur par diskutil ne l'est qu'avec une option de vérification, et absolument pas une option de réparation si erreurs trouvées, il s'ensuit que la commande de repartitionnement proprement dite est "avortée", car elle ne peut s'effectuer sur un système de fichiers invalide. Par ailleurs, l'opération au total (càd. procédure de vérification / rétrécissement de la partition /dev/disk1s2 / mise-à-jour de l'emplacement de la partition de récupération /dev/disk1s3 Recovery HD par remontée à partir de la série de blocs commençant aux alentours de 107,6 GB sur la série de blocs commençant aux alentours de 80,2 GB / construction de la néo-partition /dev/disk0s4 de 27,4 GB / création d'un système de fichiers vierge jhfs+ par le formateur de filesystems) prend une trentaine de secondes (mais le DDE est un SSD en connexion Thunderbolt-2). Tu admireras la vélocité pour l'assez impressionnante quantité d'opérations impliquées.

Bon : tout ça c'était pour te faire plaisir en te fournissant un test descriptible. Comme je n'ai rien à faire de ma nouvelle partition /dev/disk0s4 brol de 27,4 GB (et comme je ne confierais certainement pas mon porte-monnaie à l'«Utilitaire de Disque» "craignos" d'«El Capitan»), je passe donc une commande de suppression de cette partition avec virement au statut de free_space :

diskutil eraseVolume free null /dev/disk1s4

qui me renvoie sans barguigner un :

Started erase on disk1s4 brol
Unmounting disk
Finished erase on disk1

en environ 2 secondes, suite à quoi j'enchaîne par une commande de ré-intégration de cet espace libre à la partition /dev/disk1s2 Capitan (clone) de 80 GB :

diskutil resizeVolume /dev/disk1s2 0b

(qui pourrait se traduire en : invocation de diskutil avec le verbe "redimensionner_volume" et l'identifiant de device : /dev/disk1s2 comme partition-cible avec la simple mention terminale de 0b = 0_bytes pour dire concisément : "épuiser l'espace libre diponible à la suite pour n'en laisser que 0_bytes - ce, sans obstacle d'une partition de récupération «Recovery HD» éventuellement intercalée sur le chemin de ce free_space") et j'obtiens la réversion de ma commande précédente de re-partitionnement qui se trouve ainsi décrite :

Resizing to full size (fit to fill)
Started partitioning on disk1s2 Capitan (clone)
Verifying the disk
Verifying file system
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
The volume Capitan (clone) appears to be OK
File system check exit code is 0
Resizing
Waiting for the disks to reappear
Finished partitioning on disk1s2 Capitan (clone)
/dev/disk1 (external, physical):
  #:                       TYPE NAME                    SIZE       IDENTIFIER
  0:      GUID_partition_scheme                        *512.1 GB   disk1
  1:                        EFI EFI                     209.7 MB   disk1s1
  2:                  Apple_HFS Capitan (clone)         107.5 GB   disk1s2
  3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3
  4:                  Apple_HFS LIBRE                   403.6 GB   disk1s4

--> je suis donc revenu exactement à la case départ et je n'ai pas perdu un seul bit des données de mon clone. Tu remarqueras qu'il y a eu encore vérification de l'intégrité du filesystem de la partition cible en préalable, et qu'un code de sortie 0 a autorisé l'engagement du "resizing". Tu remarqueras aussi que la «Recovery HD» en /dev/disk1s3 a eu son emplacement de nouveau mis-à-jour, par redescente de la série de blocs commençant aux alentours de 80,2 GB à celle commençant (comme au tout début) aux alentours de 107,7 GB. Cette série complexe d'opération a pris encore dans les 30 secondes.

=> en résumé : si tu demandes dans l'«Utilitaire de Disque», la réparation (et pas seulement la vérification) du système de fichiers de la partition de ton DDE que tu veux redimensionner, est-ce que tu obtiens bien un "OK" final (équivalent d'un code de sortie 0) ou pas ? Si oui, je ne vois pas ce qui empêcherait un re-partitionnement, dans la mesure où le format de ta partition est bien (j)hfs+. Si tu étais en exFAT ou FAT-32, alors aucune chance : ce n'est pas un format de fichiers rétrécissable ou extensible.

 

[iDanny]

Hello macomaniac,

Merci encore une fois pour tes explications et exemples détaillés :bookworm:

Mon DDE a bien toutes ses partitions en JHFS+ oui.
Hier avant mon 2ème essai de redimensionnement j'avais bien cette fois lancé une vérification / réparation des volumes avant.
Et en effet j'avais commencé à regarder des exemples d'utilisation de diskutil en ligne de commande, pour essayer ça par la suite.
Par contre je pensais que l'Utilitaire de Disque n'était qu'une interface graphique qui utilise en fait les mêmes commandes que diskutil, mais tu as l'air de dire que non ? Dans ce cas il faut vraiment que j'essaie de faire ça en ligne de commande, en effet.
À suivre donc, ce soir j'espère

Sinon rien à voir, mais je n'ai pas saisi ce qu'il y a sur ta partition "clone El Capitan" : un copie d'une install clean de l'OS ?

 

[lamainfroide]

Bonjour,
En aparté, et juste pour mon information, qu'est-ce qui te fait dire, Ô grand macomaniac, que l'utilitaire de disque d'El Capiton est si "craignos" ?

 

[Membre supprimé 1060554]

Oui, l'«Utilitaire de Disque» pilote le programme UNIX diskutil (mais pas que : hdiutil aussi notamment). Mais avec une tendance aggravée à des combinaisons de commandes "tout-en-un" dans «El Capitan». Je ne peux plus, par exemple, supprimer tout court une partition et virer son espace à du free-space hors-partitionnement. Non : le logiciel va m'imposer dans la foulée une ré-allocation automatique de cet espace à la partition du dessus. Mais si moi j'avais envie, expérimentalement parlant, de me le garder hors Table de Partition, cet espace libre ?

Je ne peux plus activer un menu "Déboguer" pour pouvoir afficher toutes les partitions, y compris celle de l'ESP (EFI System Partition = n°1 sur un disque) et de la «Recovery HD» : commode quand on veut les monter à la volée pour vérifier des composants, puis les démonter toujours à la volée. Je ne vois plus, non plus, les sous-composants d'un CoreStorage (Physical Volume et Boot OS X = driver de montage du Volume Logique).

Et encore : je trouve l'affichage en camembert malcommode au possible. C'est comme de revenir à une montre à cadran camembert avec aiguilles qui tournent, quand on s'est habitué à des affichages digitaux. Ou de re-suggérer un disque à plateaux en rotation, à l'heure où Apple ne fournit plus que des SSD quasiment avec ses Macs. Et c'est en porte-à-faux complet avec l'objet : un disque, en terme de Table de Partition, c'est une série linéaire de blocs qui commence à 0 et qui se termine à n (que le disque soit une galette ronde ou une gaufre rectangulaire). Chaque partition est un segment numéroté (du tantième au tantième dans l'ordre croissant). Donc la représentation verticale, de haut en bas, est la seule graphiquement correcte : il y a bien des partitions du dessus et des partitions du dessous, pas des partitions en quadrans "antipodiques"...

 

[lamainfroide]

Je n'ai pas testé le Capiton sur DDE, je ne savais donc pas qu'il en était ainsi dorénavant.
Je vois désormais très bien ce qui peut te chagriner (et à un moindre niveau ce qui pourrait me gêner).
Je te remercie de ta réponse.

 

[iDanny]

Re,

Bon j'ai lancé la commande suivante, qui au départ avait l'air pas mal (je voyais une activité disque à l'étape "resizing"), mais là ça fait 15 mn qu'elle tourne et ça a l'air bloqué à nouveau (plus d'activité disque)...

> diskutil resizeVolume /dev/disk1s3 800G JHFS+ Capitanos 200G
Started partitioning on disk1s3 1 To
Verifying disk
Resizing
[ \ 0%..10%..20%..30%..40%..50%.......................... ]

Est-ce que ça pourrait être dû par exemple à iStat Menus, l'utilitaire qui affiche plein d'infos dans la barre de menus d'OS X, dont justement l'état des disques (avec la taille des partitions) ?

 

[Membre supprimé 1060554]

Est-ce que le processus s'est complété ?

Si le "resizing" s'affiche avec un pourcentage initial, c'est que la vérification du système de fichiers de la partition-cible (/dev/disk1s3) a renvoyé un code de sortie 0 (= "sans erreurs"). Donc, en cas d'échec de complétion de l'opération, il faut exclure a priori le facteur "filesystem défectueux".

Par ailleurs, j'ai moi aussi «iStat Menus» installé, sans qu'aucun de mes tests (fréquents) de re-partitionnement n'en ait jamais été entravé.​

 

[iDanny]

Re,

Le resizing n'est jamais allé + loin que ci-dessus; j'ai arrêté le processus au bout d'un moment, et mon disque était en mode "owner = _unknown", comme quand j'essayais avec l'Utilitaire de Disque.
Et "comme d'hab", un reboot suffit à retrouver un état normal.

Ensuite j'ai essayé de seulement réduire la partition (car jusqu'ici j'ai toujours essayé en plus d'en créer une nouvelle), avec l'Utilitaire de Disque, et cette fois j'ai eu un message d'erreur inédit :

Impossible de modifier la carte de partition car la vérification du système de fichiers a échoué.​

Donc je réessaierai après avoir lancé une vérif / réparation depuis l'Utilitaire de Disque.

 

[iDanny]

Bon j'ai fait une réparation... l'Utilitaire de Disque m'a indiqué un souci sur la partition de 1 To: nombre erroné de blocs libres du volume, qui était peut-être dû justement à la précédente tentative avortée de resizing de la partition, puis il l'a corrigé. Ensuite j'ai refait une vérification et les 2 partitions du disque étaient clean.

Puis j'ai retenté le resizing, après avoir tué le processus d'un utilitaire WD qui est censé surveiller l'état du disque, je me suis dit que ça pouvait jouer.

Mais non, j'ai toujours le même résultat : freeze à 50% de la jauge, plus aucune activité, pas de message d'erreur, et si je reboote je vais retrouver mes partitions comme avant. C'est désespérant...

Je vais finir par formater entièrement le disque, sinon j'y serai encore en 2016

 

[Membre supprimé 1060554]

Je vais finir par formater entièrement le disque, sinon j'y serai encore en 2016

C'est ce que je ferais aussi.

À moins que ce ne soit un logiciel gestionnaire pré-installé par Western Digital que tu aurais laissé actif sur ton disque (non ré-initialisé à l'origine) qui jouerait des tours - la "raison des effets" (pourquoi cet échec du re-partitionnement) échappe.

Personnellement, j'aime bien scruter la raison de phénomènes curieux, avec quelque patience même, aussi longtemps que cette traque fait "sens" (pour moi) : c'est-à-dire que j'arrive à me représenter les déterminismes à l'œuvre avec mon outillage mental - assez "cantonné" il faut bien le dire en informatique. Mais lorsque s'avère une inconnue = x qui échappe de manière récurrente à ma faculté d'en former une idée, ce dans un domaine technique relevant de conventions spécialisées - alors je n'hésite pas à suspendre mon jugement théorique et à passer concrètement l'éponge sur le tableau noir : ce qui dans ton cas revient, effectivement, à re-partitionner ton disque en supprimant le partitionnement actuel.

Ta sauvegarde TimeMachine : aucune importance --> tu en re-créeras une nouvelle. Reste les 500 Go de données de ta 2è partition = «1 To» : tu peux toujours sauvegarder l'ensemble sur un autre support --> si tu as un autre DDE attachable à ton Mac en parallèle à ton DDE Firewire, tu t'arranges pour avoir un volume d'accueil libre d'au moins 500 Go et dans le «Terminal» tu passes une commande respectant la syntaxe suivante :

sudo rsync -avE /Volumes/"1 To" /Volumes/"mon_volume_de_sauvegarde"

(sudo : au cas où il y aurait des fichiers sur la "source" requérant des droits root pour lecture ; rsync : un bon programme de clonage parmi les exécutables UNIX natifs d'OS X ; -avE : l'option a = mode synthétique archive + v = verbose pour avoir l'impression qu'il se passe quelque chose via un affichage progressif + E = sauvegarde des extended_attributes des fichiers ; /Volumes/"1 To" : ce doit être l'adresse exacte du volume "source" de ton DDE Firewire ; /Volumes/"mon_volume_de_sauvegarde" : il te suffit de substituer le nom de ton volume de "destination" à ce : "mon_volume_de_sauvegarde", les "" encadrant l'énoncé au cas où il y aurait des espaces libres dans l'intitulé qu'il s'agirait de neutraliser) --> tu n'as plus qu'à laisser tourner en toile de fond la tâche aussi longtemps qu'il faudra pour qu'elle se complète avec le ré-affichage de l'invite de commande à ton nom.

--> Cela fait, tu n'as plus, dans l'«Utilitaire de Disque», qu'à sélectionner le disque dur de ton DDE et à passer par le menu "Effacer" pour remettre les choses à zéro. Ensuite, tu peux ré-itérer ta sélection et passer par le menu "Partitionner" pour choisir un tri-partitionnement à ta convenance. Enfin, da capo, tu pourras passer une commande rsync inverse pour recopier les données de /Volumes/"mon_volume_de_sauvegarde" --> sur la nouvelle partition intermédiaire réduite à 800 Go de ton DDE Firewire.​

 

[iDanny]

Oui moi aussi j'aime bien creuser pour savoir ce qui cause un problème... Mais là ça commence à me prendre trop de temps pour rien.

J'ai déjà fait un backup, mais pas par rsync car j'ai un disque externe un peu trop petit pour tout contenir donc j'ai évité qques dossiers, ce qui m'a fait faire du ménage au passage.
Mais les extended attributes ont bien été préservés (tags des fichiers par exemple).

Ce soir je referai un essai de resizeVolume en ligne de commande, et après on passera au formatage si besoin.

 

[iDanny]

Bon après un dernier essai infructueux, j'ai formaté le bordel, et je suis en train d'installer El Capitan...

Dommage d'avoir pas trouvé ce qui déconnait, m'enfin...

Merci macomaniac, j'ai au moins appris qques trucs sur le resizing de partitions au passage :bookworm: