Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites".
nombre réponses : 25

#0 Re : -1 »  GPS Garmin 72H ne fonctionne pas avec ubuntu. » Le 23/06/2012, à 01:05

mazkagaz
Réponses : 7

Bonsoir,

j'ai un problème assez similaire : mon GPS BU-353 est reconnu et fonctionne avec xgps mais pas avec opencpn, sauf si je lance opencpn en root. Je pencherais pour un soucis de droits user mais je ne comprends pas pourquoi j'ai accès au gps via xgps en mode simple user et pas avec opencpn.

Pour le moment je ne sais pas pourquoi ni comment résoudre le soucis.

Je suis sur debian sid, et j'ai installé opencpn via les sources du dépôt git après avoir testé d'autres versions : toujours le même résultat.

Peux-tu tester en root pour vérifier si nos deux problèmes sont liés ?

M

#1 Re : -1 »  cacher une partition pour le compte Invité » Le 15/07/2011, à 13:08

mazkagaz
Réponses : 7

Bonjour,

je ne comprends pas trop où est le soucis en fait.

Tu veux ta partition montée en permanence : OK, fstab est ton ami

Tu veux que le comptes guest n'y accède pas :
chown root:groupe_admis rep_vers_ta_partition
chmod 770 rep_vers_ta_partition

en ajoutant seulement ceux qui ont le droit d'y aller au groupe "groupe_admis".

#2 -1 »  [résolu] Kernel et core i5 2500K = no problemo » Le 15/07/2011, à 12:32

mazkagaz
Réponses : 3

Bonjour,

J'ai fait l'acquisition il y a un peu plus d'un mois d'une nouvelle configuration matérielle.

