iMac bloqué sur "pomme" au démarrage après modif des permissions

La réponse à la première commande :

chown: /dev/fd/3: Not a directory
chown: /dev/fd/4: Bad file descriptor
chown: /network: No such file or directory
chown: /System/library/CoreServices/boot.efi: Operation not permitted
:/ root#

Le ton général de cette réponse m'inquiète un peu... Est-ce que je passe quand même la commande

chown -h 0:0 /etc /tmp /var

?
 
Une question, en attendant :
quand je démarre en single user, les dernières lignes de l'écran de démarrage indiquent :

If you want to make modifications to files:
/sbin/fsk -fy
/sbin/mount -uw /

Or, que ce soit pour mon fsk -fy d'hier ou pour mon mount -uw / d'ajourd'hui, je n'ai pas tapé /sbin/, mais directement la commande.

Faut-il faire ce /sbin/ , ou continuer à s'en passer ?
 
Les deux séries de commandes (sans /sbin/ ) que tu proposes, macomaniac, n'ont rien donné : reboot renvoie à la pomme, et la roue tourne...

Pendant ce temps, j'ai relu ton premier message. Je vois bien comment j'ai changé les permissions (cf #27 ), mais pas comment j'ai pu changer le groupe propriétaire des dossiers du système...

Voici le résultat de la deuxième série de commandes. Et sur ce, repos pour les hommes et les machines ! ;)

P1170426.webp
 
La première chose que tu devrais faire:
mount -uw /
puis
fsck -fy

Ensuite 2 erreurs dans tes commandes ci-dessus :
dans le premier chmod : /Syste; au lieu de /System
et dans l'avant dernier /temp au lieu de /tmp
Donc tu peux repasser les 2 commandes :
chmod -R go-w /System
puis
chmod -h go-w /tmp

Si tout ça ne donne rien, fais un démarrage en mode "Verbeux" :
cmd+v lors du boot et prend une photo au moment où ça s'arrête.

Perso j'aurais bien tenté (si rien ne fonctionne) de passer les commandes suivantes :
mount -uw /
puis
fsck -fy
puis
pmset noidle &
puis
/usr/libexec/repair_packages --repair --standard-pkgs /

Juste avant de se bloquer sur cette dernière commande la première fois, ton mac s'est-il mis en veille (écran éteint)?
 
Dernière édition par un modérateur:
:coucou: Jean

Ayant sur des partitions de disques de mon MacBook Pro 17" Late_2011 toutes les versions de macOS installées, de 10.6.8 à 10.12.4 (ce MacBook Pro Late_2011 - quoiqu'ayant comme OS d'usine « théorique » : «Lion 10.7.2» - a été "convaincu" par mes soins de booter en 10.6.8 comme si c'était son OS originel) --> j'ai donc pu vérifier au cas par cas, dossier à dossier avec des sondages intra-dossiers, l'état des droits dans un OS «Snow Léopard» non trafiqué. Je m'en suis inspiré pour proposer le jeu de commandes rectificatrices que tu as pu voir.

Comme tu l'as relevé > malgré la réelle application de xunolive- :coucou: (ce qui n'est pas évident dans l'interface incommode du Single User) > il y a eu une erreur de chmod sur /System (orthographié /Syste;). Il n'est pas impossible de concevoir que l'erreur de permissions récursive sur /System (qui recèle les extensions et les essentiels de l'architecture de l'OS) puisse bloquer la tâche du kernel --> d'où la nécessité de repasser une commande :
Bloc de code:
chmod -R go-w /System

Mais il me vient aussi un nouveau scrupule : régulièrement > le volume démarrable d'OS X (considéré comme dossier parent de l'espace global des fichiers-Système) doit avoir comme droits stricts :
Bloc de code:
755 root wheel
=> se pourrait-il que l'actuel (je le présume > si xunolive a opéré ses modifications sur le répertoire global du volume) :
Bloc de code:
777 root admin
bloque le kernel ? Alors il faudrait aussi passer en Singler User (après récidive du mount -uw / bien sûr) les commandes :
Bloc de code:
chown 0:0 /
chmod 755 /
pour rétablir les choses.

Et cela opéré > forcer la main au kernel par les 2 commandes :
Bloc de code:
touch /System/Library/Extensions
(pour mettre à jour la marque de temps sur le répertoire des extensions) et :
Bloc de code:
kextcache -u /
pour reconstruire le cache de démarrage-System kernelcache.

