[Résolu]Recompil' capricieuse

J’ai recompilé mon noyau hier soir, normalement avec les options qui vont bien, en suivant le tuto de ash sur le forum. Jusqu’ici l’opération s’est toujours passée sans couac. J’ai téléchargé les sources pour le 2.6.22, fait mon make menuconfig, choisi mes options, lancé la compilo, bu 5 litres de café en attendant … la routine somme toute. Quand je passe près du pécé et que je vois que le proco est calme je regarde : super la compil’ est terminée. un ptit coup de dpkg -i linux-image-monkernelamoi.deb, reboot pour tester et la :
GRUB me lance mon nouveau ker normalement, le système commence gentiment à bouter et pis paf :
“Begin : Waiting for root filesystem” et puis plus rien …
En fait apparament si j’avais attendu quelquechose que 3 ou 5 minutes j’aurais eu droit à un message d’erreur “can’t find root filesystem on /dev/le_dd_du_systeme …”

En parallèle mon noyau 2.6.22 “générique” marche très bien (j’écris ce post depuis mon pc avec le 2.6.22 générique justement).

Au départ je me suis dit que c’était ptet un bête problème de driver parceque j’étais parti sur une recompil en mode “économies drastiques” (pas tant réussi que ca, m’enfin bon si un peu quand même, mon .deb de l’image fait 11.5 megs avec 8.3 à mon premier essai). Donc recompil encore mais en rajoutant des trucs et des machins concernant les options pata/sata, mais rien ny fait, j’ai toujours le même message.

“Bon bin on va google-er un peu tout ca alors”. Et grosso modo ca me donne des choses comme des problèmes de udev (pour un 2.6.15 je sais pas si c’est encore d’actu).
Ca parle aussi d’update-grub mais j’ai regardé mon menu.lst et la partoche qu’est censée faire bouter grub semble la bonne. (D’ailleurs le système commence à bouter avant de me pondre son erreur, il me charge meme la prise en charge radeonfb avant de me planter à la tronche je crois).
La dernière hypothèse trouvée c’est que initrd fait mal son boulot et “échange” les emplacements des divers lecteurs, et que donc après ca le noyau est un peu perdu.
La solution serait d’installer yaird, virer initramfs-tools, et enfin de faire un espece de machin du genre “yaird --output=/boot/initrd.img-2.6.18-4-686 2.6.18-4-686” mais avec ma version de ker à moi et tout et tout.

Ceci étant j’ai plusieurs questions :

  1. Ma recompil me pond un noyau qui apparament est un “386” (j’ai sélectionné l’option K8 côté compatibilité du proco vu qu’apparament c’est bien un génération k8 que j’ai), alors que mon précédent (le générique) est un “486”. C’est normal docteur ? Ca change quoi ?
  2. Comme cette machine est ma machine de travail je ne voudrais pas me retrouver avec un gros presse papiers format A4+ de près de 3 kilos si je me loupe, donc je voulais savoir si les solutions trouvées étaient crédibles et
    sans danger (genre si j’ai un problème je reboot je prends un ker qui marche avec GRUB et basta). Histoire de pas tomber en “chômage technique” dès les opérations terminées.
  3. Est-ce qu’en fait j’ai juste choisi mes options comme un bourrin et qu’en fait faut juste ajouter un truc dans les options de compil et que “pouf” ca va marcher.

Voili voila voilo comme il y a un paquet d’options pour recompiler j’aimerais autant ne pas les tester une à une si c’est juste lié aux options sinon ca risque de me prendre un peu de temps :smiley:.
Sinon y’a des gens qui ont deja eu le problème par ici ?

Merci d’avance pour vos réponses.

[quote=“Hoshin”]
Sinon y’a des gens qui ont deja eu le problème par ici ?
[/quote]Oui, moi et avec le m^ arrêt au m^ endroit.
Je cherche et si je trouve qq chose ds ma mémoire (la mienne, pas celle du PC :cry: ) je reviens.

