Impossible de réparer mon MBP (dossier var...)

Alibaba44

Membre enregistré
5 Novembre 2013
2
0
Bonsoir,
J'ai télécharger un logiciel de nettoyage de fichier "Daisy disk" qui a par ma faute malencontreusement supprimé le dossier var.
Depuis impossible de :
- Démarrer l'ordinateur normalement.
- Démarrer l'ordinateur en mode sans échec.
- Impossible d'écrire des fichiers (mkdir/cp/mv) en mode single user (read-only) et impossible de passer en rw.
- Démarrer avec la touche R.
Donc je vous demande de l'aide pour :
Au mieux pouvoir creer en single user dans Volumes mon disque dur externe pour copier mes fichiers dessus avant de réinstaller.La méthode pour réinstaller OS X sachant que je n'ai pas de lecteur CD (rétina) même si je ne peux pas récupérer mes fichiers au pire.
J'ai déjà trouvé pas mal de truc à faire (les trucs plus haut) hélas sans succès.
Merci d'avance pour votre aide.
 
Salut Alibaba.

À la différence de ton homonyme du Conte qui pille le Trésor mal acquis des 40_Voleurs sans qu'il ne lui en nuise au final - dérober les honnêtes ressources cachées de ton propre Mac t'a exposé à d'immédiates sanctions :D.

Il n'est pas sûr à 100% que ce soit le répertoire var que tu aies supprimé. Parce que ledit répertoire fait partie du super-Répertoire : private localisé à la racine même de ton OS, et qui inclut en tant que sous-répertoires les dossiers-systèmes : etc, tfpboot, tmp et var justement. Mais la particularité d'OSX dans ses versions récentes est d'extrapoler hors du répertoire private dans l'espace_racine de l'OS 3 liens_symboliques pointant directement les 3 dossiers essentiels de ce répertoire, à savoir : ⤻etc, ⤻tmp et ⤻var. Parce qu'OSX nécessite on_launch l'accès direct à ces 3 dossiers_système, ce qu'assurent les 3 liens_symboliques, sans que les originaux cessent de demeurer hiérarchiquement dans le répertoire_parent private dans l'arborescence logique du Système [je trouve personnellement cette extrapolation_symbolique dédiée au boot, mais inopérante après_le_boot, quelque chose de fascinant pour un esprit spéculatif - mais je suis certain que ces abstruses considérations à rallonges sont en train de miner le moral d'Alibaba, aussi sûrement que les circonlocutions oratoires d'un praticien ne manquant pas d'être comprises d'un patient comme les précautions rhétoriques qui diffèrent l'annonce d'un diagnostic terminal :D].

Donc pour en venir au diagnostic : il y a bien des chances que ce soit le lien_symbolique : ⤻var que tu aies supprimé, et non pas le répertoire : var vraisemblablement toujours présent à l'intérieur du super-répertoire : private - ce, parce qu'en utilisant Daizy-Disk 'Bouzi-Disque' (qui s'ajoute à la liste de ces 'Hara_Ki_Mac' qui, dévoilant les entrailles secrètes de l'OS, ne manquent d'inciter le néophyte à un acte d'évicération logicielle), tu as eu la 'révélation' de l'espace-racine de l'OS où la présence de liens_symboliques (⤻etc, ⤻tmp et ⤻var) à côté de répertoires et de fichiers originaux t'a conduit à les juger dispensables comme si c'était de vulgaires alias auxquels ils ressemblent graphiquement [tu aurais aussi bien pu, dans la foulée, supprimer le fichier mach_kernel lui-même, car un fichier libre à côté de dossiers bien rangés : ça fait 'désordre' n'est-ce pas? et hop! du balai en toute logique 'nettoyeuse'...].

Bref, ton OS n'est plus démarrable, mais à le supposer démarré, il serait viable (car un lien_symbolique de boot a été supprimé, mais pas le répertoire de fonctionnement).

Réparation : en plaçant ton MacBook Pro_Rétina en mode 'Target' (touche T pressée au démarrage jusqu'à apparition du logo mobile en Y du FireWire), qui le vire à la fonction de DDE, tu peux établir la connexion 'Cible' avec un autre Mac qui jouera le rôle de 'Source' - soit directement avec un cordon 'Thunderbolt', si le Mac 'Source' a un port 'Thunderbolt', soit indirectement avec un cordon 'FireWire' (si le Mac Source n'a qu'un port FireWire') qui se connectera au Mac 'Cible' grâce à l'embout de raccordement Apple : Thunderbolt⟷FireWire [vérifier si le port 'FireWire' du Mac 'Source' est bien un port 800 (rectangle régulier) et pas 400 (rectangle biseauté d'un côté), car si c'était le cas un cordon FireWire_400 devrait, côté Mac 'Cible', comporter 2 raccords en ligne : embout FireWire_400⟷800⟷embout FireWire⟷Thunderbolt]. Bref : chercher un Mac 'Thunderbolt', pour faire simple, sur lesquel tourne le même OS.

