Re: recompilation noyau problèmatique

[Bernard <bdebreil@teaser.fr>]

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