DiskMaker X ne fonctionne pas

[mimilapatata]

Bonjour,

J'essaie de monter une clé de démarrage yosemite, mais j'ai une difficulté avec.

Diskmaker ne marche pas et pour le terminal voici ce qui s'affiche : je suis en mode désespoir, aidez moi!

sudo /Applications/Install\ OS\ X\ Yosemite.app/Contents/Resources/createinstallmedia --volume /Volumes/MacOSXYosemite --applicationpath /Applications/Install\ OS\ X\ Yosemite.app --nointeraction

sudo: unable to stat /etc/sudoers: Permission denied

sudo: no valid sudoers sources found, quitting

le modèle de la machine : macbook pro 13" mi-2012

merci

 

[Romuald]

Ce n'est pas diskmaker qui ne marche pas, c'est seulement que tu n'es pas autorisé à utiliser la commande sudo. Es-tu sur que ta session est une session administrateur ?

 

[mimilapatata]

Ce n'est pas diskmaker qui ne marche pas, c'est seulement que tu n'es pas autorisé à utiliser la commande sudo. Es-tu sur que ta session est une session administrateur ?

Oui, puisque j'ai meme entré mon mot de passe lorsque je lance diskmaker. A part la session invité je n'ai pas d'autre session dessus...:/

 

[Deleted member 1099514]

Salut @mimilapatata

Il faut donc créer une session administrateur :
Tu démarres en mode Recovery (cmd+r lors du boot) et là dans le Terminal, tu commences par taper la commande :

ls  /Volumes

Pour t'assurer que ta partition de boot s'appelle bien "Macintosh HD" sinon adapter la commande ci-dessous :

rm /Volumes/"Macintosh HD"/private/var/db/.AppleSetupDone

Cela va permettre de faire croire au système qu'il s'agit du premier lancement. Donc au démarrage, il va embrayer après qq questions sur la création de l'utilisateur.
Là créer un utilisateur Admin, lui affecter un mot de passe.
Puis repasser la commande du post#21 en te connectant sur cet utilisateur Admin.

@+

 

[Membre supprimé 1060554]

Bonjour mimilapatata.

Tu sembles avoir 2 problèmes, peut-être liés, peut-être disjoints : créer une clé USB d'install bootable via «DiskMaker X» de Guillaume Gète vs créer une clé USB d'install bootable via la commande dans le «Terminal» qui invoque le programme createinstallmedia.

- a) pour ce qui est du problème n°1 --> créer une clé USB d'install bootable via «DiskMaker X» : ton échec provient-il du fait que ton mot-de-passe d'utilisateur n'est pas accepté quand le logiciel te le demande? Ou parce que le logiciel plante, alors même que tu as renseigné ton mot-de-passe et qu'il a été honoré?

- a1) --> va à : Menu /Préférences Système/Utilisateurs et groupes : dans la colonne de gauche, sous l'intitulé de ton nom complet, est-ce qu'il y a bien mentionné : Admin? Si tu cliques le cadenas d'administration tout en bas à gauche, est-ce que le renseignement de ton mot-de-passe dans le panneau surgissant qui te le demande te permet de déverrouiller le cadenas? Si ce n'était pas le cas, c'est que (comme supposé par Romuald) tu n'aurais qu'une session en droits standard et pas admin --> suis alors les conseils de Jean dans le message qui précède le mien afin de créer un compte admin dans ton OS.

- a2) si tu es bien admin (preuve par le panneau des Préférences Système), alors si «DiskMaker X» plante, bien que ton mot-de-passe admin ait été honoré, c'est parce que ce logiciel est complètement à la ramasse pour gérer les installateurs de «Mavericks 10.9» et a fortiori avec «Yosemite 10.10». Personnellement, en tant qu'utilisateur admin dûment reconnu par le Système, je n'arrête pas d'avoir des erreurs, soit initiales, soit terminales, avec ce logiciel --> j'en ai donc abandonné l'usage pour créer une clé USB d'install bootable et j'utilise exclusivement désormais la commande dans le «Terminal».
​

- b) pour ce qui est du problème n°2 --> créer une clé USB d'install bootable via la commande dans le «Terminal», il est requis de préfacer cette commande par l'invocation de sudo afin de faire courir le programme invoqué recelé dans l'installateur lui-même : le createinstallmedia en droits root. Ce qui soit fait écho à la problématique précédente, soit met à jour une problématique nouvelle.

