Un redémarrage pas banal !

seserge

Membre actif
2 Octobre 2007
190
5
Bonjour à tous,
Aujourd'hui je décide, ayant du temps à perdre, de réparer les autorisations, et de vérifier mon disque dur, sur mon iMac C2Duo de 2007 (?} sous Snow Leopard 10.6.8
Tout se passe bien.
Je veux mettre à la corbeille un document, une boîte de dialogue s'ouvre : "êtes-vous sûr...le document sera supprimé immédiatement...irréversible..." comme si ce doc était sur un autre volume...j'essaie avec un nouveau dossier vide que je crée sur le bureau pour essayer, même réponse...
Je fais Pomme I sur le DD, afin de vérifier si je suis tjrs en mode admin...je demande dans cette fenêtre à ce que tous mes droits soient attribués aux éléments inclus...un long moment se passe, des boîtes de dialogue (au moins 50!) m'informent que tel .machin....kext n'est pas installé....
Sentant les emmerdements arriver, je redémarre........blocage sur la pomme avec la roue qui tourne indéfiniment...
J'essaie sans les extensions, rien...Je fais fsck -fy, ça répare des trucs, mais pas de démarrage...
Bon, je ne suis pas un novice, je démarre sur mon système de secours sur un DD externe.
Pas de problème, démarrage normal, sauf que je me retrouve avec l'icone de mon DD interne en haut, celle de mon DD externe (disque sur lequel j'ai démarré) en bas, le fond d'écran habituel alors qu'il aurait dû avoir changé...
Pourtant je suis certain que le démarrage s'est fait sur ce disque, la base de donnée de mon logiciel professionnel n'est pas à jour....
Tout se passe comme si mon Mac avait fait un "mix" des deux systèmes...
Avez-vous déjà vu ça?
Je précise que j'ai solutionné en réinstallant un nouveau système, mais je n'aime pas ne pas comprendre!
 
Salut!

Il était où ce document ? Si ca venait de Bibliothèque ou de Système, on est bien parti.

C'est un backup l'autre DD ou un vraiment de secours (système basique) ?

T'aurais pu vérifier sur lequel t'avais booté en essayant d'éjecter un des deux disques.


Enfin, ça tourne maintenant, c'est le principal.


Cordialement,

Xidi73
 
C'était juste une capture d'écran que j'avais laissée sur le bureau.
L'autre DD a une partition que je nomme "OS cour" (lol) qui ne comporte qu'un système tout neuf. Elle est censée me permettre de démarrer et de réparer.
Mais là je n'ai rien compris : je suis sûr que c'est sur ce DD que j'ai booté mais le DD interne était en haut à dte. du bureau.
Tout s'est passé comme si le Mac avait démarré en puisant des éléments dans l'un et l'autre disque, alors que je sais bien que c'est impossible....
Merci à toi Xidi73...oui, ça fonctionne, mais j'aurais aimé comprendre ce qui s'est passé, ça peut se reproduire...
Je ne réparerai plus jamais les autorisations!
 
Je ne réparerai plus jamais les autorisations!

oh noes!

Tu dois quand même réparer les autorisations. Ce serait comme dire "j'ai changé mon pneu, il a crevé = je ne dois plus jamais changer de pneus".

Tu es vraiment sûr de bien avoir booté sur le DD externe ? Avec la fenêtre de sélection au démarrage ?
 
Je veux mettre à la corbeille un document, une boîte de dialogue s'ouvre : "êtes-vous sûr...le document sera supprimé immédiatement...irréversible..." comme si ce doc était sur un autre volume...j'essaie avec un nouveau dossier vide que je crée sur le bureau pour essayer, même réponse...
Cela survient de façon aléatoire, moins souvent depuis 10.8 me semble-t-il.
C'est dû au changement de Propriétaire du dossier de la Corbeille de la session : System au lieu de Moi.
Cela se corrige simplement en détruisant le dossier ~/.Trash (puis en relançant la session pour en créer automatiquement un nouveau), ou en corrigeant ses autorisations.
Cela n'a habituellement aucun rapport avec une Réparation des autorisations.

Je fais Pomme I sur le DD, afin de vérifier si je suis tjrs en mode admin...je demande dans cette fenêtre à ce que tous mes droits soient attribués aux éléments inclus...
C'est connu pour mener régulièrement aux ennuis, ou à la cata
= on ne doit jamais modifier de cette façon les droits d'un dossier créé par le Système (Macintosh HD, dossier d'Utilisateur, …).

C'est ce qui me paraît avoir pu dérégler le redémarrage en mode Alt,
mais, là, je suis moins affirmatif.
 
