10.13 High Sierra macOs High Sierra fsroot tree is invalid

macomaniac a dit:
Depuis la MÀJ de Sierra 10.12.4 --> le programme interne (EFI) des Mac a été implémenté de 2 capacités de démarrage par internet -->

  • via ⌘⌥R --> démarrage par internet permettant de ré-installer l'OS public le plus récent (High Sierra actuellement)
  • via ⌘⌥⇧R --> démarrage par internet permettant de ré-installer l'OS d'usine du Mac (Lion chez toi)
Ces 2 sortes de démarrages par internet proposent donc les 2 extrêmes logiciels pour un Mac donné : OS d'usine ou OS dernier cri.

Antérieurement --> il n'existait qu'un seul type de démarrage par internet implémenté dans l'EFI du Mac : le démarrage par ⌘⌥R permettant de ré-installer l'OS d'usine. Cette combinaison de touches a donc été ré-affectée au démarrage sur l'OS dernier cri et la combinaison nouvelle ⌘⌥⇧R affectée à l'OS d'usine.
Cliquez pour agrandir...

Ok.
Alors je viens de faire comment indiqué ci-dessus à savoir :
"Il faudrait que tu démarres par ⌘⌥R (cmd alt R) = démarrage par internet permettant de ré-installer High Sierra. Le volume Crucial_SSD_OS serait alors reconnu > monté > et clonable. Et tu pourrais effacer l'apfs du disque ensuite."
Tu as bien raison, j'ai de nouveau la posibilité de reinstaller macOs High Sierra mais malheureusement il me propose cela sur Crucial_SSD_HD. Crucial_SSD_OS ne monte pas.
 
«FileVault» n'est pas activé > ce qui nécessite un remontage manuel ?

Dans l'«Utilitaire de Disque» --> sélectionne le volume Crucial_SSD_OS grisé (non monté) --> bouton "Monter" --> est-ce que le volume est affiché en noir plein (= monté) ?

Sinon > fais un S.O.S. dessus et répète la manœuve de montage --> est-ce que tu parviens à le monter ?
 
macomaniac a dit:
«FileVault» n'est pas activé > ce qui nécessite un remontage manuel ?

Dans l'«Utilitaire de Disque» --> sélectionne le volume Crucial_SSD_OS grisé (non monté) --> bouton "Monter" --> est-ce que le volume est affiché en noir plein (= monté) ?

Sinon > fais un S.O.S. dessus et répète la manœuve de montage --> est-ce que tu parviens à le monter ?
Cliquez pour agrandir...

Sur l screen ci-dessous j'ai volontairement supprimer les disque virtuel pour le (rendu visuel)
Non le disque est grisé et ne monte pas .
SOS indique fsroot tree is invalid avec un code retour = 0 (ce qui est abérant)

Bloc de code: 
-bash-3.2# diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk2         129.9 GB   disk0s2
   3:                  Apple_HFS Crucial_SSD_HD          369.8 GB   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 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +129.9 GB   disk2
                                 Physical Store disk0s2
   1:                APFS Volume Crucial_SSD_OS          60.9 GB    disk2s1
   2:                APFS Volume Preboot                 19.9 MB    disk2s2
   3:                APFS Volume Recovery                503.9 MB   disk2s3
   4:                APFS Volume VM                      1.1 GB     disk2s4


-bash-3.2# cd /Volumes/
-bash-3.2# ls
Crucial_SSD_HD        OS X Base System
-bash-3.2# diskutil mountDisk disk2
One or more volume(s) failed to mount
-bash-3.2# diskutil mount disk2s1
Volume on disk2s1 failed to mount; it appears to be an APFS Volume which might be locked
Try "diskutil apfs unlockVolume"
-bash-3.2#
 
Si tu passes la commande :
Bloc de code: 
diskutil ap list

  • qui retourne le tableau détaillé du Conteneur apfs

- à la rubrique : Volume disk2s1 --> est-ce qu'il mentionné en bas :
Bloc de code: 
FileVault:                 No
 
macomaniac a dit:
Si tu passes la commande :
Bloc de code: 
diskutil ap list

  • qui retourne le tableau détaillé du Conteneur apfs

