Je lance un sujet suite à deux mots échangés dans un autre sujet :
En fait je l’ai surtout fait “pour voir”, je pense que je n’ai pas encore le niveau pour jouer à ça normalement (à plus forte raison pas pour participer aux duels de compilation de KP2 et de dg-switcher :paf: ). Mais pour moi ensuite il suffisait d’ajouter une section dans le menu de grub pour booter sur le noyau de notre choix, et je pensais que c’était transparent pour le reste de la distribution :neutre:
J’ai manqué quelque chose (dans la phrase précédente j’entends, j’imagine que pour mon noyau expérimental c’est plutôt une option mal configurée qui est en cause…) ?
je sais que pour la debian, il faut en plus utiliser mkinitrd. C’est pas aussi le cas de ta distrib? Pour ma part, je n’utilise que mes noyaux fais à la main.
Il panique sur quoi? il trouve pas certains modules?
Je ne sais pas ce qu’est mkinitrd. Je sais qu’il existe un truc nommé initrd qui fait je ne sais pas encore quoi (mais dès que je verrai mon pote google je lui demanderai), et que le noyau que j’ai créé n’en avait pas, contrairement aux deux autres noyaux déjà présents dans /boot, qui avaient chacun un fichier initrd associé. Voici le contenu dudit dossier :
le mien c’est le “2.6.20sirb”. Constatant que je n’avais pas obtenu de “initrd.img-2.6.20sirb” à l’issue du “make install” après la compilation, je me suis contenté de modifier mon menu.lst pour y ajouter une section qui charge mon noyau en ignorant le initrd, comme ça :
Suite à ça j’arrive à “uncompressing Linux … OK, booting the kernel” puis (de mémoire) écran noir avec juste trois/quatres lignes en haut, dont le message d’erreur suivant (je l’avais noté, mon premier kernel panic :paf: ) :
Kernel panic - not syncing : VFS : Unable to mount root fs on unknown block (0,0).
une fois make modules_install fait, et dans /lib/modules
je fais un mkinitrd -o /boot/initrd.img-2.6.15.4-18feb06-386 2.6.15.4-18feb06
(2.6.15.4-18feb06 le repertoire associé dans /lib/modules au nouveau noyau).
je n’oublie pas de mettre à jour grub.
J’ai pas encore essayé le 2.6.20, mais j’utilise en ce moment le 2.6.19.2 et c’est nickel!
pour les vanillas et sur ma testing, j’ai jamais réussi à faire sans en ce qui me concerne. Sinon, je suis preneur de l’info. Toi tu utilises quels noyaux?
Je tournes toujours en unstable, et quand je n’utilisais pas kernel-package; donc avec les noyaux 2.4 de l’époque; je faisais un simple make;make install et un édit du bootloader.
Depuis je n’ai pas retenté, make-kpkg étant plus pratique
tu parles d’un temps que les moins de 30 ans ne peuvent pas connaitre! :paf:
plus sérieusement, il me semble que ça n’était pas indispensable à l’époque.
quand t’as pris l’habitude, ça va vite! un petit script, des noms bien choisis, et c’est rapide!
Quoi qu’il en soit, ta méthode est en effet plus “jolie”. Mais est-on obligé de changer de noyau à chaque version? pour ma part, avant le 2.6.19.2, j’étais en 2.6.17.8. Un noyau tous les 6 mois, y’a pire!
J’espere que Strider aura pu trouver l’aide qu’il cherchait.
Bye.
Euh tu recompiles le noyau que tu veux :neutre:
ça suit la même procédure que d’habitude, tu récupères les sources et tout, tu configures (make menuconfig, à l’ancienne) sauf qu’à la fin au lieu de faire make;make install tu fais make-kpkg [args] et ça compile pareil, sauf qu’au lieu de te faire un install qui te projette des modules partout ( :paf: ), ça te sors un *.deb qui est géré par dpkg.
Sinon ça [quote=""]
Kernel panic - not syncing : VFS : Unable to mount root fs on unknown block (0,0).
[/quote]
ça me le faisait quand je foutais la gestion de l’XFS en module :paf: (oui j’utilise des partitions en XFS)
J’ai vérifié : Mon problème était à première vue que le driver SATA (sata_nv) ne peut être inclus qu’en module (j’ignore pourquoi). D’où le non-fonctionnage du noyau.
mkinitrd n’est pas installé de base dans Ubuntu, je l’ai donc ajouté en installant le paquet initrd-tools, j’ai ajouté la ligne “sata_nv” au fichier /etc/mkinitrd/modules.
Ensuite je suis allé dans /lib/modules/linux-2.6.20sirb et j’ai fait un
ce qui m’a créé uneimage initrd que j’ai déplacée dans /boot.
J’ai remis à jour mon menu de démarrage GRUB pour qu’il prenne en compte mon image initrd, et j’ai rebooté.
Que s’est-il passé ? Votez par SMS au 3560*, et ceux qui auront trouvé la bonne réponse après la pub gagneront peut-être un fantastique baladeur mp3 sud-asiatique et l’intégrale de la Starac’ :paf:
Bon allez ne disons pas n’importe quoi. J’ai donc redémarré, et malheureusement la suite est encore pire qu’avant :paf:
J’ai une ou deux lignes qui mentionnent les images d’initrd et du noyau (probablement en provenance de grub ?), puis “Uncompressing Linux … OK, booting the kernel”. juste en-dessus j’ai un nombre décimal entre crochets, ça ressemble à ça :
[ 17.9657]
Et puis plus rien ne se passe. Quel est le probème à votre avis ?
Je confirme que debian boot très bien avec un noyau sans initrd.
Comme debian est obligé de tout compilé en module, ext3 compris pas exemple, ils ont besoin d’un initrd.
Si on compile ce qu’il faut pour booter en dur dans son noyau, l’initrd n’est pas nécessaire.
ubuntu a un boot graphique et si je ne me trompe pas ces chiffres sont utilises par le bootsplash pour la barre de progression.
A mon avis il te manque l’integration du bootsplash… spa evident de faire un noyau ubuntu :paf:
La fois où j’avais eu mon kernel panic il y avait deux trucs comme ça, suivies de texte. Enfin peu importe. Je vais essayer de virer l’option ‘splash’ de menu.lst pour voir si ça boote gentiment :jap:
EDIT : Pareil. J’ai fait l’expérience deux fois, le nombre affiché change, j’ai eu
15.852455
15.297355
Ca apparaît environ une seconde après "Uncompressing Linux … Ok, booting the kernel".
Quand je boote sur le noyau qui marche (celui d’Ubuntu) par contre il se passe environ 10 entre “Uncompressing Linux … Ok, booting the kernel” et l’apparition du logo ubuntu.
