Reprise du message précédent :

Je sus tout à fait d'accord je vais approfondir le sujet en cherchant de mon côté.
 
EDIT :
Et ben, j'ai encore pas mal à apprendre je crois... J'ai essayé de faire fonctionner OpenGL sur ma station, et bien entendu, j'ai tout pété mon X. Il y avait pourtant rien de particulier dedans, j'ai pas trop compris... Résultat, on est là pour apprendre, j'ai réinstallé mon système. Je m'y suis pris autrement pour installer les derniers pilotes proprio nVidia : installation de GCC, make et des headers de kernel pour mon noyau (k7).
Résultat : installation des pilotes nVidia sans aucun problème, j'ai bien le logo nVidia nouvelle génération au lancement de GDM (preuve de la bonne installation de la chose), à l'écran tout est plus joli, notamment le lissage de polices qui est cette fois exemplaire sans toucher à rien, mais par contre les écran de veille OpenGL ne fonctionnent toujours pas. Je comprend pas trop pourquoi, mais bon, c'est pas trop grave (sauf pour faire fonctionner Beryl à l'avenir que je comptais réinstaller).
 
J'en ai profité pour passer sur un framebuffer en 1280*1024@16bits pour le boot, c'est cool (code trouvé dans le HOWTO de framebuffer comme indiqué par Xavier OM). Tout fonctionne à merveille en l'état (sauf OpenGL), je m'y remet

Je cherche désespérément les dépots à ajouter à mon source.lst pour Java. J'en ai besoin pour jouer au poker online sous Linux. J'ai essayé d'installer le composants Java depuis Synaptic, et je pensais que ça fonctionnait puisque IceWeasel autant que Konqueror me demandent si je souhaite exécuter l'applet Java quand je suis sur mon site de jeux favori. Néanmoins, rien ne se passe, j'ai ajouté le site en liste blanche, mais k'applet ne semble pas s'exécuter.
Je pense que la mise à jour de Java permettrai de résoudre le problème, mais je ne trouve pas de dépôts de diffusion du dernier JRE. Vous avez une adresse ?

Bon, je crois que j'ai un gros problème...
 
J'ai modifié mon fstab pour avoir ma partition FAT32 avec tout mes fichiers dessus (musique, vidéo, etc). Un mount -a n'a montré aucun problème, au contraire, tout fonctionnait nickel. J'ai donc rebooté, tout allait nickel, j'ai pu lire ma musique et tout ça, trop de bonheur quoi.
Et là, sans rien avoir modifié, je ne peux plus booter. Lors du montage des partitions, le boot s'arrête sur sb (0,0,0,0). J'ai remodifié le fstab depuis un live CD pour virer la partition que j'avais ajouté, et ça ne résoud pas le problème. J'ai du mal à comprendre. La seule chose qui ai changé est une série de mise à jour des paquets de la distrib réalisée par adept-update, donc de l'officiel sur testing.
 
Avez vous une idée sur la manière de relancer le système ? Je commence à me demander si je suis bien prêt à migrer sous Debian malgré mes bases sous Linux...

Je sais pas trop ce que tu as fais, mais je vois pas comment le fait de rajouter des lignes dans fstab puis les supprimer pourrait bloquer ton système. Et ça n'a aucun rapport avec Debian là...

Je dis pas... J'ai également du mal à comprendre ce qu'il s'est passé. j'ai ajouté la ligne suivante :
 

 
J'ai pu rebooter, et tout est monté correctement. Donc je ne pense pas que ce soir le fstab qui m'ait planté mon bbot. J'ai cru que le fait de virer cette ligne permettrai de refaire partir le système, mais non. Finalement, je pense que c'est l'update qui a foutu la zone. Je vais tenter de rebooter une fois encore pour relever le message exact sur lequel le système se bloque.
 
Dans quel fichier log est-ce que je peux éventuellement trouver des infos complémentaires ?
 
