10.13 High Sierra Session Inaccessible

[deneb77]

OK je vais tenter le truc. J'ai bien lu ton tuto en début de fil, donc ça devrait bien se passer. Mais avant je vais quand même faire une sauvegarde time machine. Je ferai la manip après, je te tiens au courant. Merci pour l'aide !

 

[Membre supprimé 1060554]

En préalable --> tu dois absolument être dans une autre session admin que celle de Denis.

Tu passes une commande :

sudo rm -f /private/var/db/dslocal/nodes/Default/users/denis.plist

• si tu veux supprimer le fichier identitaire > ou une commande :

sudo mv /private/var/db/dslocal/nodes/Default/users/denis.plist ~/Desktop

• pour le déplacer sur le Bureau de la session ouverte (si tu veux inspecter son contenu ensuite)

Les 2 commandes ont le même effet : suppression d'existence de l'utilisateur Denis (le service opendirectoryd gérant les utilisateurs & groupes étant continuellement en prise de la moindre modification).

----------

Pour recréer l'identité Denis (par un fichier denis.plist) -->

- tu vas à : Préférences Système > Utilisateurs et groupes > déverrouille le cadenas en renseignant le mot-de-passe de session admin > presse le bouton + pour créer un utilisateur.

Dans le panneau de paramétrage -->

• Nouveau compte : Administrateur

• Nom Complet : Denis

• Nom de compte : strictement denis

• Mot-de-passe : le même qu'avant (pour ne pas désynchroniser le Trousseau de session calé sur l'ancien mot-de-passe pour son ouverture)

• Confirmation : idem

• Indice du mot-de-passe : ce que tu veux ou rien (facultatif)

=> Presse le bouton : Créer l'utilisateur

Une fenêtre d'avertissement va s'afficher -->

• Le dossier Utilisateurs contient déjà un dossier du même nom comme dossier de départ pour ce compte
  
  Le nom du compte reprendra celui du dossier de départ de ce nouveau compte utilisateur. Pour que le dossier serve de dossier de départ, cliquez sur « Utiliser le dossier existant ». Cliquez sur « Annuler » pour modifier le nom du compte.

=> Tu presses le bouton Utiliser le dossier existant (et surtout pas annuler)

Le Nom Complet d'utilisateur Denis apparaît dans la fenêtre de gauche du panneau des Utilisateurs et groupes avec Admin inscrit en-dessous.

----------

Tu peux alors par précaution passer encore la commande :

sudo chown -R denis:staff /Users/denis

• qui instaure denis en propriétaire récursif (de haut en bas) du dossier domicile denis (des Utilisateurs) + staff comme groupe principal. Ce qui règle tout problème d'autorisations a priori.

----------

Re-démarre le Mac une fois --> tu devrais voir affiché l'utilisateur Denis --> loge-toi dans sa session.

 

[deneb77]

OK je ferai ça ce soir au calme, après ma sauvegarde et je reviens ensuite te dire si ça a marché. Merci encore.

 

[deneb77]

Bon, j'ai fait strictement ce que tu as conseillé, mais rien de neuf: mon compte n'apparait toujours pas dans la fenêtre d'ouverture de session.
Curieux: quand je vais dans les préférences "utilisateurs et groupes" le compte "admin" que j'ai créé pour avoir un second compte administrateur n'apparait pas dans la colonne de gauche. Mais une fois que j'ai déverrouillé le cadenas, il apparait ! J'ai pu constater l'inverse: quand je suis sur le compte admin, c'est mon compte (denis) qui n'apparait pas de suite, mais seulement après déverrouillage. A mon avis ce doit être encore un problème d'autorisations. Tu saurais comment remettre d'aplomb les autorisations liées aux fichiers de l'ouverture de session ?

 

[deneb77]

Encore une bizarrerie: quand je suis sur mon compte principal (denis) et que je bascule sur la fenêtre d'ouverture de session par le menu de "permutation d'utilisateur" alors mon compte apparait (avec une icone qui n'est pas celle que j'avais choisie!) avec les autres, et avec une coche indiquant qu'il est en service. Idem pour le compte "admin" récemment créé. De même, après passage à l'économiseur d'écran, je retrouve bien mon compte (tout seul évidemment) avec l'invite de mot de passe pour réintégrer ma session. Il n'y a vraiment qu'à l'ouverture de session après un redémarrage que le compte n'apparaît pas !

 