Après
1/ mise en place de mon nouveau système,
2/ résolution de quelques boulettes (perte données...)
3/ peaufinage des derniers paramètres (look'n feel, interfaces boutons spéciaux souris clavier, speedpad n52, installation wine/jeux, mise en place des sauvegardes...etc...),
je me pose une nouvelle question : le noyaux "generic", qui semble correctement reconnaître mes 4 cœurs, est-il réellement bien adapté pour un core i5 2500K ? Ou plutôt, existe-t-il des options de compilation du noyau qui me permettraient de tirer un peu plus de puissance de ce processeur, et notamment du GPU intégré ?

Merci pour vos réponses/conseils.

#3 Re : -1 »  [résolu] Kernel et core i5 2500K = no problemo » Le 15/07/2011, à 13:19

mazkagaz
Réponses : 3

Merci MaryPopy pour cette réponse.

Le temps, oui, l'envie... j'en ai compilé pas mal des noyaux et honnêtement, euh... ben j'aime autant consacrer mon temps à autre chose big_smile

Ta réponse "oui le kernel est bien adapté" me suffit. Je vais pas perdre du temps pour gagner des cacahuètes wink

Au passage, si j'avais lu cette page, je nous aurais fait gagner du temps à tous les deux : http://doc.ubuntu-fr.org/ubuntu_64bits

Ce qui inclut :

    Amd64: (Athlon 64, Turion 64, Athlon X2, Turion X2, Phenom, Amd Opteron, Sempron en socket AM2, Sempron récents, et tous les processeurs plus récents que les processeurs pré-cités)
    Intel EM64T: (Core 2 Duo, Core 2 Quad, Core i3, Core i5, Core i7, Atom 230 et 330, presque tous les Pentium D, les derniers steps de Pentium 4 à partir des versions 6xx, les nouveaux Pentium, les Xeon récents, les Celeron à partir des Celeron D).

#4 Re : -1 »  [résolu] Kernel et core i5 2500K = no problemo » Le 20/07/2011, à 11:22

mazkagaz
Réponses : 3

Bon finalement j'avais 5 minutes à perdre hier soir et j'ai été joueur. J'ai recompilé le 2.6.38.8 en remplaçant "generic" par core2 pour l'architecture du processeur, et en virant qq options processeur spécifiques à d'autres procs.
Mis à part un petit bug de compilation nécessitant la modif d'un Makefile pour un des modules, tout s'est passé sans encombre et le noyau tourne au poil.
Maintenant, de là à dire que j'ai gagné quelque chose... C'est surtout une question de satisfaction personnelle.

Pendant la compilation du noyau, j'ai remarqué qu'il ne compile qu'un module à la fois et donc ne tire que sur un coeur, et même pas à 100%. C'est dommage quand on a 4 coeurs. Je me demandais s'il existait une option pour compiler 5 modules à la fois (un peu comme le principe des n coeurs => n+1 commandes de compil sous gentoo). Voire comme sous gentoo un fichier de conf pour régler ça une bonne fois pour toute sur tous les appels gcc.

J'ai aussi remarqué dans les options du noyau, une config spécifique pour les processeurs atom. Je pense que je vais m'en compiler un petit, parce que sur le netbook, toute optimisation est la bienvenue...

#5 Re : -1 »  Sauvegarde d'un serveur dédié distant sur un serveur local » Le 15/07/2011, à 12:42

mazkagaz
Réponses : 4

Bonjour,

Si tu t'es penché sur les sauvegardes, tu es forcément passé à côté de pages web te parlant de rsync : http://doc.ubuntu-fr.org/rsync

C'est pour le moment (et depuis plusieurs années) ce que j'ai trouvé de plus adapté. Et, coïncidences (?), c'est aussi ce qu'utilisent bon nombre d'ingénieurs système dans bon nombre de sociétés avec park informatique important.

Pour ta question "interface graphique", il me semble que grsync pourrait répondre à ton besoin. Un petit tutoriel : http://doc.ubuntu-fr.org/tutoriel/sauve … vec_grsync

Malheureusement, comme beaucoup d'interfaces graphiques, elle ne doit probablement pas couvrir toutes les options de la commande qu'elle encapsule. En d'autres termes, je suis quasiment certain que rsync peut faire c que tu cherche à faire, mais je ne suis pas certain que grsync t'offre toutes les options de rsync.

A partir de ces infos, je te laisse faire ton bonhomme de chemin et nous dire si tu as résolu ton problème.

#6 Re : -1 »  Sauvegarde d'un serveur dédié distant sur un serveur local » Le 15/07/2011, à 12:57

mazkagaz
Réponses : 4

Si j'ai besoin d'une Interface graphique c'est parce que des gens sans connaissances Linux devront pouvoir configurer ces sauvegardes

Aïe aïe aïe... Laisser à un utilisateur "sans connaissances" le soin d'effectuer ses sauvegardes via un bouton pré-configuré ou une tâche journalisée, ça va, mais le laisser configurer cette sauvegarde alors qu'il n'y entend rien, là, je te dis de suite l'avenir et sans utiliser ma boule de cristal : il va faire une connerie.
La configuration est normalement du ressort de l'expert (celui qui sait) et l'utilisation limité à des tâche pré-définies par l'expert pour les utilisateurs (ceux qui ne savent pas).

#7 Re : -1 »  [RESOLU] perte données suite montage raid1 mdadm sur disques non vides » Le 29/06/2011, à 19:36

mazkagaz
Réponses : 55

Yes !!!!

...

Et je dirais même plus : YES !!!!! big_smile

J'ai des images, des vrais, qui sortent. Donc : mdadm n'a pas tout cassé. On ne sait toujours pas ce que ça a fait exactement mais il y a encore de la donnée sur ces disques.

Du coup, soit je me plonge dans les specs du format ext4, soit vous avez une solution vachement plus simple à me proposer. Mais il va de soi que je ne peux pas en rester là ! big_smile

#8 Re : -1 »  [RESOLU] perte données suite montage raid1 mdadm sur disques non vides » Le 29/06/2011, à 21:30

mazkagaz
Réponses : 55

Bon, photorec, testdisk, même combat : ça plante.

J'ai l'impression qu'il va falloir que je me fade tout ça à la main.

#9 Re : -1 »  [RESOLU] perte données suite montage raid1 mdadm sur disques non vides » Le 29/06/2011, à 22:21

mazkagaz
Réponses : 55

Bon, je sors l'artillerie e2fsprogs. On va voir si ça aide.

$ dumpe2fs wazaaa.dd
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   DATA_OK2
Last mounted on:          /media/DATA_OK2
Filesystem UUID:          64651a7c-b379-46f3-bae6-cff867ef8ceb
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              61054976
Block count:              244190646
Reserved block count:     12209532
Free blocks:              146737945
Free inodes:              60980148
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      965
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sun Jun 26 21:45:39 2011
Last mount time:          Sun Jun 26 21:46:17 2011
Last write time:          Sun Jun 26 23:06:05 2011
Mount count:              2
Maximum mount count:      32
Last checked:             Sun Jun 26 21:45:39 2011
Check interval:           15552000 (6 months)
Next check after:         Fri Dec 23 20:45:39 2011
Lifetime writes:          362 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:              256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      3c67dfd6-8d09-41a2-982d-539a45a90189
Journal backup:           inode blocks
dumpe2fs: A block group is missing an inode table lors de la lecture de l'i-noeud du journal

Donc ça ça correspond aux info qu'on avait dans les premiers 4k je pense, avant l'arrivée des metadata raid.

EDIT : lancement de

$ e2fsck wazaaa.dd

très verbeux, me demande confirmer des milliards de corrections... ctrl+c et tentative de

$ e2fsck -p wazaaa.dd
DATA_OK2 n'a pas été démonté proprement, vérification forcée.
DATA_OK2: l'i-noeud 44961552 a le drapeau de compression qui est initialisé sur un système de fichiers sans support de compression.

DATA_OK2: INCONSISTENCE INATTENDUE ; EXÉCUTEZ fsck MANUELLEMENT.
    (i.e., sans options -a ou -p)

Bon, ok, je vais utiliser la technique du tournevis qui bloque la touche "O" et je vais fumer une cloppe pendant le "e2fsck wazaaa.dd"

#10 Re : -1 »  [RESOLU] perte données suite montage raid1 mdadm sur disques non vides » Le 29/06/2011, à 22:44

mazkagaz
Réponses : 55
rmy a écrit :
mazkagaz a écrit :

Bon, photorec, testdisk, même combat : ça plante.

J'ai l'impression qu'il va falloir que je me fade tout ça à la main.

Désolé pour le manque de réactivité, suis overbooké par les RMLL.

Essaye une autre version  de photorec. Si tu as pris celle des paquets en particulier, c'est obsolète. Va chopper sur le site de Christophe Grenier la 6.12 ou la 6.13-WIP, et relance testdisk et photorec s'il te plaît.

En vrac pour les réponses : R-Studio (de r-tt). Logiciel de récup proprio qui tourne sous linux. Bien joué pour foremeost, est-ce que tu as des images de plus de 1M ? Est-ce qu'elles ne sont pas corrompues ?

pour l'instant j'ai pas essayé de récupérer les grosses images. J'ai juste acter leur existence en en récupérant une petite et je m'en suis allé avec l'idée de réparer le FS (non... si si).
En plus maintenant que l'hypothèse copie de l'un sur l'autre semble se vérifier, ce qui serait intéressant, ce serait de savoir lequel était le source. Du coup, je fais joujou avec le dump du premier, au pire, si je le démolis, je le re dumpe. Et si j'obtiens rien, je teste avec le second disque, au cas ou ce soit la "source".

#11 Re : -1 »  [RESOLU] perte données suite montage raid1 mdadm sur disques non vides » Le 29/06/2011, à 22:46

mazkagaz
Réponses : 55

En fait voilà, mon idée c'est : je répare le FS dans un dump et je monte le dump réparer... Je sais pas si c'est possible étant donné que je ne connais pas le niveau de dégradation, mais je vais tester.

#12 Re : -1 »  [RESOLU] perte données suite montage raid1 mdadm sur disques non vides » Le 29/06/2011, à 23:13

mazkagaz
Réponses : 55

La vache ! je commence à voir apparaître les noms de mes fichiers/dossiers smile
Je le laisse finir et demain je ferais un dump de l'autre disque, pour voir si j'obtiens la même chose, ou mieux, ou pire.

#13 Re : -1 »  [RESOLU] perte données suite montage raid1 mdadm sur disques non vides » Le 30/06/2011, à 09:16

mazkagaz
Réponses : 55

Levé ce matin, restauration en pause, attente de réponse pour dupliquer des blocks partagés... bref, le tournevis qui bloquait la touche "O" est tombé lol
Dans l'hypothèse peu probable où qqun ayant le même soucis que moi suivrait l'évolution de ce post :
/!\ATTENTION/!\ Ne pas faire comme moi. J'y vais comme un bourrin parce que j'ai pas grand chose à perdre. Je mettrai à jour le premier post en supprimant le blabla et en ajoutant toutes les infos utiles (s'il en est) quand j'aurai terminé mes expériences. /!\ATTENTION/!\

Comme en attendant de récupérer ou non mes datas je suis un peu bloqué pour le reste (2 disques de 1To mis au placard, ça manque...), j'installe prochainement 2 disques de 2To et je mets les 2 de 1To dans 2 boîtiers externes. Comme ça je vais pouvoir refermer ma tour et travailler sur les 2 dumps en même temps, tout en vaquant à mes occupations habituelles.

Je suis allé sur le site de Christophe Grenier. Effectivement il semble qu'il y ait du nouveau. Je verrais ce que proposent ces nouvelles versions. Sachant que ce que j'aimerais faire est assez particulier : je souhaite essayer de réparer un FS et non simplement récupérer quelques fichiers. Je ne sais pas si c'est possible, je ne sais pas si je vais y arriver, mais c'est le but que je me suis fixé pour le moment.

Donc pour résumer ce que je vais faire :
1/ dump des disques :

dd if=/device_1To_disque1 of=/media/Disque_2To_1/image_1To_1.dd bs=4096 conv=notrunc,noerror
dd if=/device_1To_disque2 of=/media/Disque_2To_2/image_1To_2.dd bs=4096 conv=notrunc,noerror

2/ identification des images :

dumpe2fs /media/Disque_2To_1/image_1To_1.dd
dumpe2fs /media/Disque_2To_2/image_1To_2.dd

3/ tentative de récup bourrine :

e2fsck -p /media/Disque_2To_1/image_1To_1.dd
e2fsck -p /media/Disque_2To_2/image_1To_2.dd

4/ si l'un des 2 e2fsck donne des résultats encourageants, je compare certains gros fichiers avec ma sauvegarde externe actuelle (somme de contrôle md5) non corrompue et j'avise. Si pas de résultat, je recommence les étapes 1 et 2 puis je modifie l'étape 3 par des réparations moins bourrines : d'autres utilisations de e2fsck et/ou testdisk/photorec (dernières versions) et/ou ce que j'aurai trouvé d'ici là (restauration en utilisant les 2 dumps simultanément ??? )...

#14 Re : -1 »  [RESOLU] perte données suite montage raid1 mdadm sur disques non vides » Le 30/06/2011, à 18:50

mazkagaz
Réponses : 55

moi@machine:~$ sudo mount -o loop /media/DJu/wazaaa.dd test/
[sudo] password for moi:
moi@machine:~$ ls test
elle  lost+found  moi
moi@machine:~$ echo content
content
moi@machine:~$

TADAM ! cool

et j'ai des images qui font largement plus d'un méga, et intactes ! Oui messieurs ! big_smile

Bon, vu que j'ai interrompu le e2fsck parce que j'en avais ras la cacaouette, ben je vais recommencer à zéro en essayant de le faire proprement sur les images des 2 disques.

(content content content content content content content content content content content content) smile

#15 Re : -1 »  [RESOLU] perte données suite montage raid1 mdadm sur disques non vides » Le 01/07/2011, à 09:37

mazkagaz
Réponses : 55
rmy a écrit :

Bien joué.

Pour la prochaine fois, ou pour les prochains dumps :

sudo ddrescue /device_1To_disque1 /media/Disque_2To_1/image_1To_1.dd /media/Disque_2To_1/image_1To_1 -n

Avec le log tu peux reprendre en cas d'interruption, avec "-n" tu évites les blocs défectueux au cas où il y en a.

À la place du tournevis, pourquoi pas e2fsck -y ?

Pour comparer tes fichiers, il y a fslint, ou fdupes qui peut t'aider et te mâcher le travail.

Salut rmy,

merci pour ces tuyaux. Je me doutais qu'il existait une option e2fsck pour "always yes", tu m'as évité d'aller farfouillé dans le man smile
fslint, effectivement, je m'en étais servi pour discriminer les doublons dans ma bibliothèque mp3 y a pas très longtemps, ça va m'être bien utile.
fdupes, le nom me dit qqch mais je ne me rappelle pas ce que c'est, je vais regarder et peut-être l'utiliser.

#17 Re : -1 »  [RESOLU] perte données suite montage raid1 mdadm sur disques non vides » Le 13/07/2011, à 13:02

mazkagaz
Réponses : 55
Hoper a écrit :

Merci à Hoper pour m'avoir insufflé la volonté de pousser jusqu'au bout l'expérience ;-) (ma formation scientifique me pousse à cultiver le doute tant que rien n'est prouvé par a+b, et surtout à combattre les certitudes basées sur des éléments vagues)

Mouhai bein... Je pourrai te retourner le remerciement. C'est malin, maintenant, par ta faute, je passe mon temps à me poser la question de savoir ce que fait très précisément le mdadm --create smile

Une chose qui n'est pas encore éclaircie il me semble...

Je n'ai malheureusement pas la réponse à cette question. Je ne me suis pas creusé davantage la cervelle puisque finalement, la résolution de mon soucis ne nécessitait pas cette connaissance. Tout comme je ne me suis pas plongé dans les specs du format ext4 puisqu'une boîte à outil très bien fournie existait déjà.

Par contre, je peux t'assurer que pendant 3 heures, mdadm n'écrase pas les 2 disques et qu'il n'y a pas à proprement parler de formatage. Il s'agit bel et bien d'une synchronisation.

La modification des disques résulte donc au moins de 2 actions que j'ai vaguement explorées :
- l'écriture des metadatas (au début à partir de 4k en version 1.2).
- la synchronisation des disques.

A partir de là je ne peux faire que des hypothèses. Une des sous-tâches de la synchro pourraît être une "copie" d'un disque vers l'autre. Je mets "copie" entre guillemets car c'est probablement plus qu'une copie, il doit y avoir des opérations de contrôle (secteurs défectueux ?), peut-être même des calculs de somme de contrôle, lesquelles sont peut-être écrites dans les metadatas.
Une hypothèse : les metadatas contiennent peut-être des adresses de secteurs avec sommes de contrôle et état du secteur (défectueux, en cours de modif, synchonisé ou non, date dernière modif...etc...) qui permettent à mdadm de connaître l'état "physique" de l'ensemble raid sans se préoccuper du format du contenu (ext4, ntfs, fat32, ...etc...) et de faire les opérations qui conviennent (synchro des secteurs qui en ont besoin, reallocation d'un secteur si défectueux sur un des disques, finalisation des tâches de copie en cours...etc...).
Finalement ça paraîtrait logique, si mdadm écrivait des données sur toute la surface du disque, comment pourrait-on "incruster" un FS au sein même de cette sorte de "super FS" ?

Mais gardons nous des conclusions hâtives, ce ne sont là que pures spéculations, la vérité, c'est que je n'en sais rien. Je sais juste avec certitude que lors de la création d'un ensemble RAID 1, avec la version actuelle de mdadm sous ubuntu 11.04, on ne perd pas toutes les données présentes sur les disques, et comme j'ai pu en récupérer un bon paquet, on peut admettre qu'il y existe à un certain niveau de l'étape de création de l'ensemble, ce qui pourrait s'apparenter à une copie d'un disque vers l'autre.

Pour conclure, ne m'en veux pas trop pour cette touche d'ironie dans la réédition de mon premier post. Je voulais juste que tu te rendes compte que si je n'avais aucune compétence linux, et si j'avais pris pour argent comptant tes premières réponses ( un "tout est formaté" catégorique si je me rappelle bien), j'aurais abandonné et n'aurais rien récupéré. Ce qu'il faut retenir, c'est qu'en établissant de telles certitudes alors que visiblement, tu te trompais (ce que je ne suis pas sensé savoir, à priori je demande l'avis d'experts), tu aurais provoqué la perte de données récupérables. C'est pas bien grave puisque tout finit bien, mais la prochaine fois que tu donnes ton aide, sois un peu moins catégorique (sauf si tu es vraiment sûr de toi, mais vraiment, pas par acte de foi), sinon ton aide risque de mener dans une impasse. Surtout que visiblement tu as pas mal de compétences, ce serait dommage de les gâcher wink A contrario, tu vois rmy, visiblement il n'en savait pas plus que nous, mais il a proposé des idées de solutions (faire des tests avec un autre disque, chercher des images...etc...) qui ont permis d'aboutir. C'est ça aussi aider : admettre qu'on ne sait pas, mais user de tes compétences pour aider à trouver la réponse au problème.

#18 Re : -1 »  [RESOLU]Plantage d'Ubuntu, bug inconnu » Le 29/06/2011, à 20:13

mazkagaz
Réponses : 10

Bonjour,

quand ça arrive, fait un

ps aux --sort pmem |tail

Je parie que le coupable se dénoncera en dernière ligne.

#19 Re : -1 »  [RESOLU]Plantage d'Ubuntu, bug inconnu » Le 30/06/2011, à 10:07

mazkagaz
Réponses : 10

Salut,

J'imagine que même si tu n'utilises plus ni google chrome, ni vlc (ou vlc intégré dans chrome... streaming ?), tu les as quand même utilisés entre le boot et le plantage. Confirme si c'est bien le cas. (remarque : ici c'est surtout vlc le fautif, 74.5% de la mémoire, chrome "seulement" 3.3%)

VLC, tu l'utilises intégré dans un navigateur ou directement ? Si tu ne sais pas, reboote et lance seulement vlc, n'ouvre jamais une vidéo dans un navigateur et attends de voir si le pb se manifeste. Puis reboote et fais la même opération en lisant une vidéo dans chrome et sans jamais ouvrir de vidéo hors navigateur puis attends de voir si le pb se manifeste.
La réponse à cette dernière question te permettra de savoir où faire un rapport de bogue, car c'est soit chez google, soit chez vlc, soit chez les intégrateur de vlc dans un navigateur.

En attendant, ce que tu peux faire pour palier au problème : essayer de réinstaller les paquets concernés (au cas où l'installation se soit mal passée...), essayer un autre navigateur, ... et, si le soucis persiste, quand il se manifeste, tu ouvres un terminal et tu tapes :

killall chrome
killall vlc

ou

kill -9 pid_chrome
kill -9 pid_vlc

Leur pid étant indiqué en deuxième colonne de

ps aux --sort pmem |tail

ici, respectivement 1711 et 2548 :

1000      1711 19.9  3.3 394568 34380 ?        Dl   22:55  11:17 /opt/google/chrome/chrome       
1000      2548  2.5 74.5 1178416 764132 ?      Sl   23:46   0:08 vlc

Ce ne sont pas des solutions définitives, elles te permettront juste de patienter jusqu'à correction du bogue ou réinstallation correcte de tes paquets chrome/vlc/lib*vlc , si tant est que ce sont eux les responsables (un chargeur d'appli ? autre chose ?).

En tout cas c'est ce que je ferais.

#20 Re : -1 »  [RESOLU]Plantage d'Ubuntu, bug inconnu » Le 30/06/2011, à 10:13

mazkagaz
Réponses : 10

En regardant mieux le résultat de ta commande, je pense sincèrement que c'est chrome associé à vlc (peut-être juste pour une vidéo dans une bannière, vas savoir, tu n'as pas forcément fait du streaming).
Utilise firefox pour voir si ça se reproduit.