Sinon, je parlais de l'histoire de Debian parce que j'étais un peu dépité de plus booté mon Linux, je sais bien que Debian n'y est pour rien, mais j'ai cru que j'avais fait une annerie, puisque jusqu'à maintenant, je gérais mes partitions en graphique avec DiskDrake sous Mandriva. Aucun griefs de ma part après Debian...

Alors, toujours pas de boot. Il semble charger mon HD puis affiche ceci :
 

 
Et c'est tout. Mon système : disque dur Hitachi 320 Go SATA sur chipset nForce4. Les partitions semblent toutes là, voici mon fstab :
 

 
Si ça peut vous aider à voir ce qui déconne...

Bon, je progresse...
 
J'ai supprimé la ligne qui faisait référence à /dev/sdb car je n'arrivais pas à comprendre à quel périphérique cela faisait référence. Résultat : le sstème boot à nouveau C'est déjà une bonne chose.
Par contre je ne m'en sort pas avec le montage de ma partition FAT32 de données. J'ai la ligne suivante :
 

 
Si je décommente cette ligne, je ne boot plus, comme lorsque la ligne avec /dev/sdb était dans fstab. Dès que je la commente à nouveau, tout fonctionne à nouveau correctement, si ce n'est que je n'ai pas accès à mes données. Pourtant, un mount -a lorsque la ligne n'est pas commentée fait bien monté les données correctement, avec le bon umask et tout ça. Donc je ne comprend pas où est-ce que je fais une erreur.

Je savais pas qu'ils faisaient des lecteurs de disquettes Sata...  

 
c'est peut-être une floppy scsi.... ou une erreur oué

Je n'ai pourtant jamais tapé cette ligne...
 
Edit :
Je commence à péter les plombs avec ce fstab... Je boot sous Debian, ça passe. Je reboot ça ne passe plus ! Je redémarre sous Windows, j'édite mon fstab (drivers ext3 installés), je ne fais que mettre un espace puis le retirer pour conserver un fichier identique mais permettre son enregistrement. Je reboot sous Debian ça passe. Je redémarre à nouveau : ça ne passe plus.
C'est comme si Debian me foirait le fstab lors du boot, donc ça passe une fois mais après c'est fini. j'ai du mal à comprendre. Le fstab doit-il être accessible en écriture ? Je pense que oui pour root et pas pour les autres. Si oui, alors mes droits sur le fichier sont bons (-rx-r--r--). Je ne me connecte bien entendu pas en root sous KDE.
Des idées ?

Bizarre ce problème...
 
Chez moi les droits d'accès sur le fstab sont : -rw-r--r-- ; le propriétaire est root évidemment.
 