Oui c'est ce que j'ai vu! Ça m'a mené effectivement à la cata!
Ce changement de propriété du dossier Corbeille s'est produit après avoir réparé les autorisations, puis le disque.
J'ai peut-être aussi commis une erreur de chronologie :
J'ai d'abord :
- vérifié les autorisations
- réparé les autorisations
- vérifié et réparé le disque de démarrage (qui au passage semblait OK)
c'est après que j'ai voulu poubelliser un fichier et que ce message m'est apparu.
Et enfin en me disant qu'un bon redémarrage allait solutionner, ça n'a rien solutionné du tout! Et le panneau "interdit de stationner" s'est affiché au-dessus de la pomme grise.

J'ai donc fini par démarrer une nouvelle installation de SL à partir du DVD d'origine.
Mon logiciel de travail (basé sur une BdD Mysql) a refusé de fonctionner car il avait perdu le chemin d'accès à la base...3h de téléintervention ont été nécessaires pour reconfigurer!!

À chaque fois que le tech redémarrait l'ordi, le même problème se reproduisait (panneau "interdit de stationner" malgré un système tout neuf et dûment mis à jour dans la foulée).
Je devais démarrer sans extensions, pour ensuite redémarrer normalement...

Finalement, une dernière sauvegarde bien conduite, et zou! Décision a été prise de changer le DD pour un SSD et réinstaller à partir de Time Machine... Le Mac est actuellement à l'atelier!

Il n'empêche que je n'ai pas vraiment d'explication de cet enchaînement désagréable!!

---------- Nouveau message ajouté à 12h40 ---------- Le message précédent a été envoyé à 12h37 ----------

ET surtout ce truc extrêmement bizarre de boot sur le DD externe, mais avec l'icône du DD interne en haut, et ce méli-mélo des deux systèmes...
 
J'ai peut-être aussi commis une erreur de chronologie :
J'ai d'abord :
- vérifié les autorisations
- réparé les autorisations
- vérifié et réparé le disque de démarrage (qui au passage semblait OK)
c'est après que j'ai voulu poubelliser un fichier et que ce message m'est apparu..
Il n'y a pas de chronologie à respecter spécialement : on fait ce qu'on veut.

Et les droits de la Corbeille de la session partent en vrille quand ils l'ont décidé : il n'y a pas d'élément déclencheur connu.


Tu as provoqué la cata en modifiant les droits sur la racine du Mac et en appliquant la modification à tous les éléments inclus.
Cata dont on ne se sort facilement qu'en reformatant le disque et en réinstallant une sauvegarde valide.


Tu n'as pas détaillé les modifications de droits que tu as appliquées aux éléments de ton disque,
mais il me semble évident que si System ne pouvait plus accéder aux éléments de lancement du fait de ces droits modifiés, ton disque ne pouvait être vu que comme non démarrable.



À ta place, je m'arrêterais à l'idée que j'ai eu peur d'une manœuvre bénigne (la réparation des autorisations) et perdu mon sang-froid devant un gag bénin (le vidage de la Corbeille en root),

mais que je n'ai pas craint de modifier n'importe comment les droits de mon Mac. :)
 
Je n'ai pas eu peur de ma "manœuvre bénigne", sauf à posteriori puisque c'est à sa suite que ça a commencé...
Sinon mon Mac fonctionnait très très bien avant, il s'est passé pendant... je dirais.....un an, de réparation d'autorisations, pour un usage quotidien, professionnel, de 12h par jour 5 jours sur sept plus 5h le 6ème jour....
Je n'ai pas modifié les droits, j'ai juste déverrouillé le cadenas, puis, sans rien modifier, puisque c'était correct, j'ai cliqué sur "modifier tous les éléments...".
Mon histoire semble en fait avoir été le révélateur d'une défaillance dans l'arborescence du disque, des secteurs endommagés et pourtant non répertoriés comme tels par l'Utilitaire de Disque, enfin je suppose...
Du coup mon Imac est revenu de l'atelier, un SSD tout neuf, un système réinstallé et les éléments repris de la dernière sauvegarde Time machine...à cette heure, tout fonctionne bien; on verra demain....
Merci de votre collaboration.
 
Salut seserge - et :coucou: François (qui s'est départi - une fois n'est pas coutume - de sa concision attique) :D