- à la rubrique : Volume disk2s1 --> est-ce qu'il mentionné en bas :
Bloc de code: 
FileVault:                 No
Cliquez pour agrandir...


A cette question je réponds Oui.

Bloc de code: 
-bash-3.2# diskutil ap list
APFS Container (1 found)
|
+-- Container disk2 C3D540E9-4A7E-4B19-B563-1551B85906DC
    ====================================================
    APFS Container Reference:     disk2
    Capacity Ceiling (Size):      129924218880 B (129.9 GB)
    Capacity In Use By Volumes:   62641278976 B (62.6 GB) (48.2% used)
    Capacity Available:           67282939904 B (67.3 GB) (51.8% free)
    |
    +-< Physical Store disk0s2 71995E4C-FAB7-49DE-A4CD-40BCB43F1064
    |   -----------------------------------------------------------
    |   APFS Physical Store Disk:   disk0s2
    |   Size:                       129924218880 B (129.9 GB)
    |
    +-> Volume disk2s1 238CBE0C-B006-3F36-8D84-FB49A674697A
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk2s1 (No specific role)
    |   Name:                      Crucial_SSD_OS (Case-insensitive)
    |   Mount Point:               Not Mounted
    |   Capacity Consumed:         60881481728 B (60.9 GB)
    |   FileVault:                 No
    |
    +-> Volume disk2s2 19BC6928-8EF6-4778-97D8-ADB74617837E
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk2s2 (Preboot)
    |   Name:                      Preboot (Case-insensitive)
    |   Mount Point:               Not Mounted
    |   Capacity Consumed:         19890176 B (19.9 MB)
    |   FileVault:                 No
    |
    +-> Volume disk2s3 5E455124-B8F3-4EC4-B859-EDDBB4B0992E
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk2s3 (Recovery)
    |   Name:                      Recovery (Case-insensitive)
    |   Mount Point:               Not Mounted
    |   Capacity Consumed:         503947264 B (503.9 MB)
    |   FileVault:                 No
    |
    +-> Volume disk2s4 6F5FA5BD-BB00-4715-B725-68F65CD271C4
        ---------------------------------------------------
        APFS Volume Disk (Role):   disk2s4 (VM)
        Name:                      VM (Case-insensitive)
        Mount Point:               Not Mounted
        Capacity Consumed:         1073762304 B (1.1 GB)
        FileVault:                 No
-bash-3.2#
 
Tu peux encore tenter un :
Bloc de code: 
mount -t apfs -r /dev/disk2s1 /tmp

  • cette commande tente un montage en mode restreint (lecture seule) du volume > en prenant comme point de montage le dossier des éléments temporaires /tmp de l'OS de secours démarré (sachant que le dossier /tmp est monté comme pseudo-volume d'une image-disque en RAM)

=> qu'est-ce qui est retourné ? (je conjecture un rejet du style : instruction invalide).
 
Erreur de syntaxe dans la commande
Bloc de code: 
-bash-3.2# mount -t apfs -r /dev/disk2s1 /tmp
mount_apfs: mount: Invalid argument
-bash-3.2#

Est-il possible de tenter une réparation du disque ou même volume sans perte de données ?
 
Le mécanisme logique est le suivant : un service du Système démarré (l'OS de secours en RAM ici) > intitulé diskarbitrationd > opère la probation des systèmes de fichiers générateurs de volumes. En cas de probation positive (pas d'erreur ou des erreurs simplement mineures) > il passe au kernel l'instruction de monter le volume en lecture et écriture. En cas de probation négative (erreurs graves) mais disons "avec compromis" > il passe au kernel l'instruction de monter le volume en lecture seule (verrouillage du volume). En cas de probation négative (erreurs graves) "sans compromis" > il ne passe pas d'instruction de montage au kernel.

Le volume était auparavant dans le cas n°2 > il a glissé au cas n°3. La commande mount tentait d'amadouer le diskarbitrationd > en lui demandant un montage restreint (lecture seule)- mais ça a été rejeté comme invalide.

Le problème est que l'erreur du fsroot tree (le segment principal de l'apfs) est irréparable. Un diskutil repairVolume disk2s1 ne va que "secouer" encore plus le système de fichiers.

