SINCE THERE HAS BEEN NO FEEDBACK OR INTEREST IN THIS SERIES, I HAVE DECIDED TO RETIRE IT. This will be our last look into the certification prerequisites. Last time, we looked at tips for compiling a kernel. This time around it is kernel run-time management and troubleshooting. The base Linux kernel sometimes needs a little help, that is where loadable kernel modules come in. (LKM). Just like the name suggests, these modules are loaded into the kernel as necessary. So they do not take up any memory when the kernel starts, they get loaded into memory only when called or needed. This may sound silly, but if the system does not have a parallel port, why load the parport module into memory? So, when last have you looked in the /lib/modules/ directory? That is where your kernel modules are stored. They are based on the kernel version, so quickly check it with uname. Are you still fresh on the switches for uname? Which switch would you use other than -a ? Yep, -r. OK great, you have been paying attention. Well that is the directory you need to navigate to and enter its sub-directory named kernel (if you are on a Red Hat based distribution). If at any time you feel lost, refer to the previous article on kernel compilation, as you should know this by now.
PUISQU'IL N'Y A JAMAIS EU NI RETOURS NI INTÉRÊT DANS CETTE SÉRIE, J'AI DÉCIDÉ DE L'ABANDONNER.
Celui-ci sera notre dernier regard aux prérequis d'une certification. La dernière fois, nous avons examiné des astuces pour la compilation du noyau. Cette fois-ci, ce sera la gestion du runtime du noyau et la résolution des problèmes. Le noyau de base Linux a parfois besoin d'un peu d'aide et c'est là où les LKM (loadable kernel modules ou modules chargeables du noyau) entrent en scène. Comme leur nom le suggère, ces modules sont chargés dans le noyau lorsque cela est nécessaire. Ainsi, quand le noyau démarre, ils n'accaparent pas des ressources mémoire, ils sont chargés en mémoire seulement quand ils sont appelés ou nécessaires. Ceci peut sembler idiot, mais, si le système n'a pas de port parallèle, pourquoi charger le module parport en mémoire ?
Alors, quand est-ce la dernière fois où vous avez regardé dans le dossier /lib/modules/ ? C'est là où les modules de votre noyau sont stockés. Ils sont spécifiques à la version du noyau, et vous devez donc rapidement vérifier cela avec uname. Connaissez-vous toujours bien les commutateurs pour uname ? Quel commutateur devriez-vous utiliser autre que -a ? Bien, -r. OK, c'est bon, vous avez suivi le cours avec attention. Il s'agit du répertoire où il faut aller, puis entrez dans le sous-répertoire nommé kernel (noyau) (si votre distribution est basée sur Red Hat). Si à quelque moment que ce soit vous vous sentez perdu, regardez l'article précédent sur la compilation du noyau, car vous devriez le savoir à ce stade.
Now some people will say kernel objects. The extension is “.ko” after all. Just be aware of this, but do not get hung up on terminology. If you need to add a pre-compiled kernel object, you need to be aware of the dependencies. That is number 1. Your system also needs to know these things. Our lives are, however, simplified by a nifty tool named depmod (module dependencies). Now, if you look at the man page for depmod, under description, you will see: “These dependencies can get quite complex.” You can run depmod from your home directory, you do not need to be in the modules directory. Again be aware of the differences between Debian-based systems path and Red Hat-based systems path. If you run depmod on its own, you get no output. If you would like some, use the -v switch. Quickly do a cat on the modules.dep file. You should see a whole bunch of .ko-files. This is all the detected modules on the system. You may need to scroll back a bit to see some kernel modules with a colon after them and more kernel modules after that. Like Windows services that depend on another service, this is how you find out which kernel module depends on which other kernel module. Anything BEFORE the colon depends on the listed modules AFTER the colon (very easy once you know it). Just like Windows services, multiple modules may depend on one module and vice-versa. You can do this on a modern release of Ubuntu, you do not need to be in your CentOS 5 VM. However, in your Ubuntu workstation, you will not find the “map” files mentioned. You will only find them in your CentOS 5 VM. Each ”map” file (eg. modules.serio.map) will map out the addresses to certain interfaces. Go ahead and cat module.serio.map, and peruse the output. So when you plug in a device, the kernel then can determine which device driver to load. You can think of these as lookup tables. That should demystify why the Red Hat systems have map files in the kernel folder. When you actually write kernel modules, you will have to include a header linux/module.h and linux/kernel.h, as well as macros, for things like licensing. All these are taken into account when you try to add a module.
Certaines personnes diront kernel objects. Après tout, l'extension est « .ko ». Il suffit de le savoir, mais ne vous attardez pas sur la terminologie. Si vous devez ajouter un kernel object pré-compilé, vous devrez être conscient des dépendances. C'est le numéro 1. Votre système doit connaître ces choses aussi. Toutefois, notre vie est simplifiée par un outil chouette, nommé depmod (les dépendances du module). Si vous regardez la page man pour depmod, dans la section description, vous verrez : « Ces dépendances peuvent devenir très complexes. » Vous pouvez lancer depmod à partir de votre répertoire personnel ; nul besoin d'être dans le répertoire des modules. À nouveau, il faut être conscient des différences de chemin entre les systèmes basés sur Debian et ceux basés sur Red Hat. Si vous exécutez depmod tout seul, il n'y a pas de résultat. Si vous en voulez, utilisez le commutateur -v. Et faites un cat rapide sur le fichier modules.dep.
Vous devriez voir une foule de fichiers .ko. Ce sont tous les modules détectés sur le système. Vous devrez sans doute remonter un peu pour voir quelques modules du noyau suivi d'un deux-points et d'autres modules du noyau après cela. Comme pour les services de Windows qui dépendent d'un autre service, c'est comme cela que vous trouvez quel module du noyau dépend de quel autre module. Tout ce qui s'affiche AVANT les deux-points dépend des modules listés APRÈS celui-ci (c'est très facile une fois que vous le savez). Tout comme pour les services Windows, de multiples modules peuvent dépendre d'un seul module, et vice versa. Vous pouvez faire cela sur une version récente d'Ubuntu ; pas besoin d'être dans votre machine virtuelle avec CentOS 5. Cependant, dans la station de travail d'Ubuntu, vous ne trouverez pas les fichiers « map » mentionnés. Vous ne les trouverez que dans votre VM avec CentOS 5. Chaque fichier « map » (par exemple modules.serio.map) mappera les adresses vers certaines interfaces. Allez-y, faites un cat module.serio.map et étudiez le résultat. Ainsi, quand vous branchez un appareil, le noyau peut déterminer quel pilote charger. Pensez-y comme des tables à consulter. Cela devrait vous dire pourquoi les systèmes Red Hat mettent les fichiers map dans le dossier du noyau. Quand vous écrirez en fait des modules pour le noyau, vous devrez inclure une en-tête linux/module.h et linux/kernel.h ainsi que des macros pour des trucs comme les licences. Toutes ces choses sont prises en compte quand vous essayez d'ajouter un module.
So how do we add or remove modules then? Why would we even want to remove any loadable kernel modules? Well, for one, it frees up memory. IOT is the current buzzword and usually IOT devices are spec’ed very low. But before we start removing modules, how about we look at them first? To list the currently installed modules, we remember back to LPIC level one and use the lsmod command. When you run the lsmod command, translate “used by” to “dependent on”, in your mind. That way you will know if a module can be removed safely or other modules or processes depend on it. It is a good idea to always check with lsmod, BEFORE using rmmod. This is especially true when using the -f switch, not that I ever advise you to use the -f switch. Now, if you have read the chapter in the book, you will know we have lsmod, rmmod and insmod. (yes, I know, but we are getting to it). Think of insmod as the dumb one. When you use insmod, you need the full path of where the particular module is. So we also need to know about modprobe and modinfo. Instead of telling you to peruse the manpages on this, I am going to suggest that you try bropages or cheat or even TL;DR. The modinfo command will list what you need to know about that particular module.
Alors comment ajouter ou enlever des modules ? De toute façon, pourquoi voudrions-nous enlever quelque module chargeable du noyau que ce soit ? Une raison est que cela libère de la mémoire. Le mot à la mode est actuellement IOT (Internet of Things, ou Objets connectés) et généralement les dispositifs IOT ont des spécifications minimes. Mais avant de commencer à enlever des modules, regardons-les d'abord, non ? Pour lister les modules actuellement installés, nous nous souvenons du LPIC niveau un et utilisons la commande lsmod. Quand vous lancez la commande lsmod, traduisez « used by » par « dependent on » dans votre tête. Comme cela, vous saurez si un module peut être enlevé en toute sécurité ou si d'autres modules ou processus en sont dépendants. C'est une bonne idée de vérifier toujours avec lsmod, AVANT d'utiliser rmmod.
C'est particulièrement vrai quand vous utilisez le commutateur -f ; mais je ne vous conseille jamais d'utiliser le commutateur -f. Bon, si vous avez lu le chapitre du livre, vous saurez que nous avons lsmod, rmmod et insmod. (Oui, je sais, mais nous y venons.) Pensez à insmod comme celui qui est bête. Quand vous utilisez insmod, vous devez connaître le chemin complet vers l'emplacement du module concerné. Ainsi, nous devons connaître modprobe et modinfo. Au lieu de vous dire de bien lire les pages man dessus, je vais vous suggérer d'essayer bropages ou cheat ou même TL;DR. La commande modinfo vous donnera tout ce qu'il faut savoir sur tout module précis.
For example type: modinfo psmouse The “filename” lists the full path for your pleasure. That license macro I mentioned earlier should be next, telling you what you can do with said module. This is very handy when you work with say, a libre-only distribution. Notice “depends”, as this is the module it would depend on, so you may need to install a module before this one, if it was not installed. So if you wanted to add the psmouse module, you would need to copy the “filename” path from modinfo (the .ko-file). Know that modinfo and modprobe work the same way. That’s why I say you should think of modprobe as the smart one. Put a blonde wig on insmod, if you cannot remember which is which. A fun command is to type: modprobe sams_brain (If Sam was the slow kid in class) and you should get back: “module sams_brain not found.” Go ahead and add and remove the dummy file, so you can get used to the way of doing things. Add the dummy file with insmod as well as modprobe, then remove it with rmmod and with modprobe. (You need to know both ways for the LPIC-201 exam).
Par exemple, tapez : modinfo psmouse
« filename » vous donne le chemin entier ! Le macro de la licence, que j'ai mentionné plus tôt, devrait venir ensuite, vous détaillant ce que vous pouvez faire avec le dit module. Cela est très utile quand vous travaillez avec, disons, une distribution uniquement libre. Notez les « depends », car c'est le module dont il dépendrait ; aussi, vous devrez peut-être installer un autre module avant celui-ci, s'il n'est pas déjà installé. Ainsi, si vous voulez ajouter le module psmouse, vous devrez copier le chemin « file name » à partir de modinfo (le fichier.ko).
Sachez que modinfo et modprobe fonctionnent de la même façon. c'est pourquoi je vous conseille de penser à modprobe comme étant celui qui est intelligent. Si vous ne pouvez pas bien distinguer les deux, mettez une perruque blonde sur insmod [Ndt : serait-ce une remarque sexiste ?!]. Une commande amusante est de taper modprobe sams_brain (le cerveau de Sam, si Sam portait le bonnet d'âne dans votre classe) et vous devriez avoir comme résultat : « module sams_brain not found ». Allez-y, ajoutez et enlevez ce fichier bidon, pour que vous puissiez vous accoutumer à la façon de faire les choses. Ajoutez le fichier bidon avec insmod aussi bien qu'avec modprobe, puis enlevez-le avec rmmod et avec modprobe. (Il faut connaître les deux façons de faire pour l'examen LPIC-201.)
One thing I skipped was the”parm” that you see in modinfo. This is actually parameters that you can specify when loading a module. Now one of the tricks , if you roll your own kernel, is to tweak some of these values, like resolution: 800 , for instance. Which you can use to match the dpi of your mouse. However, this is not a constant value, as after the next boot, the parameters are gone. You need to make these constant / permanent in another way. Sometimes you need to blacklist a module, like Nvidia, for instance. You will find those configuration files in /etc/modprobe.d/. If you look here, inside your Ubuntu desktop PC, you should see quite a few blacklist files. Feel free to “cat” out these files. Know that blacklist files take precedence. There is obviously a lot more here, but unless there is interest, next month we will start something new.
Une chose que j'ai sautée était le « parm » visible dans modinfo. Il s'agit en fait des paramètres que vous pouvez spécifier quand vous chargez un module. Un des trucs que vous pouvez faire, si vous compilez votre propre noyau, est l'ajustement de quelques-unes de ces valeurs, comme la résolution : 800, par exemple, que vous pouvez faire correspondre aux dpi de votre souris. Cependant, ce n'est pas une valeur constante, car, après le prochain démarrage, les paramètres auront disparu. Il vous les rend constants/permanents d'une autre façon. Vous devez parfois ajouter un module à la liste noire, notamment Nvidia. Vous trouverez ces fichiers de configuration dans /etc/modprobe.d/. Si vous regardez dedans, vous verrez sans doute pas mal de fichiers sur la liste noire à l'intérieur de votre ordinateur de bureau sous Ubuntu. N'hésitez pas à lancer « cat » pour ces fichiers et sachez que les fichiers sur la liste noire sont passés en priorité.
IL y a, bien évidemment, beaucoup plus à ce sujet, mais, à moins que de l'intérêt ne se soit manifesté, le mois prochain, je commencerai quelque chose de nouveau.
If you would like to jump ahead, or test your skills at an LPI exam, do a test paper here: https://www.itexams.com/exam/117-201 (These were once valid LPI questions and will ease you into the format.) • The new exam number is 201-400, and 117-201 was the old one. • The site does require signing up, but sign up with temporary email – not your real email. • DO NOT learn these questions parrot fashion, as they are probably not real exam questions. Let us know how you did – good or bad, it does not matter. ‘Good’ means you are ready to write and confident in your skills. ‘Bad’ means you will be learning new stuff!! Yay! There is no downside here. If you do not know why an answer is the way it is, contact us. As always, comments or corrections to: misc@fullcirclemagazine.org
Si vous aimez prendre de l'avance, ou tester votre dextérité pour un examen du LPI, faites un test sur papier ici : https://www.itexams.com/exam/117-201 (ce sont d'anciennes vraies questions du LPI et elles vous mettront à l'aise avec la formulation).
••Le numéro du nouvel examen est 201-400 et 117-201 était l'ancien.
••Le site nécessite une inscription, mais donnez un adresse mail temporaire, pas votre vraie adresse mail.
••N'apprenez PAS ces questions par cœur, car ce ne sont probablement pas les vraies questions de l'examen.
Faites-nous savoir votre résultat - bon ou mauvais, ça n'a pas d'importance. « Bien », ça signifie que vous êtes prêt pour l'écrit et confiant dans vos connaissances. « Mauvais », ça signifie que vous apprendrez de nouvelles choses ! Eh oui ! Ici, il n'y a pas de côté négatif ! Si vous ne connaissez pas les raisons pour telle ou telle réponse, contactez-nous.
Comme toujours, envoyez vos commentaires ou corrections à : misc@fullcirclemagazine.org