Sans m'être manifesté jusqu'ici, je suis ce fil avec intérêt depuis le début car le cas évoqué présente plusieurs anomalies remarquables.


  • Modification récursive des droits sur le volume ☞

    Je fais Pomme I sur le DD, afin de vérifier si je suis tjrs en mode admin...je demande dans cette fenêtre à ce que tous mes droits soient attribués aux éléments inclus...un long moment se passe, des boîtes de dialogue (au moins 50!) m'informent que tel .machin....kext n'est pas installé....
    Sentant les emmerdements arriver, je redémarre........blocage sur la pomme avec la roue qui tourne indéfiniment...
    et​
    Tu as provoqué la cata en modifiant les droits sur la racine du Mac et en appliquant la modification à tous les éléments inclus.
    Cata dont on ne se sort facilement qu'en reformatant le disque et en réinstallant une sauvegarde valide.

    et​

    Je n'ai pas modifié les droits, j'ai juste déverrouillé le cadenas, puis, sans rien modifier, puisque c'était correct, j'ai cliqué sur "modifier tous les éléments...".

    «Snow Léopard 10.6» (le 1er OS purement Intel), à la différence des versions postérieures d'OSXLion 10.7», «Mountain Lion 10.8» et «Mavericks 10.9», offre l'originalité remarquable suivante en ce qui concerne les droits sur les répertoires Système présents à la racine de l'OS : le groupe_propriétaire sur le répertoire de la Bibliothèque générale (/Library) n'y est pas wheel (le groupe dédié de root, le Super-Utilisateur_Système), mais admin.

    Mais cette "anomalie" historique ne s'étend pas plus loin et Système = root est toujours le seul et unique utilisateur_propriétaire (droit à valeur récursive) sur l'ensemble des répertoires_Système, y compris celui de la /Library, comme pour les OS suivants. Cette situation est notamment valable en ce qui concerne le Volume global de l'OS (qui délimite l'espace-racine), où les droits réguliers sont comme pour les OS suivants :

    Bloc de code:
    système (root) : lecture & écriture
    wheel (groupe_root) : lecture seulement
    everyone (other) : lecture seulement

    Que la commande ⌘I sur l'icône du Volume global de l'OS ait pu révéler (avec valeur de 'confirmation' ressentie) un état des droits où l'utilisateur_seserge se trouvait en position d'admin sur le Volume (= périmètre logique de l'espace-racine) - voilà à n'en pas douter une situation jugée normale mais règlementairement pas normale. Situation héritée (je le conjecture) d'une manipulation des droits antérieure sur le Volume et par suite de l'accoutumance, ultérieurement estimée comme normale.

    Laquelle? Pour que le démarrage de l'OS ait pu bloquer à la suite de l'extension des droits en question sur le Volume global, récursivement à la profondeur de l'arborescence de son contenu, le "seserge = admin" évoqué devait aller au-delà d'une susbtitution d'admin à wheel comme groupe_propriétaire sur le Volume global. Je me hasarde même à conjecturer (au point d'ignorance où j'en suis) plus qu'une simple ACL (droit supplémentaire) qui eût surajouté seserge à Système = root comme utilisateur co-propriétaire du Volume, car une extension récursive de cette ACL de Volume aux éléments inclus n'aurait en rien dépossédé root de son statut d'owner (utilisateur_propriétaire) sur l'arborescence système par le rajout d'une ACL d'user collatéral sur les éléments --> comme au démarrage (on boot), tous les fichiers-système (boot_Loader : boot.efi comme kernel : mach_kernel autant qu'extensions_système : apple_kexts ou programmes : binaires) doivent impérativement être lus & pris en charge en mode root, le greffon d'une ACL : co-user = seserge n'aurait pas invalidé (supputé-je) le boot.

    Reste à imaginer que seserge, grâce à une manipulation antérieure oubliée des droits sur le Volume global, ait destitué root en tant qu'owner (= utilisateur_propriétaire) du périmètre-racine --> on aurait eu la situation anormale mais jugée régulière :

    Bloc de code:
    seserge (Moi) : lecture & écriture
    wheel (groupe_root) : lecture seulement
    everyone (other) : lecture seulement

    Susbtitution d'owner cantonnée au plan du Volume global, sans affecter intrinsèquement l'arborescence incluse, càd. les droits des répertoires_système à partir du point de montage / où root aurait continué d'être l'owner seul, ce qui permettait le chargement des fichiers on boot.

    Si ma conjecture n'erre pas :D, la décision d'étendre récursivement la propriété de l'utilisateur seserge sur le Volume à l'arborescence incluse aurait, par contre, substitué seserge à root comme user sur toute la profondeur de l'arborescence à partir du point de montage / --> conséquence : impossibilité on boot à root = Système d'exécuter le chargement des fichiers dont il n'avait plus la propriété d'utilisateur. Car root ne peut pas en direct exécuter le chargement de fichiers dont il n'est pas l'owner --> plantage assuré du démarrage.​

    ♤

  • Démarrage sur OS clean d'un DDE affichant des paramètres de l'OS du disque interne non-démarré (fond d'écran du Bureau et icône du disque non-démarré en position princeps) ☞

    alors là je n'ai aucune idée. Je n'ai jamais personnellement expérimenté ni jamais entendu parler que le fichier démarreur boot.efi spécifique au filesystem d'un disque, exécutant le chargement du mach_kernel inhérent à ce même filesystem, non plus que le processus launchd terminal, aient jamais pu suivre d'autres rails que ceux du filesystem du volume monté d'obédience.

    La seule très vague analogie dont je me souvienne remonte aux années jurassiques d'Apple : lorsque, sur un Mac supportant Mac OS 9 installé, ou même Mac OS X (PPC) installé mais supportant le boot sur Mac OS 9 à partir d'un Dossier-Système copié, on insère un CD d'install de Mac OS 9 pour démarrer dessus, alors l'installateur affiche la fenêtre d'install du CD dans l'environnement complètement accessible de l'OS installé sur le disque interne : le fond d'écran, certes, reste celui du CD d'install, mais un Bureau est affiché arborant des alias pointant comme raccourcis aux répertoires-système de OSX (seules les applications OS 9 y étant lançables). Il semble bien dans ce cas, que le Boot_Loader : Mac OS ROM soit capable de charger et de déployer deux environnements hybridés : celui de l'installateur et celui de la racine de l'OSX non-démarré dont les fichiers sont néanmoins affichés du point de vue d'OS 9.

    Il aurait été intéressant de vérifier si les répertoires / applications du «Snow» du disque interne étaient accessibles.​

    ♧
 
Dernière édition par un modérateur:
Bonjour Macomaniac et merci de te pencher sur mon histoire... Te lire est toujours un (long) plaisir et un moment de prose informatique qui, nul doute, te trouverait une place à l'Académie Française si l'informatique y était représentée!
Après un (court) moment à décoder ton cheminement, il apparaît que :
- je n'ai jamais au grand jamais modifié quoi que ce soit au niveau des droits sur le système, étant bien trop ignorant en la matière.
- Lors du démarrage sur le Système du DDE, tout fonctionnait, j'avais accès à mes applis. Sauf que, comme je l'ai écrit plus haut, ma base de donnée MySql se révélait inaccessible.
Le navigateur internet n'avait plus mes favoris.
Durant le boot, c'était bien mon DDE qui "grattait" et pourtant son icône était située en dessous de celle du DDI...incompréhensible!
- Effectivement, le "mach_kernel"(?) du système sur le DDE s'est chargé, mais ensuite le reste du processus a repris une partie des éléments du système du DDI...
On va se permettre une analogie automobile : j'ai branché les câbles sur la batterie d'une autre voiture, ce qui a juste donné du jus pour lancer mon moteur...
Je pense plutôt à un problème "discal"...non?
Ce qui me rend "mauvais", c'est de ne pas comprendre ce qui a pu se passer!!:mad:
Merci en tous cas à FrançoisMacG et Macomaniac!
 
Je n'ai pas modifié les droits, j'ai juste déverrouillé le cadenas, puis, sans rien modifier, puisque c'était correct, j'ai cliqué sur "modifier tous les éléments..."..
La fenêtre des Informations d'un dossier te montre les autorisations du dossier,
et plus précisément de l'enveloppe du dossier,
mais absolument pas de son contenu : sous-dossiers et fichiers.

Quand tu cliques sur Appliquer à tous les éléments inclus, tu modifies les autorisations de nombre de ces sous-dossiers et fichiers (= ceux qui n'ont jamais eu et ne doivent jamais avoir les mêmes droits que le dossier-enveloppe).

Encore une fois, ce menu ne doit être utilisé que sur des dossiers créés par l'utilisateur.
 
Ce matin, démarrage du Mac, panneau "interdit de stationner" et paf! Les mêmes problèmes réapparaissent malgré changement de DD, nouveau système...
Démarrage possible sans extensions, puis démarrage normal ensuite... 500€ dépensés pour rien!
 
Tu parlais plus haut d'une réinstallation à partir d'une sauvegarde Time Machine : ça recopie les fichiers mais aussi les problèmes.

Si tu as réinstallé de zéro, tu peux chercher du côté hardware en faisant un Apple Hardware Test avec ton DVD d'origine n°2 et la touche D : un Mac ne contient pas qu'un disque. :hein:
 
Non, en fait la réinstallation s'est faite avec un système tout propre ; ce sont les données et les applis qui ont été réinstallées de Time Machine.
Le Hardware test n'a rien décelé.
Le tech vient de me changer les deux barrettes de RAM... Le Mac démarre normalement.... pour aujourd'hui...
 
pour aujourd'hui...
Rendez-vous dans quelques jours, alors !

(le reset de PRAM est une des solutions à l'interdiction de stationner, la RAM est la cause d'ennuis divers, et l'AHT n'est pas toujours très fiable sur les barrettes)