10.11 El Capitan Disque usb3 Seagate plante mon iMac

brunowajskop

Membre actif
2 Juillet 2008
130
0
Hello. J'ai plusieurs disques SEAGATE USB3 branchés sur mon iMac. Après une copie d'un gros fichier sur l'un d'eux, le disque externe enquestion plante le Mac (roue multicolore). Au démarrage, idem : roue multicolore. Le disque apparaît sur le bureau mais pas moyen de l'ouvrir. Si je le débranche, je reçois la traditionnelle alerte indiquant qu'il a été improprement éjecté. Utilitaire de disque tourne en continu sans le reconnaître. J'ai essayé de brancher le disque sur un autre Mac (Macbook Pro): même topo. Il apparaît sur le bureau, je peux faire un CMD-I qui me confirme qu'il reste de la place libre dessus mais pas moyen de l'ouvrir, roue multicolore et utilitaire de disque plante. Comment récupérer le contenu de ce disque ? J'imagine qu'un fichier a corrompu le disque. Comment faire pour l'isoler, le brancher d'une manière ou d'une autre et récupérer les fichiers ? Heeeelp !
 
Salut Bruno

Le volume de ton DDE a l'air de monter, mais ne se laisse pas ouvrir ni manipuler en mode graphique.

Ta session de l'iMac ouverte sans que tu aies connecté le DDE problématique > est-ce que tu peux : détacher tous tes périphériques > attacher ce seul DDE sans opérer sur lui aucune manipulation graphique afin de ne rien planter ?

Cela fait, va à : Applications > Utilitaires et lance le «Terminal». Dans la fenêtre qui s'affiche, je te propose de saisir 2 commandes purement informatives (agissent en lecture seule - espérons qu'elles ne plantent pas) -->

- saisis d'abord la commande :
Bloc de code:
diskutil list
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> si le processus diskutil ne plante pas > tu devrais voir affiché le tableau des disques actuellement attachés à ton Mac (en interne / externe) avec les paramètres de [format > nom > taille > device] de leurs partitions => peux-tu en faire un copier-coller ici (pas de photo) ?


- Saisis ensuite la commande :
Bloc de code:
df -H
et ↩︎ --> cette commande appelle l'utilitaire display_free_space pour lui demander d'afficher la taille en GB des volumes montés et le % d'espace occupé vs libre dans chacun => pareil : si la commande ne plante pas > peux-tu faire un copier-coller du tableau retourné ?​

=> ces informations pourraient permettre de poursuivre par des commandes opératoires...
 
Salut Bruno

Le volume de ton DDE a l'air de monter, mais ne se laisse pas ouvrir ni manipuler en mode graphique.

Ta session de l'iMac ouverte sans que tu aies connecté le DDE problématique > est-ce que tu peux : détacher tous tes périphériques > attacher ce seul DDE sans opérer sur lui aucune manipulation graphique afin de ne rien planter ?

Cela fait, va à : Applications > Utilitaires et lance le «Terminal». Dans la fenêtre qui s'affiche, je te propose de saisir 2 commandes purement informatives (agissent en lecture seule - espérons qu'elles ne plantent pas) -->

- saisis d'abord la commande :
Bloc de code:
diskutil list
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> si le processus diskutil ne plante pas > tu devrais voir affiché le tableau des disques actuellement attachés à ton Mac (en interne / externe) avec les paramètres de [format > nom > taille > device] de leurs partitions => peux-tu en faire un copier-coller ici (pas de photo) ?

VOICI LA PREMIERE PARTIE DEMANDÉE :

Last login: Wed Jul 13 22:35:35 on console
iMacBruno:~ brunow$ diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *121.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage Macintosh HD 121.0 GB disk0s2
3: Apple_Boot Boot OS X 134.2 MB disk0s3
/dev/disk1 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_CoreStorage Macintosh HD 999.3 GB disk1s2
3: Apple_Boot Recovery HD 650.1 MB disk1s3
/dev/disk2 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Macintosh HD +1.1 TB disk2
Logical Volume on disk0s2, disk1s2
F4228A3E-BEAA-49F8-811B-CD666BD77B29
Unencrypted Fusion Drive
/dev/disk3 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *2.0 TB disk3
1: EFI EFI 209.7 MB disk3s1
2: Apple_HFS ARCHIVE BACKUP 2.0 TB disk3s2
iMacBruno:~ brunow$