Tu pourrais re-démarrer encore > mais simplement avec ⌘R cette fois (OS de secours local) - ce qui est plus rapide qu'un démarrage par internet. Juste pour voir si cet autre OS de secours encore aurait un diskarbitrationd plus enclin au compromis (je sais : c'est assez risible > ce "psycho-logisme"). Ce qui fait que le volume Crucial_SSD_OS pourrait être monté en mode "lecture seule". Suffisant pour un clonage.
 
Si tu ne peux pas démarrer par ⌘R --> c'est que le volume Recovery du Conteneur apfs est lui aussi inmontable suite à la corruption du fsroot tree. Car j'ai bien l'impression que le système de fichiers apfs a une forme en arborescence > génératrice de 4 volumes coexistants (Système > Pré-démarrage > Récupération > Mémoire virtuelle) à partir d'un tronc unique. Si le fsroot tree (arbre principal du système de fichiers apfs) est le segment "commun" à partir duquel se dérivent les embranchements déterminant les 4 volumes --> alors sa corruption équivaut à l'invalidation des 4 volumes et pas du seul volume de l'OS.

Cette partition indépendante de ton SSD Crucial -->
Bloc de code: 
 3:                  Apple_HFS Crucial_SSD_HD          369.8 GB   disk0s3
  • porte un volume Crucial_SSD_HD de 369,8 Go > dont 318 Go sont occupés par des données et 52 Go en espace libre.