Je n'ai pas trop d'idée, ça pourrait ressembler à une corruption du fichier ; essaye en le supprimant totalement et en recréant un neuf (sous Debian, évite de faire les manip' depuis Windows avec un driver fs externe, le problème peut venir de là aussi). Sinon fait un fsck des systèmes de fichier à tout hasard.
 
Sinon par le passé il y avait de possibles problèmes avec le fstab lorsqu'on installait des programmes (si on peut les appeler comme ça tellement ça ressemblait à de gros hacks) de montage automatique, par ex. fstab-sync. Mais heureusement ces utilitaires ont évolués et ne touchent plus au fstab (cf. pmount par ex.).

Je m'étais demandé si le fait d'utiliser Windows avec un driver ext ne pouvait pas engendrer des problèmes. Mais il se trouve que c'est suite à une modification du fstab via Windows que le système repart, et que c'est une fois démarré sous Debian qu'il ne démarre plus au boot suivant. On dirait donc que c'est Debian qui corrompt le fichier et non Windows. De plus en plus étrange.
 
Je vais essayer en mettant le fichier en -r--r--r-- pour voir si le fait de le protéger complètement contre l'écriture permet de e conserver en l'état et fonctionnel, quit à galérer en cas de besoin de modification, ce qui n'arrive pas tous les jours.

Lors d'un problème de corruption de fichier j'ai suffisamment confiance en Debian pour savoir que c'est généralement soit une défaillance matérielle, soit l'utilisation d'un utilitaire pour FS externe à la distribution...  
 
Il faut savoir que les cas de corruption de système de fichier par le système lui-même c'est tout de même très rare ; ça peut arriver avec certaines versions de noyau et drivers pour FS expérimentaux, mais Debian fait suffisamment bien son travail à ce niveau pour ne pas avoir d'ennuis avec les noyaux pré-compilés (surtout dans Etch à son stade actuel).
 
 
Personnellement, si je devrais donner un bon conseil, ce serait d'arrêter de bidouiller avec des utilitaires de ce type, surtout lorsqu'il s'agit de fichiers systèmes ; insidieusement ça peut créer plus de problèmes que ça n'en règle. Rien ne t'empêche de faire un test à ce niveau pour le vérifier : tu prends deux fichiers identiques et fais la même modif dedans, sur l'un depuis Debian, sur l'autre depuis Windows avec le driver ext ; compare ensuite les sommes md5 des deux fichiers, mon intuition me dit que tu risques d'avoir des surprises.
 
 
 

Si le fichier est corrompu, changer les droits dessus n'arrangera rien.
 
Reboote sous Debian, vire le fstab existant et refais-en un tout neuf. C'est la solution la plus propre et la plus sûre ; il y a des chances que ça règle ton problème, ça ne coûte rien d'essayer.
 
 

J'ai essayé de virer fstab et de le recréer à la mano comme tu me le suggérais, en recopiant scrupuleusement ce qui était dedans, mais........ n'a pas marché, je n'ai toujours pas compris pourquoi. Du coup, j'ai voulu réinstaller la distrib (me brûlez pas, que je maîtriserai mieux, je perdrai ces mauvaises habitudes), mais cela n'a pas été possible, une erreur de FS appraissant lors de la copie du système de base (DVD HS ou FS corrompu apriori d'après le message d'erreur). J'ai voulu faire une netinstall à partir d'un CD, mais l'installateur se bloque à l'étape "Examen du miroir". Ma configuration réseau fonctionne pourtant très bien.
 
Bref, de guerre lasse et pour tester si c'était mon ordi qui déconnait (hardware ou FS pourri), j'ai résinatllé une Mandriva à l'arrache, et elle est passée nickel. Je retenterai donc Debian plus tard, je n'avais plus le temps de m'y remettre hier. Si j'ai le temps cette semaine, je réinstallerai, sinon ce sera la semaine prochaine, je serai en vacances. Dur dur quand même...

Tes images de CD / DVD de Debian sont sans doute défectueuses ; c'est la seule raison que je vois.
 
Quand tu auras l'occasion refais un test en re-gravant une iso netinstall de Etch de Debian-Installer en RC2 (qui ne devrait vraiment plus trop tarder (d'ici une à deux semaines environ), puis vérifie la somme md5 de l'iso gravée ou fais un test de l'intégrité du CD / DVD via l'utilitaire intégré dessus.

J'ai suffisamment de HD en rab pour sauvegarder toutes mes données et formatter complètement mon HD principal. Je vais donc attendre mes vacances et sabrer toutes mes partitions actuelles pour les remonter en ext3, ce qui devrait également résoudre pas mal de pb (c'est toujours mieux de tourner sur du natif et prévu pour Linux je pense), à part une partition d'échange de données qui restera en FAT32 (je joue un peu, Windows gardera sa place sur mon HD, pas le choix).
Je repartirai également avec un CD neuf frais et dispo sur une netinstall. Là encore, je pense que ce sera un peu plus sécurisé concernant le media que mon vieillissant CD-RW. Néanmoins, je ne sais pas pourquoi l'examen du miroir à planté l'install en netinstall, il y a pas de raison, il ne se sert plus du CD à ce moment là...

Si le CD est défectueux, il a très bien pu copier des fichiers moisis sur ton dur... Une partie des fichiers sur le CD peuvent très bien comporter des erreurs qui passeront malgré tout lors de l'opération de copie ; généralement cela induit des problèmes qui sont par la suite difficiles à identifier.
 
