Je viens de récupérer un Macbook (OS X 10.5.2, Leopard) qui ne démarrait pas car il restait éternellement bloqué sur un écran gris avec un logo Apple et une roue qui tourne. Le coupable était un fichier de configuration corrompu ( /etc/authorization
), et je vais décrire ci-dessous comment j'ai trouvé et résolu le problème.
D'abord, j'ai vérifié si le matériel était correct, en redémarrant et en appuyant sur D pour exécuter des diagnostics matériels. Le matériel était en bon état, j'ai donc continué à chercher des messages d'erreur.
Après avoir démarré en mode Verbose ( Command () + V ), j'ai vu que securityd s'est planté, et qu'un journal de plantage a été écrit dans le fichier /Library/Logs/CrashReporter/securityd_2015-06-23-120634_localhost.crash
. Donc une fois de plus, j'ai redémarré pour obtenir un shell en mode mono-utilisateur ( Command () + S ). Le journal a montré que le crash a été causé par un appel à CFDictionaryContainsKey
(qui a déclenché un EXC_BAD_ACCESS
erreur). Cela a alimenté ma suspicion que le crash était causé par un mauvais fichier de configuration.
Je suis finalement tombé sur cet article de blog ce qui suggère d'utiliser fs_usage
pour surveiller et enregistrer l'activité du fichier :
mount -uw /
fs_usage > /var/log/fs-usage.log &
exit
Après le redémarrage, j'ai regardé dans /var/log/fs-usage.log
et a constaté que securityd
consulté sur private/etc/authorization
avant de s'écraser. J'ai ensuite visualisé le contenu de /etc/authorization
et il était en effet cassé au-delà de toute réparation.
Pour récupérer ce fichier, j'ai cherché la version originale du fichier dans la source de la securityd
paquet (référencé à Le code source d'OS X 10.5.2 ). J'ai fini par trouver etc/authorization.plist
qui présentait des similitudes avec le corrompu /etc/authorization
.
Pour terminer la récupération, j'ai mis le nouveau etc/authorization.plist
sur une clé USB, l'a branchée sur le Macbook (toujours en mode utilisateur unique) et a monté le lecteur comme suit :
mount -uw /
launchctl load /System/Library/LaunchDaemons/com.apple.kextd.plist
# Wait about 20 seconds
mkdir /Volumes/usb
mount -t msdos -v -o ro /dev/disk1s1 /Volumes/usb
J'ai ensuite copié le fichier vers sa destination, démonté la clé USB, synchronisé et redémarré avec succès :
cp /Volumes/usb/authorization.plist /etc/authorization
umount /Volumes/usb
sync
reboot
0 votes
Vous pouvez essayer de réinitialiser la NVRAM (PR jusqu'au deuxième carillon) mais si cela ne fonctionne pas, essayez un démarrage verbeux (V) et voyez ce que cela donne.
0 votes
Que fait exactement un démarrage verbeux ?