Je ne trouve pas grand chose mais il me semble que j’avais modifié la famille du proc car en natif, il me mettait Pentium pro alors que j’ai un P4.
J’avais donc mis ‘Pentium 4’ et j’arrivais au m^ problème que toi.
J’avais refait une autre compil en laissant Pentium pro et je crois que c’est là que ça avait fonctionné.
Je ne suis pas sûr de ma mémoire mais vérifie quand m^ de ce côté.
Qu’as-tu ds “processor type & features” comme ‘processor family’ :question:

Ce problême correspond au fait qu’il n’a pas accés à la partition root, soit parcequ’on a oublié de compiler un module qui participe à cette lecture (ext, reiserfs, ide, ou autre), soit parcequ’on l’a mis en module, et qu’on a oublié d’appeler make-kpkg avec l’option --initrd.
Sinon encore, quand tu dis " J’ai téléchargé les sources pour le 2.6.22", tu as fait l’erreur d’aller les chercher sur kernel.org ? ben faut pas.
Sinon, pour affiner un noyau, il faut partir de la config standard, et nettoyer par bouts, en verifiant par des compils intermediaires que ça marche toujours, et en y allant à tous petits pas quand on touche à l’ATA.
Une fois que tu as une config affinée, tu peux l’utiliser pour les noyaux suivants, mais la première fois, faut faire trés doucement.

Ok ricardo bah je vais voir

@matt : nan je suis pas allé sur kernel.org, quand je dis que je l’ai téléchargé je veux dire que j’ai “installé” le .tar.bz via apt. Sinon concernant le nettoyage que j’ai fait jusqu’ici c’était plus pour virer les trucs du genre la prise en charge de l’ISA ou ce genre de trucs qui, vu ma bécanne, ne me servent pas (exit le support pour Token Ring par exemple). Sinon justement de peur de ne pas arriver à rebooter les changements au niveau de l’ATA ont été méga “light” pour ne pas dire inexistants.
Quand à la ligne de commande pour compiler elle doit ressembler à ca :

 make-kpkg --append-to-version "-lighter2" --initrd kernel_image modules_image kernel_headers

