Ce message fait suite à cette discussion, où le rôle de udev dans la vitesse de démarrage est abordé. Ayant des ennuis avec udev, je vais raconter ici :
- les ennuis que udev m'a apporté (démarrage et système très lent)
- ce que j'ai trouvé pour y remédier
- quelques considérations générales pour expliquer un peu plus ce que j'ai observé avec Arch et udev.
Ma vie
J'ai installé Archlinux à la fin de juin 2007. Aucun problème à relever dans les premiers temps : RAS. J'utilise la conf du noyau par défaut proposé à l'installation. J'ai trouvé quand même qu'au fur et à mesure des mises à jour, KDE devenait très rapide (j'y reviendrai). Puis, un beau jour, le démarrage s'est mis, de façon aléatoire, à devenir très lent : udev uevents prenait parfois plus d'une minute, HAL prenait alors quelques secondes à charger et tout le système était très lent au point d'en être quasi inutilisable.
Ceci se produisait environ 1 démarrage sur 5 et ne semble pas si rare que ça puisque le forum anglophone regorge de discussions à ce propos, et ce depuis quelques mois pour ne pas dire années...(sans commentaires !). Quelques bugs ont bien été ouverts et le dernier en date (http://bugs.archlinux.org/task/8878) a été fermé sans la moindre vérif : sans vouloir parler sans savoir, je trouve que ce problème récurrent et ennuyeux n'a l'air préoccuper aucun développeur.
J'ai bien trouvé une discussion récente sur leur mailing list (je n'ai pas conservé le lien) où un "problème" avec udev est évoqué, mais la dernières versions devaient avoir réglé le pb selon leurs dires (c'est là qu'on apprend que blacklister les modules dans le rc.conf peut ralentir le démarrage -on marche sur la tête...). J'ai essayé presque toutes les solutions évoquées à droite et à gauche : aucune ne fonctionne, inutile de vous fatiguer à les essayer (en particulier celles-ci et celle-ci).
La ubuntu de l'ordinateur de ma femme ayant fini d'achever toute la patience que je lui (=ubuntu) consacrais, je lui ai mis une belle petite Arch toute neuve. Et là, stupéfaction : sa machine fonctionne mieux que la mienne (nous avons 2 portables), alors que c'est la moins puissante !
Un peu dégoûté, mais plein d'espoir, je me dis qu'une réinstallation de la mienne ne me coûtera pas bien cher et devrait me débarrasser de ce pb avec udev. Et bien ce fut pire que tout, puisqu'au lieu d'être aléatoire, le pb devint systématique.
J'ai mis une semaine (j'avais décidé de m'entêter) à réinstaller Arch je ne sais combien de fois et à la triturer dans tous les sens pour trouver ce qui n'allait pas. Je n'ai pas résolu le pb (sinon j'écrirais à phrakture ou un autre), mais élaboré une solution qui donne toute satisfaction.
Une solution
Je donne ici directement une méthode fonctionnelle, les explications sont dans la troisième partie, pour les plus courageux.
Dans /etc/mkinitcpio.conf, on passe comme MODULES les seuls modules nécéssaires à la création de /, et en virant udev et autodetect des HOOKS :
Code : Tout sélectionner
...
MODULES="sd_mod pata_atiixp ata_generic reiserfs"
...
HOOKS="base pata scsi keymap filesystems"Bien vérifier dans le /etc/rc.conf que mod_autoload est fixé à "yes" et ça devrait rouler.
J'ai bien sûr tâtonné pour trouver les modules dont j'avais besoin, aussi, à partir d'un système qui fonctionne bon an mal an, il faut générer une image noyau spécifique à vos essais avec une entrée spéciale dans grub :
Code : Tout sélectionner
mkinitcpio -c /etc/mkinitcpio.conf.crashtest -g /boot/linuxtest.imgCode : Tout sélectionner
# (1) Arch Linux
title Arch Linux test
root (hd0,1)
kernel /boot/vmlinuz26 root=/dev/sda2 ro
initrd /boot/linuxtest.img
), redémarrez avec votre entrée par défaut et bidouillez votre mkinitcpio.conf.crashtest jusqu'au succès. Quand c'est bon, copiez ce fichier à la place de /etc/mkinitcpio.conf et générez l'image principale :
Code : Tout sélectionner
mkinitcpio -g /boot/kernel26.imgLe seul détail qui me reste à régler (mais ma science s'épuise) est que KDE est moins réactif que sur ma précédente installation (quand elle ne bugait pas bien sûr) et que sur la machine de ma femme. Là j'y comprend plus rien, malgré prelink & preload et le /etc/hosts modifié comme il faut : affaire à suivre.
Le pourquoi du comment
Je reviens ici sur quelques unes de mes affirmations précédentes, ainsi qu'un explication de ce que j'ai compris du fonctionnement des modules et de udev dans Archlinux. si je raconte des bêtises, dites-le (gentiment, de préférence
) !En utilisant mkinitcpio (ce qui est fait à chaque installation ou mise du jour du noyau), on dit, par le biais de mkinitcpio.conf, quels ingrédients doit contenir l'initrd chargé au démarrage du système. Les HOOKS disent quelles doivent être les grandes caractéristiques de cette image, et surtout quelles "familles" de modules doivent être installées.
La variable MODULES, elle, liste les modules qui doivent être chargés avant toutes choses, avec le noyau, et dans l'ordre donné (c'est équivalent à compiler les "modules" "en dur" dans un noyau perso).
Le hook udev intègre udev à cett initrd et dit au noyau d'utiliser udev pour choisir quels modules utiliser pour créer la partition racine : udev va les choisir dans ceux qui ont été installé, donc ceux qui (généralement) ont été choisis à l'installation du noyau par le hook autodetect pour coller à votre matériel, dans les familles listées (pata, scsi, filesystem...).
Quel est le rapport avec le chargement des uevents ? J'ai acquis la conviction que udevd et udev intégré dans le noyau kernel26 ne font pas bon ménage sur certaines machines. Le problème semble donc résider dans la gestion et l'appel des modules ad-hoc, et notamment ceux nécessaires à l'utilisation de la partition root. Le but du jeu de la solution expliquée plus haut est donc de laisser le système au maximum tel que conçu par les dev (avec le chargement automatique des modules par udevd) mais en l'orientant suffisamment pour éviter les conflits en ne lui laissant pas le choix des modules pour créer / . Donc il faut virer udev de l'image du noyau chargée au démarrage (j'ai bien dit dans la première que les bidouilles du rc.conf et des scripts de udevd sont inopérants) afin du lui dire quels modules charger (et que ceux là).
C'est là où enlever autodetect des hooks est intéressant (en tous cas sur ma machine) : il peut mal reconnaitre votre matériel et choisir pour vous des modules inadaptés. Les appeler dans MODULES ne servira alors à rien (c'est surtout ici que je peux me tromper). En tout cas je l'ai viré et je m'en porte très bien. J'ai peut-être trop de modules d'installés, mais ils ne seront jamais appelés.
Car il faut bien comprendre que ce HOOK ne dit pas au noyau de touver votre matériel au démarrage (ça c'est le rôle de udev lui-même), mais de trouver les modules à installer avec votre noyau qui correspondent à votre matériel. Il ne joue en rien sur la grosseur de l'initrd donc sur le temps de démarrage. Mais il peut apporter des ennuis sur certains protables (comme le mien).
Ensuite, les différentes façon d'accélérer udev au démarrage listées sur le wiki anglophone ne fonctionnent pas si vous avez ce problème. Elles ne font que chinter load_modules.sh, qui fait pourtant bien son travail quand les conditions sont correctes. En tous cas, à moins de 5 secondes de chargement des uevents, vous n'y gagnerez rien du tout.
Pour info, ce script est appelé par les règles de /etc/udev/rules.d/ (ce balayage des règles s'appelle précisément uevents).
Non, le problème est avec udevd lui-même. J'ai remarqué grâce à bootchart que udev uevents laggait quand deux instances de udevd étaient lancées au démarrage. Et quand cela ne se produisait pas, la séquence de démarrage était normale et le système "rapide". Voici mon message en anglais avec les images bootchart qui mettent bien ceci en évidence : http://bbs.archlinux.org/viewtopic.php? ... 45#p364345 (cette découverte n'a pas eu l'air de soulever les foules d'ailleurs).
Je suppose donc suite à tout ceci que udevd bugue face à un mauvais choix de modules et surtout lorsqu'une sorte de conflit a l'air de se créer entre les choix d'un noyau abandonné à udev et des load_modules.sh qui pédalent dans la semoule ? Je précise que j'ai essayé de comprendre les initscripts mais que ceux-ci me semblent hors de cause (contrairement à ce que j'affirme dans mon message en anglais).
Voilà, j'espère que tout ceci n'est pas trop fumeux ni prétentieux, et surtout que cela pourra en aider quelques uns (car j'ai été moi-même à deux doigts de changer de distrib).
, ils te changent tout...