Perso je vérifie toujours les CD que je grave, ça évite de passer une journée à chercher pourquoi une install déconne ou de se rendre compte lorsqu'un dur à brûlé que le CD de sauvegarde est mort lui aussi  

Effectivement, ça peut expliquer les choses. En tout cas, j'ai eu un peu de temps ce soir, et même si je vais de toute façon casser mes partoches de manière à passer à ext3 pour la majorités de mes données, j'ai réinstallé Debian Etch. J'ai refusé lors de l'installation d'utiliser un serveur de paquets en me contentant de ce qui était présent sur le DVD1. Je suis donc à nouveau sous Debian (j'arrête pas de changer ces temps ci mais je m'accroche). Je viens de modifier mon fstab pour monter ma partition multimedia, j'attends la fin de la mise à jour des paquets pour rebooter et voir comment ça se passe.

Chaud comme situation...

Hello, c'est encore le chieur qui débute sous Debian et qui galère...
 
J'ai eu quelques problèmes de paquets corrompus (ce qui confirme que mes DVD doivent être un peu naze), mais je m'en suis sorti.
 
En revanche, j'ai une erreur au boot, non bloquante néanmoins. j'ai la ligne suivante juste avant le passage sous GDM :
 
starting DirMngr: dirmngrchgrp: invalid group 'dirmngr'
      failed !

 
Laissez tomber, j'ai corrigé le problème. Je sais pas comment je me démerde, mais j'ai l'impression d'être un vrai manche...

Je suis vraiment désolé, mais mon problème avec fstab est réapparu !
 
J'ai portant rebooté fois hier, ça démarrait nickel, mais ce matin en allumant la machine, vlan, à nouveau le boot se bloque à l'étape de montage des FS. Et cette fois ci, je n'ai pas modifié mon fstab sous Windows puisque j'ai désinstallé le driver ext pour éviter les effets de bord.
De quoi cela peu-il venir ? Je ne comprend vraiment plus...

Copie de deux post sur un autre forum :
Post 1 :
Bon, j'y comprend rien, je n'ai rien touché depuis ce matin, et pourtant Debian a démarré sans problème ce soir Ca commence à me faire tourner en bourrique ce truc...
 
J'ai un peu regardé tout les logs, mais je n'ai rien trouvé de particulier. J'ai bien quelques messages au boot après le montage des FS (longtemps après) mais je n'ai pas le temps de les lire et après je n'arrive pas à les relire sur la console de démarrage (ils sont hors de l'écran et pourtant je suis en framebuffer 1280). Ils parlent de unable to quelque chose, mais je n'en sais pas plus. Je vais rebooter pour essayer de voir mieux.
 
Post 2 :
Alors, je viens de me taper un tas de reboot, je commence à en avoir ma claque... Mais cela a été instructif et vous allez peut être y voir plus clair que moi avec ces nouveaux éléments.
 
En fait j'ai rebooté plein de fois pour voir ce qu'était ce warning bizarre dans le boot. En fait, voilà ce qui s'affiche :  
 
writting for /dev to be fully populated... udev-event[1462]: udev_db_device: unable to create db_file '/dev/.udev/db/class@usb_device@usbdev1.1': no such file or directory
 
Mais en fait cela ne va avoir que peu d'importance j'ai l'impression. En effet au fur et à mesure de mes reboot, j'ai voulu essayer de trouver cette ligne dans /var/log/dmesg. Pour cela, je me suis mis en root dans Konsole, et hop, vi. Je n'ai pas trouvé la ligne en question, mais du coup, vu que j'étais en root, j'ai fait un reboot dans Konsole.
Là, le boot s'est à nouveau figé sur la ligne suivante :
 
sd 0:0:0:0: Attached scsi disk sda
 
C'est sur cette ligne qu'il bloque d'habitude. Je venais de me taper quelques boot donc je me suis dit bizarre que celui ci ne passe pas... J'ai donc éteint la station et rallumé 1 minute plus tard comme on me l'a appris Le boot est passé tout seul ! Je n'avais toujours pas fini de noter ce fouttu message donc j'ai rebooté, en root dans Konsole à nouveau, pour voir si cela avait une influence. Résultat : pas de problème pour rebooter.
J'ai ensuite enchainé quelques reboot pour noter le message, en rebootant directement depuis le menu Action de GDM. Au bout de quelques reboot, le démarrage s'est à nouveau bloqué sur la succession de ligne suivante :
 
