Problème de boot sur noyau 2.6.19
nourry
-
nourry -
nourry -
Bonjour,
je dois mettre en place une machine équipée d'un GNU-Linux temps réel (RTAI 3.5 patché sur noyau 2.6.19).
Je travaille sous Ubuntu 7.04 (2.6.20.16) avec un Intel Core 2 duo, disque SATA, 2 GB de ram, carte graphique ATI.
Mon problème se situe :
- soit au niveau de la création du RAMdisk :
une fois la commande " make && make modules &&
make modules_install && make install " achevée
la commande " mkinitrd -o /boot/initrd.img-2.6.19 2.6.19 "
me renvoie " warning: file sizes truncated to 16MB (minus 1 byte) "
J'ai vu qu'on pouvait élargir jusqu'à 256 MB la taille des RAMdisks en
recompilant mkcramfs, seulement tout comme pour l'installation de RTAI,
silence est fait sur la phase la plus ardue en ce qui me concerne : la compilation
(du moins sur les éléments nécessaires à son bon déroulement).
En réduisant le nombre de modules j'ai pu créer un RAMdisk sans erreur.
(ceci dit le problème n'est pas vraiment réglé)
- soit au niveau du boot sur le nouveau noyau :
Aprés avoir ajouter l'entrée dans le GRUB, le boot stoppe en m'annonçant " unknown_bootoption "
précédé de termes comme " ipipe, common interrupt, mwait, cpu_idle, start_kernel ".
Savez-vous à quel niveau se situe l'erreur ? Est-ce un ou des modules que je devrais désactiver ?
(j'ai suivi les recommandations de plusieurs ouvrages, les modules clés sont présents et d'autres
doivent être désactivés).
J'avais eu des problèmes avec des versions plus anciennes du noyau qui ne proposaient pas les modules
SATA comme ahci ou ata_piix. Je pense que le noyau actuel est suffisamment proche de celui de Ubuntu 7.04
pour que les fonctionnalités importantes soient présentes. Toutefois aucune certitude.
Est-ce une option au niveau du GRUB ? j'ai essayé avec " ro quiet splash " ou " ro single " ou encore
" ramdisk_size=(valeur) ". Sans succés.
Est-ce un problème de compilation ? d'architecture de la machine ? Je n'ai pas encore eu l'occasion de
tester sur une machine moins récente.
Une fois le problème résolu (soyons optimistes), je me ferai un plaisir de publier une démarche détaillée
de l'installation de RTAI sur une machine et avec des versions récentes.
Je vous remercie d'avoir pris le temps de lire ce texte, en espérant avoir respecter les règles du forum.
Antoine.
je dois mettre en place une machine équipée d'un GNU-Linux temps réel (RTAI 3.5 patché sur noyau 2.6.19).
Je travaille sous Ubuntu 7.04 (2.6.20.16) avec un Intel Core 2 duo, disque SATA, 2 GB de ram, carte graphique ATI.
Mon problème se situe :
- soit au niveau de la création du RAMdisk :
une fois la commande " make && make modules &&
make modules_install && make install " achevée
la commande " mkinitrd -o /boot/initrd.img-2.6.19 2.6.19 "
me renvoie " warning: file sizes truncated to 16MB (minus 1 byte) "
J'ai vu qu'on pouvait élargir jusqu'à 256 MB la taille des RAMdisks en
recompilant mkcramfs, seulement tout comme pour l'installation de RTAI,
silence est fait sur la phase la plus ardue en ce qui me concerne : la compilation
(du moins sur les éléments nécessaires à son bon déroulement).
En réduisant le nombre de modules j'ai pu créer un RAMdisk sans erreur.
(ceci dit le problème n'est pas vraiment réglé)
- soit au niveau du boot sur le nouveau noyau :
Aprés avoir ajouter l'entrée dans le GRUB, le boot stoppe en m'annonçant " unknown_bootoption "
précédé de termes comme " ipipe, common interrupt, mwait, cpu_idle, start_kernel ".
Savez-vous à quel niveau se situe l'erreur ? Est-ce un ou des modules que je devrais désactiver ?
(j'ai suivi les recommandations de plusieurs ouvrages, les modules clés sont présents et d'autres
doivent être désactivés).
J'avais eu des problèmes avec des versions plus anciennes du noyau qui ne proposaient pas les modules
SATA comme ahci ou ata_piix. Je pense que le noyau actuel est suffisamment proche de celui de Ubuntu 7.04
pour que les fonctionnalités importantes soient présentes. Toutefois aucune certitude.
Est-ce une option au niveau du GRUB ? j'ai essayé avec " ro quiet splash " ou " ro single " ou encore
" ramdisk_size=(valeur) ". Sans succés.
Est-ce un problème de compilation ? d'architecture de la machine ? Je n'ai pas encore eu l'occasion de
tester sur une machine moins récente.
Une fois le problème résolu (soyons optimistes), je me ferai un plaisir de publier une démarche détaillée
de l'installation de RTAI sur une machine et avec des versions récentes.
Je vous remercie d'avoir pris le temps de lire ce texte, en espérant avoir respecter les règles du forum.
Antoine.
A voir également:
- Problème de boot sur noyau 2.6.19
- Dual boot - Guide
- Hiren's boot - Télécharger - Divers Utilitaires
- Boot camp - Télécharger - Systèmes d'exploitation
- Clé boot windows - Guide
- Hiren's boot cd - Télécharger - Divers Utilitaires
5 réponses
C'est beaucoup plus simple que tout ça. Grosso modo tu fais ton make menuconfig et ensuite tu utilise la commande
Exemple
http://lea-linux.org/cached/index/Kernel-kernel_debian.html
Les deux commandes suivantes
correspondent respectivement au make clean et au "make && make modules"
Ca te génère un paquet debian (si tu as compilé par exemple /usr/src/linux-2.6.18, ca te génère un paquet debian dans /usr/src). Il ne reste plus qu'à l'installer
C'est tout :) Les modules sont mis aux bons endroits et le grub et mis à jour, il n'y a plus qu'à rebooter.
Bonne chance
make-kpkg
Exemple
http://lea-linux.org/cached/index/Kernel-kernel_debian.html
Les deux commandes suivantes
make-kpkg clean make-kpkg --revision=CUSTOM.1.0 kernel_image
correspondent respectivement au make clean et au "make && make modules"
Ca te génère un paquet debian (si tu as compilé par exemple /usr/src/linux-2.6.18, ca te génère un paquet debian dans /usr/src). Il ne reste plus qu'à l'installer
dpkg -i lefichier.deb
C'est tout :) Les modules sont mis aux bons endroits et le grub et mis à jour, il n'y a plus qu'à rebooter.
Bonne chance
C'est trivial à condition d'utiliser uniquement make-kpkg et dpkg. Sinon c'est beaucoup plus compliqué.
Es-tu arrivé à construire ton paquet .deb et à l'installer ?
Par exemple si tes sources sont dans /usr/src/linux, que donne
(normalement on doit voir apparaître le fameux .deb).
Sous linux il faut être patient, contrairement à windows il y a généralement une explication logique à un comportement bizarre.
Bonne chance
Es-tu arrivé à construire ton paquet .deb et à l'installer ?
Par exemple si tes sources sont dans /usr/src/linux, que donne
ls /usr/src
(normalement on doit voir apparaître le fameux .deb).
Sous linux il faut être patient, contrairement à windows il y a généralement une explication logique à un comportement bizarre.
Bonne chance
Tu as réussi à construire ton .deb ?
Tu l'as installé en faisant un :
Si oui, est ce que le plantage à lieu
- au niveau du grub : il ne trouve pas le kernel
- au niveau du boot : il plante en bootant. Auquel cas tu as oublié des choses dans ton noyau. Il faut les rajouter pendant le make menuconfig, désinstaller le paquet .deb associé au noyau foireux, recompiler ton noyau avec make-kpkg, et installer ce nouveau .deb.
Autre question, pourquoi ne pas directement installer un noyau tout prêt, qui plus est plus récent ?
Par exemple pour installer linux-image-2.6.20-15-386 :
Bonne chance
Tu l'as installé en faisant un :
dpkg -i /usr/src/lepaquet.deb
Si oui, est ce que le plantage à lieu
- au niveau du grub : il ne trouve pas le kernel
- au niveau du boot : il plante en bootant. Auquel cas tu as oublié des choses dans ton noyau. Il faut les rajouter pendant le make menuconfig, désinstaller le paquet .deb associé au noyau foireux, recompiler ton noyau avec make-kpkg, et installer ce nouveau .deb.
Autre question, pourquoi ne pas directement installer un noyau tout prêt, qui plus est plus récent ?
(mando@polgara) (~) $ apt-cache search linux-image | grep linux-image linux-image-2.6.20-15-386 - Linux kernel image for version 2.6.20 on i386 linux-image-2.6.20-15-generic - Linux kernel image for version 2.6.20 on x86/x86_64 linux-image-2.6.20-15-server - Linux kernel image for version 2.6.20 on x86/x86_64 ...
Par exemple pour installer linux-image-2.6.20-15-386 :
sudo aptitude install linux-image-2.6.20-15-386
Bonne chance
Encore merci mamiemando pour ton suivi,
GRUB trouve bien l'image. Effectivemment je pense qu'il y a un problème au niveau du menuconfig du noyau.
J'utilise la 2.6.19 car c'est la version la plus récente supportée par RTAI 3.5 (du moins j'essaye de faire simple, ils assurent le fonctionnement avec cette version, pas avec d'autres).
Quand tu parles d'installer un noyau tout prêt, tu veux dire que sa configuration minimale est déjà prête ?
Je pensais éviter les problèmes de configuration en récupérant la configuration de la machine actuelle (/boot/config-2.6.20-15).
Si j'arrive à booter avec le 2.6.20-15 je devrais pouvoir avec la 2.6.19. A moins qu'au lieu d'une option manquante ce soit une option en trop, càd présente dans la 2.6.20 et pas dans la 2.6.19.
GRUB trouve bien l'image. Effectivemment je pense qu'il y a un problème au niveau du menuconfig du noyau.
J'utilise la 2.6.19 car c'est la version la plus récente supportée par RTAI 3.5 (du moins j'essaye de faire simple, ils assurent le fonctionnement avec cette version, pas avec d'autres).
Quand tu parles d'installer un noyau tout prêt, tu veux dire que sa configuration minimale est déjà prête ?
Je pensais éviter les problèmes de configuration en récupérant la configuration de la machine actuelle (/boot/config-2.6.20-15).
Si j'arrive à booter avec le 2.6.20-15 je devrais pouvoir avec la 2.6.19. A moins qu'au lieu d'une option manquante ce soit une option en trop, càd présente dans la 2.6.20 et pas dans la 2.6.19.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Alors en fait il existe dans ton gestionnaire de paquet des noyaux précompilés (paquets linux-image sous debian et dérivés, sinon le paquet s'appelle kernel image). Dans ces cas là pas besoin de compiler de noyau, concrètement tu installes ça comme un paquet normal. Quand tu fais un make-kpkg tu construis en fait un paquet debian similaire, qui s'occupe notamment de corriger ton grub.
Sauf raison particulière (matériel non reconnue par le noyau standard, raison philosophique...) il est en général inutile de compiler son propre noyau. Il peut arriver qu'un paquet de source ait besoin de sources de noyau mais dans ce cas il suffit d'installer le paquet linux-header associé à ton noyau. Encore une fois il n'y a rien à compiler (un header déclare ce que peut faire ton noyau).
Dans ton cas le plus simple est donc de récupérer la dernière linux-image correspondant à ton architecture de processeur. Cf dans <8> les commandes apt-cache search et aptitude install.
Si tu veux absolument compiler un noyau, récupère le fichier .config situé à la racine des sources de noyaux qui généraient un noyau valide. Par exemple si tu passe d'un noyau 2.6.x à un noyau 2.6.y, copie le fichier .config depuis le répertoire de sources du noyau 2.6.x vers celui du noyau 2.6.y. En général la version 2.6.y est plus récente et au liue de taper
(qui génère un nouveau .config concrètement), on utilise :
(qui réutilise le .config présent à la racine et le corrige). Avec un peu de chance dans ton cas ça marchera. Dans cette phase de mise à jour il devrait te poser pas mal de question. Dans le doute prends le choix par défaut (indiqué en majuscule). Ceci fait, compile ton noyau avec make-kpkg (cf post <1>), et installe le avec dpkg (cf post <1>). Reboote dessus et tu verras bien si ça marche...
Bonne chance
Sauf raison particulière (matériel non reconnue par le noyau standard, raison philosophique...) il est en général inutile de compiler son propre noyau. Il peut arriver qu'un paquet de source ait besoin de sources de noyau mais dans ce cas il suffit d'installer le paquet linux-header associé à ton noyau. Encore une fois il n'y a rien à compiler (un header déclare ce que peut faire ton noyau).
Dans ton cas le plus simple est donc de récupérer la dernière linux-image correspondant à ton architecture de processeur. Cf dans <8> les commandes apt-cache search et aptitude install.
Si tu veux absolument compiler un noyau, récupère le fichier .config situé à la racine des sources de noyaux qui généraient un noyau valide. Par exemple si tu passe d'un noyau 2.6.x à un noyau 2.6.y, copie le fichier .config depuis le répertoire de sources du noyau 2.6.x vers celui du noyau 2.6.y. En général la version 2.6.y est plus récente et au liue de taper
make menuconfig
(qui génère un nouveau .config concrètement), on utilise :
make oldconfig
(qui réutilise le .config présent à la racine et le corrige). Avec un peu de chance dans ton cas ça marchera. Dans cette phase de mise à jour il devrait te poser pas mal de question. Dans le doute prends le choix par défaut (indiqué en majuscule). Ceci fait, compile ton noyau avec make-kpkg (cf post <1>), et installe le avec dpkg (cf post <1>). Reboote dessus et tu verras bien si ça marche...
Bonne chance
oui effectivement c'est ce que je fais à chaque fois (make oldconfig). Il faut bien comprendre que je dois impérativement compiler le noyau 2.6.19 avec le patch RTAI qui permettra ensuite à l'OS de fonctionner en temps réel strict (c'est le but de la manoeuvre).
Malheureusement aprés un make oldconfig, ce noyau ne boote pas, toujours l'erreur unknown_bootoption.
Il faut dire que j'ai été fiévreux ces derniers temps et je n'ai pas été trés efficace, ceci dit le problème reste entier. Il doit y avoir une option qui ne passe pas, mais alors tout tester un à un c'est du délire (et quand c'est ça l'informatique, ça me gave).
encore merci pour tes éclaircissements.
Malheureusement aprés un make oldconfig, ce noyau ne boote pas, toujours l'erreur unknown_bootoption.
Il faut dire que j'ai été fiévreux ces derniers temps et je n'ai pas été trés efficace, ceci dit le problème reste entier. Il doit y avoir une option qui ne passe pas, mais alors tout tester un à un c'est du délire (et quand c'est ça l'informatique, ça me gave).
encore merci pour tes éclaircissements.
j'avais entendu parlé de cette commande, j'ai essayé mais toujours le même résultat (à part que je n'ai pas de problème avec le RAMdisk, quoiqu'il m'affiche au premier boot "RAMDISK image too big ! ")
J'ai donc réduit le nombre de modules et c'est passé, par contre toujours ces lignes :
" unknown_bootoption "
" ==================== "
J'ai essayé de ne pas patcher le noyau, histoire de voir si l'erreur pourrait provenir de RTAI mais là j'obtiens :
" kernel_thread_helper "
" ==================== "
A noter que j'ai tout mis en dur, cela peut-il être une source d'erreur ?
Rassurez-moi, normalement c'est aussi facile que tout le monde le dit non ? Parce que je commence sérieusement à perdre patience, attendre trois plombes que tout ce petit monde se compile pour obtenir un plantage, comme on dit ça me saoule.