Forum Clubic

[Debian] Problème de boot aléatoire

Hello,

J’ouvre ce topic en désespoir de cause, j’ai déjà essayé pas mal de choses mais je ne trouve pas comment résoudre le problème. Laissez moi vous exposer les faits.

Utilisateurs traditionnel de Mandriva, j’ai voulu passer sur une distrib plus “pro” (me demandez pas pourquoi, envie de plus de contrôle ou je sais pas, une lubie quoi, mais c’est pas la question).
J’ai donc réalisé une installation de la distribution à partir du DVD1 de Etch, puis installé les miroirs de mise à jour pour tout (etch, non-free, etc). Tout fonctionnait à merveille, mais j’avais besoin de ma partition de données en FAT32. J’ai donc modifié le fichier fstab. Un mount -a n’a montré aucun problème et a bien monté la partition, donc j’ai rebooté. Dans le même temps, j’avais installé un driver ext2/ext3 sur Windows pour accéder à mes partitions Linux. Lorsque j’ai voulu redémarrer Debian, le chargement s’est bloqué lors du montage des FS.
Redémarré sous Windows, j’ai édité le fichier fstab et y modifiant le montage de ma partition de données, ça ne passait pas. J’ai commenté la ligne de montage de cette partition, et ça a fonctionné. Lors du rebbot suivant, à nouveau le même problème. Retour sous Windows, édition du fstab en y ajoutant puis retirant un simple espace pour forcer l’enregistrement du fichier. Avec cette manipulation, le premier rebbot sous Debian a fonctionné, puis le suivant a présenté le problème à nouveau. Comme si le premier boot passait bien corrompait le fichier empêchant ainsi le boot suivant.

J’ai d’abord pensé que le responsable était le driver Windows. J’ai donc tenté de supprimer le fichier fstab d’origine puis j’en ai recréé un identique manuellement en root et en console, en y mettant les droits -rw-r–r-- avec bien entendu root comme propriétaire. Là encore, le premier boot est passé, puis le second a déconne.
J’ai supprimé le driver ext de Windows, puis procédé à une réinstallation totale de Debian. une fois sous Debian, j’ai remonté dans fstab ma partition de données puis rebooté plusieurs fois, tout fonctionnait nickel. J’ai donc continué à configurer ma distrib : installation des drivers nVidia et des paquets requis pour l’installation (installeur propriétaire, d’où installation de gcc, g++, make et linux-headers pour mon kernel), installation de kde, openoffice, etc… J’ai éteins la machine hier soir, tout fonctionnait. En l’allumant ce matin, le problème était à nouveau là.

Ainsi, je pense que le driver Windows pour ext peut être exclu puisqu’il n’a pas été utilisé depuis la réinstallation de la distrbution, et que le problème est là. La façon dont est monté la partition de données ne doit pas intervenir puisque plusieurs reboot ont fonctionnés suite à l’édition de fstab. Je pense que c’est plutôt ce qui a été installé après qui me met la panique. Un paquet corrompt le fichier fstab parmi ceux installés après les tests de montage de partitions et de reboot.
A votre avis, qu’est-ce qui coince ? J’aimerai vraiment embrasser Debian, mais si je ne peux pas la booter ça va être difficile… Je pense que mon matériel peut être écarté, dans le sens où, entre les deux installations de Debian, j’ai réinstallé une Mandriva 2007 qui n’a présenté aucune défaillance. Bref, je n’arrive pas à comprendre d’où vient le problème.

Je serait presque tenté de dire que les problèmes apparaissent suite à l’installation de drivers nVidia, mais en réfléchissant de manière logique, je ne vois pas dans quelle mesure ces drivers pourraient entrainer la corruption de fstab.

Enfin voila quoi, si vous avez des idées, je suis preneurs, parce qu’en l’état, moi je patauge…

heu, comme ça, c’est assez difficile a dire.
je serais toi, je commencerais par fouiller dans les log /var/log…
en particulier -> /var/log/dmesg
si tu trouve un message suspect et que tu vois pas trop ce que c’est copie le ici.
on pourra surement t’en dire plus.

OK, merci pour l’info. J’avais essayé de matter le log boot, mais il était vide, je n’avais pas pensé à matter le log dmesg. Je ferai ça ce soir, je suis au taf là. Je vous tiens au courant dès que possible :slight_smile:

tu peux aussi essayer de voir la date de dernière modification du fichier pour voir si tu as fait un truc louche dans ces eaux là.

