Bonjour,
 
 suite à la découverte d'une instabilité du noyau offert par défaut dans la redhat 8, j'ai mis à jour via un RPM Redhat officiel (2.4.18-27smp, car j'ai un système multi processeurs) et quand je reboot sur le nouveau noyau j'ai l'erreur suivante :
-> "VFS: Cannot open root device"
 
Il me dit qu'il faut que je passe un parametre different dans LILO concernant le root directory
 
J'ai déjà tenté :
-> De copier l'ancien initrd dans le /boot pour le nouveau noyau -> Meme résultat
-> De ne pas passer le nom du root directory par LABEL mais par le nom de la partition
 
Meme résultat
 
Sachant que j'ai une Carte RAID smartArray 641, mon ancien noyau (2.4.18-14) monte le système parfaitement
 
Mais le 2.4.18-27 lui bloque.
 
Savez vous comment je peux m'en sortir ? Puis je modifier le config-2.4.18-27.8.0smp dans le /boot en toute securité ?
 
Merci

a prioris il ne trouve pas ta partition de boot, ca peut venir d'un ordre different de l'init des controleur par le kern, essaye de passer au boot un autre /dev/hdX, sinon soit tu nas pas le support de ta carte raid dans le kernel ou dans ton initrd. Tu peux toujours mounter ton sys avec un livecd et un chroot, puis recompiler ton kern

Oki. Dans mon ancien noyau, tout est OK. Je peux encore booter dessus. Helas ce noyau est instable. Donc, si je ne trouve pas une solution, je vais devoir passer ce serveur sous Win 2003 server, ce que je ne desire pas.
 
Donc, il va falloir que je recompile ce noyau, mais je n'ai pas les sources car c'est un rpm.
 
Y a t-il un autre moyen de s'en sortir ?
 
Merci

ben oui, tu va sur kernel.org, tu récupères les sources du dernier kernel stabel (2.4.23 de mémoire) et tu le compiles.
 
pour que ça soit plus facile : dans ton /boot, tu dois avoir un fichier config.qqchose
 
lorsque tu fera le make xconfig de ton nouveau kernel, tu immporte ce fichier, comme ça tu auras la même config qu'avec ton noyau "instable"

Je ne peux helas pas utiliser le 2.4.23, le produit client etant certifié que pour Redhat et le noyau 2.4.18

ca ne devrait pas changer grand chose, a moin que le produit ne soit un module kernel. A moin que ca vous pause des problèmes de garantie, accès au support ?

C'est mon chef qui ne veut pas, il ne veut rien savoir

ben c pas grave, tu prends la version que tu veux, c'est pareil (sauf que la série 2.4.18 a une faille qui n'est corrigée que dans le 2.4.23)

Ok.
 
J'ai trouvé le SRC.RPM
Je l'installe avec rpm -ihv
Maintenant j'ai les sources. Comme je n'ai pas X d'installé, je dois faire un make menuconfig.
 
Comment je fais pour reprendre la configuration initiale du noyau 2.4.18-14 qui detecte tout le matos ?
 
Merci

il a pas preconfiguré le .config su src.rpm ?
sinon il faut prendre le .config de l'ancien kernel, vu que tu nas pas les sources, je doute que tu l'ayes, mais certaines distrib le mette dans le /boot, a ce moment il suffit de recopier se fichier dans /usr/src/linux-<taversion>/.config
 
Par contre je pige pas, ca gene ton boos ou pas ?

ben tu dois avoir une option dans ton menuconfig qui te dit un truc du genre "load config from file", et là tu rentres le chemin complet pour accéder au fichier config de ton 2.4.18-14, qui doit se trouver dans /boot (j'ai la même redhat 8, je sais qu'il y est).
 
et zou, ça roule!

Pour le 2.4.18-27 non.
 
Par contre, excuses moi mon manque de culture àç ce sujet, mais le src.rpm n'est il pas sensé installer un tar.gz quand on lui fait un rpm -ihv ?
Je l'ai fait, et je ne retrouve pas la trace du noyau

dans /usr/src ??

J'ai cherché, pas trouvé

ben c pas grave!
 
tu fais (en root) : find / -type f | grep tar.gz
 
il devrait te le trouver

Aucun résultat
Je suis pas gaga, c'est bien un rpm -ihv nompackage.src.rpm qui faut faire, non ?

J'ai trouvé un bz2, mais il date de Fev 2002 alors que le patch date de Mars 2003

non, d'ailleurs! avec un src.rpm tu fais rpm --rebuild machin.src.rpm
 
après tu devrais trouver le rpm dans /usr/src/RPMS/RPMS et le sources dans /usr/src/RPMS/SOURCES