(du copier / coller du tuto de ash en fait mis à part l’append.)
Concernant les modules je vais y jeter un oeil vite fait mais en général ce que je faisais pour les modules qui me paraissaient sensibles c’est que je leur mettais le flag “built in” quand ca me concernait. Mais encore une fois j’ai très peu touché à tout ca. Je vais aller re-jeter un oeil et pis je ferais 2 ou 3 modifs ce soir avant de relancer une compil’ (de toute facon demain j’aurais plein de temps pour faire des tests vu que je pense rester chez moi plutot que de tenter le metro / RER sur 20 allant jusqu’a ma fac XD.

Edit : Ricardo : dans “Processor Type and features -> Processor Family” j’ai coché “Opteron/Athlon64/Hammer/K8”. Vu que mon lspci me donne :

00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control

Edit 2 : Concernant l’ATA, dans la rubrique “Device Drivers -> ATA/ATAPI/MFM/RLL support” l’option “ATI IXP chipset IDE support” est bien cochée (en module seulement je peux pas “faire mieux”), enfin en fait dans ces rubriques la j’ai tout laissé coché “comme c’était” en général.
Bref ce soir je reprends mon lspci pour être sur de rien avoir laissé trainer. Sinon bah si ca reboot toujours pas après qqs modifs pour l’ATA je changerais le type de proco et pis on verra bien ^^.
Je vous tiens au courant.

Alors, apparament ce n’est pas le type de proco qui pose problème (j’ai fait une recompil’ avec juste cette option et j’ai bouté sans problème après). Je vais me faire un .config sans du tout toucher à l’ATA et pis voir ce que ca donne maitenant .

Bon, tout d’abord désolé de déterrer ce post. Mais j’ai exactement le même problème avec le kernel 2.6.24 !
J’ai pris les sources depuis le site de Debian, j’ai réussi à compiler la version “par défaut”, c’est-à-dire la 2.6.18 qui tourne nikel, tout ça en suivant scrupuleusement le tuto donné sur le site pour compiler un kernel. Mais rien à faire avec le 2.6.24.

Est-ce que quelqu’un a trouvé une solution depuis le temps ?? Ca me ferait énormément plaisir car là je suis obligé de rester sur mon kernel d’origine ce qui ne me convient pas pour diverses raisons.

EDIT : à défaut, si vous avez réussi à installer un kernel supérieur au 2.6.24, comment avez-vous fait ? Merci !

Salut

moi j’ai compiler un 2.6.25 avec patch RT préemptif avec ce tuto

http://forums.debian.net/viewtopic.php?t=17035

Si ça peut t’aider. :smt006

[quote=“getdr”]Salut

moi j’ai compiler un 2.6.25 avec patch RT préemptif avec ce tuto

http://forums.debian.net/viewtopic.php?t=17035

Si ça peut t’aider. :smt006[/quote]
Le seul truc fondamental qui change entre ce que j’ai fais et ce qui est sur la page que tu m’as donné c’est que j’ai mis ça (ce qui est indiqué dans le tuto sur notre forum) :

make-kpkg --append-to-version "custom-XXX" --initrd kernel_image modules_image kernel_headers
et que dans ton tuto ils donnent ça :

make-kpkg --initrd -rev mz1 kernel_image kernel_headers kernel_source

Je pense que le “-rev” n’est pas important ?

Le “kernel_image” reste dans les 2 cas, le “kernel_headers” aussi, par contre le “modules_image” joue peut être un rôle important ? Je ne sais pas à quoi il sert. Pareil pour le “kernel_source”, je ne sais pas à quoi il sert non plus.

Bon, pour make-kpkg, il peut produire jusqu’à 4/5 .deb:

  • kernel-image (le noyau avec ses modules)
  • kernel-headers (le paquet de headers, inutile si tu laisse l’arborescence de sources de ton noyau en place aprés avoir compilé)
  • kernel-source (un réempaquetage des sources, avec le .config modifié, et éventuellement les patchs qu’on a pu appliquer entre temps, même remarque d’utilité si on laisse les sources en place)
  • kernel-doc,kernel-manual (les pages de manuel et la documentation du noyau).

Tu peux donc produire le .deb en fonction de tes besoins (en général kernel-image est suffisant), et tu peux les produire tous d’un coup avec make-kpkg buildpackage.

make-kpkg --targets te donnera l’ensemble des cibles possibles.

Sinon, si vous avez bien vérifié que les modules se chargeaient et que ça s’arrète au moment de la partition root que le noyau ne trouve pas, c’est qu’il y a une variation sur la manière dont / s’appelle (genre hda1 -> sdb1, etc…). On peut essayer de changer manuellement au boot dans grub pour tester, et si ça marche, il y a moyen de dire ensuite dans le menu.lst à update-grub “si c’est un noyau <2.6.22 utiliser hda1 comme root, sinon, utiliser sda1”.
Le vidage de /etc/udev/rules.d/60-persistent-storage.rules peut aussi aider.

[quote=“mattotop”]
Sinon, si vous avez bien vérifié que les modules se chargeaient et que ça s’arrète au moment de la partition root que le noyau ne trouve pas, c’est qu’il y a une variation sur la manière dont / s’appelle (genre hda1 -> sdb1, etc…). On peut essayer de changer manuellement au boot dans grub pour tester, et si ça marche, il y a moyen de dire ensuite dans le menu.lst à update-grub “si c’est un noyau <2.6.22 utiliser hda1 comme root, sinon, utiliser sda1”.
Le vidage de /etc/udev/rules.d/60-persistent-storage.rules peut aussi aider.[/quote]
Normalement mon root est sur sda6. J’ai vérifié que c’est bien ce que j’avais dans Grub et pas de problème.
J’ai donc commenté la ligne de initrd et j’ai rebooté pour voir, là il bloquait bien avant sans explication aucune. De plus quand je remonte dans les logs de d’habitude je vois bien qu’il me charge des composants d’initrd, c’est donc qu’il le trouve.

A quoi sert ce fichier ?

Quand il détecte un périphérique pour la première fois, udev génère une entrée dans ce fichier ou il lui associe un nom qui est théoriquement réutilisé même si tu changes la disposition des supports. Mais ça peut merder. Regardes son contenu tu comprendras mieux.

Ah OK, parce que j’ai vu que souvent ça pouvait venir de udev et des problèmes de nommage de disques et de partitions. Mais c’est généralement quand on passe d’un vieux kernel (genre 2.6.8 ) à un plus récent (2.6.18 par exemple).

Une autre piste que j’ai retrouvé sur plusieurs topic et qui semble avoir résolu le problème à chaque fois, quand Grub était malgré tout bien configuré : il faut virer “initramfs-tools”, installer “yaird” à la place, et recréer l’image “initrd.img” via “yaird”. Cela proviendrait d’un problème de compatibilité entre “initramfs-tools” et “udev”.
J’essaye ça ce soir en rentrant et je vous dis ce qu’il en est.

Bon, j’ai à moitié résolu le problème ! :slightly_smiling:

J’ai recompilé en utilisant “yaird” à la place de “mkinitrd” qui était invoqué par défaut au moment de la compilation du kernel, après modification du fichier de configuration du kernel et installation de “yaird” (je vous détaillerai la totalité des manips quand j’aurai réussi à résoudre 100% de ce topic :smt003 ).
Donc je n’ai plus le message “Waiting for root file system” !

Cette erreur provient en fait d’une incompatibilié de “mkinitrd” avec “udev” qui a remplacé “devfs”, car “mkinitrd” a été écrit pour être compatible avec “devfs” et n’a pas été correctement mis à jour, et donc quand on demande à “mkinitrd” de créer une image, il nous sort un truc buggué avec “udev”. “yaird” quant à lui ne tourne que sur les kernels 2.6.x (et espérons sur les suivants 2.x.x), mais comme “mkinitrd” n’est buggué qu’à partir du kernel 2.6.20 si je me souviens bien, il n’y a aucun problème.

Mais… j’ai maintenant une autre erreur ! (et là je pense que plus d’une personne saura m’aider, les kernel panic ça vous connaît non ? :smt005 )

En temps normal quand tout fonctionne, tout mon système Debian se trouve sur la partition “sda6”.
Voilà ce que j’obtiens :

Freeing unused kernel memory: 296k freed
SCSI subsystem initialized
Driver 'sd' needs updating - please use bus_type methods
/bin/cat: /sys/block/sda/dev: No such file or directory
Waiting 1 seconds for /sys/block/sda/dev to show up
/bin/cat: /sys/block/sda/dev: No such file or directory
Waiting 2 seconds for /sys/block/sda/dev to show up
/bin/cat: /sys/block/sda/dev: No such file or directory
Waiting 4 seconds for /sys/block/sda/dev to show up
/bin/cat: /sys/block/sda/dev: No such file or directory
Waiting 8 seconds for /sys/block/sda/dev to show up
/bin/cat: /sys/block/sda/dev: No such file or directory
Waiting 16 seconds for /sys/block/sda/dev to show up
/bin/cat: /sys/block/sda/dev: No such file or directory
Device /sys/block/sda/dev seems to be down.
/bin/mknod: missing operand after `b'
Special files require major and minor device numbers.
Try `/bin/mknod --help' for more information.
/bin/cat: /sys/block/sda/sda6/dev: No such file or directory
Waiting 1 seconds for /sys/block/sda/sda6/dev to show up
/bin/cat: /sys/block/sda/sda6/dev: No such file or directory
Waiting 2 seconds for /sys/block/sda/sda6/dev to show up
/bin/cat: /sys/block/sda/sda6/dev: No such file or directory
Waiting 4 seconds for /sys/block/sda/sda6/dev to show up
/bin/cat: /sys/block/sda/sda6/dev: No such file or directory
Waiting 8 seconds for /sys/block/sda/sda6/dev to show up
/bin/cat: /sys/block/sda/sda6/dev: No such file or directory
Waiting 16 seconds for /sys/block/sda/sda6/dev to show up
/bin/cat: /sys/block/sda/sda6/dev: No such file or directory
Device /sys/block/sda/sda6/dev seems to be down.
/bin/mknod: missing operand after `b'
Special files require major and minor device numbers.
Try `/bin/mknod --help' for more information.
mount: special device /dev/sda6 does not exist
Switching root ...
/usr/lib/yaird/exec/run_init: current directory on the same filesystem as the root: Success
Kernel panic - not syncing: Attempted to kill init!

D’après les topics que j’ai trouvé en googlisant, le message “Driver ‘sd’ needs updating - please use bus_type methods” n’a pas d’effets sur le système. Mais là, permettez moi d’en douter tout de même !

Maintenant, voilà ce que j’ai essayé pour résoudre le problème :
[ul]

[li]J’ai recompilé tout mon noyau en prenant soin d’activer en dur tout ce qui pouvait toucher à la prise en charge des disques SCSI, et ça n’a absolument rien changé.[/li][/ul]
[ul]

[li]J’ai modifié le fichier “/boot/grub/menu.lst” pour chercher l’image sur “sda9” (qui n’existe pas) au lieu de “sda6”, et j’obtiens exactement la même erreur, il me dit toujours que “sda6” n’existe pas. Donc je serais tenté de dire que c’est là que ça coince ! Car si en mettant une partition qui n’existe pas à coup sur il continue de me dire la même chose sans me rajouter d’erreurs supplémentaires, c’est que pour lui “sda6” ou “sda9” dans Grub c’est la même chose ! Il ne trouve pas “sda6” de la même manière qu’il ne trouve pas “sda9” (sauf qu’avec “sda9” c’est normal). Donc je vais tester la méthode des labels pour les partitions comme décrit dans ce post : viewtopic.php?f=3&t=9933. Si ça ne fonctionne pas alors je risque d’avoir vraiment du mal à résoudre le problème :confused:[/li][/ul]

Je compte en partie sur vous, car après avoir fait pas mal de recherches sur Google, je n’ai rien trouvé de bien convainquant. Si vous avez déjà eu un problème similaire, bien évidemment criez le ici. Si vous avez une idée, une piste, n’hésitez pas.

EDIT : d’après ce qui a été dit précédemment, je vais également voir dans le fichier “/etc/udev/rules.d/60-persistent-storage.rules” s’il n’y a pas quelque chose à exploiter.

Il me vient une question con: vous prenez bien vos paquets udev, votre noyau, et le constructeur d’initrd qui va avec (yaird,mkinitrd,mkinitramfs) dans la même release ?
Pas d’hétérogènéité ?

Parceque sinon, essayez de vous rendre homogènes, puis reinstallez le noyau qui fait chier (même s’il est toujours là): il y a des chances que ça passe comme ça.

[quote=“mattotop”]Il me vient une question con: vous prenez bien vos paquets udev, votre noyau, et le constructeur d’initrd qui va avec (yaird,mkinitrd,mkinitramfs) dans la même release ?
Pas d’hétérogènéité ?

Parceque sinon, essayez de vous rendre homogènes, puis reinstallez le noyau qui fait chier (même s’il est toujours là): il y a des chances que ça passe comme ça.[/quote]
Et bien figure toi qu’en voulant donner la réponse à ce post : posting.php?mode=reply&f=3&t=15365
et que je ne me souvenais plus des lignes de commandes et que Google.fr ne fonctionnait pas chez moi ce soir, je suis allé sur Yahoo! et je suis tombé sur ce document : debian.org/releases/stable/i … ex.fr.html
où il est dit ceci au paragraphe 2.3.2 :

[quote]2.3.2 Nouveaux utilitaires pour générer les initrd

Les paquets d’image de noyau Debian pour Intel x86 nécessitent un initrd pour amorcer le système. À cause de changements dans le noyau, l’utilitaire utilisé pour générer les initrd dans sarge, initrd-tools ne peut plus être utilisé et est obsolète. Deux nouveaux utilitaires ont été développés pour le remplacer : initramfs-tools et yaird. Les concepts derrière ces deux utilitaires sont très différents ; une vue d’ensemble est disponible dans le wiki Debian. Les deux génèrent un initrd en utilisant le système de fichiers initramfs qui est une archive cpio compressée. L’utilitaire par défaut et recommandé est initramfs-tools.

Mettre à jour vers un noyau d’etch entraînera l’installation d’initramfs-tools par défaut. Si vous faites une mise à jour depuis un noyau 2.4 vers un noyau 2.6, vous devez utiliser initramfs-tools. Utiliser yaird fera échouer les installations de linux-image-2.6 quand celles-ci s’exécutent sur un noyau 2.2 ou 2.4.

Le paquet initrd-tools est encore inclus dans etch car il est nécessaire pour les mises à niveau depuis sarge. Il sera abandonné pour la prochaine version.
[/quote]
Donc je vais tester en recréant mon image avec “initramfs-tools” car j’avais utilisé “initrd” il me semble. Ca vaut le coup de tester en tout cas.

EDIT : en plus, “initramfs-tools” inclut un shell de débuggage dans les “initrd” qu’il génère, comme l’indique la page que j’ai mis ci-dessus. Ca devrait m’aider…

RESOLU ! (2 topics dans le même soirée, j’assure :smt080 mdr)

N.B. : pour ceux qui ne connaissent pas la procédure à suivre pour compiler un nouveau kernel, c’est par ici : viewtopic.php?f=8&t=1806

Donc pour mettre fin à ce topic qui date de plusieurs mois, voici comment procéder :

1) Installez “initramfs-tools” :

