Le Jeudi 5 Juin 2003 17:24, Jean-Fran�ois Tronche a �crit :
> Whouaaaaaa !! Tu l'as trouv�e o� la doc pour compiler comme �a ? Because le
coup du "/sbin/mkinitrd" j'en avais
> l'intuition (suite � un kernel panic de mes 2 kernels, l'ancien et le
nouveau, apr�s avoir fait saut� le "local
> APIC" du noyau. Mais comme il y a une d�pendance avec le module ibmphp.o, je
vais remettre l'option APIC en
> module, ce coup-ci, et en esp�rant que �a plante pas mon portable, comme
actuellement).
> Bref, un lien ? Parce que chez Mandrake, y'a rien, ou pas grand chose et sur
le guide de Delafond, c pas
> expliqu� comme �a.
> Merci !
Hoops, on ne s'emballe pas ! Ce second script a pour but de forcer une
installation d'un "bootimage" quand cette ex�cution ne s'est pas r�alis�e
correctement avec le premier script. En effet il m'est arriv� que apr�s
l'ex�cution de ce premier script un kernel panic apparaisse � l'amor�age, et
que cette situation soit d�finitivement r�par�e apr�s ex�cution du second
script. Le probl�me est que j'ignore ce qui se passe exactement avec ce
premier script, entre autres, sous quelles conditions s'ex�cute
"/sbin/mkinitrd" et c'est surtout l� que r�side le probl�me.
Il pourrait y avoir une explication beaucoup plus simple et surtout plus
satisfaisante pour l'esprit :
Si on ex�cute le premier script ainsi (et je l'ai d�j� fait par le pass� !):
su -c '/path_file/install_kernel'
avec le mot de passe de "root", alors on a un pb avec les commandes du type :
mkinitrd
lilo
ex�cut�es au cours du proc�dure et qui n'apparaissent pas explicitement dans
le script, car les ex�cutables sont situ�s sous "/sbin" qui, dans ce cas,
n'est pas dans $PATH, ce qui les rend inex�cutables !
Pour �viter ce probl�me on proc�de comme sugg�r� dans ma proc�dure :
- on se logge sous "root" (mais vraiment root avec son $PATH)
- on ex�cute :
$ '/path_file/install_kernel'
et dans ce cas pas de probl�me car "/sbin" fait partie du $PATH.
� quoi peut alors servir le second script "install_kernel_image" ? Tout
simplement � recompiler un "bootimage" correspondant � de nouveaux modules et
c'est bien l� encore un avantage de la compilation avec modules qui �vite de
se refarcir la compilation du noyau quand l'option "y" est pr�f�r�e).
Imaginons la situation suivante qui m'est arriv�e :
- j'ai une carte Tekram 395 (dont le sources du module n'est pas toujours
fourni avec le source du noyau) et dont le source du module n'est pas � jour.
- Je peux me procurer le source du nouveau module sur le site internet et
compiler ce module en faisant "make" dans le dossier correspondant (cette
compilation se fait bien en utilisant mon nouveau kernel puisque
"/usr/src/linux" pointe sur mon nouveau source du noyau).
- Je peux recopier (peut ne pas �tre n�cessaire si le "Makefile est bien
touill� ce qui n'est pas forc�ment v�rifi�) ce module sous
"/lib/modules/mon_nouveau_kernel/kernel/drivers/scsi" pour �craser l'ancienne
version du module.
� ce stade je n'ai pas termin� le boulot car mon "bootimage" n'est pas � jour,
ce nouveau module devant y �tre int�gr�. Il suffit alors d'ex�cuter
"install_kernel_image" sous root (voir remarque pr�c�dente).
Il est inutile de faire :
$ lilo
puisque l'option correspondante de "lilo.conf" est correctement renseign�e et
que vis � vis de la recompilation du module rien n'est � changer dans ce
fichier (je pense ne pas raconter de b�tises ici !).
Note : pour l'APIC qui tombe bien mal ici (heu... !) j'ai pos� une question
dans un autre message.
Voil�.
--
Daniel Moyne
(Nulix)-----------------------------------------------------------
Software : Mandrake 9.1 \\|// kernel "2.4.21-0.13mdk"
KDE 3.1.0 / --- \
(' o-o ')
--------------------------------oOO-(_)-OOo------------------------------------
Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
Rendez-vous sur "http://www.mandrakestore.com";.
Foire Aux Questions de la liste : http://mdk.mondelinux.org
