lors du boot de ma mandrake 9.2 il y a une blocage assez long sur
"recherche des dépendances des modules". est ce normal ? y a t-il un
moyen d'accélérer le boot ?
lors du boot de ma mandrake 9.2 il y a une blocage assez long sur
"recherche des dépendances des modules". est ce normal ? y a t-il un
moyen d'accélérer le boot ?
lors du boot de ma mandrake 9.2 il y a une blocage assez long sur
"recherche des dépendances des modules". est ce normal ? y a t-il un
moyen d'accélérer le boot ?
dav writes:lors du boot de ma mandrake 9.2 il y a une blocage assez long sur
"recherche des dépendances des modules". est ce normal ? y a t-il un
moyen d'accélérer le boot ?
Bonjour,
L'affichage correspond à la commande depmod -a. S'il y a
beaucoup de modules dans le système, ça peut prendre un
peu de temps (une dizaine de secondes ?).
Pour accélérer le boot, on peut désactiver cette commande
dans les scripts d'initialisation, puisqu'elle ne sert à
rien tant qu'on n'installe pas de nouveaux modules.
Par contre, n'ayant pas de Mandrake, je ne sais pas comment
procéder à la suppression de façon propre.
dav <dav49400@wanadoo.fr> writes:
lors du boot de ma mandrake 9.2 il y a une blocage assez long sur
"recherche des dépendances des modules". est ce normal ? y a t-il un
moyen d'accélérer le boot ?
Bonjour,
L'affichage correspond à la commande depmod -a. S'il y a
beaucoup de modules dans le système, ça peut prendre un
peu de temps (une dizaine de secondes ?).
Pour accélérer le boot, on peut désactiver cette commande
dans les scripts d'initialisation, puisqu'elle ne sert à
rien tant qu'on n'installe pas de nouveaux modules.
Par contre, n'ayant pas de Mandrake, je ne sais pas comment
procéder à la suppression de façon propre.
dav writes:lors du boot de ma mandrake 9.2 il y a une blocage assez long sur
"recherche des dépendances des modules". est ce normal ? y a t-il un
moyen d'accélérer le boot ?
Bonjour,
L'affichage correspond à la commande depmod -a. S'il y a
beaucoup de modules dans le système, ça peut prendre un
peu de temps (une dizaine de secondes ?).
Pour accélérer le boot, on peut désactiver cette commande
dans les scripts d'initialisation, puisqu'elle ne sert à
rien tant qu'on n'installe pas de nouveaux modules.
Par contre, n'ayant pas de Mandrake, je ne sais pas comment
procéder à la suppression de façon propre.
HG a écrit :
| On peut desactiver cette partie en commentant les lignes du test
| if [ -x /sbin/depmod -a -n "$USEMODULES" ]; then
| ...
| fi;
| [...]
Desactiver inconditionnellement depmod me parait dangereux. Comment
est-il lance ? depmod -A, equivalent a depmod --quick, ne regenere
modules.dep et autres que si un module est plus recent que les
fichiers existants. Est-ce que meme ca prend 10 secondes ?
| Donc pour se resumer il suffit soit de passer directement au boot
| l'option "nomodules" au kernel si on veut le faire au coup par coup
Je m'attendrais a ce que nomodules inhibe completement le chargement
des modules. Acceptable avec un noyau perso monolithique, mais il n'y
plus grand chose qui risque de fonctionner avec un noyau modulaire,
comme celui inclus par Mandrake.
HG <ghaouti@nospam.freenix.org> a écrit :
| On peut desactiver cette partie en commentant les lignes du test
| if [ -x /sbin/depmod -a -n "$USEMODULES" ]; then
| ...
| fi;
| [...]
Desactiver inconditionnellement depmod me parait dangereux. Comment
est-il lance ? depmod -A, equivalent a depmod --quick, ne regenere
modules.dep et autres que si un module est plus recent que les
fichiers existants. Est-ce que meme ca prend 10 secondes ?
| Donc pour se resumer il suffit soit de passer directement au boot
| l'option "nomodules" au kernel si on veut le faire au coup par coup
Je m'attendrais a ce que nomodules inhibe completement le chargement
des modules. Acceptable avec un noyau perso monolithique, mais il n'y
plus grand chose qui risque de fonctionner avec un noyau modulaire,
comme celui inclus par Mandrake.
HG a écrit :
| On peut desactiver cette partie en commentant les lignes du test
| if [ -x /sbin/depmod -a -n "$USEMODULES" ]; then
| ...
| fi;
| [...]
Desactiver inconditionnellement depmod me parait dangereux. Comment
est-il lance ? depmod -A, equivalent a depmod --quick, ne regenere
modules.dep et autres que si un module est plus recent que les
fichiers existants. Est-ce que meme ca prend 10 secondes ?
| Donc pour se resumer il suffit soit de passer directement au boot
| l'option "nomodules" au kernel si on veut le faire au coup par coup
Je m'attendrais a ce que nomodules inhibe completement le chargement
des modules. Acceptable avec un noyau perso monolithique, mais il n'y
plus grand chose qui risque de fonctionner avec un noyau modulaire,
comme celui inclus par Mandrake.
Daniel Dechelotte wrote in
news::HG a écrit :
| On peut desactiver cette partie en commentant les lignes du test
| if [ -x /sbin/depmod -a -n "$USEMODULES" ]; then
| ...
| fi;
| [...]
Desactiver inconditionnellement depmod me parait dangereux. Comment
est-il lance ? depmod -A, equivalent a depmod --quick, ne regenere
modules.dep et autres que si un module est plus recent que les
fichiers existants. Est-ce que meme ca prend 10 secondes ?
| Donc pour se resumer il suffit soit de passer directement au boot
| l'option "nomodules" au kernel si on veut le faire au coup par coup
Je m'attendrais a ce que nomodules inhibe completement le chargement
des modules. Acceptable avec un noyau perso monolithique, mais il n'y
plus grand chose qui risque de fonctionner avec un noyau modulaire,
comme celui inclus par Mandrake.
Je completai la reponse de Liu quant a vouloir inhiber la recherche des
dependances sur Mandrake sans repondre effectivement au probleme
initial. Le depmod -A (sans regeneration de modules.dep) utilisé sur une
Mandrake brute de fonderie prend du temps par la taille consequente en
standard de modules.dep. La solution pour optimiser cette phase, passe
donc par la recompilation du noyau avec juste les modules necessaires
voir a en inclure certains dans le noyau, ceci afin d'obtenir un
modules.dep minimal generé par le premier depmod lancé apres la
compilation et l'installation de ces nouveaux modules. Quant a l'option
nomodules, elle n'empeche pas le chargement de tous les modules, en tout
cas pas l'execution de /etc/rc.d/rc.modules qui charge ceux present dans
/etc/modules, ni les modules audio, lvm, ide-scsi, firewire, ... Par
contre certains modules risquent d'etre absents meme durant le boot (
ex. vfat pour le montage des partitions vfat ) situation que l'on peut
arranger en les redefinissant dans /etc/modules. Mais bon, il faut etre
coherent si on ne veut pas de modules ou si le temps de chargement de
ces modules un critere important autant opter pour un noyau personalisé.
cordialement,
HG
Daniel Dechelotte <maitre_yodan@fr.club-internet.invalid> wrote in
news:20040201160251.0a82960f.maitre_yodan@fr.club-internet.invalid:
HG <ghaouti@nospam.freenix.org> a écrit :
| On peut desactiver cette partie en commentant les lignes du test
| if [ -x /sbin/depmod -a -n "$USEMODULES" ]; then
| ...
| fi;
| [...]
Desactiver inconditionnellement depmod me parait dangereux. Comment
est-il lance ? depmod -A, equivalent a depmod --quick, ne regenere
modules.dep et autres que si un module est plus recent que les
fichiers existants. Est-ce que meme ca prend 10 secondes ?
| Donc pour se resumer il suffit soit de passer directement au boot
| l'option "nomodules" au kernel si on veut le faire au coup par coup
Je m'attendrais a ce que nomodules inhibe completement le chargement
des modules. Acceptable avec un noyau perso monolithique, mais il n'y
plus grand chose qui risque de fonctionner avec un noyau modulaire,
comme celui inclus par Mandrake.
Je completai la reponse de Liu quant a vouloir inhiber la recherche des
dependances sur Mandrake sans repondre effectivement au probleme
initial. Le depmod -A (sans regeneration de modules.dep) utilisé sur une
Mandrake brute de fonderie prend du temps par la taille consequente en
standard de modules.dep. La solution pour optimiser cette phase, passe
donc par la recompilation du noyau avec juste les modules necessaires
voir a en inclure certains dans le noyau, ceci afin d'obtenir un
modules.dep minimal generé par le premier depmod lancé apres la
compilation et l'installation de ces nouveaux modules. Quant a l'option
nomodules, elle n'empeche pas le chargement de tous les modules, en tout
cas pas l'execution de /etc/rc.d/rc.modules qui charge ceux present dans
/etc/modules, ni les modules audio, lvm, ide-scsi, firewire, ... Par
contre certains modules risquent d'etre absents meme durant le boot (
ex. vfat pour le montage des partitions vfat ) situation que l'on peut
arranger en les redefinissant dans /etc/modules. Mais bon, il faut etre
coherent si on ne veut pas de modules ou si le temps de chargement de
ces modules un critere important autant opter pour un noyau personalisé.
cordialement,
HG
Daniel Dechelotte wrote in
news::HG a écrit :
| On peut desactiver cette partie en commentant les lignes du test
| if [ -x /sbin/depmod -a -n "$USEMODULES" ]; then
| ...
| fi;
| [...]
Desactiver inconditionnellement depmod me parait dangereux. Comment
est-il lance ? depmod -A, equivalent a depmod --quick, ne regenere
modules.dep et autres que si un module est plus recent que les
fichiers existants. Est-ce que meme ca prend 10 secondes ?
| Donc pour se resumer il suffit soit de passer directement au boot
| l'option "nomodules" au kernel si on veut le faire au coup par coup
Je m'attendrais a ce que nomodules inhibe completement le chargement
des modules. Acceptable avec un noyau perso monolithique, mais il n'y
plus grand chose qui risque de fonctionner avec un noyau modulaire,
comme celui inclus par Mandrake.
Je completai la reponse de Liu quant a vouloir inhiber la recherche des
dependances sur Mandrake sans repondre effectivement au probleme
initial. Le depmod -A (sans regeneration de modules.dep) utilisé sur une
Mandrake brute de fonderie prend du temps par la taille consequente en
standard de modules.dep. La solution pour optimiser cette phase, passe
donc par la recompilation du noyau avec juste les modules necessaires
voir a en inclure certains dans le noyau, ceci afin d'obtenir un
modules.dep minimal generé par le premier depmod lancé apres la
compilation et l'installation de ces nouveaux modules. Quant a l'option
nomodules, elle n'empeche pas le chargement de tous les modules, en tout
cas pas l'execution de /etc/rc.d/rc.modules qui charge ceux present dans
/etc/modules, ni les modules audio, lvm, ide-scsi, firewire, ... Par
contre certains modules risquent d'etre absents meme durant le boot (
ex. vfat pour le montage des partitions vfat ) situation que l'on peut
arranger en les redefinissant dans /etc/modules. Mais bon, il faut etre
coherent si on ne veut pas de modules ou si le temps de chargement de
ces modules un critere important autant opter pour un noyau personalisé.
cordialement,
HG