sd 0:0:0:0: Attached scsi disk sda
hda: TSSTCorp CD/DVDW SH-S182D, ATAPI DC/DVD-ROM drive
ide 0 at 0x1f0-0x1f7,0x3f6 on irq14
hda: ATAPI 48x DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB cache, UDMA(33)
Uniform CD-ROM drive Revision: 3.20
 
Vous imaginez que pour noter ce message, il m'a fallu un peu de temps. Et bien alors que j'avais presque fini et que j'allais rebooter au reset, le chargement à repris pour se bloquer cette fois ci définitivement sur :
 
Detecting hardware
 
J'ai à nouveau éteint puis relancé la machine, et elle est reparti comme un charme, la preuve, je vous écris depuis Debian... Remarquez, cette arrêt sur Detecting hardware m'a bien aidé puisque le message à propos de /dev était apparent et ne bougeait plus, ce qui m'a permis de finir de le noter .
 
Bref, je ne crois pas finalement que mon fstab soit en cause dans quoi que ce soit la dedans, j'ai l'impression qu'il existe un état du sytème de bas niveau qui fait que parfois le système se fige. A noter que je ne remarque ce problème qu'avec Debian, Mandriva ou Windows ne m'ayant jamais fait défaut au boot (oui, oui, même Windows ).
Je ne suis pas sur que cela amène des éléments clairs au problème, mais ils semblent disculper complètement fstab et mettre plutôt en cause le matériel ou en tout cas un état dans certains cas que je ne peux pas reproduire.

Bon, je me suis fendu d'un nouveau reboot, pour voir par curiosité comment ça se comportait
 
Le boot a bien commencé, j'ai cru que c'était gagné, mais... arrivé à un moment il a commencé à scanner ma partition /dev/sda13 avec l'affichage suivant :
 
/dev/sda13 [=====                              ] XX.X%
 
Une fois le scan terminé, le chargement s'est terminé et j'ai pu accéder à ma session graphique. C'et grave docteur ? Mes partoches sont malades ?
 
P.S. : ma partition /dev/sda13 est le point de montage /

En effet matériellement ca n'a pas l'air top Le scan du disque n'a pas fait d'erreurs donc ?

Non non, aucune bien entendu. Quelque part j'aurai préféré, au moins j'aurai su que ma partition était clairement esquintée, on en parlait et voila. Mais là ben non.
 
Edit :
J'avais pas éteint ma machine cette nuit, donc forcément je n'ai pas eu à booter ce matin. Mais avant de partir bosser, je l'ai quand même fait par curiosité. Résultat : chargement figé sur le montage du HD -> shutdown au bouton. J'ai rallumé, le boot s'est bien déroulé au début, puis à nouveau le scan de /dev/sda13. Je pense que cela est du au fait que je suis obligé d'arrêter violament la machine quand elle se fige, du coup le FS n'est pas correctement démonté.
Le système m'a mentionné qu'il avait trouvé des erreurs cette fois () mais qu'elles ont pu être réparée. Le problème étant qu'à force, il risque d'y avoir des erreurs irrécupérables. Va vite falloir trouver une solution, sinon, je serai contraint d'abandonner cettge distribution (à contre coeur), puisque c'est la seule à me poser des problèmes avec mes partitions. Cette semaine de test avec formattage intégral du disque dur va être décisive pour ma collaboration avec Debian je crois.

Ça pourrait ressembler à une mauvaise prise en charge correcte du contrôleur de disques SATA, puisque ça bloque précisément au moment de l'initialisation du/des disque(s) dur(s). À part dans le cas d'un périph' défectueux, le phénomène du système qui se bloque au boot ou qui sans raison se fige en cours d'utilisation, c'est typique d'un problème de support matériel au niveau du noyau, je dirais.
 