- Saisis ensuite la commande :
Bloc de code:
df -H
et ↩︎ --> cette commande appelle l'utilitaire display_free_space pour lui demander d'afficher la taille en GB des volumes montés et le % d'espace occupé vs libre dans chacun => pareil : si la commande ne plante pas > peux-tu faire un copier-coller du tableau retourné ?

et voilà la suite :

iMacBruno:~ brunow$ df -H
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/disk2 1.1T 619G 492G 56% 151222340 120219642 56% /
devfs 193k 193k 0B 100% 652 0 100% /dev
map -hosts 0B 0B 0B 100% 0 0 100% /net
map auto_home 0B 0B 0B 100% 0 0 100% /home
/dev/disk3s2 2.0T 1.6T 355G 83% 401717008 86577658 82% /Volumes/ARCHIVE BACKUP​

=> ces informations pourraient permettre de poursuivre par des commandes opératoires...



Après apararition de la fenêtre du disque sur le Finder, retour de la roue multicolore…
 
Dernière édition:
Merci déjà macomaniac. Je suis chaque fois stupéfait par la gentillesse que l'on rencontre sur ces forums techniques, alors que dans la rue les gens ne se disent pas bonjour… Le disque concerné est bien ARCHIVE BACKUP. Depuis l'exécution de ces commandes terminal, on peut parler d'une sorte de progrès : la roule multicolore ne tourne plus. Le disque apparaît bien sur le bureau mais lorsqu'on double clique pour l'ouvrir, la fenêtre du disque apparaît, mais vide, et la roue crantée tourne fou (ou folle, s'agissant d'une roue ?)
 
Suite des événements : la fenêtre apparaît enfin avec tous les dossiers mais l'ouverture de ceux-ci est super lente. Le disque semble avoir besoin de réparations, mais comment les effectuer avec le nouvel utilitaire de disque ? J'ai Onyx et Clean my Mac3 installés.
 

Suite des événements : la fenêtre apparaît enfin avec tous les dossiers mais l'ouverture de ceux-ci est super lente, voire statique. Le disque semble avoir besoin de réparations, mais comment les effectuer avec le nouvel utilitaire de disque ? J'ai Onyx et Clean my Mac3 installés.
 
Je vois que tu as un Fusion Drive dans ton iMac qui solidarise un SSD de 121 Go (disk0) et un HDD de 1 To (disk1) pour exporter un Volume Logique unique de 1,1 To (disk2).

En ce qui concerne ton DDE : table de partition GUID pour le disque (disk3) + format JHFS+ pour la partition ARCHIVE BACKUP (disk3s2). Volume rempli à 83% : 1,7 To de données pour 2 To de volume > dans la perspective d'une recopie : pfuiii ! ça fait un paquet de fichiers...