je t’ai déjà posé la question sur l’autre topic, mais utilises-tu du montage automatique de CD ou clé USB ?
Si oui avec quelle méthode ?
Si ce n’est pas la méthode udev-hal-dbus, il est possible qu’un utilistaire édite le fstab quand quelque chose est inseré pour te permettre de le monter et l’y supprime une fois que c’est retiré, fais des essais pour voir.
Une autre astuce aussi est de trouver un utilitaire de surveillance des fichier qui te diras dès que ce fichier est modifié et par qui. Je n’en connais pas directement, mais je sais que kate/kwrite te signale quand un fichier que tu édite est modifié par un programme extérieur.
Donc si personne ne connais d’utilitaire qui fais ça bien en te disant quel process édite ece fichier, tu peux l’ouvrir dans kwrite (pas la peine d’être root, il faut juste qu’il soit lisible) et attendre en cliquant de temps en temps sur la fenêtre de kwrite pour lui donner le focus (sinon elle ne signale pas :().
Tu pourras essayer de reperer quelle opération louche tu as fait juste avant

OK, je vais regarder ça. De ce que je me souviens, je n’ai pas branché de clé USB ou disque dur externe depuis l’installation de Debian, donc je ne suis pas sur que ça puisse avoir une influence. De mémoire, je vois bien passer udev et hal au démarrage dans les démarrage de services, donc je pense que c’est effectivement cette méthode qui est utilisée.

Pour ce qui est d’un soft qui endommagerai le fichier, je n’en suis pas sur car :

  • les lignes du fstab ne sont pas modifiées. Après il est possible qu’un soft remplace mal certains caractères et endommage le fichier, mais c’est en tout cas invisible à l’écran
  • lors de la première fois ou le problème se présentait, j’avais modifié le fichier pour en forcer l’enregistrement, et tout de suite après j’avais placé les droits d’accès à -r–r--r-- de manière à ce que rien ne puisse le modifier. Le problème était toujours là.

D’autre part, pour ce qui est de surveiller l’accès au fichier depuis KWrite (par exemple), ça va être difficile, car le fichier semble se corrompre avant l’ouverture de session. En effet, lorsque je boot sous Debian (après avoir feinté une modif), même si je reboot avant l’ouverture de session (lors de l’attente sous GDM donc), le fichier se trouve altéré.

Ca peut pas venir des différences d’encodage entre utf8 et iso-… ?
Je ne m’y connais pas assez pour t’aider, mais je me dis que des fois des trucs tout bête comme ça…

Bon, j’y comprend rien, je n’ai rien touché depuis ce matin, et pourtant Debian a démarré sans problème ce soir :confused: 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.

Comment savoir quelle méthode est utilisée pour le montage en temps réel automatique des périphériques de masse externe ? Je démarre sur un runlevel 2, j’ai remarqué que dans /etc/rc2.d il y avait un lien symbolique sur /etc/init.d/dbus. Cela confirmerait-il que tourne sous dbus ? Sinon, il me semble bien voir passer hal dans mon démarrage.

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 :wink: 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 :D.

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 :slight_smile:

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 /

Il faut savoir qu’après un certain nombre de démarrages (une vingtaine je pense), les partitions montée sont testées automatiquement donc pas de panique docteur c’est probablement normal.

Pour tes problèmes probablement l’initialisation d’un périphérique. Mois j’ai eu ce genre de problème avec un lecteur dvd; une fois sur 2 il bloquait à l’initialisation.

Ton driver windows ext3 c’est quoi?? Si tu écris sur une partition ext3 système de linux depuis windows, tu as intéret à faire confiance à ton driver :slight_smile:

Ce driver windowsien est d’ailleurs probablement la cause de ce scan de partition.

Pas d’accord. Le drivers ext3 pour Windows était suspect lors de la première installation de Debian et du coup je l’ai désinstallé. Or, dorénavant, il est désinstallé, Debian a été réinstallé après sa désinstallation (avec formatage des partitions ext3 lors de la réinstallation de Debian) et le problème est réapparu après un certains nombre de reboot. Donc le drivers ext peut être exclu.

P.S. :
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.

cherche si t’as pas un peripherique qui a des problemes de compatibilité avec nux.
c’est quand meme bizar ton truc, j’ai installer debian sur un paquet de pc et j’ai jamais eu ce genre de soucis :neutre:

edit : tu peux aussi essayer de passer en sid au pire(paquets plus recent donc peut etre pas le probleme), mais si tu connais pas debian je te le conseil pas trop…

Donc je vais éviter Sid… Pour ce qui est de la compatibilité matérielle, je ne sais pas si ça peut venir de ça puisque Mandriva fonctionne comme un charme, sans jamais planter au chargement. Les paquets ne sont peut être pas les même ou les patchs kernel de Mandriva permettent peut être une meilleure prise en charge de mon matos, je ne sais pas, mais je pense que mon matos est très standard.

Dans tous les cas, j’ai passé une bonne partie de l’après midi à m’occuper de ma machine : suppression de toutes mes partitions, création de 2 partitions primaires (la première pour Windows, la seconde pour le / Debian), réinstallation de Windows puis Debian. J’ai pas encore eu le temps de trop tester depuis la nouvelle installation, je vais voir ce que ça donne. Peut être que le fait que / soit sur une partition primaire aura une meilleur comportement, mais honnêtement, je n’y crois pas trop… Je vous tiendrai au courant de toute façon.