10.13 High Sierra MacBook ne démarre plus / s’allume directement sur les utilitaires macOS

J_liette

Membre confirmé
12 Janvier 2019
16
0
26
Bonjour,

Je possède un vieux MacBook 2010 unibody, qui n’etait plus très rapide mais marchait quand même et suffisait pour mon utilisation.
Dessus la dernière version compatible je crois (Sierra / High Sierra ? je ne sais pas trop)

Je l’utilisais tout a l’heure, il ramait beaucoup et je ne pouvais plus rien faire, donc je l’ai éteint de manière forcée en laissant le bouton power appuyé.
Quand je le rallume la barre de chargement se bloque alors qu’elle était quasi remplie. J’ai attendu sans doute 10-15 min et voyant que ça ne bougeait pas j’ai reteint l’ordi de force.
Après, ce qu’il me faisait c’est qu’il s’allumait, la barre de démarrage chargeait à 55-60% et là l’ordinateur s’éteignait tout seul d’un coup.

J’ai lu à plusieurs endroits qu’il fallait démarrer en tenant commande+r pour arriver sur le menu avec les utilitaires, je l’ai fait plusieurs fois. L’une des fois j’ai tenté de faire SOS mais sans succès (j’ai les messages d’erreurs en photo au cas où). Et j’ai fait quelques manips dans le terminal pour afficher des infos sur le disque comme j’avais vu ici.

Maintenant, je ne sais pas si c’est du à ces manips via l’utilitaire de disques, mais quand je rallume mon mac, d’abord j’ai un panneau barré à la place de la pomme mais qui reste très peu de temps, ensuite la pomme, le démarrage se fait, et j’arrive directement sur le menu « utilitaires macOS » sans avoir appuyé sur aucune touche au démarrage.

Je vous mets les infos renvoyées par le Terminal etc.

Je crois que le problème est « read only volume Yes » d’apres ce que j’ai vu sur Internet.

Merci infiniment pour l’aide que vous pourrez m’apporter

56FFB644-6116-43A7-9A77-6B28F52ED6C2.jpeg FBA41F28-BABC-4FC9-96C1-E6E9F1EE1E59.jpeg 2BF02887-EDE4-4817-91C3-0411622C53BA.jpeg
 
Dernière édition par un modérateur:
Bonsoir J_liette

Tu as fourni toutes les informations souhaitables et diagnostiqué toi-même le problème.

- le volume est monté en lecture seule > ce qui le verrouille contre toute écriture (comme une réinstallation) et explique le plantage du démarrage de l'OS qu'il contient (le Système ayant besoin d'écrire en cours d'initialisation). La raison constante en est une corruption du système de fichiers jhfs+ générateur du volume : manifestement le fichier du catalogue B-tree qui est corrompu.​

- monté en lecture seule > le volume est lisible. Donc clonable (via une commande du Terminal) --> à destination du volume d'un DDE USB. Il y a 236 Go à récupérer.​

=> as-tu un DDE UBS avec dans les 280 Go d'espace libre (toujours compter large) ?
 
Merci de ta réponse!

Comment sais tu que c’est un problème au niveau du catalogue B-tree ?

=> as-tu un DDE UBS avec dans les 280 Go d'espace libre (toujours compter large) ?​
Pas du tout :/
Est ce qu’il y a d’autres solutions ? On ne pourrait pas réparer le fichier en question via le terminal ?
 
Comment sais tu que c’est un problème au niveau du catalogue B-tree ?

  • je le sais parce que l'opération de vérification du système de fichiers jhfs+ > qui parcourt dans l'ordre la série de fichiers de cette structure logicielle > a stoppé sur :
Bloc de code:
Checking catalog file

  • vérification du fichier du catalogue

Sachant que ce fichier s'appelle le catalogue B-tree (à cause du dispositif en arborescence de sa structure logique) => il ne faut pas un grand effort de raisonnement pour conclure que : c'est le fichier du catalogue B-tree qui est corrompu par des erreurs..