Le fait que cela fonctionne sous Mandriva et pas sous Debian pourrait bien venir du noyau, soit parce que certaines options sont activées chez l'une et pas chez l'autre, soit parce que Mandriva utilise un noyau plus récent ou intègre un patch permettant une meilleure prise en charge de ton matériel.
 
Tu as essayé en passant des options de démarrage pour désactiver certains modes qui peuvent être la source de problèmes ? En passant au bootloader par ex. : noapic nolapic (en particulier, connus pour poser des problèmes avec certaines configs). Sinon il faudrait tenter avec une version plus récente du noyau (en installant le paquet linux-image-2.6-amd64 ; adapté à ton architecture -Turion64)

Comme je l'avais annoncé, j'ai tout réinstallé mon système : mise au chaud des données sur des HD que j'ai en rab, suppression de toutes mes partitions, et réinstallation en douceur de mes OS (je suis obligé d'avoir un Windows, je joue aussi un peu). J'ai donc pour l'instant :
 
- créé un partition primaire NTFS pour Windows et installé l'OS dessus
- créé une partition primaire ext3 pour /
- créé une partition étendue sur le reste de mon HD
- créé un lecteur logique NTFS pour le SWAP de Windows
- créé un lecteur logique ext3 pour mon /home
- réinstallé Debian
 
Le fait que / soit désormais sur une partition primaire pourrait-il avoir une influence ? Je me suis dit que ce serait probablement mieux comme ça, mais peut être est-ce juste une lubbie ? En tout cas, pour le moment RAS, mon système boot correctement avec Debian, j'ai pourtant pas mal bidouillé dessus déjà, je me suis fendu de l'installation de nvidia via les dépôts experimental et Beryl fonctionne désormais au poil

Non clairement pas ; rien à voir avec Windows qui a besoin d'une partition primaire pour installer la partition système.
 
Dommage de ne pas savoir exactement ce qui à bien pu causer ton précédent problème, mais en tous cas content de savoir que tout fonctionne bien (et je te souhaite que ça continue ainsi)  

Merci pour ces encouragements. Je me suis remis en tête de monter ma partition de données via fstab, mais pour l'instant j'ai une erreur sur cette ligne :

Lorsque j'essaie un mount -a, j'ai le message suivant :

En consultant dmesg, il me dit :

Pourtant mon ID d'utilisateur est bien 1000. Si je retire cette option, c'est le gid qui ne passe pas alors que mon groupes d'utilisateur "users" porte bien l'ID 100, et si je retire gid et uid, c'est le umask qui ne passe pas. Bien entendu, si je vire tout, la partition se monte bien, mais du coup je n'ai pas les droits d'écriture dessus, ce qui ne me convient pas.
Je dois faire une erreur, mais je ne vois pas où, il me semble que c'est exactement ce que j'avais écrit la première fois et ça fonctionnait, malgré les problèmes de boot.

C'est le genre d'options que j'utilise pour mes partitions fat uniquement, pour l'ext3 je mets juste "defaults" et je mets les bons droits sur le répertoire /home/partage

Va voir le man de mount et regarde les options auxquelles tu as le droit pour de l'ext3

Effectivement ça fonctionne beaucoup mieux Ca allait bien avec les partitions FAT via gid et uid, du coup j'ai pas réfléchi au fait que je n'étais plus sur du fat mais sur du ext.
 
Merci pour le tuyau

J'ai un problème avec Evolution...

J'ai configuré mes comptes mails, placé mes règles de messages et tout ça, tout fonctionnait nickel. Maintenant que j'ai redémarré (sans problème d'ailleurs ), le bouton "Envoyer/Recevoir" est grisé et je ne peux donc pas relever mes messages. Voici ce que j'ai vérifié que j'étais bien en mode en ligne, et que les comptes sont toujours présents dans les préférences, il n'y a pas de problème de ce côté là.
Bug connu ou comportement normal à cause d'une option que j'ai loupé ?
 
Laissez tomber, problème résolu