10.9.3 est disponible
- Créateur du sujet gpsnail
- Date de début
Je ne pense pas que cette histoire du dossier Users soit volontaire. Quel intérêt ?
C'est plutôt le même sagouin qui nous avait fait le coup de mach_kernel en 10.8.5 qui a récidivé.
Je précise que je n'ai pas ce problème. J'ai activé les partages et j'ai quelques dossiers dans /users/shared.
C'est plutôt le même sagouin qui nous avait fait le coup de mach_kernel en 10.8.5 qui a récidivé.
Je précise que je n'ai pas ce problème. J'ai activé les partages et j'ai quelques dossiers dans /users/shared.
Bon, je viens d'essayer la solution trouvé sur MacBidouille : http://forum.macbidouille.com/index.php?showtopic=380739&st=30&gopid=3863306&#en try3863306
Elle a marché dans mon cas.
Elle a marché dans mon cas.
Je marquerai 10.9.3 d'une pierre blanche, moi qui ne fais jamais d'emblée les mises à jour du Système =
Do not interrupt the installation process once you have started to update your system.
(n'interrompez pas le processus d'installation une fois que vous avez commencé la mise à jour)
selon l'avertissement d'Apple.
Hier soir, de nouvelles mises à jour m'ont été annoncées dans le Finder via la bannière habituelle : j'ai laissé en l'état.
Ce matin, je regarde dans App Store ce que sont les mises à jour : iTunes et RAW. Je laisse se terminer la recherche d'une autre mise à jour.
Pour tester (!), je quitte l'App Store et je valide la bannière : la nécessité d'un redémarrage s'affiche alors. :eek:
Je retourne dans l'App Store et je vois la 10.9.3 qui se télécharge, avec un bouton Annuler qui ne fonctionne pas.
Je coupe le wi-fi et me crois sauvé.
Quelques minutes plus tard, le Mac s'éteint de lui-même pour redémarrer et effectuer la 10.9.3 (incomplètement téléchargée, donc). :eek:
Au redémarrage, écran bleu inerte.
Extinction forcée, et redémarrage en mode sans extension : une fois le wi-fi reconnecté (en 10.9.2 selon le menu 
, la 10.9.3 s'affiche autant dans les logiciels récemment mis à jour que dans les nouvelles mises à jours de l'App Store
:heu:
Je télécharge et applique donc la Combo.
Mon Mac redémarre enfin normalement, en 10.9.3.
J'ai juste perdu le son dans ma session. :mad:
Do not interrupt the installation process once you have started to update your system.
(n'interrompez pas le processus d'installation une fois que vous avez commencé la mise à jour)
selon l'avertissement d'Apple.
Hier soir, de nouvelles mises à jour m'ont été annoncées dans le Finder via la bannière habituelle : j'ai laissé en l'état.
Ce matin, je regarde dans App Store ce que sont les mises à jour : iTunes et RAW. Je laisse se terminer la recherche d'une autre mise à jour.
Pour tester (!), je quitte l'App Store et je valide la bannière : la nécessité d'un redémarrage s'affiche alors. :eek:
Je retourne dans l'App Store et je vois la 10.9.3 qui se télécharge, avec un bouton Annuler qui ne fonctionne pas.
Je coupe le wi-fi et me crois sauvé.
Quelques minutes plus tard, le Mac s'éteint de lui-même pour redémarrer et effectuer la 10.9.3 (incomplètement téléchargée, donc). :eek:
Au redémarrage, écran bleu inerte.
Extinction forcée, et redémarrage en mode sans extension : une fois le wi-fi reconnecté (en 10.9.2 selon le menu 
, la 10.9.3 s'affiche autant dans les logiciels récemment mis à jour que dans les nouvelles mises à jours de l'App Store
:heu:Je télécharge et applique donc la Combo.
Mon Mac redémarre enfin normalement, en 10.9.3.
J'ai juste perdu le son dans ma session. :mad:
Bah, je laisse toujours les autres essuyer les plâtres,
et quand je décide de me lancer, c'est après maintenance et sauvegardes.
Là, je me suis fait prendre par surprise. :o
et quand je décide de me lancer, c'est après maintenance et sauvegardes.
Là, je me suis fait prendre par surprise. :o
Bonsoir ,
Est.il possible de télécharger la 10.9.3 directement sur un DDE sans l'installer directement sur la machine si oui comment forcer le téléchargement sur le DDE
Merci
Le Mbp vient d'être révise et marche super bien , je n'ai pas envié de le déstabiliser
Merci pour votre aide
cordialement
Ccim12
Est.il possible de télécharger la 10.9.3 directement sur un DDE sans l'installer directement sur la machine si oui comment forcer le téléchargement sur le DDE
Merci
Le Mbp vient d'être révise et marche super bien , je n'ai pas envié de le déstabiliser
Merci pour votre aide
cordialement
Ccim12
Une mise à jour sur Mac OS ne cause des problèmes que sur les systèmes déjà problématiques (mais dont l'utilisateur n'est pas forcément au courant, c'est en fonction de ce qu'il fait ou utilise sur sa session). L'histoire du dossier utilisateur caché c'est le cas.
J'ai eu des Macs depuis 2008, les MAJ toutes faites day 1, jamais un seul problème à signaler, comme des millions de gens. Chaque install est différente, c'est ces diférences d'un utilisateur à l'autre qui posent problème, pas les MAJ
Par contre récemment sur Windows 8.1 Update 1, une mise à jour a gaiement par un moyen assez loufoque, fait en sorte que mon mot de passe de session de soit plus reconnu au redémarrage. Pourquoi, mystère.
J'ai eu des Macs depuis 2008, les MAJ toutes faites day 1, jamais un seul problème à signaler, comme des millions de gens. Chaque install est différente, c'est ces diférences d'un utilisateur à l'autre qui posent problème, pas les MAJ
Par contre récemment sur Windows 8.1 Update 1, une mise à jour a gaiement par un moyen assez loufoque, fait en sorte que mon mot de passe de session de soit plus reconnu au redémarrage. Pourquoi, mystère.
tout fonctionne bien, j'ai même une impression de plus grande réactivité, et même firewire qui ne voulait plus rien savoir refonctionne et je peux abandonner l'usage de l'USB2 et chaîner mes DDE en FW800 
Une seule interrogation pourquoi dans les préférences system, FW est-il marqué comme non connecté  en même temps, du temps où ça fonctionnait, je ne me suis jamais préoccupé de ce que disait les pref system. Qu'est-ce qui est normal ?
Une seule interrogation pourquoi dans les préférences system, FW est-il marqué comme non connecté 
en même temps, du temps où ça fonctionnait, je ne me suis jamais préoccupé de ce que disait les pref system. Qu'est-ce qui est normal ?
tout fonctionne bien, j'ai même une impression de plus grande réactivité, et même firewire qui ne voulait plus rien savoir refonctionne et je peux abandonner l'usage de l'USB2 et chaîner mes DDE en FW800 
Une seule interrogation pourquoi dans les préférences system, FW est-il marqué comme non connecté 
Le FW est aussi une interface réseau. C'est de cela qu'il s'agit ici.
Si tu veux vérifier pour tes disques, tu vas dans les informations système.
M
Membre supprimé 1060554
Invité
Je reviens sur la dissimulation au Finder du répertoire Utilisateurs qui, apparemment, n'affecte que certains utilisateurs et pas d'autres pour une raison des plus obscures. J'irais volontiers dans le sens de Moonwalker quand il écrit :
Il semble qu'un forçat de la ligne de code se soit pris les pieds dans le tapis, en effet, à la différence avec la MÀJ de «Mountain Lion» que le fichier mach_kernel manquait universellement du flag_hidden alors, tandis qu'ici c'est le même flag_hidden qui se trouve imposé au répertoire on_launch par je ne sais quelle instruction dans je ne sais quel fichier que visite le processus launchd au démarrage. Par conséquent, il s'agirait d'une instruction récurrente affectant le boot.
Mais ce qui m'intrigue quand même, intellectuellement parlant, c'est la présence aléatoire de cette instruction du flag_hidden, et pour ma part mon OS en est affligé sans que j'ai pu prendre le mal à la racine, mais seulement le patcher a posteriori par le LoginHook que j'ai évoqué malicieusement auparavant (solution discutable, car le recours à cette implémentation du fichier : /var/root/Library/Preferences/com.apple.loginwindow file se trouve actuellement dépréciée - 'deprecated' - sous OSX 10.9). Aucune des manipulations que j'ai tentées (ré-installation de la MÀJ-Combo 10.9.3 ou réparation du volume et des autorisations depuis la partition de Récupération) n'a eu d'effet pour ce qui est de mon Système.
J'ai regardé la 'solution' proposée par un certaincommandant kousto d'après le lien donné par gpsnail, qui consiste à se logguer dans la session Récupération pour réparer le volume Macintosh HD et ses autorisations par l'«Utilitaire de Disque», puis à rectifier les permissions sur /Users et /Users/Shared avant de rétablir le flag_nohidden sur ces répertoires (opération qui n'a pas marché pour moi), et il y a un point qui m'a intrigué (je sais gré à ce plongeur des profondeurs d'OSX pour cela) --> il propose en effet, loggé dans l'espace-racine :
càd. de rectifier d'abord à drwxr-xr-x les permissions sur le répertoire des Utilisateurs sans changement des accédants (qui sont réguliers : user : root, group : wheel, other : everyone), ce qui équivaut à : lecture/écriture/exécution[de l'entrée au répertoire] pour root et seulement lecture/exécution [sans écriture] pour le groupe wheel et le tout-venant.
Pourquoi diantre? C'est qu'apparemment chez ceux (du moins - mais qui sait? je serais un des heureux bénéficiaires de la visibilité du répertoire, je vérifierais...) qui sont affligés de la dissimulation au Finder du répertoire des Utilisateurs, une autre facétie se trouve instruite on_launch : à savoir la mise-en-permissions totales du susdit répertoire, qui se trouve au démarrage en :
soit en 777 en valeur octale. Cette valeur est la preuve, s'il était besoin d'en attester une, qu'il y a bien bourde de codage, car accorder des permissions d'écriture au tout-venant sur l'espace interne du répertoire des Utilisateurs (du même geste où on le fait glisser dans l'invisibilité graphique) instaure une exception logique en ce qui concerne le statut des répertoires de l'espace-racine / de OSX. En effet, cela implique que n'importe quel utilisateur standard de l'OS, par exemple, à supposer que par la commande ⌘⇧G du Finder (Aller au dossier...) il renseigne '/Utilisateurs'), se trouve en capacité de supprimer carrément n'importe quel dossier de départ des autres utilisateurs, même admins, ce sans authentification, car nanti a priori de permissions d'édition directe de l'espace du répertoire.
Instruction manifestement antinomique de celle de la dissimulation du répertoire au Finder, car introduisant un faille de sécurité là où l'autre paraît faire de la surenchère dans la sécurité - ce qui, d'un point de vue logique, signe une incohérence.
Inlassablement sur mon Mac on_launch, de même que le répertoire des Utilisateurs se trouve frappé d'invisibilité graphique, il se trouve généreusement crédité de permissions totales, et curieusement mon implémentation du script shell que j'ai créé par un chmod [root] 755 sur le répertoire n'empêche pas que les Utilisateurs se retrouvent en 777 au déploiement de ma session graphique. Tout se passe comme si les 2 instructions paradoxales étaient a-synchrones, ou du moins de 'force' différente, celle du flag étant aisément over_written par mon script, l'autre (celle des permissions totales) over_writting mon instruction d'ouverture de session.
Pour accentuer le côté : 'abscons point-de-détail scolastique' de mon billet, lorsque le sus-évoquécommandant kousto introduit en 2è ligne un :
à partir de la session de la Récupération d'où il s'est loggé dans l'espace-racine de l'OS, manifestement il erre (à mon sens), car le sous-répertoire Partagé des Utilisateurs devrait posséder l'implémentation paradoxale de permissions totales pour tous (soit : drwxrwxrwx root wheel other), càd. de permission d'écriture à son espace permettant à tous d'y loger quelque chose à destination informative des autres ; restreinte par un sticky_bit ('brin_gluant' --> effet de scotch dont le prototype graphique se trouve dans le gag du 'sparadrap' indécrochable qui affecte le Capitaine Haddock dans «L'Affaire Tournesol») qui freine la capacité par les autres de supprimer les données introduites dans l'espace du répertoire par son propriétaire).
La commande 755 sur le sous-répertoire Partagé est à la fois trop restreinte (en permissions d'écriture pour tous) et trop laxiste (en ignorance du sticky_bit - lequel, d'après la MÀJ de mon OS du moins - fait défaut sur le sous-répertoire).
quand il écrit :Il semble qu'un forçat de la ligne de code se soit pris les pieds dans le tapis, en effet, à la différence avec la MÀJ de «Mountain Lion» que le fichier mach_kernel manquait universellement du flag_hidden alors, tandis qu'ici c'est le même flag_hidden qui se trouve imposé au répertoire on_launch par je ne sais quelle instruction dans je ne sais quel fichier que visite le processus launchd au démarrage. Par conséquent, il s'agirait d'une instruction récurrente affectant le boot.
Mais ce qui m'intrigue quand même, intellectuellement parlant, c'est la présence aléatoire de cette instruction du flag_hidden, et pour ma part mon OS en est affligé sans que j'ai pu prendre le mal à la racine, mais seulement le patcher a posteriori par le LoginHook que j'ai évoqué malicieusement auparavant (solution discutable, car le recours à cette implémentation du fichier : /var/root/Library/Preferences/com.apple.loginwindow file se trouve actuellement dépréciée - 'deprecated' - sous OSX 10.9). Aucune des manipulations que j'ai tentées (ré-installation de la MÀJ-Combo 10.9.3 ou réparation du volume et des autorisations depuis la partition de Récupération) n'a eu d'effet pour ce qui est de mon Système.
J'ai regardé la 'solution' proposée par un certain
Bloc de code:
chmod 755 Userscàd. de rectifier d'abord à drwxr-xr-x les permissions sur le répertoire des Utilisateurs sans changement des accédants (qui sont réguliers : user : root, group : wheel, other : everyone), ce qui équivaut à : lecture/écriture/exécution[de l'entrée au répertoire] pour root et seulement lecture/exécution [sans écriture] pour le groupe wheel et le tout-venant.
Pourquoi diantre? C'est qu'apparemment chez ceux (du moins - mais qui sait? je serais un des heureux bénéficiaires de la visibilité du répertoire, je vérifierais...) qui sont affligés de la dissimulation au Finder du répertoire des Utilisateurs, une autre facétie se trouve instruite on_launch : à savoir la mise-en-permissions totales du susdit répertoire, qui se trouve au démarrage en :
Bloc de code:
drwxrwxrwx root wheel othersoit en 777 en valeur octale. Cette valeur est la preuve, s'il était besoin d'en attester une, qu'il y a bien bourde de codage, car accorder des permissions d'écriture au tout-venant sur l'espace interne du répertoire des Utilisateurs (du même geste où on le fait glisser dans l'invisibilité graphique) instaure une exception logique en ce qui concerne le statut des répertoires de l'espace-racine / de OSX. En effet, cela implique que n'importe quel utilisateur standard de l'OS, par exemple, à supposer que par la commande ⌘⇧G du Finder (Aller au dossier...) il renseigne '/Utilisateurs'), se trouve en capacité de supprimer carrément n'importe quel dossier de départ des autres utilisateurs, même admins, ce sans authentification, car nanti a priori de permissions d'édition directe de l'espace du répertoire.
Instruction manifestement antinomique de celle de la dissimulation du répertoire au Finder, car introduisant un faille de sécurité là où l'autre paraît faire de la surenchère dans la sécurité - ce qui, d'un point de vue logique, signe une incohérence.
Inlassablement sur mon Mac on_launch, de même que le répertoire des Utilisateurs se trouve frappé d'invisibilité graphique, il se trouve généreusement crédité de permissions totales, et curieusement mon implémentation du script shell que j'ai créé par un chmod [root] 755 sur le répertoire n'empêche pas que les Utilisateurs se retrouvent en 777 au déploiement de ma session graphique. Tout se passe comme si les 2 instructions paradoxales étaient a-synchrones, ou du moins de 'force' différente, celle du flag étant aisément over_written par mon script, l'autre (celle des permissions totales) over_writting mon instruction d'ouverture de session.
Pour accentuer le côté : 'abscons point-de-détail scolastique' de mon billet, lorsque le sus-évoqué
Bloc de code:
chmod 755 Users/Sharedà partir de la session de la Récupération d'où il s'est loggé dans l'espace-racine de l'OS, manifestement il erre (à mon sens), car le sous-répertoire Partagé des Utilisateurs devrait posséder l'implémentation paradoxale de permissions totales pour tous (soit : drwxrwxrwx root wheel other), càd. de permission d'écriture à son espace permettant à tous d'y loger quelque chose à destination informative des autres ; restreinte par un sticky_bit ('brin_gluant' --> effet de scotch dont le prototype graphique se trouve dans le gag du 'sparadrap' indécrochable qui affecte le Capitaine Haddock dans «L'Affaire Tournesol») qui freine la capacité par les autres de supprimer les données introduites dans l'espace du répertoire par son propriétaire).
La commande 755 sur le sous-répertoire Partagé est à la fois trop restreinte (en permissions d'écriture pour tous) et trop laxiste (en ignorance du sticky_bit - lequel, d'après la MÀJ de mon OS du moins - fait défaut sur le sous-répertoire).
Dernière édition par un modérateur:
D
Deleted member 18124
Invité
A
Anonyme
Invité
D
Deleted member 18124
Invité
M
Membre supprimé 1060554
Invité
Exact, C0rentin. Bourde réparée chez moi (qui en souffrais) après téléchargement de «iTunes 11.2.1» --> visibilité automatique du répertoire Utilisateurs + du sous-répertoire Partagé et rectification des permissions à drwxr-xr-x root admin everyone sur le répertoire Utilitsateurs et à drwxrwxrwxt root wheel everyone sur le sous-répertoire Partagé comme attendu.
Petit soucis depuis la mise à jour, mon iMac late 2013 (SSD apple interne) démarre systèmatiquement en 40 sec au lieu de moins de 15 sec habituellement.
Pour le reste, les performances du SSD ne sont pas affectées, toujours la rapidité en écriture et lecture (autour de 700 Mb/s selon Disk speed test), lancement des applis toujours rapide etc...
mais je ne comprends pas pourquoi le démarrage est retardé de la sorte.
J'ai passé les réparations onyx , çà ne change rien.
c'est pas bien gênant vu que je redémarre pas le mac très souvent, mais c'est curieux de voir un SSD démarrer comme un disque normal alors qu'il démarrait très rapidement avant cette 10.9.3.
Si quelqu'un a le même phénomène? (iMac 27" i5 late 2013)
Merci
Pour le reste, les performances du SSD ne sont pas affectées, toujours la rapidité en écriture et lecture (autour de 700 Mb/s selon Disk speed test), lancement des applis toujours rapide etc...
mais je ne comprends pas pourquoi le démarrage est retardé de la sorte.
J'ai passé les réparations onyx , çà ne change rien.
c'est pas bien gênant vu que je redémarre pas le mac très souvent, mais c'est curieux de voir un SSD démarrer comme un disque normal alors qu'il démarrait très rapidement avant cette 10.9.3.
Si quelqu'un a le même phénomène? (iMac 27" i5 late 2013)
Merci
Dernière édition:
Sujets similaires
