Re: recompilation noyau problèmatique
Tout bien pensé, et à la lueur des infos recueillies ici et là (pas de possibilité de recompiler les noyaux antérieurs à 2.6.20 avec les outils récents), j'aimerais tenter une démarche assez simple - j'espère qu'elle n'est pas trop naïve - mais pour laquelle j'ai besoin de vos conseils, s'agissant d'une liste de packages utiles. 1ère étape : apt get purge kernel-utils make gcc build-utils etc... 2 ième étape : vi /etc/apt/sources.list modifier ce fichier de façon à désactiver les liens vers des répertoires contenant des packages récents (stable, lenny, testing), ré-activer uniquement les répertoires de packages anciens (sarge) 3 ième étape : apt get install kernel-utils make gcc build-utils etc... 4 ième étape : avec ces nouveaux (anciens) outils, essayer la recompilation de mon noyau actuel (2.6.20-16-386) afin d'en exclure les fonctionalités audio incluses (c'est la but initial de la manip) Mais j'ai besoin de connaître la liste de tous les nouveaux packages que je dois désactiver et remplacer par les anciens. Merci d'avance pour votre contribution. Bernard wrote: Daniel Huhardeaux wrote: Bernard a écrit : Bonjour à tous, bonjour [...] Le plus simple serait sans doute que je recompile mon noyau d'origine '2.6.20-16-386' j'en doute fort: sudo aptitude search kernel-image p kernel-image-2.6.8-13-amd64-generic - Linux kernel image for version 2.6.8 on generic x86_64 systems p kernel-image-2.6.8-13-amd64-k8 - Linux kernel image for version 2.6.8 on AMD64 systems p kernel-image-2.6.8-13-amd64-k8-smp - Linux kernel image for version 2.6.8 on AMD64 SMP systems p kernel-image-2.6.8-13-em64t-p4 - Linux kernel image for version 2.6.8 on Intel EM64T systems p kernel-image-2.6.8-13-em64t-p4-smp - Linux kernel image for version 2.6.8 on Intel EM64T SMP systems v kernel-image-2.6.8-16sarge2-custom.1 Le noyau est donc 2.6.8 [...] 'make' retourne un message d'erreur que j'ai oublié [...] Et bien il s'agit peut être de l'information la plus importante ! ;-) Je me souviens avoir eu des soucis avec Sarge car il s'agissait de la migration vers udev je crois. Mais comme votre noyau est déją en 2.6.20, le problème doit venir d' ailleurs, vous avez bien réussi à le compiler et l'installer :-) Dans un autre forum, j'ai vu qu'il y avait des problèmes pour compiler les anciens noyaux (avant 2.6.26) avec les outils plus récents. A partir de 2.6.26, j'arrive bien à compiler sans erreur, mais les images que j'obtiens plantent au boot. J'ai passé des heures à examiner le peu de messages que je puis lire à l'écran (inutile de préciser qu'en cas de crash aucune logfile n'est produite), examiner, également, les logs des boot du noyau qui boote normalement, celui que je n'ai pas recompilé. Je pense que, vraisemblablement, le problème vient de mon mkinitrd qui génère une image qui ne convient pas. Dans /etc/mkinitrd.conf, j'ai trouvé le passage suivant : # Command to generate the initrd image. # MKIMAGE='mkcramfs %s %s /dev/null' this has been changed august 19, 2009 MKIMAGE='genromfs -d %s -f %s' La modif date de 3 jours... Il s'agit donc sans doute d'un fichier provenant d'un nouveau package update que j'ai fait ces jours derniers. Comme les messages aperçus à l'écran lors des crash faisaient référence à cramfs, j'ai eu l'idée de modifier cette mkinitrd.conf et de réactiver MKIMAGE='mkcramfs', et désactiver la ligne d'après. Après cela, les images que j'obtiens avec mkinitrd sont plus petites, leur taille se rapproche de celle de mes anciennes images. Ceci étant installé dans /boot/grub/menu.lst, le boot va plus loin que précédemment avant le crash... mais çà finit quand même par planter. J'ai fait des photos d'écran au moment des crash : http://www.teaser.fr/~bdebreil/bootcrash1.jpg et http://www.teaser.fr/~bdebreil/bootcrash2.jpg La première image provient d'un crash avec un noyau dans lequel j'avais compilé le RAID dans le noyau. L'examen des logfiles des boot qui marchent, m'ayant révélé qu'il est fait appel à des modules, j'ai refait une compil avec raid en modules. Et là çà va plus loin (voir seconde image), le raid se lance bien, mais ensuite il ne peut créer /devfs/vg-00 car il s'agit d'un read only filesystem. Ensuite : 'incompatible livedevmapper 1.01.00-ioctl and kernel driver' Y-a-t-il quelqu'un qui pourrait me dire quels packages purger, par quels packages plus anciens ou plus récents les remplacer, afin de me permettre de compiler un noyau qui soit bootable sur mon système Debian 3.1 Merci d'avance pour votre aide -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Re: recompilation noyau problèmatique
Daniel Huhardeaux wrote: Bernard a écrit : Bonjour à tous, bonjour [...] Le plus simple serait sans doute que je recompile mon noyau d'origine '2.6.20-16-386' j'en doute fort: sudo aptitude search kernel-image p kernel-image-2.6.8-13-amd64-generic - Linux kernel image for version 2.6.8 on generic x86_64 systems p kernel-image-2.6.8-13-amd64-k8 - Linux kernel image for version 2.6.8 on AMD64 systems p kernel-image-2.6.8-13-amd64-k8-smp - Linux kernel image for version 2.6.8 on AMD64 SMP systems p kernel-image-2.6.8-13-em64t-p4 - Linux kernel image for version 2.6.8 on Intel EM64T systems p kernel-image-2.6.8-13-em64t-p4-smp - Linux kernel image for version 2.6.8 on Intel EM64T SMP systems v kernel-image-2.6.8-16sarge2-custom.1 Le noyau est donc 2.6.8 [...] 'make' retourne un message d'erreur que j'ai oublié [...] Et bien il s'agit peut être de l'information la plus importante ! ;-) Je me souviens avoir eu des soucis avec Sarge car il s'agissait de la migration vers udev je crois. Mais comme votre noyau est déją en 2.6.20, le problème doit venir d' ailleurs, vous avez bien réussi à le compiler et l'installer :-) Dans un autre forum, j'ai vu qu'il y avait des problèmes pour compiler les anciens noyaux (avant 2.6.26) avec les outils plus récents. A partir de 2.6.26, j'arrive bien à compiler sans erreur, mais les images que j'obtiens plantent au boot. J'ai passé des heures à examiner le peu de messages que je puis lire à l'écran (inutile de préciser qu'en cas de crash aucune logfile n'est produite), examiner, également, les logs des boot du noyau qui boote normalement, celui que je n'ai pas recompilé. Je pense que, vraisemblablement, le problème vient de mon mkinitrd qui génère une image qui ne convient pas. Dans /etc/mkinitrd.conf, j'ai trouvé le passage suivant : # Command to generate the initrd image. # MKIMAGE='mkcramfs %s %s /dev/null' this has been changed august 19, 2009 MKIMAGE='genromfs -d %s -f %s' La modif date de 3 jours... Il s'agit donc sans doute d'un fichier provenant d'un nouveau package update que j'ai fait ces jours derniers. Comme les messages aperçus à l'écran lors des crash faisaient référence à cramfs, j'ai eu l'idée de modifier cette mkinitrd.conf et de réactiver MKIMAGE='mkcramfs', et désactiver la ligne d'après. Après cela, les images que j'obtiens avec mkinitrd sont plus petites, leur taille se rapproche de celle de mes anciennes images. Ceci étant installé dans /boot/grub/menu.lst, le boot va plus loin que précédemment avant le crash... mais çà finit quand même par planter. J'ai fait des photos d'écran au moment des crash : http://www.teaser.fr/~bdebreil/bootcrash1.jpg et http://www.teaser.fr/~bdebreil/bootcrash2.jpg La première image provient d'un crash avec un noyau dans lequel j'avais compilé le RAID dans le noyau. L'examen des logfiles des boot qui marchent, m'ayant révélé qu'il est fait appel à des modules, j'ai refait une compil avec raid en modules. Et là çà va plus loin (voir seconde image), le raid se lance bien, mais ensuite il ne peut créer /devfs/vg-00 car il s'agit d'un read only filesystem. Ensuite : 'incompatible livedevmapper 1.01.00-ioctl and kernel driver' Y-a-t-il quelqu'un qui pourrait me dire quels packages purger, par quels packages plus anciens ou plus récents les remplacer, afin de me permettre de compiler un noyau qui soit bootable sur mon système Debian 3.1 Merci d'avance pour votre aide -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
recompilation noyau problèmatique
Bonjour à tous, Sous Debian 3.1 (Sarge), j'ai besoin de recompiler un noyau afin d'en exclure la prise en charge du son. Mais voilà plusieurs jours que je suis là dessus, et ce ne sont que des échecs. Autrefois, sous RedHat 7.2, cela ne posait pas autant de problèmes. Il faut préciser que je suis en RAID1. Ma partition '/boot' est en /dev/md0 et en clair (ext3), montée à partir de /dev/sda1 (miroir /dev/sdb1). Ma partition '/' est montée à partir de /dev/sda2 et en miroir /dev/sdb2, sur /dev/md1 au format LVM2, et cela apparaît comme /dev/mapper/vg00-root. Cela fonctionne ainsi depuis des années sans problème. Le plus simple serait sans doute que je recompile mon noyau d'origine '2.6.20-16-386' en ne modifiant que la prise en charge du son dans le noyau ; pour la config, partir du fichier /boot/config-2.6.20-16-386 avec make oldconfig. Malheureusement, je n'y arrive pas, car ensuite 'make' retourne un message d'erreur que j'ai oublié, en rapport avec des fonctions non déclarées... Comme la compil fonctionne sans erreur avec des noyaux plus récents, j'en déduis que, dans mon répertoire /usr/src/linux-2.6.20-16-386, la Makefile est 'buggy', ou alors la version de 'make' dont je dispose n'est plus compatible avec cette Makefile là. J'avoue avoir sans doute un peu trop abusé des apt-get install sans avoir désactivé dans mon /etc/apt/sources.list les lignes en rapport avec des répertoires 'testing' et autres imprudences. Donc, je ne réussis pas à recompiler mon noyau 2.6.20-16-386. J'ai téléchargé le 2.6.20-17-386, mais j'obtiens les mêmes échecs. Alors qu'avec 2.6.26.2 çà compile sans erreur... à ceci près que je n'arrive pas à booter le noyau ainsi obtenu ! Ma méthode de compilation ne générant pas de initrd-img, j'ai dû en générer une à l'aide de mkinitrd, et je l'ai mise dans /boot/grub/menu.lst avec l'image du kernel... Voici ce que j'obtiens à la tentative de boot : le boot commence, tout défile très vite à l'écran comme à l'habitude, et pas moyen de lire grand chose jusqu'à ce que çà s'arrète... et, comme çà plante avant la fin, aucune logfile à consulter... Lorsque çà se bloque, je lis ceci : md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 device mapper . no filesystem could mount root. Tried: cramfs kernel panic - not syncing: VFS unable to mount root fs on unknown block(0,0) Alors j'ai refait une compil en désactivant raid0 dans la config, ne laissant que raid1... mais c'est le même plantage au final. Quelqu'un pourrait il me dire ce que je devrais sélectionner dans la config pour obtenir un nouveau noyau qui boot avec mon architecture RAID ? Je sais qu'il existe d'autres façons de compiler des noyaux pour Debian, notamment avec 'make-kpkg' mais cela ne fonctionne pas chez moi, sans doute à cause d'une version trop récente ou trop ancienne ; il m'est précisé qu'il me manque des paramètres, alors que les howto que j'ai vus n'en font pas mention. Alors je me cantonne à make menuconfig, make, ensuite su et make install, puis make modules_install. Au fait, j'ai remarqué que les initrd.img que j'obtiens avec mkinitrd sont environ 5 fois plus grosses que celle qui sert à booter mon noyau habituel. Je ne suis pas bien certain d'utiliser correctement mkinitrd ; je tape : mkinitrd -o initrd.img-2.6.26.2 2.6.26.2 ceci, à partir du répertoire /boot. Et là j'obtiens un message me précisant que cette image ne pourra pas prendre en compte le RAID et, par conséquent, elle ne pourra pas monter root. Si je tape la même commande en étant dans le répertoire /usr/src/linux-2.6.26.2 je n'obtiens aucune erreur, mais cela ne fonctionne pas non plus. Merci d'avance pour votre aide. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Re: recompilation noyau problèmatique
Bernard a écrit : Bonjour à tous, bonjour [...] Le plus simple serait sans doute que je recompile mon noyau d'origine '2.6.20-16-386' j'en doute fort: sudo aptitude search kernel-image p kernel-image-2.6.8-13-amd64-generic - Linux kernel image for version 2.6.8 on generic x86_64 systems p kernel-image-2.6.8-13-amd64-k8 - Linux kernel image for version 2.6.8 on AMD64 systems p kernel-image-2.6.8-13-amd64-k8-smp - Linux kernel image for version 2.6.8 on AMD64 SMP systems p kernel-image-2.6.8-13-em64t-p4 - Linux kernel image for version 2.6.8 on Intel EM64T systems p kernel-image-2.6.8-13-em64t-p4-smp - Linux kernel image for version 2.6.8 on Intel EM64T SMP systems v kernel-image-2.6.8-16sarge2-custom.1 Le noyau est donc 2.6.8 [...] 'make' retourne un message d'erreur que j'ai oublié [...] Et bien il s'agit peut être de l'information la plus importante ! ;-) Je me souviens avoir eu des soucis avec Sarge car il s'agissait de la migration vers udev je crois. Mais comme votre noyau est déją en 2.6.20, le problème doit venir d' ailleurs, vous avez bien réussi à le compiler et l'installer :-) -- Daniel -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Re: recompilation noyau problèmatique
Bernard a écrit : ... des noyaux plus récents, j'en déduis que, dans mon répertoire /usr/src/linux-2.6.20-16-386, la Makefile est 'buggy', ou alors la Ne serais-ce pas plutôt dans /usr/src/linux (avec linux = symlink vers linux-2.6.20-16-386) qu'il faudrait être... Ce symlink n'est pas fait que pour permettre de compiler plusieurs kernels, les scripts en ont besoin. -- I'm in Pittsburgh. Why am I here? -- Harold Urey, Nobel Laureate -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org