Archlinux.fr [Forums]

Hi .

Je compte utiliser Arch Linux - en fait, la distro est déjà installée - sur une machine qui me servira de mini-chaîne, qui ne lira pas de CD mais qui fonctionnera en réseau. J'ai déjà un disque dur de 40Go dessus, ce qui suffit pour le moment à stocker ma musique. Voilà ce qui sera lancé au démarrage :

- Serveur SSH
- Serveur MPD
- LCD4Linux

Normalement, c'est tout. Cependant, pour arriver jusqu'à l'invite de login (tty), je compte 47 secondes. Le timeout de GRUB est à 1 seconde. Et pour le moment, aucun daemon n'est lancé au démarrage... Si je pouvais descendre à 30 secondes, ce serait parfait, mais comment ?

Merci d'avance !

Il faut jouer avec le blacklist des modules.

Ton noyau charge trop de choses donc bloque ce qui est inutile dans ton rc.conf … ou compile ton noyau

Comment puis-je savoir quels modules blacklister ? En listant tous les modules que j'utilise, puis en blacklistant tout le reste ? Ce n'est pas un peu lourd comme solution ?

c'est quoi comme proc, parce que 47sec, c'est énorme pour peu que la machine soit pas trop vieille, meme avec un kernel d'origine.
sur un p4, ca met 25sec pour arriver sur gdm, alors 47 pour juste la console texte...

On arrive aux points qui fâchent . C'est un Celeron @ 1,3GHz épaulé par 192Mo de RAM. Je compte le temps à partir d'une pression du bouton Power.

Effectivement sur mon laptop, Celeron M @ 1,6GHz et 1Go de RAM, ça ne met que 25 secondes pour arriver à GDM .

Pareil, 28 sec pour arriver à SliM sur un Athlon 2200+
Bon, j'ai pas beaucoup de modules, mais quand-même.

Ça doit être à cause de la ram. J'ai 1 Go, un amd avec 2.2Ghz et ça prend à peine plus de 15 secondes jusqu'au tty.

Tu as quoi comme modules non commentés dans le rc.conf ?

1,3G, donc ca doit etre de la famille des p4...

je suppose qu'il est destiné à être accèssible depuis le réseau, tu es du coup obligé d'attendre la fin du lancement des daemons, par contre, si on oublie le réseau, tu mets la plupart des daemons avec @, ca devrait améliorer, après il reste la recompilation du noyau

C'est vrai qu'il y a beaucoup de modules au démarrage, la plupart des snd-* ; dès que j'ai installé une carte réseau (elle m'attend chez mon père ) je pourrai faire toutes les mises-à-jour et installer SSH pour vous faire un copier-coller.

un des modules qui peut facilement etre supprimé: udev. Tant que les modules sont configurés comme il faut dans /etc/rc.conf, et que la config materielle ne change pas, il est inutile.

Mais si j'etais toi, je rajouterais un peu de RAM (mettre le double, ca couterait vraiment pas grand chose) et je recompilerais le noyau, ca vaut le coup la comme tu sais que tu n'as pas besoin de grand chose sur cette machine.

Bonne chance

Hmm, personnellement, j'ai eu pas mal de pb avec udev et les modules ces derniers temps. Sur le forum anglophone, certains développeurs n'hésitent pas à dire que le blacklisting peut poser des problèmes dont le moindre est d'augmenter le temps de démarrage !

J'avais le pb récurrent (bizarre que personne n'en ait parlé dans ce forum) avec udev uevents qui lag au démarrage et fait que tout le système en est ralenti. J'ai donc réinstallé le système le week-end dernier et ça s'est révélé encore pire qu'avant...Une vraie catastrophe, j'ai failli abandonner Arch !
J'avais trouvé une solution de contournement en mettant à "no" le chargement automatique des modules dans le rc.conf et en les chargeant avec le noyau (le lister dans MODULES du mkinitcpio.conf) : ça donne une démarrage lent mais une machine utilisable.
Finalement j'ai trouvé une solution en listant dans le mkinitcpio les trois modules absolument nécessaires à la création de la partition root nors du chargement du noyau et en enlevant udev des HOOKS (ainsi que autodetect, qui peut foutre le brin).
J'ai remis l'autoload à "yes" dans le rc.conf et depuis, ça roule très correctement et mes démarrages sont plus rapides que jamais.