#21 Re : -1 »  [RESOLU]Plantage d'Ubuntu, bug inconnu » Le 30/06/2011, à 16:06

mazkagaz
Réponses : 10
Y0a0bon a écrit :

Ok alors déja non j'utilise vlc a part, c'était un téléchargement megaupload, et le plantage arrive souvent avec vlc il me semble (pas de plantage juste avec google chrome ou quoique ce soit d'autre a mon souvenir) mais je vais rééssayer et le ré-installer. Je vais quand meme faire tes tests, on verra. Merci!

Oui, effectivement, en regardant encore un peu mieux, on voit bien que tu a appelé vlc sur un south park dans ton rép. de téléchargement tongue
Juste pour savoir : tu as combien de ram et combien pèsent tes south park ?

#22 Re : -1 »  [RESOLU]Plantage d'Ubuntu, bug inconnu » Le 30/06/2011, à 16:12

mazkagaz
Réponses : 10

Ah et puis aussi, si tu réinstalles vlc, vérifie si tu as un répertoire du style ".vlc" (avec le point devant) :

cd && ls -a|grep -i vlc

Si tu en trouves un, renomme le :

mv ton_rep ton_rep.old

et tout ça avant de relancer vlc après réinstallation.

#23 Re : -1 »  [RESOLU] kubuntu boot soudain sur du prompt » Le 29/06/2011, à 19:57

mazkagaz
Réponses : 9
lys3r3 a écrit :

Bonsoir à tous,
Alors, dans l'ordre : Mloupiot, effectivement tu as parfaitement raison, c'est pour ça que je disais que je ne savais pas trop quoi penser de la solution trouvée sur le net pour un kubuntu version 7.04...
Ensuite Mazkagaz : avec le CTRL+ALT+FX j'obtiens des changements... l'information tty2 se transforme en fonction de la touche F(x) choisie, pour la touche F7, j'obtiens une série de lignes de commandes qui finissent toutes par un [OK] à la fin, c'est pour ça que je ne l'ai pas recopiée...
Autrement, la fonction "startx |tee stx.out" fonctionne et j'obtiens des informations qui je l'espère seront utiles :
NVIDIA : could not open the device file /dev/nvidia1 (input/output error)
(EE) NVIDIA (GPU-1) : failed to initialize the NVIDIA GPU at PCI 3:0:0
(EE) NVIDIA (GPU-1) : check your system's kernel log for additionnal error message and refer to chapter 8 : common problems in the README for additionnal informations
(EE) NVIDIA (GPU-1) : failed to initialize the NVIDIA graphic device !
backtrace
0: /usr/bin/X (xorg_backtrace+0x3b) [0x80eab2b]
1: /usr/bin/X (0x8048000+0x5fad8) [0x80a7ad8]
2: (vdso) (_kernel_rt_sigreturn+0x0) [0xb77b240c]

Segmentation fault in adress (nil)
Caught signal 11 (segmentation fault). Server aborting.


Voilà le message d'erreur, tout le reste c'est du texte qui ne me dit rien, mais en tout cas qui semble ne pas faire partie du message d'erreur.

La commende "dmesg > stx.pb" ne donne rien et je reconnaîs amèrement ma complète inaptitude à comprendre pourquoi windows marche et pas linux...

Bon, déjà, on a un peu plus de grain à moudre.
dmesg > stx.pb ne te donne rien car j'ai délibérément redirigé la sortie vers un fichier, stx.pb, afin que tu gardes une trace. J'aurais dû te dire de taper dmesg |tee stx.pb comme ça tu aurais vu en même temps les sortie (">" = redirection, "|tee " = copie)

(EE) NVIDIA (GPU-1) : check your system's kernel log for additionnal error message and refer to chapter 8 : common problems in the README for additionnal informations

dmesg fournira ces logs. Donc il nous les faut.

Quelques infos de plus à te demander :
1/ as-tu récemment installer un nouveau noyau ?
2/ même question concernant des pilotes nvidia
3/ avez-vous toi et ta copine le même PC ? Si oui, essaie d'échanger les carte graphiques. Si non, ben c'est balot tongue

Tu dis : "je comprends pas, ça marche sous windows". Du coup je penche plutôt pour des soucis liés aux point 1/ et 2/ MAIS parfois des différences de pilote entre 2 OS font que sur un matériel défectueux, l'un va s'en sortir, et pas l'autre. Je pense par exemple à de la ram défectueuse. J'ai eu à une époque une carte ATI (rage2 je crois, c'était y a trèèèès longtemps) qui m'a fait ce coup, sous minux freeze et sous windows, fallait la pousser dans ses retranchements pour la planter.

Donc, outre répondre aux 3 questions posées au dessus, tu peux, si tu as une carte nvidia de même génération que la tienne, essayer de remplacer celle qui est dans ton PC, juste pour écarter ou non l'hypothèse "pb matériel". Si pas de soucis matériel, on avisera en fonction de tes réponses.

#24 Re : -1 »  [RESOLU] kubuntu boot soudain sur du prompt » Le 01/07/2011, à 09:15

mazkagaz
Réponses : 9

Content que tu t'en sois sorti smile

Comme quoi, les OS évoluent mais certaines différences/caractéristiques subsistent et résistent au temps : ATI RAGE2, je crois que c'était dans les années 2000.... roll (époque windows 98 / debian potato). Et ce genre de comportement vis à vis du matériel a déjà été observé sur autre chose que des cartes graphiques.

Si tu fais fonctionner 2 cartes nvidia en SLI (et que ça fonctionne sous linux), je serais intéressé d'avoir tes retours car j'ai moi même 2 cartes nvidia et je me pose la question de plugger seconde en SLI pour faire du calcul vectoriel (CUDA).