Ok je vais voir ce que je peux faire.
Pour info dans mon /boot j'ai les fichiers suivant :
config-2.4.18-14smp
initrd-2.4.18-14.img
 
Le premier fichier, c'est ce qui permet de charger la config de l'ancien noyau, c'est ça ?

as tu un initrd pour ton nouveau noyau (2.4.18-27) ?
 
si non, régénère le avec mkinitrd ; il me semble que ton pb vient du fait que la partition / se trouve à un endroit inaccessible pour le noyau comme une partition sur un controlleur dont la gestion est pas en dur mais en module.  
l'initrd inclus ces modules et est chargé par lilo (voir dans lilo.conf pour le charger) > règle ce genre de pb.  
 
note : tu ne peux pas juste copier l'ancien initrd, il faut le régénérer.

pour le fichier config, oui, c bien ça.
 
pour le initrd, vu que tu as installé ton -27 en rpm, il doit te l'avoir créé. Mais il est possible que tu aies mal configuré ton lilo. fais péter ton lilo.conf

Mjules>  
j'ai pas bien compris le truc en fait. Si je fais un mkinitrd, comment je fais exactement ? un  mkinitrd imagenoyau ?
 
Apres, dans le lilo, je rajoute quoi ? car en ce moment j'ai ça :
prompt
timeout=200
boot=/dev/cciss/c0d0
map=/boot/map
install=/boot/boot.b
message=/boot/message
linear
 
 
image=/boot/vmlinuz-2.4.18-14smp
     label=linux-smp
     initrd=/boot/initrd-2.4.18-14smp.img
     read-only
     append="root=LABEL=/"
 
image=/boot/vmlinuz-2.4.18-27.8.0smp
      label=linux-new
      initrd=/boot/initrd-2.4.18-27.8.0smp.img
      read-only
      append="root=LABEL=/"

Si je fais un mkinitrd vmlinuz-2.4.18-27smp, va t-il ecraser l'ancien initrd correct pour l'autre noyau ?  
J'ai un peu peur de tout faire peter

mkinitrd necessite que tu ayes deja compilé ton noyau et tes modules
ensuite si ma mémoire est bonne tu fais un mkinitrd /lib/modules/<ver de ton kern>, tu copies ensuite le fichier creer dans ton /boot
 
ensuite dans ton lilo tu rajoute les meme elements en renomant les parties necessiare (nom du kern, du initrd et le label)

tu es sûr que ton vmlinuz et initrd -27 sont bien dans /boot et portent ce nom?
 
c bizarre car ton lilo.conf semble correct (chuis pas un spécialiste de lilo, j'utilise grub perso)

Apparamment il bloque ici :
RAMDISK : Compressed image found at block 0
 
Puis plus rien

Une question, le mkinitrd, je dois le faire sur le noyau qui fonctionne ou le nouveau noyau que j'essaye d'installer ?

le nouveau, mais y'a pas de raison que celui fourni avec le rpm ne marche pas!

Ben ça marche pas
Je vais refaire une tentative :  
installer le noyau 2.4.18-27 en rpm avec l'option replacepkgs
ensuite faire mkinitrd
Modifier lilo et le mettre a jour via lilo -t
Si ça marche pas, je vais devoir me taper une compilation de noyau
 
Si ça marche pas d'ici ce soir, bye bye Linux et bonjour Windows Server 2003

ben ça serait bien dommage, c quand même pas la mort de compiler un noyau!

Euh, le System.map; il sert a quoi exactement ? Faut il aussi le modifier pour qu'il point sur le nouveau System.map.x du noyau ?

toutafé
 
--edit--
par contre, garde l'ancien dans un coin au cas où...

ça marche toujours pas
J'ai contacté le support de Redhat, j'ai tenté ceci :
mkinitrd --preload=scsi_mod  --with=scsi_mod monimage lenoyau
 
Voici en fait le message d'erreur :
 

pas d'erreur lors du mkinitrd ?

Non, mais je viens de voir (avec effroi) que le cciss.o n'existait pas dans /lib/modules/2.4.18-27smp  

Quand on rajoute un module (fichier.o) faut il faire quelque chose pour que le noyau le prenne en compte ?

depmod -a je crois

J'ai repris le module present dans le 2.4.18-14, et quand je fais un :
depmod -a -f /boot/System.map-2.4.18-27.8.0smp 2.4.18-27.8.0smp
(puisque je rappelle, ce n'est pas pour le noyau en cours d'execution !!!)
j'ai l'erreur :
depmod : *** Unresolved Symbols in /lib/modules/2.4.18-27.8.0smp/kernel/drivers/scsi/cciss.o

ça marche pas comme ça (déjà essayé ), il faut recompiler le module depuis les sources pour le nouveau noyau ( installes le kernel-source correspondant)

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à