- b1) écho de la problématique précédente : si en tant qu'utilisateur tu n'étais pas dans le groupe admin, alors bien évidemment tu ne pourrais pas faire courir une commande de type sudo dans le «Terminal», car pour ce faire il faut que le Système, au renseignement du mot-de-passe d'utilisateur, identifie ce dernier comme membre du groupe admin habilité par défaut à passer des commandes sudo --> quand ce n'est pas le cas (utilisateur membre simple du groupe staff), alors la demande est rejetée. Cette problématique, écho de la précédente, te renverrait donc à la méthode décrite par Jean afin de récupérer un compte à privilèges admin dans l'OS.

- b2) mais il peut survenir un cas relevant d'une toute autre problématique (bien plus passionnante, mais aussi beaucoup plus abstruse). Lorsque un utilisateur non admin en effet tente de passer une commande sudo, le Système accompagne son rejet d'une courte notitification du style : toto user is not in the sudoers file ou plus spécifique : toto user is not empowered to run a command such as etc. Ce qui m'amène à ce court aperçu (que je me garde de développer, afin de ne pas piétiner une plate-bande réservée de droit à Maître bompi qui en est expert) --> lorsqu'un utilisateur, fût-il admin, requiert de passer une commande sudo dans le «Terminal», la vérification du caractère correct de son mot-de-passe n'est qu'une facette du protocole ; le protocole majeur porte sur le nom de l'utilisateur et consiste à vérifier s'il relève bien du groupe admin habilitant ses membres à passer des commandes sudo mais aussi si des paramètres restrictifs ou extensifs d'usage de la commande sudo ne sont pas spécialement appendus, soit à ce groupe lui-même dans l'OS relativement à telles sortes d'invocations (de domaines ou de commandes), soit à cet utilisateur proprement dit, qui pourrait se trouver spécialement privilégié (par rapport au vulgum pecus des admins) ou inversement restreint dans le champ opératoire des commandes sudo qu'il peut passer.