----------

Voici une commande :
Bloc de code:
diskutil repairVolume disk0s2

  • la commande tente de réparer le système de fichiers générateur du volume. Elle échoue en cas d'erreurs graves (comme le sont celles du catalogue).
  • c'est toujours risqué : car la commande implique le démontage préalable du volume afin de désactiver le système de fichiers --> au risque que > la réparation ayant échoué > le volume ne puisse plus être remonté.

=> c'est toi qui prends la décision de passer ou non la commande fournie.
 
  • J’aime
Réactions: Fullcrum
250 Go de volume de destination peuvent suffire pour 236 Go d'occupation de la source. Sans garantie.

- le problème vient de ce que la commande de recopie cp (copy) --> délaie régulièrement sur la destination. On obtient donc une taille d'occupation de blocs sur la destination > (supérieure à) la taille des blocs de la source. Impossible de prédire de combien sera l'excédent. Je présume que ce débordement a partie liée avec des volumes sources corrompus (au niveau de leurs système de fichiers).​
 
D’accord merci

J’imagine qu’on verra, au moment de la manip, si les données ont bien été copiées sur le dde ? (je veux dire, il n’y a pas de risques de tout perdre parce que l’espace sur le dde est insuffisant ?)

Encore merci de ton aide
 
Après le clonage > il suffira de passer une commande de mesure de l'occupation de l'espace dans tous les volumes montés -->

- on verra aisément s'il reste de l'espace libre dans le volume du DDE > et quelle est la taille de son occupation.​
 
Ça doit être possible, en effet.