Ton DDE toujours seul attaché en périphérique > vérifie quand même d'abord par un :
Bloc de code:
diskutil list
que ARCHIVE BACKUP est toujours identifié comme disk3s2 en tant que device (support) > si oui (pas forcé, si tu as entre temps reconnecté des DDE avant celui-là), passe la commande (copier-coller - sinon adapte l'identifiant de device) :
Bloc de code:
diskutil repairVolume /dev/rdisk3s2
> tu vas bien voir le retour que tu obtiens : volume non trouvé (ce qui voudrait dire que le disque a été automatiquement éjecté) ? impossibilité de démonter le volume ? ou vérification du système de fichiers (chargé de monter en volume l'espace de la partition) > erreurs trouvées > échec des réparations ? ou réussite des réparations ?

=> si tu as bien un affichage déroulant de l'opération de vérification / réparation > peux-tu en faire un copier-coller encore ici ? Tu peux utiliser directement des balises de code : bouton > sous-menu </> Code pour encadrer ton texte.
 
Je vois que tu as un Fusion Drive dans ton iMac qui solidarise un SSD de 121 Go (disk0) et un HDD de 1 To (disk1) pour exporter un Volume Logique unique de 1,1 To (disk2).

En ce qui concerne ton DDE : table de partition GUID pour le disque (disk3) + format JHFS+ pour la partition ARCHIVE BACKUP (disk3s2). Volume rempli à 83% : 1,7 To de données pour 2 To de volume > dans la perspective d'une recopie : pfuiii ! ça fait un paquet de fichiers...

Ton DDE toujours seul attaché en périphérique > vérifie quand même d'abord par un :
Bloc de code:
diskutil list
que ARCHIVE BACKUP est toujours identifié comme disk3s2 en tant que device (support) > si oui (pas forcé, si tu as entre temps reconnecté des DDE avant celui-là), passe la commande (copier-coller - sinon adapte l'identifiant de device) :
Bloc de code:
diskutil repairVolume /dev/rdisk3s2
> tu vas bien voir le retour que tu obtiens : volume non trouvé (ce qui voudrait dire que le disque a été automatiquement éjecté) ? impossibilité de démonter le volume ? ou vérification du système de fichiers (chargé de monter en volume l'espace de la partition) > erreurs trouvées > échec des réparations ? ou réussite des réparations ?

=> si tu as bien un affichage déroulant de l'opération de vérification / réparation > peux-tu en faire un copier-coller encore ici ? Tu peux utiliser directement des balises de code : bouton > sous-menu </> Code pour encadrer ton texte.

En rebranchant le disque, j'ai eu un message du finder "OX N'A PAS PU RÉPARER LE DISQUE ARCHIVE BACKUP. Faites en une copie et reformattez le"
Ensuite, j'ai entré la commande terminal mais il ne se passe rien
 
Je vais m'acheter un disque externe fissa. Peux-tu m'indiquer par quelle commande terminal je peux copier l'intégralité de ce disque sur un disque externe ?
 
Il te faut un DDE de 2 To aussi. Dont tu effaces le disque global pour lui imprimer une table de partition GUID > et exporter un volume de 2 To au format JHFS+ - que j'appellerai pour l'exemple RECUP). Ce qui te permettrait d'envisager de faire une recopie des 1,7 Go de données de ARCHIVE BACKUP dans RECUP.

C'est là que les choses se compliquent : il existe 2 grands types d'utilitaires de recopie > des cloneurs de fichiers et des cloneurs de clusters (blocs) - je parle des utilitaires UNIX, appelables en ligne de commande, fournis nativement dans le répertoires de l'OS genre /bin ou /sbin.

- cloneurs de fichiers : ils sont entièrement sous la dépendance du système de fichiers qui gère la montée en volume de l'espace de la partition considérée. Un système de fichiers (comme le jhfs+) est un une série de fichiers inscrits sur les blocs d'en-tête d'une partition qui gèrent l'espace des blocs de cette partition en mode : "conversion en répertoire de fichiers" : ils permettent donc le montage de l'espace des blocs sous forme de volume > et ils gèrent les écritures supportées par les blocs de la partition sous forme de fichiers > avec tout ce qu'il faut pour qu'ils soient manipulables : adresses des fichiers etc.

Si le système de fichiers est plombé > cela veut dire que le montage de l'espace des blocs de la partition en volume est compromis > ou encore que le déploiement des écritures des blocs sous forme de fichiers adressables est compromis. Ce qui m'a bien l'air d'être le cas, avec ta partition ARCHIVE BACKUP. Dans ce cas de figure, un utilitaire de recopie de fichiers ne va pas trouver une "source" valide (parce que le système de fichiers ne la lui fournit pas) > il va te ressortir input / ouput error sur input / ouput error = erreur en entrée=lecture > erreur en sortie=écriture.

- cloneurs de clusters : ils sont plus ou moins indifférents à l'état dans lequel se trouve le système de fichiers gérant l'espace d'une partition > leur domaine de compétence, ce ne sont pas les fichiers affichés avec le montage en volume > ce sont les blocs (de 512 octets chacun) de la partition sur lesquels sont inscrites des écritures. Il y a un qui est, disons, assez susceptible à l'état du système de fichiers ; et un autre totalement indifférent au système de fichiers, capable de cloner bloc par bloc l'espace brut d'une partition. Avec l'inconvénient d'une prodigieuse lenteur...​

Donc, une fois que tu auras acheté > apprêté logiquement (GUID > JHFS+) ton DDE > attache-le à ton Mac en compagnie du DDE à problèmes (si tu veux que le DDE ARCHIVE BACKUP garde les identifiants primitifs de devices - pour la clarté - une fois ta session ouverte, attache-le en premier, et seulement le nouveau DDE en second > ainsi le DDE à problème sera toujours disk3 et le nouveau DDE sera disk4) => repasse alors un :
Bloc de code:
diskutil list
dans le «Terminal» > car toutes les opérations de recopie possibles impliquent de connaître exactement soit les identifiants de devices, soit les intitulés exact de volumes > tu n'auras qu'à faire un copier-coller encore du tableau ici (inutile de me re-citer > colle directo).

[Ne crois pas que les choses vont se dérouler comme à la parade. Ta partition ARCHIVE BACKUP a l'air salement plombée. Tu vas bien voir ce que donnent successivement plusieurs types de commandes...]
 
Il te faut un DDE de 2 To aussi. Dont tu effaces le disque global pour lui imprimer une table de partition GUID > et exporter un volume de 2 To au format JHFS+ - que j'appellerai pour l'exemple RECUP). Ce qui te permettrait d'envisager de faire une recopie des 1,7 Go de données de ARCHIVE BACKUP dans RECUP.

C'est là que les choses se compliquent : il existe 2 grands types d'utilitaires de recopie > des cloneurs de fichiers et des cloneurs de clusters (blocs) - je parle des utilitaires UNIX, appelables en ligne de commande, fournis nativement dans le répertoires de l'OS genre /bin ou /sbin.

- cloneurs de fichiers : ils sont entièrement sous la dépendance du système de fichiers qui gère la montée en volume de l'espace de la partition considérée. Un système de fichiers (comme le jhfs+) est un une série de fichiers inscrits sur les blocs d'en-tête d'une partition qui gèrent l'espace des blocs de cette partition en mode : "conversion en répertoire de fichiers" : ils permettent donc le montage de l'espace des blocs sous forme de volume > et ils gèrent les écritures supportées par les blocs de la partition sous forme de fichiers > avec tout ce qu'il faut pour qu'ils soient manipulables : adresses des fichiers etc.

Si le système de fichiers est plombé > cela veut dire que le montage de l'espace des blocs de la partition en volume est compromis > ou encore que le déploiement des écritures des blocs sous forme de fichiers adressables est compromis. Ce qui m'a bien l'air d'être le cas, avec ta partition ARCHIVE BACKUP. Dans ce cas de figure, un utilitaire de recopie de fichiers ne va pas trouver une "source" valide (parce que le système de fichiers ne la lui fournit pas) > il va te ressortir input / ouput error sur input / ouput error = erreur en entrée=lecture > erreur en sortie=écriture.

- cloneurs de clusters : ils sont plus ou moins indifférents à l'état dans lequel se trouve le système de fichiers gérant l'espace d'une partition > leur domaine de compétence, ce ne sont pas les fichiers affichés avec le montage en volume > ce sont les blocs (de 512 octets chacun) de la partition sur lesquels sont inscrites des écritures. Il y a un qui est, disons, assez susceptible à l'état du système de fichiers ; et un autre totalement indifférent au système de fichiers, capable de cloner bloc par bloc l'espace brut d'une partition. Avec l'inconvénient d'une prodigieuse lenteur...​

Donc, une fois que tu auras acheté > apprêté logiquement (GUID > JHFS+) ton DDE > attache-le à ton Mac en compagnie du DDE à problèmes (si tu veux que le DDE ARCHIVE BACKUP garde les identifiants primitifs de devices - pour la clarté - une fois ta session ouverte, attache-le en premier, et seulement le nouveau DDE en second > ainsi le DDE à problème sera toujours disk3 et le nouveau DDE sera disk4) => repasse alors un :
Bloc de code:
diskutil list
dans le «Terminal» > car toutes les opérations de recopie possibles impliquent de connaître exactement soit les identifiants de devices, soit les intitulés exact de volumes > tu n'auras qu'à faire un copier-coller encore du tableau ici (inutile de me re-citer > colle directo).

[Ne crois pas que les choses vont se dérouler comme à la parade. Ta partition ARCHIVE BACKUP a l'air salement plombée. Tu vas bien voir ce que donnent successivement plusieurs types de commandes...]

Voici ce qu'a fini par me donner la première commande Terminal :
Started file system repair on disk3s2 ARCHIVE BACKUP
Repairing file system
Checking Journaled HFS Plus volume
The volume could not be verified completely
File system check exit code is 8
Error: -69845: File system verify or repair failed
Underlying error: 8: POSIX reports: Exec format error
 
Voici ce qu'a fini par me donner la première commande Terminal :
Started file system repair on disk3s2 ARCHIVE BACKUP
Repairing file system
Checking Journaled HFS Plus volume
The volume could not be verified completely
File system check exit code is 8
Error: -69845: File system verify or repair failed
Underlying error: 8: POSIX reports: Exec format error


Voilà j'ai acheté un disque externe 3TO, QUEJ'AI FORMATÉ EN journalisé étendu avec partition GUID.
Je le branche après le disque à problème de sorte qu'il sera identifié comme disk4.
Quelle est maintenant la commande Terminal pour copier disk3 vers disk4 ?
 
File system verify or repair failed
Bon : on se doutait qu'il y avait un problème avec le système de fichiers de la partition ARCHIVE BACKUP. L'ennui, d'après ce compte-rendu succinct, c'est qu'il semble y avoir un échec d'entrée de l'utilitaire en charge (diskutil appelle fsck_hfs ici) pour lire les fichiers gestionnaires.

Donc retour aux tentatives de recopie ARCHIVE BACKUP > RECUP. Poste le tableau du diskutil list quand tu auras ton nouveau DDE, apprêté logiquement, et attaché au Mac avec le DDE à problèmes.

[Note : il arrive qu'il y ait des "rémissions" dans ce genre d'ennuis. Quelqu'un de patient, qui répète jour après les jours les tentatives de montage et/ou de recopie > voit parfois le volume du DDE monter correctement d'un seul coup > ce qui permet un clonage des fichiers assez rapide. À voir...]
 
Bon : on se doutait qu'il y avait un problème avec le système de fichiers de la partition ARCHIVE BACKUP. L'ennui, d'après ce compte-rendu succinct, c'est qu'il semble y avoir un échec d'entrée de l'utilitaire en charge (diskutil appelle fsck_hfs ici) pour lire les fichiers gestionnaires.

Donc retour aux tentatives de recopie ARCHIVE BACKUP > RECUP. Poste le tableau du diskutil list quand tu auras ton nouveau DDE, apprêté logiquement, et attaché au Mac avec le DDE à problèmes.

[Note : il arrive qu'il y ait des "rémissions" dans ce genre d'ennuis. Quelqu'un de patient, qui répète jour après les jours les tentatives de montage et/ou de recopie > voit parfois le volume du DDE monter correctement d'un seul coup > ce qui permet un clonage des fichiers assez rapide. À voir...]
Voilà. Je suis en train de tenter une copie avec Carbon Copy Cloner

/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage Macintosh HD 999.3 GB disk0s2
3: Apple_Boot Recovery HD 650.1 MB disk0s3
/dev/disk1 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *121.3 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_CoreStorage Macintosh HD 121.0 GB disk1s2
3: Apple_Boot Boot OS X 134.2 MB disk1s3
/dev/disk2 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Macintosh HD +1.1 TB disk2
Logical Volume on disk1s2, disk0s2
F4228A3E-BEAA-49F8-811B-CD666BD77B29
Unencrypted Fusion Drive
/dev/disk3 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *2.0 TB disk3
1: EFI EFI 209.7 MB disk3s1
2: Apple_HFS ARCHIVE BACKUP 2.0 TB disk3s2
/dev/disk4 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *3.0 TB disk4
1: EFI EFI 209.7 MB disk4s1
2: Apple_HFS TERA 3 3.0 TB disk4s2
 
et évidemment ça ne marche pas avec ccc. j'ai quitté, mais au bout d'un temps, le finder bloque et je me retrouve avec la roue colorée (après avoir double cliqué sur l'icone du disque à problème pour l'ouvrir)
 
Dernière édition:
Même Disk Warrior plante : disk hardware failure. Pourtant je vois ce fichu disque sur le bureau et la "panne" a été soudaine. Il doit quand même bien y avoir moyen de récupérer des fichiers, non ?
 
J'ai redémarré. Le disque apparaît et le Finder répond (tant que je ne cherche pas à ouvrir le disque). Existe-il un moyen vie la terminal pour copier les fichiers au moins dossier par dossier ? Mais pour cela je devrais connaître la commande qui liste les dossiers du disque.
 
«Carbon Copy Cloner» est un duplicateur de fichiers : comme j'ai tenté de l'expliquer précédemment, il dépend entièrement pour son opération du système de fichiers qui gère le montage de l'espace d'une partition sous forme de volume et l'affichage des écritures des blocs sous forme de fichiers adressables et manipulables. Qu'il plante corrobore l'idée que le système de fichiers de la partition ARCHIVE BACKUP est plombé.
--------------------​

Je te propose une tentative de clonage par un utilitaire qui procède en mode bloc à bloc : asr (apple_software_restore). Tes 2 volumes montés : celui de la "source" = ARCHIVE BACKUP et celui de la "destination" = TERA 3 > ouvre une fenêtre du «Terminal» et fais un copier-coller de la commande :
Bloc de code:
sudo asr restore -s /Volumes/ARCHIVE\ BACKUP -t /Volumes/TERA\ 3 --erase --noprompt
et ↩︎ --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et presse derechef la touche ↩︎.

asr commence par démonter les 2 volumes et procède en préalable à une vérification de la "destination" et de la "source", avant tout engagement du clonage en bloc à bloc.

Les tables de partitions (GPT), les formats de systèmes de fichiers (JHFS+) et les tailles de partitions ("destination" > "source") sont intrinsèquement valides chez toi > mais si asr trouve à redire à la "source" (système de fichiers ou impossibilité de démonter le disque) > ça va pas le faire et ça va planter sur un message d'erreur.

Par contre, si jamais le dispositif était validé, voici ce que tu verrais dans la fenêtre du «Terminal» :
Bloc de code:
Validating target...done
    Validating source...done
    Validating sizes...done
    Restoring  ....10....20....30....40....50....60....70....80....90....100
    Verifying  ....10....20....30....40....50....60....70....80....90....100
    Remounting target volume...done
> c'est un affichage progressif : tout va se jouer pour toi dans les 3 premières étapes (Validating) > si jamais tu accédais à l'étape Restoring > il y aurait des chances que ça marche. Pour 1,7 To de données, ce serait très long > les tranches de compétion (10....20....) s'affichent au fur et à mesure, ce qui donne une idée de la vitesse de progression. Le Restoring est suivi par un Verifying : plus rapide.

Si tout a bien marché > en sortie d'opération les 2 volumes sont remontés > le volume de "destination" est désormais une image-miroir de la "source" : même nom (ce serait ARCHIVE BACKUP aussi), même icône de volume, même contenu de fichiers.
 
Voilà. J'ai entré la première commande mais il me renvoie ceci :
sudo: /etc/sudoers is world writable
sudo: no valid sudoers sources found, quitting

et je n'ai pas eu de demande de password