10.13 High Sierra Problème redémarrage mac book pro apres mise a jour high sierra

Redémarre une fois > en revenant dans la session de secours. Vérifie alors dans l'Utilitaire de disque > si l'intitulé du volume Macintosh HD (dans la colonne de gauche) est en noir (= monté) ou en grisé (= non monté) -->
  • quel est le résultat ?
 
Alors voici quelle sera la 1ère étape d'ensemble du sauvetage -->

- a) tu passes la commande :
Bloc de code: 
caffeinate -dimsu &

  • qui va empêcher le Mac de dormir

----------

- b) tu passes la commande :
Bloc de code: 
mkdir /Volumes/TEDDY/Sauvegarde

  • qui crée un dossier vide intitulé Sauvegarde dans le volume TEDDY

----------

- c) tu passes la commande :
Bloc de code: 
cp -av /Volumes/"Macintosh HD"/* /Volumes/TEDDY/Sauvegarde

  • mets "Macintosh HD" avec des "" ; pas d'espace entre HD" et /* ; un espace entre /* et /Volumes---
  • la commande clone le contenu de Macintosh HD dans le dossier Sauvegarde
  • une ligne s'affiche par item copié
  • la recopie suit l'ordre alphabétique des dossiers > sous-dossiers > fichiers

Si tu vois un défilé de lignes commencer à l'écran --> c'est que le clonage a bien démarré. Ne fais rien tant que tout ne se soit pas arrêté > avec réaffichage de l'invite de commande : -bash-3.2#. Signale-le alors.
 
slt macomaniac !!! aprés plusieur heure de défilé de lignes sur le terminal et l'affichage de -bash-3.2# je pense que sa ses bien passé ; quel et la prochaine etape stp ???
 
On sait que TEDDY recelait 259 Go de données avant le clonage.

Passe la commande :
Bloc de code: 
df -H /Volumes/TEDDY

  • qui va mesurer l'allocation actuelle du volume

Poste le tableau.
 
Bloc de code: 
-bash-3.2# df -H /Volumes/TEDDY
Filesystem     Size   Used  Avail Capacity iused ifree %iused  Mounted on
/dev/disk3s1   500G   419G    81G    84%       0     0  100%   /Volumes/TEDDY
-bash-3.2#
 
160 Go de données ont été ajoutées au volume TEDDY.

Passe la commande :
Bloc de code: 
df -H /Volumes/Mac*

  • termine par Mac* tout court (ça abrège la saisie)
  • la commande mesure l'occupation du volume Macintosh HD

Poste le tableau retourné --> je veux vérifier précisément s'il n'y a pas eu de perte de taille des données copiées.
 
Bloc de code: 
-bash-3.2# df -H /Volumes/Mac*
Filesystem   Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk1   749G   173G   576G    24%  614032 4294353247    0%   /Volumes/Macintosh HD
-bash-3.2#
 
Ça fait donc 13 Go en moins de copié.

Est-ce que tu veux qu'on procède à une mesure un peu plus fine > pour savoir où se situe la déperdition ?
 
Tu peux passer les 2 commandes (l'une après l'autre) :
Bloc de code: 
/Volumes/Mac*/usr/bin/du -sh /Volumes/Mac*/*
/Volumes/Mac*/usr/bin/du -sh /Volumes/TEDDY/Sauvegarde/*

  • les 2 commandes sont obligées d'aller chercher au départ l'utilitaire du (de mesure des dossiers) dans le volume Macintosh HD (du n'existe pas dans les ressources de l'OS de secours démarré) ; tu n'as que 2 espaces en tout dans chacune : au milieu > un de part et d'autre de l'option -sh ; mets bien les * où il sont indiqués
  • les commandes sont lentes d'exécution --> attends chaque fois le réaffichage de l'invite de commande -bash-3.2# en signale de complétion
  • la 1ère liste & mesure les dossiers de 1er rang de Macintosh HD
  • la 2è fait de même pour ceux copiés dans le dossier Sauvegarde du volume TEDDY

Poste ces 2 tableaux ici.
 
Bloc de code: 
-bash-3.2# /Volumes/Mac*/usr/bin/du -sh /Volumes/Mac*/*
3.4G    /Volumes/Macintosh HD/Applications
14G    /Volumes/Macintosh HD/Library
  0B    /Volumes/Macintosh HD/Network
6.9G    /Volumes/Macintosh HD/System
125G    /Volumes/Macintosh HD/Users
  0B    /Volumes/Macintosh HD/Volumes
2.5M    /Volumes/Macintosh HD/bin
  0B    /Volumes/Macintosh HD/cores
  0B    /Volumes/Macintosh HD/dev
4.0K    /Volumes/Macintosh HD/etc
  0B    /Volumes/Macintosh HD/home
4.0K    /Volumes/Macintosh HD/installer.failurerequests
4.0K    /Volumes/Macintosh HD/model
  0B    /Volumes/Macintosh HD/net
9.1G    /Volumes/Macintosh HD/private
1.1M    /Volumes/Macintosh HD/sbin
4.0K    /Volumes/Macintosh HD/tmp
430M    /Volumes/Macintosh HD/usr
4.0K    /Volumes/Macintosh HD/var
1.0G    /Volumes/Macintosh HD/vm
-bash-3.2#
 
Bloc de code: 
-bash-3.2# /Volumes/Mac*/usr/bin/du -sh /Volumes/TEDDY/Sauvegarde/*
7.9G    /Volumes/TEDDY/Sauvegarde/Applications
500M    /Volumes/TEDDY/Sauvegarde/Library
32K    /Volumes/TEDDY/Sauvegarde/System
129G    /Volumes/TEDDY/Sauvegarde/Users
32K    /Volumes/TEDDY/Sauvegarde/Volumes
5.1M    /Volumes/TEDDY/Sauvegarde/bin
32K    /Volumes/TEDDY/Sauvegarde/cores
32K    /Volumes/TEDDY/Sauvegarde/dev
32K    /Volumes/TEDDY/Sauvegarde/etc
32K    /Volumes/TEDDY/Sauvegarde/home
32K    /Volumes/TEDDY/Sauvegarde/installer.failurerequests
32K    /Volumes/TEDDY/Sauvegarde/model
32K    /Volumes/TEDDY/Sauvegarde/net
9.3G    /Volumes/TEDDY/Sauvegarde/private
3.7M    /Volumes/TEDDY/Sauvegarde/sbin
32K    /Volumes/TEDDY/Sauvegarde/tmp
1.4G    /Volumes/TEDDY/Sauvegarde/usr
32K    /Volumes/TEDDY/Sauvegarde/var
1.0G    /Volumes/TEDDY/Sauvegarde/vm
-bash-3.2#
 
J'ai inspecté les 2 tableaux et voici ce qui ressort -->

- a) la commande cp a opéré par "réduction" en ce qui concerne principalement -->

  • Library (Bibliothèque Générale) : 14 Gi (source) => 500 Mi (destination)
  • System (Bibliothèque du Système) : 6,9 Gi (source) => 32 Ki (destination)

- b) la commande cp a opéré par "extension" en ce qui concerne principalement -->

  • Applications : 3,4 Gi (source) => 7,9 Gi (destination)
  • Users (Utilisateurs = dossiers-domiciles) : 125 Gi (source) => 129 Gi (destination)
  • private (contient les fichiers identiaires d'utilisateurs) : 9,1 Gi (source) => 9,3 Gi (destination)
----------

Soit (pour l'essentiel) : 20,4 Gi = 21,9 Go en moins sur 2 localisations-Système vs 8,7 Gi = 9,3 Go en plus sur 3 localisations-Système. On obtient bien (en arrondissant) le déficit de 13 Go de la destination par rapport à la source.

En considérant la nature de ces localisations --> voici le jugement qu'on peut porter -->

  • la commande cp est notoire lorsqu'on l'utilise depuis la session de secours --> pour "étirer" ses recopies > de sorte que les données sur la destination ont régulièrement une taille plus large que sur la source. Dans cette optique > on peut considérer que les Applications > les dossiers-domiciles des Utilisateurs > et le dossier private contenant les fichiers identiaires --> ont été clonés de manière valide.
  • il est extrêmement rare que la commande cp opère par "réduction" de la taille d'items de la source sur la destination. C'est le cas ici pour la Bibliothèque du Système - ce qui n'a aucune espèce d'importance dans le contexte présent --> puisque l'OS sera réinstallé > càd. qu'un dossier-Système valide sera installé de neuf. C'est aussi le cas pour la Bibliothèque Générale (= multi-utilisateurs) de l'OS --> ce qui n'a pas non plus d'impact prévisible en ce qui concerne le fonctionnement du futur OS puisque cette Bibliothèque sera aussi réinstallée de neuf. Mais le seul point qui chagrine est qu'elle recèle des ressources (par exemple dans son sous-dossier Application Support) des applications tierces installées. Cela veut dire qu'un bon nombre des logiciels tiers ajoutés ne pourront pas être lancés (une fois la récupération du clone effectuée) > faute des ressources d'appoint de la Bibliothèque Générale.

=> on peut estimer que cette perte est minime > car il sera toujours possible de réinstaller lesdits logiciels. Alors qu'aucune donnée d'utilisateur n'est a priori perdue.

----------
 
[suite et fin]

Je ne m'explique les "réductions" de copie effectuées par cp que par l'effet de corruption du catalogue B-tree du système de fichiers jhfs+. Ce catalogue a une forme d'arbre de dérivation classique > qui déploie des embranchements à partir d'une racine unique > en direction des "feuilles" terminales ou fichiers de données individuels. Sur chaque embranchement appelé "nœud" (node) > réside une clé numérique d'une valeur donnée > chaque fichier terminal étant indexé par un nombre.

  • par rapport au nombre désignant le fichier terminal (par exemple 10800) > une clé numérique porte un nombre qui peut lui être inférieur (par exemple 4650) ou supérieur (par exemple 29361). Tout processus d'accès à un fichier opère par recherche de sa valeur numérique > de telle manière que pour toute clé de nœud accédée > la branche supérieure est suivie si le nombre du fichier est supérieur à la valeur de la clé > ou la branche inférieure si le nombre du fichier est inférieur à la valeur de la clé. Ce principe de sélection binaire (voire ternaire) opérant instantanément à chaque nœud > le fichier terminal est trouvé.
  • une corruption de nœud intervient > lorsqu'un embranchement de l'arbre du catalogue porte une clé numérique erronée par rapport aux valeurs numériques des fichiers dépendant des branches desservies. Soit une clé numérique illisible > soit une clé numérique inconsistante. Cette impropriété est désignée comme : « erreur de nœud » --> et a pour effet l'impossibilité pour un processus d'accès aux fichiers de suivre l'une ou l'autre des branches qui partent du nœud. Par voie de conséquence > toute une partie de l'arborescence de l'arbre du catalogue se trouve inaccessible. L'« erreur de nœud » dans le catalogue B-tree est la plus grave des erreurs (c'est une erreur "cruciale") > et les erreurs dans le catalogue sont les plus graves des erreurs d'un système de fichiers --> car le catalogue est le fichier cardinal dans le dispositif logiciel générateur du volume.

Je pense donc qu'une ou des erreurs de nœuds dans le catalogue B-tree sont intervenues > qui invalident l'accès principalement aux 2 Bibliothèques de l'OS (Générale & Système). Par chances > les données correspondant aux utilisateurs sont accessibles.

----------

Je ne sais pas ce que tu en penses. On peut estimer que le clone est satisfaisant du point de vue utilisateur et poursuivre le processus de sauvetage (reformatage du volume source etc.). Ou on peut s'estimer chagrins que la Bibliothèque Générale ait été "réduite" en copie > parce qu'elle recèle les ressources d'installation additionnelles des logiciels tiers --> et dans ce cas tenter une mise-à-jour spécifique du dossier de la Library > en effectuant une 2è passe de copie pour voir si les choses s'améliorent. En cas d'erreur de nœud --> il est bien entendu impossible que l'arborescence invalidée soit mieux accédée que la 1ère fois.
 
Dernière édition par un modérateur:
Bon. Repasse une commande :
Bloc de code: 
diskutil list

  • et poste le tableau des disques

=> que je sois sûr de l'index de disque du Logical Volume CoreStorage qui porte le volume Macintosh HD verrouillé.
 
Bloc de code: 
-bash-3.2# diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *750.2 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage Macintosh HD            749.3 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Macintosh HD           +748.9 GB   disk1
                                 Logical Volume on disk0s2
                                 DC1FA62C-9839-4862-BE55-830905CFCCC2
                                 Unencrypted

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

/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *500.1 GB   disk3
   1:             Windows_FAT_32 TEDDY                   500.1 GB   disk3s1

/dev/disk4 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +5.2 MB     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               +2.1 MB     disk8

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

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

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

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

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

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

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

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

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

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

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

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

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

-bash-3.2#
 
Le temps que tu postes le tableau > je me suis avisé d'un meilleur plan peut-être possible.

Rappelle-moi quelle est l'année de ton Mac (pour savoir s'il peut démarrer par internet) et si c'est bien l'OS High Sierra qui est actuellement installé dans le volume Macintosh HD.
 
J'ai un macbook pro de fin 2011 ; Processeur : 2,8 GHz Intel core i7 Memoire: 4go 1333Mhz DDR3 Graphisme: intel je graphics 3000 384mo
 

Sujets similaires

C
MacBook Pro "patché" en Mojave et réinstallé en High Sierra
Réponses
4
Affichages
999
Hackintosh
Caren
C
S
10.13 High Sierra Problème de réinstallation MacOS High Sierra MBP 2011
Réponses
4
Affichages
1K
macOS
Skyxcube
S
AZ17
10.12 Sierra Plantage au démarrage (mise a jour ratée de Sierra à High Sierra)
Réponses
25
Affichages
3K
macOS
Mathh
M
B
10.6 Snow Leopard iMac 2006 10.5.8 Boot High Sierra
Réponses
7
Affichages
2K
macOS
totoguile
totoguile
Alexis_bazinga
10.9 Mavericks Installation de macOS High Sierra ou Mojave impossible
Réponses
8
Affichages
4K
macOS
Ahiqar
A
Haut Bas