Reprise du message précédent :
Aie, si je recompile, je risque fort bien de ne plus avoir le support Redhat, ce que mon entreprise ne veut pas.
Si j'avais eu la liberte, j'aurais deja recompilé, mais là

Aie, je crois qu'on va passer a Windows 2003 (qui lui a passé tous les tests)
 
Franchement, j'aurais fait ce que j'ai pu

essaye de créer l'initrd toi-même, là il a pas mis le bon module dedans on dirait ou il y a un problème de dépendance (sg.o d'après les symboles, j'ai un module qui me l'a fait ce coup là), la marche à suivre :
 
tu boot bien sûr le noyau qui fonctionne
 
une fois arrivé à une console, tu fais :  

si rien ne s'affiche, c'est bon le module est impeccable, si tu vois au moins la ligne "depmod: *** Unresolved symbols in cciss.o", c'est cuit, tu as des erreurs dessus, donc c'est pour ça que ça ne passe pas au boot. Si tu n'as pas d'erreur, tu peux poursuivre...
 
maintenant on va reconstruire un initrd potable :
 
cd /boot
gunzip -S .img initrd-2.4.18-27smp.img
mount initrd-2.4.18-27smp /initrd -o loop
cd /initrd/lib
cp /lib/modules/2.4.18-27smp/kernel/drivers/block/cciss.o . (s'il te demande d'écraser, tu confirmes en validant "o" ou "y" )
cp /lib/modules/2.4.18-27smp/kernel/drivers/scsi/sg.o .
(ton éditeur préféré, ie emacs/vi) /initrd/linuxrc
tu dois avoir quelque chose qui ressemble à ça après modification :

ATTENTION : ne copie/colle pas bêtement ! il faut juste ajouter le chargement de "sg.o" et "cciss.o" comme ci-dessus, le real-root-dev peut être différent pour toi  
 
tu enregistres le fichier, ensuite tu fais :
 
rm -f /initrd/linuxrc~ (au cas où il y aurait un fichier de sauvegarde)
 
cd /boot
umount initrd-2.4.18-27smp
gzip -S .img initrd-2.4.18-27smp
 
voilà c'est fini, plus qu'à tester, à consommer bien cuit
ça arrive que mkinitrd se foute les pieds dans le plat, c'est la solution alternative qui au moins a le mérite d'être claire

Merci pour ton aide, mais j'ai bien un Unresolved Symbols
Il ne parle pas du module sg mais du module cciss.o
 
J'ai peut etre fait une betise : j'ai copié betement le cciss.o de l'ancien kernel sur le nouveau, me disant qu'en fait la difference entre ces deux noyaux etaient minimes. Dois je aussi copier l'ancien sg.o sur le nouveau noyau ?

ouhla ! très mal, on évite de mélanger les modules de kernel différents, surtout que RH compile ses noyaux avec le "Set version information on all module symbols", donc ça risque pas de se charger
 
le mieux à mon avis est que tu désinstalles le rpm : rpm -e kernel-2.4.18-27smp
ensuite tu réinstalles le rpm pour ton architecture : rpm -ivh kernel-2.4.18-27smp.ARCH.rpm
 
ensuite tu fais la manip du post précédent si besoin, mais ne mélange jamais les versions de modules

 
au fait c'est un .tar.bz2 sûrement qui va se loger avec les patchs dans /usr/src/redhat/SOURCES

Bon marche po
 
Apparemment c un bug du noyau 2.4.18-27

et t'en a pas un autre de noyal??  
 
si t'as le support redhat, c'est à eux de régler ça!

essaye un 2.4.20, ce sont des noyaux officiels RH, puis au moins tu bénéficieras du patch ptrace, parce que le 2.4.18 contient finalement 2 belles failles, tu ne peux pas perdre le contrat RH avec un noyau officiel, justement faut suivre les mises à jour, je ne vois pas ce qui pourrait poser problème
 
pour le 2.4.20, le dernier en date pour RH 8.0 :
 
edit : bon le voilà :
http://ftp.club-internet.fr/mirror [...] 8.i686.rpm

Merci tout le monde
 
On a pas reussi a trouver le pb mais on va repousser la date de decision su Switch vers Win2003 a la semaine prochaine.
D'ici la, on va essayer de trouver un compromis
A+