Donc; il semble qu'il puisse sur certaines machines (aucun pb sur la machaine de ma femme) udev ait des problèmes existentiels et le mélange udev noyau, MODULES du rc.conf, udevd et udev events ne fonctionnent plus correctement.
J'ai donc viré udev de l'initramfs, et depuis ça roule.

Clark a écrit :Hmm, personnellement, j'ai eu pas mal de pb avec udev et les modules ces derniers temps. Sur le forum anglophone, certains développeurs n'hésitent pas à dire que le blacklisting peut poser des problèmes dont le moindre est d'augmenter le temps de démarrage !

J'avais le pb récurrent (bizarre que personne n'en ait parlé dans ce forum) avec udev uevents qui lag au démarrage et fait que tout le système en est ralenti. J'ai donc réinstallé le système le week-end dernier et ça s'est révélé encore pire qu'avant...Une vraie catastrophe, j'ai failli abandonner Arch !
J'avais trouvé une solution de contournement en mettant à "no" le chargement automatique des modules dans le rc.conf et en les chargeant avec le noyau (le lister dans MODULES du mkinitcpio.conf) : ça donne une démarrage lent mais une machine utilisable.
Finalement j'ai trouvé une solution en listant dans le mkinitcpio les trois modules absolument nécessaires à la création de la partition root nors du chargement du noyau et en enlevant udev des HOOKS (ainsi que autodetect, qui peut foutre le brin).
J'ai remis l'autoload à "yes" dans le rc.conf et depuis, ça roule très correctement et mes démarrages sont plus rapides que jamais.

Donc; il semble qu'il puisse sur certaines machines (aucun pb sur la machaine de ma femme) udev ait des problèmes existentiels et le mélange udev noyau, MODULES du rc.conf, udevd et udev events ne fonctionnent plus correctement.
J'ai donc viré udev de l'initramfs, et depuis ça roule.

Pourrais-tu détailler STP ? ce sujet intéresse à coup sûr la plupart d'entre nous !
En donnant tes fichiers de conf, ça aiderait à la compréhension...
Merci !

Pour info, j'arrive a booter (xdm) en 33 secondes avec un eeePC, donc tu dois pouvoir ameliorer ca !

Si tu gardes udev, tu peux utiliser les astuces ici http://wiki.archlinux.org/index.php/Speedup_udev (j'ai choisi la seconde option).

Sinon, vire autodetect de ton initram (/etc/mkinitcpio.conf), tu gagneras quelques precieuses secondes.

Enfin, regardes combien de secondes mets udev pour se lancer (c'est ecrit lors du boot), et tu sauras combien tu peux gagner en le supprimant...

Je regarde ça dès que j'ai un moment... merci...

ok, l'option 2 n'est pas risquée, je l'appliquerai sans doute... mais bon, j'y gagnerai certainement peu, udev mettant actuellement moins de 6 secondes...

Concernant l'astuce de l'autodetect de l'initram, j'avoue être paumé... je vais donc probablement gagner du temps, mais quelle est la contre-partie ? qu'est-ce-que je perds ?

Cactus a écrit : Pourrais-tu détailler STP ? ce sujet intéresse à coup sûr la plupart d'entre nous !
En donnant tes fichiers de conf, ça aiderait à la compréhension...
Merci !

OK. Que AddiKT1ve ne m'en veuille pas, mais je crois que ça mérite un sujet à part entière, donc j'en ouvre un à l'instant et je reviens donner le lien.

Au passage, je crois que vous vous faites quelques fausses idées sur udev, les modules et leur fonctionnement dans Arch (à moins que ce ne soit moi qui n'ai rien compris ), donc je vous invite à suivre le guide pour mettre tout ça à plat et vous conter mes aventures : http://forums.archlinux.fr/post17045.html#17045

Bon, alors plusieurs tests sur une machine virtuelle (Host: Dell Latitude D430, 2Go de RAM, Intel Core 2 U7600, 1.2Ghz, Guest: 256Mo de RAM), je boot en 34 secondes, dont 6.3 pour udevd/uevents.

Conf:
Je recommence en essayant de "speedup udev" comme indique dans le wiki anglais.

Edit: suite a la manip' (appel direct a modprobe pluto que le script load-module.sh), je suis arrive a 30 secondes pour booter (5.9 secondes pour udevd/uevents).
Pour ces deux tests, le timeout de grub etait a 5 secondes et j'ai appuye sur "Entree"...