[Membre supprimé 1060554]

Ce que tu décris me fait penser à un dysfonctionnement du Système et en aucun cas à un problème d'autorisations. Car il n'y a aucune autorisation à rectifier : tu as recréé un fichier identitaire denis.plist dans la base de données users de la manière la plus légitime qui soit. C'est la prise en charge de l'identité d'utilisateur qu'il définit par le service opendirectoryd qui foire > ou par le service LoginWindow en charge de l'écran de connexion.

Je te conseille de télécharger depuis l'AppStore un installateur de High Sierra (5,2 Go - ce sera la version 10.13.5) --> et d'appliquer l'installation au volume démarré. Le Logiciel-Système sera restauré / mis-à-jour > sans que les comptes ni les applications tierces ne soient touchés. Tu n'auras qu'à dire si ton problème d'écran de connexion a été réglé.

 

[deneb77]

OK, mais j'ai déjà fait ça avec command-R: reinstallation à partir du net. Rien de mieux...

Je vais voir ce que ça donne avec le combo 10.13.5... Si ça marche pas tant pis, la gêne est mineure, 5 lettres à rentrer en plus à chaque redémarrage, ça ne vaut pas une réinstall clean complète. C'est juste que j'aime bien trouver les solutions des énigmes... (pour ça j'ai eu pas mal d'entraînement avec mes hackintosh !). Merci en tous cas pour l'aide, j'aurais au moins appris comment on peut refaire un compte sans perdre ses données

 

[deneb77]

Rien de changé avec le combo 10.13.5... J'abandonne pour l'instant, je referai une clean install quand j'aurai le temps

 

[Membre supprimé 1060554]

Je ne parlais pas de la MÀJ combinée > mais d'un installateur complet de High Sierra. Mais je me demande à présent si ça changerait quelque chose.