Pour opérer cette vérification, le Système consulte un fichier ultra sensible : le fichier /private/etc/sudoers qui peut supporter, par-delà le paramétrage basique par défaut, des paramétrages d'une admirable sophistication mais qui doivent obéir à des contraintes syntaxiques pointilleuses. C'est là, par exemple, dans le paramétrage disons basique (brut d'install), que se trouve notamment mentionné ce qui relève des user priviledge specifications (qui est autorisé à faire quoi en ce qui concerne une commande sudo) :

# User privilege specification
root    ALL=(ALL) ALL
%admin    ALL=(ALL) ALL

Ce paramétrage "basique brut d'install" est le default et s'impose tant que des paramétrages plus pointus n'y apportent pas de modulations --> pour ce qui nous intéresse exclusivement dans ce fil, on note ici que par défaut le groupe admin est habilité à passer des commandes sudo sans restrictions de domaines d'application ni de commandes --> il suffira alors, que quand un utilisateur requiert de passer une commande sudo dans le «Terminal», le Système qui va browser les paramétrages du fichier sudoers lise que le groupe admin possède les privilèges ALL=(ALL) ALL et il suffira que l'utilisateur soit bien identifié comme membre de ce groupe et ait renseigné un mot-de-passe correct pour qu'il soit habilité à passer la commande sudo requise.

Mais si jamais, pour une raison = x, l'utilisateur se trouve nommément restreint en matière de commandes sudo dans le sudoers_file, ou si cela concerne le groupe admin dont il relève, ou encore si des erreurs de syntaxe sont intervenues dans la rédaction des préférences de ce fichier excessivement pointilleux, ou encore si le fichier venait carrément à avoir été supprimé du répertoire /private/etc --> alors une situation de blocage drastique se ferait jour qu'il est toujours malaisé de redresser.
​

☞ quand je lis les messages d'erreurs :

sudo: unable to stat /etc/sudoers: Permission denied
sudo: no valid sudoers sources found, quitting

qui portent spécifiquement sur le sudoers_file dont j'ai survolé précédemment les caractéristiques --> je me dis qu'il y a un "blème" à ce niveau. Le 2è message : no valid sudoers sources found, quitting pourrait évoquer une absence du fichier sudoers, mais je ne le pense pas dans le contexte, car il est spécifié : no valid sudoers sources, et pas no sudoers sources tout court ; et parce que l'erreur du 2è message paraît provenir de l'échec du browsing du statut de droits du fichier signalé par la 1ère : unable to stat /etc/sudoers: Permission denied --> il semble que le browsing du statut de droits du sudoers_file s'opère via la commande stat, et que l'échec de cette commande proviennent d'un Permission denied --> déni de permission. Suite à cet échec du browsing, la lecture du contenu du fichier par root serait bloquée.

La question est alors : pourquoi? Pourquoi le Système (l'utilisateur root ici) se heurterait-il à un Permission denied lors de son opération de browsing automatique du sudoers_file par la commande stat avant de pouvoir lire les paramétrages de ce fichier et d'établir si l'utilisateur a ou non (et dans quelles limites) le droit de passer telle commande sudo?

Le problème me semble excessivement insolite et énigmatique. Voici ce que tu pourrais faire, mimilapatata, pour éclairer les lanternes --> afin de contourner ton absence de capacité sudo, démarre par ⌘R sur ta «Recovery HD», va à la barre supérieure de menus de l'écran, menu Utilitaires et lance le «Terminal» --> dans sa fenêtre, commence par saisir :

ls /Volumes

et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande - attention : le l de ls est la minuscule de la lettre L, pas le chiffre 1) --> tu vois s'afficher la liste des volumes montés actuellement, dont celui de ton OS sous son exact intitulé ; par défaut c'est Macintosh HD mais tu as pu le customiser.

Passe à présent la commande :

ls /Volumes/"Macintosh HD"/Users

et ↩︎ [tu substitues bien sûr à mon Macintosh HD le nom réel du volume de ton OS s'il était différent. La mise entre "" de l'intitulé est requise s'il y a un espace vide central, afin de solidariser les termes en une seule désignation d'objet] --> tu obtiens la liste des utilisateurs de ton OS, dont ton nom court d'utilisateur exact.

Passe enfin la commande (attention aux espaces !) :

cp /Volumes/"Macintosh HD"/private/etc/sudoers /Volumes/"Macintosh HD"/Users/ton_nom_d'utilisateur/Desktop

et ↩︎ [étant en droits root automatiques en -bash-3.2#, tu es habilité à passer la commande de recopie du fichier sudoers sur ton Bureau de session] --> si tu veilles à adapter correctement le nom du volume de l'OS et à bien remplacer mon ton_nom_d'utilisateur à sa place par ton véritable nom court affiché par la commande précédente, alors une copie du fichier sudoers manipulable va t'attendre sur ton Bureau. Le fichier original /private/etc/sudoers est intact. Quitte le «Terminal», re-démarre et reloge-toi dans ta session --> ouvre d'un double-clic dans «TextEdit» par défaut le fichier sudoers présent sur ton Bureau --> est-que tu peux sélectionner son contenu et par copier-coller le poster ici pour vérification du paramétrage?

Par ailleurs, dans ta session de l'OS, lance le «Terminal» et passe la commande qui ne requiert pas de droits spéciaux :

 ls -la /private/etc/sudoers

--> est-ce que tu peux poster aussi la ligne de retour d'information? Normalement, il doit y avoir :

-r--r-----   root  wheel

--> droit de lecture seule pour root et le groupe-Système wheel. En irait-il différemment? Une absence de permission de lecture pour root pourrait-elle expliquer l'échec du browsing des droits du fichier par la commande stat? [pfuiiii!]

☞ si tu étais bien aussi admin sans avoir eu besoin de recourir à la tactique de Jean, si le paramétrage intrinsèque de sudoers était correct, si enfin root avait bien un dorit de lecture sur le fichier --> ça sentirait la ré-installation de l'OS...​

 

[Deleted member 1099514]

@mimilapatata

En complément du spitch de @macomaniac
Tu peux tenter CECI :
Dans un terminal :

dsenableroot

puis répondre aux questions et donner un mot de passe à root.
puis :

su

là entrer le mot de passe root
puis :

chmod go+rx-w /
exit

et retenter un :

sudo  ls -l /

par exemple voir si ça passe.

@+