La différence peut consister en un débit d'écriture plus faible (si la clé est lente malgré sa taille imposante). Mais il y a aussi des clés de grande capacité qui sont rapides : j'en ai une de 256 Go dont le débit est de 450 Mo/s (l'équivalent d'un SSD 2,5"). J'ai pu y installer un OS expérimentalement et démarrer dessus sans souffrir de lenteurs.

Comme je te ferai passer de toute façon une commande empêchant le Mac de dormir en cours de clonage > même si ça prend du temps --> l'opération pourra s'effectuer jusqu'au bout.
 
Ça doit être possible, en effet.

La différence peut consister en un débit d'écriture plus faible (si la clé est lente malgré sa taille imposante). Mais il y a aussi des clés de grande capacité qui sont rapides : j'en ai une de 256 Go dont le débit est de 450 Mo/s (l'équivalent d'un SSD 2,5"). J'ai pu y installer un OS expérimentalement et démarrer dessus sans souffrir de lenteurs.

Comme je te ferai passer de toute façon une commande empêchant le Mac de dormir en cours de clonage > même si ça prend du temps --> l'opération pourra s'effectuer jusqu'au bout.


Ok super!

Bon, du coup j’ai enfin ma clé USB neuve de 256 Go et mon ordi à disposition

Est ce que je récupérerai tout comme avant ? (je pense notamment à ma bibliothèque iTunes et à une sauvegarde d’iPhone faite sur iTunes, mon téléphone m’ayant aussi lâchée récemment :( )


Un grand merci pour ton aide en tout cas!
 
Alors > la session de secours ouverte > attache la clé au Mac > passe la commande :
Bloc de code:
diskutil list

  • et poste le tableau des disques (qui va montrer la clé en fin de liste).
 
Voici
Bloc de code:
-bash-3.2# diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *250.1 GB   disk0
   1:                        EFI                         209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            249.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +2.1 GB     disk1
   1:                  Apple_HFS OS X Base System        2.0 GB     disk1s1

/dev/disk2 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +5.2 MB     disk2

/dev/disk3 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk3

/dev/disk4 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk4

/dev/disk5 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk5

/dev/disk6 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk6

/dev/disk7 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk7

/dev/disk8 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +6.3 MB     disk8

/dev/disk9 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +2.1 MB     disk9

/dev/disk10 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +1.0 MB     disk10

/dev/disk11 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +2.1 MB     disk11

/dev/disk12 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk12

/dev/disk13 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk13

/dev/disk14 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +1.0 MB     disk14

/dev/disk15 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +6.3 MB     disk15

/dev/disk16 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk16

/dev/disk17 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *268.4 GB   disk17
   1:               Windows_NTFS                         268.4 GB   disk17s1

-bash-3.2#
 
Je vois la clé en disk17. Passe la commande :
Bloc de code:
diskutil eraseDisk jhfs+ Clone gpt disk17

  • respecte tous les espaces ; le 1 de disk17 est le chiffre "un"
  • la commande initialise "Mac" le disque de la clé et remonte un volume intitulé Clone

Poste l'affichage retourné.
 
Bloc de code:
-bash-3.2# diskutil eraseDisk jhfs+ Clone gpt disk17
Started erase on disk17
Unmounting disk
Creating the partition map
Waiting for partitions to activate
Formatting disk17s2 as Mac OS Extended (Journaled) with name Clone
Initialized /dev/rdisk17s2 as a 250 GB case-insensitive HFS Plus volume with a 24576k journal
Mounting disk
Finished erase on disk17
-bash-3.2#

Merci encore de ton aide
 
L'initialialisation de la clé a réussi. Alors hop ! opération clonage.

Passe d'abord la commande :
Bloc de code:
caffeinate -dimsu &

  • qui va empêcher le Mac de dormir pendant l'opération ; elle passe sans commentaire

Passe ensuite la commande :
Bloc de code:
cp -av /Volumes/"Macintosh HD"/* /Volumes/Clone

  • mets "Macintosh HD" aves des "" ; pas d'espace entre HD" et /* ; un espace entre /* et /Volumes---
  • la commande clone Macintosh HD dans Clone
  • une ligne s'affiche par fichier copié
  • la copie suit l'ordre alphabétique des dossiers > sous-dossiers > fichiers

=> si tu vois un défilé de lignes démarrer à l'écran > c'est que le clonage est lancé. Attends jusqu'à l'arrêt du défilé et au retour de l'invite de commande -bash-3.2# en signal de complétion. Tu peux laisser ton Mac sans surveillance. Préviens quand tout est fini.
 
Au début aucun souci et puis un moment il y a eu beaucoup de « could not copy (...) » « input/output error ». Ca s’est arrêté puis ça a repris.
591ECABE-53CA-4A56-8B34-922605BCBDE5.jpeg 6B398AA0-A848-4BED-B322-482830696FB0.jpeg upload_2019-2-4_12-56-7.jpeg C127C5DC-1DB5-4093-87C5-485BF07CB36B.jpeg DB6BFC50-40DD-4EAF-B4DF-7DBD22980CBF.jpeg
 
Dernière édition par un modérateur:
Le clonage est donc en cours. Il y a peut-être des problèmes d'accès en lecture à des fichiers de la source (avec un système de fichiers corrompu > ça n'a rien de surprenant).

- tu n'auras qu'à indiquer quand l'opération s'est terminée (retour de -bash-3.2#) => on fera une comparaison quantitative : occupation du volume source / occupation du volume de destination...​
 
Ok merci beaucoup

Petit problème : je suis actuellement dans un bus de nuit (je n’aurais pas du commencer le clonage ce matin mais j’avoue que je ne pensais pas que ce serait aussi long ahah), j’ai fait attention à garder mon ordi bien ouvert à côté de moi en le transportant mais il n’a bientôt plus de batterie. Et je n’ai à disposition que des prises usb donc impossible de le recharger...
Sachant que ça fait 13 heures que le clonage a commencé et qu’il n’est qu’à Applications/Chess

J’imagine qu’il vaut mieux arrêter le process proprement, quite à tout reprendre à 0 ensuite ? (je resterai 6 semaines au même endroit cette fois donc ça nous laisse un peu de marge ahah)