D'après ce que tu dis > ce qui pourrais te sauver serait le procédé suivant : installation propre > avec à la fin récupération des données de ta TM via l'«Assistant de migration» (ce qui fait que seuls les comptes d'utilisateurs et les applications tierces seraient récupérés - pas le Système).

 

[r e m y]

Au passage, est-ce que la mise à jour 10.13.5 corrige une partie de ses bugs dans la gestion de l'open directory?

 

[deneb77]

Non, comme dit plus haut, pas de changement pour mon problème de compte absent de la fenêtre login session.

 

[deneb77]

Après plusieurs tentatives (suppression de compte, ajout de compte, etc.) je confirme qu'il ne s'agit que des comptes administrateurs qui disparaissent de la fenêtre d'ouverture de session. Les autres types de compte ne sont pas impactés par ce bug. Ce problème ne se produit que sur mon Macbook pro, pas sur le Hackintosh sous 10.13.4. (un comble !)
Une question: si je fais une réinstallation clean je suis obligé d'utiliser APFS ou bien je peux revenir à HFS+ ? (si installation à partir d' "Installer macOS Sierra" normalement on peut reformater avant d'installer il me semble, mais revenir à HFS+ ?)

 

[Membre supprimé 1060554]

• l'apfs aura un meilleur rendement sur ton SSD : je ne te conseille donc pas de chercher à installer High Sierra en format standard jhfs+.

• je ne pense pas de surcroît que le format apfs soit pour quelque chose dans le ratatouillage du Service d'Annuaire en ce qui te concerne.

• enfin : pour installer High Sierra sur un SSD dans un format jhfs+ --> il faut utiliser une commande appelant un utilitaire startosinstall recelé dans un sous-dossier de l'application d'installation. Cet utilitaire startosinstall est en somme un programme d'installation alternatif de l'InstallAssistant qui se lance par double-clic sur l'icône de l'application d'installation. Pour pouvoir lancer cette commande > il faut disposer de l'environnement d'un OS - soit externe au volume interne à installer en jhfs+ (la validation de cette commande adressée à un autre volume que le volume démarré > s'avérant aléatoire : chez moi elle marche toujours > chez d'autres elle plante toujours) ; soit interne au volume à réinstaller et dans ce cas-là dans un format qui ne soit pas déjà apfs, car ce format n'est pas réversible logiquement. Il faudrait donc commencer par réinstaller un OS antérieur genre Sierra 10.12 > et passer la commande d'installation de High Sierra en jhfs+ à destination du même volume démarré comme une mise-à-niveau.
  
  
  • remarque : un procédé alternatif consiste à installer d'abord High Sierra dans le volume d'un DDE USB --> ce qui forcera l'installation en jhfs+ > puis à rétro-cloner cet OS au volume interne du SSD --> ce qui donnera un clone en jhfs+ lui aussi.

Si tu fais le bilan des mes 3 observations --> tu admettras que tu vas au devant d'un grand nombre d'ennuis en voulant installer High Sierra en jhfs+ sur ton SSD.

 

[deneb77]

Si tu fais le bilan des mes 3 observations --> tu admettras que tu vas au devant d'un grand nombre d'ennuis en voulant installer High Sierra en jhfs+ sur ton SSD.

OK tu as raison. Mais je voudrais faire un reformatage car j'ai d'autres trucs bizarres (comme le directory "/var/vm" qui se présente comme une image disque, et qui permet de renommer le dossier vm -mais ça reste vm pour le système et le terminal- !). Le plus simple à mon avis est de faire une clef USB avec createinstallmedia. Je pense qu'il suffit de suivre les conseils d'Apple ? J'ai déjà fait une réinstall par command-R, mais ça ne permet pas de reformatage, et ça s'est avéré inopérant dans mon cas.

 

[Membre supprimé 1060554]

d'autres trucs bizarres (comme le directory "/var/vm" qui se présente comme une image disque, et qui permet de renommer le dossier vm -mais ça reste vm pour le système et le terminal- !

• c'est une innovation du système de fichiers apfs. Classiquement > la sleepimage (qui archive le contexte de la RAM) réside at: /private/var/vm/sleepimage. Avec le format apfs > un volume spécial du Conteneur (le volume VM = Virtual Memory) est dédié à cet archivage. Pour que le volume soit adressable commodément > après montage et démarrage du volume principal Macintosh HD > le volume VM est remonté dans le volume Macintosh HD au point de montage du dossier classique : /private/var/vm. Donc le dossier vm devient identique au volume VM remonté à cet espace.

 

[deneb77]

Super, quelle science ! Tu es développeur pour savoir tant de choses ? J'étais étonné car j'ai tenté de renommer le dosser vm, et ça a marché... mais maintenant je ne peux plus lui redonner le nom d'origine: vm tout court... Et comme ce dossier (ou volume ?) contient toujours un fichier sleep image d'un giga d'il y a trois jours, j'ai tenté de le supprimer en me loggant en root, impossible ! (pourtant il n'est pas utilisé, j'ai configuré pmset avec hibernatemode=0). Je croyais pourtant qu'en root, on avait tous les droits ! (sauf bien sur si le fichier est utilisé, mais avec hibernatemode=0 il ne devrait pas l'être ?)

 

[Membre supprimé 1060554]

Pour renommer le dossier d'origine = vm --> tu peux le faire à partir du Terminal de la session de secours (démarrage avec ⌘R > barre de menus supérieure > menu : Utilitaires > Terminal). Car avec ce démarrage > le volume VM n'est pas monté au point de montage du dossier (originellement intitulé) vm.

Si le dossier originel vm a été renommé brol (par exemple) et si le nom du volume de démarrage est Macintosh HD > tu passes une commande du type :

mv /Volumes/Mac*/var/brol /Volumes/Mac*/var/vm

----------

Ce qui doit te bloquer depuis ta session > c'est l'activation du SIP (System Integrity Protection) qui verrouille des dossiers-Système contre toute modification - même en root > par des flags invisibles dits "rootless" (sans root). Pour savoir si le SIP est activé > passe la commande :

csrutil status

• qui retourne le statut du SIP

Poste le retour.

----------

Note : dans le Terminal de la session de secours > tu es dans un shell root > et le SIP n'est pas activé sur le volume de démarrage (il ne s'active qu'au démarrage sur ce volume > par un mécanisme de transmission : EFI > flags du SIP en NVRAM > démarreur boot.efi > kernel > service launchd --> arrosage aux dossiers / fichiers cibles. Tu peux y voir comme un passage de relais multiples qui n'intervient qu'en cas de démarrage sur le volume).

 