# apt-get install initramfs-tools

En effet, il ne faut ni utiliser “initrd”, ni utiliser “yaird”, car ces 2 outils sont buggués et vous fournissent des images de boot bugguées (c’était en tout cas le cas ici). On utilise donc “initramfs” à la place (pour l’utiliser manuellement, utilisez la commande “mkinitramfs”).

2) Changez le programme de compilation d’images de boot utilisé par défaut par le kernel. Pour cela, vous lancez la commande suivante (vous pouvez toujours utiliser “vi” si vous n’avez pas d’environnement graphique :smt118 ):

# gedit /etc/kernel-img.conf

puis vous cherchez une ligne qui commence par “ramdisk =”. Si vous n’en avez pas, c’est parfait. Si vous en avez une, rajoutez un “#” au début de la ligne en question pour la “transformer” en commentaire. Mais dans les 2 cas de figure, rajoutez la ligne suivante à la fin du fichier :

ramdisk = /usr/sbin/mkinitramfs

et vous enregistrez le fichier.

3) Vous vous placez dans le répertoire qui contient les sources du kernel que vous voulez compiler, et… vous compilez votre kernel (cf. viewtopic.php?f=8&t=1806) :

# make-kpkg --append-to-version "custom-XXX" --initrd kernel_image modules_image kernel_headers

L’option “–initrd” est très importante !!! C’est elle qui va permettre de générer une nouvelle image de boot avec le nouvel outil “mkinitramfs” installé au début.

4) Vous remontez un cran plus haut dans l’arborescence de vos répertoires :

# cd ..

et vous installez votre nouveau kernel :

# dpkg -i kernel-image-2.x.x

(enfin vous devrez faire un “ls -al” afin de trouver le nom exact de l’image générée qui est bien plus long que ça, mais bon ça c’est de la compil de kernel, c’est pas le thème du topic, pour ça je vous ai donné l’adresse).

FINI !!! C’était pourtant pas compliqué… 1 semaine de galère à cause de 2 programmes buggués… :smt076

EDIT : par la suite j’ai eu un “Waiting for root file system” suivit d’un shell BusyBox à cause d’un disque SATA non reconnu par le nouveau kernel. Pour régler ce problème, c’est par ici : viewtopic.php?f=3&t=15365