=> si on arrivait à générer un kernel_panic au boot > ce serait une progression décisive...-
361608_original.png
Parce que : é pur si muove (et pourtant elle tourne)... la roue crantée giratoire indicatrice que le kernel a bien été activé et cherche désespérément à charger les extensions avant de démarrer le processus INIT (launchd).
 
Hello Maco :coucou:

Post #13 je lui ai fait faire un :
chmod 755 /
Mais pas un
chown 0:0 /

Pour en avoir le cœur net il faudrait que @xunolive nous donne le retour de :
ls -ld /
 
Bonjour à vous !

Je ne sais comment vous remercier de vous donner tout ce mal pour moi !

Pour répondre à vos questions :

- à aucun moment durant les manips en single user le mac ne s'est mis en veille. L'écran est resté vaillamment allumé d'un bout à l'autre.

- GRMBL ! Je les ai pourtant relues attentivement avant de les valider, ces commandes !

- ce matin, les commandes mount -uw / et fsck -fy indiquent que le volume semble ok.

ls ld / donne

drwxr-xr-x 33 root wheel 1190 Sep 14 2015 /


... et je m'en vais donc tenter chmod -R go-w /System puis chmod -h go-w /tmp
 
Et si tu n'obtiens rien de bon de ce coté là, tente :
mount -uw /
puis
fsck -fy
puis
pmset noidle &
puis
/usr/libexec/repair_packages --repair --standard-pkgs /
 
Complète la série avec (commandes à passer l'une après l'autre) :
Bloc de code:
chown 0:0 /
chmod 755 /
touch /System/Library/Extensions
kextcache -u /
 
Et si rien ne fonctionne, si tu as le dvd Snow Leopard, tente de réinstaller.
Normalement tes données ne devraient pas être touchées.
 
Complète la série avec (commandes à passer l'une après l'autre) :
Bloc de code:
chown 0:0 /
chmod 755 /
touch /System/Library/Extensions
kextcache -u /
Les 2 première commandes sont inutiles si tu regardes les retours de :
ls -ld / :
drwxr-xr-x 33 root wheel 1190 Sep 14 2015 /
 
Les réponses :

chmod -R go-w /System


chmod: Unable toi change file mode on /System/Library/CoreServices/boot.efi: Operation not permitted

chmod -h go-w /tmp

:/ root#
 
Le boot_loader : boot.efi est un fichier verrouillé par défaut > il est donc insusceptible de modification (il n'a donc pas été affecté au départ par les modifications de droits mais a gardé ses permissions intactes). C'est l'exécution de ce fichier démarreur qui se signale à l'écran au démarrage par la .

L'échec de la commande sur cet élément > ne l'a pas empêché d'être effectuée sur le reste du répertoire /System.
 
Donc là ça va être long et faut espérer que tu récupères le prompt
:/ root#

Si ce n'est pas efficace, il faudrait peut être commencer par sauver tes données (si ce n'est pas fait) puis tenter une réinstallation via le DVD ou une clé créée pour l'occasion sur un autre Mac.
 
Les données sont pour l'essentiel sauvées, mais manuellement, sur un DD externe, mais certaines sont verrouillées, d'où ma manip malencontreuse.

J'ai mes CD d'installation, mais le lecteur interne est quasi mort, je crains de bloquer l'un des cd à l'intérieur, et je n'ai pas réussi à démarrer sur le lecteur USB... Et je ne crois pas connaitre de possesseur de mac dans mon entourage (mais je vais fouiller dès la fin de mes vacances...).

C'est pourquoi je m'obstine à m'arracher les cheveux en "single user" et sur mon dictionnaire qwerty/azerty :D

Là, après une longue alternance de lignes commençant par "permissions differ on..." et "repaired...",
me voici bloqué (sans :/ root# ) sur

Bloc de code:
Repaired "System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/Support/LockScreen.app/Contents/Ressources/English.lproj/MainMenu.nib".

Est-ce que je force l’extinction pour tenter ce que vous suggériez plus haut ?

Passe ces 2 commandes (dixit Maco) :
touch /System/Library/Extensions
kextcache -u /

puis
exit
 
Sur l'écran bloqué, la ligne précédant le "repaired "System/..." est :

Permissions differ (...), should be drwxr-xr-x , they are -rwxr-xr-x .
 
Dernière édition:
C'est étonnant que ton ordi bloque comme ça.
Redémarre et tente les commandes listées.
Puis tu repasses celles que je t'ai donné.
L'idéal serait de démarrer sur le DVD et demander la réinstallation du système depuis le lecteur externe (cmd+c lors du boot)