[deneb77]

[QUOTE="macomaniac, post: 13292771, member: 1060554"
Si le dossier originel vm a été renommé brol (par exemple) et si le nom du volume de démarrage est Macintosh HD > tu passes une commande du type :

mv /Volumes/Mac*/var/brol /Volumes/Mac*/var/vm

Note : dans le Terminal de la session de secours > tu es dans un shell root > et le SIP n'est pas activé sur le volume de démarrage (il ne s'active qu'au démarrage sur ce volume > par un mécanisme de transmission : EFI > flags du SIP en NVRAM > démarreur boot.efi > kernel > service launchd --> arrosage aux dossiers / fichiers cibles. Tu peux y voir comme un passage de relais multiples qui n'intervient qu'en cas de démarrage sur le volume).[/QUOTE]
-------

1. en session de secours (command-R au démarrage) le SIP reste activé. Je crois qu'on peut le désactiver avec "csrutil disable" ou qq chose comme ça, de mémoire. Je ne l'ai pas fait.
2. du coup la commande

mv /Volumes/Mac*/var/brol /Volumes/Mac*/var/vm

me renvoie "no such file". Dans le doute, j'ai essayé en remplaçant "Mac*" par le nom de mon disque (MACBOOKPRO) mais même résultat: no such file.
Ceci dit, je viens de tenter la manip inverse (renommer vm en vmb) sur mon hackintosh sur lequel le SIP est désactivé, et le résultat est identique: no such file or directory. Essayé d'abord avec "Mac*" puis à la place, le nom de mon volume (disque) de démarrage.
PS je viens de voir que sur le hackintosh, il y a aussi un fichier sleepimage alors que j'ai "hibernatemode=0". Pas normal ??? (il semble que la mise en veille s'est vraiment complexifiée dans les dernières versions du système, alors que l'interface de les prefs système s'est à mon avis un peu trop simplifiée). Mais là, je peux le supprimer à partir de ma session normale sans même utiliser sudo: il va direct à la poubelle sans problème !

 

[deneb77]

Curieusement, dans ma session normale (administrateur) je peux éjecter l'image disque 'vml' (par un clic droit sur l'icone, alors que le dossier "var" est verrouillé), et alors je retrouve un dossier "vm" comme avant, et le fichier sleepimage a disparu. Je pense que c'est cohérent avec tes explications ci-dessus. Mais au redémarrage suivant, tout revient comme avant (image disque "vml" impossible à renommer en "vm" (mais on peut la renommer autrement !

 

[Membre supprimé 1060554]

Le SIP n'est jamais activé dans la session de secours > car les flags "rootless" ne "collent" pas en mode permanent aux objets du volume de démarrage (ce ne sont pas des attributs fixes) > mais seulement en mode provisoire : aussi longtemps que le volume est démarré (ce sont des attributs volatiles). Opérer depuis un autre Système à destination du volume de démarrage monté mais non démarré > c'est donc avoir affaire à un volume dépouillé des flags volatiles du SIP.

Un message : "no such file or directory" retourné dans la session de secours quand on emploie une commande rm ou mv --> ne signifie pas forcément que l'objet-cible n'a pas été trouvé > si l'on a utilisé une abréviation de saisie comportant un astérique *. D'après mon expérience > il s'agit d'un effet de "redondance" parasite dans la commande : l'opération est d'abord exécutée > puis une lecture a posteriori est effectuée à destination de l'objet > lequel forcément n'est plus trouvé puisqu'il a été soit supprimé > soit modifié dans son intitulé.

Comme je n'ai jamais eu sous les yeux la configuration logique de ton disque > je te conseille de passer (depuis ta session habituelle) la commande :

diskutil list

• qui affiche le tableau des disques

et de poster le tableau dans une fenêtre de code.

----------

Note : il est toujours préjudiciable d'intervenir sur l'organisation logique d'un Système (ne serait-ce que sur ses intitulés d'objets) > si l'on n'a pas une idée préalable claire & distincte de son fonctionnement. Modifier l'intitulé du dossier vm dans un volume de démarrage de type apfs > bloque le montage à cet emplacement du volume auxiliaire VM recelant la sleepimage.