Il est donc envisageable de re-partitionner (de manière non-destructive pour son volume) cette partition > en la rétrécissant à 324,8 Go (marge d'espace libre restant = 6,8 Go) > pour créer une 4è partition sur le disque de 45 Go > avec un système de fichiers jhfs+ > et un volume vide intitulé SOS par exemple.

Ce re-partitionnement effectué > installer (à partir du démarrage par internet permettant l'installation de High Sierra = ⌘⌥R) High Sierra en format apfs dans le volume SOS. Ce qui permettra d'ouvrir une session dans ce volume.

Ce démarrage en apfs local (sur le disque) --> permettra de vérifier si le volume Crucial_SSD_OS peut être monté dans ces conditions. Càd. si le service diskarbitrationd d'un Système résidant sur l'espace-disque (et pas en RAM) --> accepte de monter un volume collatéral de l'espace-disque relevant d'un système de fichiers alternatif. Je sais : c'est miser sur une chance des plus mince > mais autant la jouer. Si le volume pouvait être remonté --> alors il n'y aurait aucune difficulté à cloner son contenu dans un volume externe.
 
Dernière édition par un modérateur:
:coucou: macomaniac,
Loin de mon macOS aujourd'hui (on y est pas encore au boulot :)), mais OK pour suivre ce plan ce soir.

Par contre, tes estimations de l'espace restant ne sont pas forcément bonne, à ta décharge tu ne le savais pas :p
De l'espace a était fait sur Crucial_SSD_HD avant perte de Crucial_SSD_OS & containers.

De mémoire c'est plutôt ça maintenant, mais je posterais un état de l'espace disque restant sur Crucial_SSD_HD
Crucial_SSD_HD 369.8 Go > dont 199.8 Go sont occupés par des données et 170 Go en espace libre

Merci pour l'aide.
 
Hello,
Alors voici la taille exact du volume Crucial_SSD_HD
Bloc de code: 
-bash-3.2# df -H /Volumes/Crucial_SSD_HD/
Filesystem     Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk0s3   370G   199G   171G    54%   39480 4294927799    0%   /Volumes/Crucial_SSD_HD
-bash-3.2#[code]

La taille des autres Volumes => à noter, un volume clone (Clef usb sur laquelle je vais essayais d'installer High-Sierra puis, tenter de réparer le disque Crucial_SSD_OS & containers) Bonne ou mauvaise idée je sais pas, mais brûle d'impassiance là !  
 
[code]-bash-3.2# df -H
Filesystem      Size   Used  Avail Capacity iused               ifree %iused  Mounted on
/dev/disk1s1    2.0G   1.3G   733M    64%   44898          4294922381    0%   /
devfs           212k   212k     0B   100%     716                   0  100%   /dev
/dev/disk3      5.2M   647k   4.6M    13%      21          4294967258    0%   /private/var/log
/dev/disk4      524k   147k   377k    29%       8          4294967271    0%   /Volumes
/dev/disk5      524k   147k   377k    29%       7          4294967272    0%   /private/var/tmp
/dev/disk6      524k   160k   365k    31%      12          4294967267    0%   /private/var/run
/dev/disk7      2.1M   147k   1.9M     8%       3          4294967276    0%   /private/tmp
/dev/disk8      524k   143k   381k    28%       2          4294967277    0%   /System/Installation
/dev/disk9      524k   307k   217k    59%      21          4294967258    0%   /private/var/db
/dev/disk10      13M   2.7M   9.9M    22%      61          4294967218    0%   /private/var/folders
/dev/disk11     2.1M   209k   1.9M    10%      28          4294967251    0%   /private/var/root/Library
/dev/disk13     2.1M   348k   1.7M    17%      49          4294967230    0%   /private/var/root/Library/Containers
/dev/disk14     524k   176k   348k    34%      10          4294967269    0%   /Library/Preferences
/dev/disk15     524k   164k   360k    32%       6          4294967273    0%   /Library/Preferences/SystemConfiguration
/dev/disk16     1.0M   176k   872k    17%       5          4294967274    0%   /Library/Keychains
/dev/disk17     6.3M   176k   6.1M     3%       2          4294967277    0%   /private/var/tmp/RecoveryTemp
/dev/disk18     6.3M   860k   5.4M    14%       4          4294967275    0%   /private/var/tmp/OSISPredicateUpdateProductTemp
/dev/disk19     524k   143k   381k    28%       2          4294967277    0%   /private/var/tmp/InstallerCookies
/dev/disk20     2.1M   143k   2.0M     7%       2          4294967277    0%   /Library/Logs/DiagnosticReports
/dev/disk0s3    370G   199G   171G    54%   39480          4294927799    0%   /Volumes/Crucial_SSD_HD
/dev/disk21s2    16G    37M    16G     1%       4          4294967275    0%   /Volumes/clone
/dev/disk2s2    130G    20M    67G     1%      65 9223372036854775742    0%   /Volumes/Preboot
/dev/disk2s3    130G   504M    67G     1%      10 9223372036854775797    0%   /Volumes/Recovery
/dev/disk2s4    130G   1.1G    67G     2%       3 9223372036854775804    0%   /Volumes/VM
-bash-3.2#[code]


[code]-bash-3.2# diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk2         129.9 GB   disk0s2
   3:                  Apple_HFS Crucial_SSD_HD          369.8 GB   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 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +129.9 GB   disk2
                                 Physical Store disk0s2
   1:                APFS Volume Crucial_SSD_OS          60.9 GB    disk2s1
   2:                APFS Volume Preboot                 19.9 MB    disk2s2
   3:                APFS Volume Recovery                503.9 MB   disk2s3
   4:                APFS Volume VM                      1.1 GB     disk2s4
[code]

Comme on pouvaient s'en douter impossible de remonter le disque, par contre, de gros problème de vérification de structure dans les containers. Réparable selon toi ?

[code]-bash-3.2# diskutil mountDisk disk2
One or more volume(s) failed to mount
-bash-3.2#
-bash-3.2# diskutil repairDisk disk2
Nonexistent, unknown, or damaged partition map scheme
If you are sure this disk contains a (damaged) APM, MBR, or GPT partition map,
you can hereby try to repair it enough to be recognized as a map; another
"diskutil repairDisk disk2" might then be necessary for further repairs
Proceed? (y/N) y
Error repairing map: MediaKit reports bad partition or no map found (-5324)
-bash-3.2#
-bash-3.2# diskutil mount disk2s1
Volume on disk2s1 failed to mount; it appears to be an APFS Volume which might be locked
Try "diskutil apfs unlockVolume"
-bash-3.2# diskutil mount disk2s2
Volume Preboot on disk2s2 mounted
-bash-3.2# diskutil mount disk2s3
Volume Recovery on disk2s3 mounted
-bash-3.2# diskutil mount disk2s4
Volume VM on disk2s4 mounted
-bash-3.2# diskutil mount disk2s1
-bash-3.2#
-bash-3.2# diskutil verifyVolume disk2s1
Started file system verification on disk2s1 Crucial_SSD_OS
Verifying file system
Volume is already unmounted
Live mode required because other APFS Volumes in its Container are mounted
Using live mode
Performing fsck_apfs -n -l -x /dev/rdisk2s1
Checking volume
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the object map
Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
error: apfs_root: btn: invalid o_oid (0x79503)
fsroot tree is invalid
The volume /dev/rdisk2s1 could not be verified completely
File system check exit code is 0
Restoring the original state found as unmounted
Finished file system verification on disk2s1 Crucial_SSD_OS
-bash-3.2#
-bash-3.2# diskutil repairVolume disk2s1
Started file system repair on disk2s1 Crucial_SSD_OS
Repairing file system
Volume is already unmounted
Can't repair volume because other APFS Volumes in its Container are mounted. Unmount them, or perform a repair while running from another macOS system (such as the Recovery System)
Restoring the original state found as unmounted
Error: -69673: Unable to unmount volume for repair
-bash-3.2#
-bash-3.2# diskutil verifyVolume disk2s2
Started file system verification on disk2s2 Preboot
Verifying file system
Volume was successfully unmounted
Live mode required because other APFS Volumes in its Container are mounted
Using live mode
Performing fsck_apfs -n -l -x /dev/rdisk2s2
Checking volume
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the object map
Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots
Verifying allocated space
error: Underallocation Detected on Main device: (1018944+64) bitmap address (440930)
error: Underallocation Detected on Main device: (1019008+64) bitmap address (440930)
error: Underallocation Detected on Main device: (1019072+12) bitmap address (440930)
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
Space Verification failed
The volume /dev/rdisk2s2 could not be verified completely
File system check exit code is 0
Restoring the original state found as mounted
Finished file system verification on disk2s2 Preboot
-bash-3.2#
-bash-3.2# diskutil verifyVolume disk2s3
Started file system verification on disk2s3 Recovery
Verifying file system
Volume was successfully unmounted
Live mode required because other APFS Volumes in its Container are mounted
Using live mode
Performing fsck_apfs -n -l -x /dev/rdisk2s3
Checking volume
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the object map
Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots
Verifying allocated space
error: Underallocation Detected on Main device: (1018944+64) bitmap address (440930)
error: Underallocation Detected on Main device: (1019008+64) bitmap address (440930)
error: Underallocation Detected on Main device: (1019072+12) bitmap address (440930)
error: Underallocation Detected on Main device: (1035383+2) bitmap address (440930)
error: Underallocation Detected on Main device: (1035386+6) bitmap address (440930)
error: Underallocation Detected on Main device: (1035392+64) bitmap address (440930)
error: Underallocation Detected on Main device: (1035456+64) bitmap address (440930)
error: Underallocation Detected on Main device: (1035520+64) bitmap address (440930)
error: Underallocation Detected on Main device: (1035584+44) bitmap address (440930)
error: Underallocation Detected on Main device: (1067464+56) bitmap address (440932)
error: Underallocation Detected on Main device: (1067520+64) bitmap address (440932)
error: Underallocation Detected on Main device: (1067584+23) bitmap address (440932)
error: Underallocation Detected on Main device: (1067823+17) bitmap address (440932)
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
Space Verification failed
The volume /dev/rdisk2s3 could not be verified completely
File system check exit code is 0
Restoring the original state found as mounted
Finished file system verification on disk2s3 Recovery
-bash-3.2#
-bash-3.2# diskutil verifyVolume disk2s4
Started file system verification on disk2s4 VM
Verifying file system
Volume was successfully unmounted
Live mode required because other APFS Volumes in its Container are mounted
Using live mode
Performing fsck_apfs -n -l -x /dev/rdisk2s4
Checking volume
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the object map
Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots
Verifying allocated space
error: Underallocation Detected on Main device: (1018944+64) bitmap address (440930)
error: Underallocation Detected on Main device: (1019008+64) bitmap address (440930)
error: Underallocation Detected on Main device: (1019072+12) bitmap address (440930)
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 2 @ -1 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
warning: error (6) getting cib 5 bitmap 4 @ 4294967295 on device 0
Space Verification failed
The volume /dev/rdisk2s4 could not be verified completely
File system check exit code is 0
Restoring the original state found as mounted
Finished file system verification on disk2s4 VM
-bash-3.2#
-bash-3.2#

PS : J'ai volontairement supprimé quelques occurences au niveau des warning car dépasé la limite de caractéres.

- J'installe sur USB
- Je tente de réparer le volume endommagé & les containers.
- Je reviens vers toi.

Si, on avise et suis ton plan.

Merci pour ton aide.
 
Mon plan ne diffère pas du tien, en fait --> démarrer sur un High Sierra résidant sur un disque dur (et pas en RAM) --> pour voir si le volume Crucial_SSD_OS peut être remonté.

Sinon > si tu tiens absolument à récupérer des données > ce sera par un logiciel de récupération de données. Tu as de quoi créer un volume d'accueil des données récupérées en re-partitionnant le volume Crucial_SSD_HD.
 
Un logiciel de récupération de données ??
Enfin quoiqu'il en soit mon plan vient d'échouer. La clef fait pourtant 16 Go. Il est gourmand le petit !
MacOS n'a pas pu être installé sur votre ordinateur.
L'espace libre est insuffisant sur cline pour l'installation

Je t'ecoute (commande) pour effectuer un re-partitionnement (de manière non-destructive pour sonvolume) du volume Crucial_SSD_HD
 
Passe la commande :
Bloc de code: 
diskutil resizeVolume disk0s3 220g jhfs+ SOS 0b

  • cette commande rétrécit la partition disk0s3 à 220 Go > et crée une partiiton disk0s4 avec l'espace restant (environ 150 Go) > montant un volume intitulé SOS
  • l'affichage retourné t'apprend si la commande a été validée

=> si oui > tu peux installer à destination du volume SOS.
 
Oupss !
La commande a échoué.
Bloc de code: 
-bash-3.2# diskutil resizeVolume disk0s3 220g jhfs+ SOS 0b
Resizing to 220000000000 bytes and adding 1 partition
Started partitioning on disk0s3 Crucial_SSD_HD
Verifying the disk
Verifying file system
Volume was successfully unmounted
Performing fsck_hfs -fn -x /dev/rdisk0s3
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 Crucial_SSD_HD appears to be OK
File system check exit code is 0
Restoring the original state found as mounted
Resizing
Shrinking file system
Error: -69787: The partition cannot be resized; try reducing the amount of change in the size of the partition
-bash-3.2#
 
Passe la commande :
Bloc de code: 
df -H /Volumes/Crucial_SSD_HD

  • qui retourne le tableau d'occupation de l'espace pour le volume Crucial_SSD_HD

=> tu n'as qu'à poster le tableau. Je me suis sans doute planté dans la valeur numérique. Par contre > le système de fichiers est clair et accepte le re-dimensionnement.
 
Ci-dessous le tableau
Bloc de code: 
-bash-3.2# df -H /Volumes/Crucial_SSD_HD/
Filesystem     Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk0s3   370G   199G   171G    54%   39480 4294927799    0%   /Volumes/Crucial_SSD_HD
-bash-3.2#
 
Pourtant il n'y a que 199 Go d'espace occupé --> on doit bien pouvoir réduire le volume à 220 Go (ça laisse 21 go d'espace libre) ?

Changeons la valeur --> passe la commande :
Bloc de code: 
diskutil resizeVolume disk0s3 250g jhfs+ SOS 0b

  • est-ce qu'elle passe ?
 

Sujets similaires

F
Problème osx base system
Réponses
3
Affichages
491
macOS
Locke
Locke
J
10.12 Sierra Réinstallation mac Sierra
Réponses
2
Affichages
444
macOS
JulieReap
J
J
10.13 High Sierra Permission denied en essayant d'installer High Sierra depuis une clef USB
Réponses
12
Affichages
2K
macOS
jackoup
J
A
10.12 Sierra MacOS Sierra - Recovery Mode - Erreur installation
Réponses
5
Affichages
1K
macOS
Sly54
Sly54
V
disque dur hs
Réponses
5
Affichages
802
macOS
Locke
Locke
Haut Bas