Note du modérateur : doc sous GNU Free Documentation License
![[fr]](../images/fr.png)
La documentation (3627 hits)
> Lire la dépêche (13 commentaires, moyenne: 3,7).
Vous avez demandé le commentaire #109684.
Run by 
Cette page a été générée par Templeet en 0.0645s (dont 0.0067 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Question supplémentaire
Bon article, précis et concis :-)
J'utilise aussi ce modem sous une debian et j'utilise le script adsl.sh qui est fourni avec le tarball pour la connexion. (D'ailleurs, je ne crois pas qu'il en est question, cela pourrait-être rajouté).
Je voulais savoir où il était possible sous la debian de ne pas faire apparaître systématiquement les messages sur la console lorsque je me connecte, mais seulement d'afficher le 'done' une fois que ceci est fait.
Lorsque je charge le module usb-uhci, il y a vraiment trop de choses qui s'affichent à l'écran. J'ai beau rediriger vers /dev/null stdout et stderr et ça ne marche pas.
Il y a-t-il moyen de ne pas faire apparaître tous ces messages ? En fait, il en est de même pour tous les modules qui sont chargés au démarrage, comme la carte réseau par exemple. (Ce qui est moins gênant, puisque ça fait 2 lignes).
Si qquun peut donc m'éclairer sur la question, je lui serait reconnaissant. Merci d'avance.
[^]Re: Question supplémentaire
Malheureusement je ne pense pas qu'il soit possible d'enlever ces messages. Je sais, j'ai le même problème, ça fait pas très propre mais je n'ai pas trouvé le moyen de faire autrement.
Cela dit, même sur une Mandrake on obtient les mêmes messages donc ça doit venir de modem_run lui-même.
Sinon tu peux toujours compiler usb-uhci en dur dans le noyau (c'est que j'ai fait), ca va un peu plus vite au démarrage.
Voilà, pour le reste, je m'en remets aux autres.
[^]Re: Question supplémentaire
meme avec 2>&1 >/dev/null ?
[^]Re: Question supplémentaire
Bah à vrai dire, je n'ai pas essayé (je sais je suis une quiche) vu que je n'ai pas modifié le script, je n'ai fait que le configurer... Mais je vais regarder ça dès que j'ai le temps.
[^]Re: Question supplémentaire
Coucou les fidèles utilsateurs de mes scripts :-)
Ca fait plaisir de voir qu'après bientôt 1 an de développement des contributions externes fleurissent encore un peu partout.
Pour vos problèmes de messages de noyau, une solution existe. Cette solution consite à mettre dans votre lilo.conf l'option "quiet" à votre string append.
Chez moi ça donne :
Cette option a pour effet de "fermer le clapet" au noyau durant le boot. Donc dites aurevoir à tous ces messages déplaisants qui vous empêchent de profiter d'un "beau" boot fait de Starting ADSL : done. ;-)
La version 1.1rc1 ne devrait pas tarder à faire son apparition sur le site mais pour cela il me faut régler un problème dans modem_run. Il semble que ce dernier bloque avec certains modèles de modems, c'est pourquoi je fais appel aux bonnes volontés pour tester le cvs, et m'envoyer leurs logs (modem_run utilise syslog) en cas de problèmes.
Pour les débianeux, dpkg-buildpackage vous sortira un beau package cvs (non officiel cad hors responsabilité du mainteneur debian du package) et pour les red hat/mandrake, make rpm devrait vous permettre d'obtenir un package rpm.
Que l'installation se déroule grâce à dpkg, rpm ou make install, les binaires sont dorénavant installés dans un répertoire sbin (/usr/sbin pour les packages, /usr/local/sbin pour la méthode make). Donc faites attention a votre PATH et à la version effectivement utilisée (en théorie le cvs utilise le numero de version fictif CVS_HEAD).
Les rapports de bugs concernant l'installation, la fabrication des packages ou autre petit problème de finition du driver sont les bienvenus sur notre site sourceforge à travers le système bug track.
Quant aux problemes liés à modem_run, envoyez moi directement le feedback avec les logs les plus significatifs possibles à ed dot gomez at wanadoo dot fr.
Voilà et peut être à bientôt pour une news concernant la version 1.1 du driver.
PS : ne pas surcharger ce pauvre DaCode avec vos retours sur le cvs. Merci d'avance pour linuxfr.org ;-) (bien lent aujourd'hui)
--
Edouard Gomez
[+] [^]Re: Question supplémentaire
Oui plutot > /dev/null 2>&1
Sinon la sortie d'erreur sort quand même à l'ecran.
Etienne
[^]Re: Question supplémentaire
Perso, j'utilise console=/dev/tty6, et ca le fait grave ;)
En revanche, bye bye les messages du noyau sur la première console.
J'utilise donc les log de syslog.
[^]Re: Question supplémentaire
Ohhh merci, je crois que c'est ça la solution !!!
console, ça se paramètre ou ? C'est une variable d'environnement ou ça se paramètre ailleurs ?
[^]Re: Question supplémentaire
C'est un des paramètres du noyau, tiens amuses-toi :
http://www.linuxhq.com/kernel/v2.4/doc/kernel-parameters.txt.html(...)