L'image-disque du SSD du MacBook Pro_Rétina une fois montée sur le Bureau du Mac 'Source' comme celle d'un DDE, vérifier si c'est uniquement le lien symbolique : ⤻var qui manque, ou si c'est carrément le dossier var absent du répertoire private, et par glisser-déposer au bon emplacement à partir des items correspondant du Mac 'Source', restaurer des copies_conformes à l'endroit requis. Après quoi, le kernel devrait sans rechigner opérer sa tâche de chargement des fondations BSD_UNIX du Système on_boot et ton OS devrait se lancer.

Sinon, c'est ré-installation en mode 'Target' encore, ou à partir d'une clé USB embarquant l'installateur OSX Install.
 
Dernière édition par un modérateur:
Sur Mac on n'a pas de virus (ou si peu...) mais on n'en a pas besoin!
tous ces logiciels de "nettoyage" s'y substituent de façon remarquablement efficace.

Daisy disk... je ne le connaissais pas ce lui-là

Vu le nom, je suppose qu'il supprime les dossiers système un à un en sussurant une petite comptine du style
"ce Mac marche toujours, un peu (hop un dossier), beaucoup (hop un autre), passionnément (encore un!), à la folie (oh! je joli dossier /var !), ... pas du tout!"
 
Je rajouterais (en acquiesçant aux aimables piques de r e m y que je salue :coucou:) que, si c'est le répertoire var qui a été supprimé, et pas seulement le lien symbolique ⤻var qui le pointe, un problème d'autorisation de copie risque fort de se poser, même après renseignement d'un mot-de-passe admin, parce que le répertoire var, parmi les +20 000 (!) fichiers qu'il contient en comprend que le Finder n'est pas autorisé à copier.

À supposer même la copie effectuée, des problèmes de réparation de droit d'accès se poseraient. Car le dossier copié à la racine de l'OS 'Cible' va importer un propriétaire qui ne sera plus root (='Système) en Lecture & écriture, ainsi qu'un groupe qui ne sera plus wheel (le groupe_système) en Lecture seulement, mais l'utilisateur-admin du Mac-Source s'étant approprié le dossier à la copie et qui deviendra un 'inconnu' pour l'OS 'Cible', et le groupe 'staff' des ayant-comptes simples. Ce qui risque fort de bloquer l'accès au répertoire on_launch.

Le mieux serait encore d'activer l'utilisateur root du Mac 'Source' afin d'opérer la copie sur le Mac 'Cible' à partir d'une session root. Mais je vois d'ici la tête de l'aimable prêteur devant l'ampleur des opérations :D. Surtout qu'une fausse manœuvre pourrait lui supprimer des répertoires décisifs (je suggère etc par exemple).

Pour me résumer : si c'est le lien symbolique qu'il faut remplacer, passe ; sinon, récupérer les données (au cas où) en mode 'Target', et ré-installer en mode non destructif.
 
Ôh seigneur macomaniac, merci beaucoup pour votre aide, Grace aux informations que vous m'avez transmises et un peu d'huile de coude, mon Mac fonctionne a nouveau :)
Veuillez recevoir mes remerciements les plus sincères !
Vous souhaitant bonne journée !