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