(Re)-créer une image de boot (initrd.img) avec yaird

Trucs et Astuces
#1

Suite à un changement dans l’ordre de mes partitions, il m’a été impossible de redémarrer depuis des versions de noyaux >= 2.6.14

Il semble que ces noyaux utilisent un initrd.img généré par l’outil ‘yaird’

La solution trouvée sur le net qui consiste à désinstaller yaird et à générer une image classique avec mkinitrd semble fonctionner mais comme yaird est présenté comme un successeur + performant autant le remettre d’aplomb. :wink:

1/ Connaître sa nouvelle table de partitions (tous les moyens sont bons)

2/Modifier /etc/fstab en conséquence

3/Renommer le /boot/initrd.img-[version] qui vous pose pb ou le déplacer. (je suppose que votre noyau actif est autre puisque vous avez eu ce genre de souci) :

/usr/lib/yaird/exec/run_init Impossible de trouver ce fichier
 kernel panic -not syncing:Attempted to kill init!

4/Vérifier les options de yaird dans /etc/yaird/Default.cfg
(le format des images pour les noyaux 2.6 est en général ‘cpio’ qui utilise ‘initramfs’)

nb : l’option -f=cpio permet d’imposer ce format (ou un autre) lors de la commande.

5/Créer l’image pour votre système de fichier, la partition racine active et la version souhaitée du noyau (ce noyau doit avoir été installé même s’il n’est pas accessible pour l’instant)

#yaird (--verbose) --output=/boot/initrd.img-[version] [version]

nb : --output indique le chemin et le nom de l’image à créer. Le dernier champ [version] est essentiel pour générer l’image pour un autre noyau que le noyau actif. Attention, il y a bien un espace avant [version].

6/Adapter /boot/grub/menu.lst si besoin avec :

root [partition /boot mode grub]
initrd /initrd.img-[version]

7/shutdown -r now

man yaird pour un supplément d’infos :wink:

#2

[quote=“Bluenote”]1/ Connaître sa nouvelle table de partitions (tous les moyens sont bons)[/quote] :question:

#3

Un outil de partitionnement :wink:

#4

Et tu le fais tourner comment ton outil de partitionnement, puisque ton 2.6.15 ne tourne pas encore ?
Je dis ça parceque ton truc m’interresse: j’ai une testing/unstable qui refuse de démarrer en 2.6.15, alors qu’elle démarre parfaitement en 2.6.14, et comme c’est effectivement un problême de disque, j’aimerais savoir si c’est parceque les disque sont nommés d’une manière différente, ou quoi…
Bon, ceci etant dit, je n’ai pas eu le temps de me pencher sur le problême plus que ca…

#5

Je n’ai pas dû être dans le même cas de figure que toi

D’abord, tu n’as aucun système qui tourne et qui monte tes partitions à pb (sinon df évidemment)

Bon oublie tu ne dois pas pouvoir y accéder…

Et si tu mets un cd d’installation avec cfdisk ou ses successeurs, tu dois voir les tailles des partitions et leur ordre (tu peux en déduire les changements par rapport à ton fstab obsolète)

A part ça j’ai aucun expérience avec des outils “séparés”.
Mais j’ai entendu parlé de partition magic et cie. Ca me semble faisable. Détaille plus ton pb.

Excuse-moi si je suis à côté de la plaque, j’ai l’esprit très embrouillé en ce moment :blush:

#6

Dans mon cas, je voulais réduire une partition pour loger 2 nouvelles partions dédiées à Hurd. J’ai utilisé le cd d’installation de Mandriva pour faire la manip parce que je suis une bille avec qtparted. Une fois le travail fait, il m’a affecté un nouvel ordre pour mes partochs. (que j’ai noté)

Après qd j’ai installé Hurd (qui utilise cfdisk, l’outil de partitionnement de Debian Woody) j’ai choisi les pts de montage que je voulais en fonction de ce nouvel ordre.

#7

[quote=“MattOTop”]Et tu le fais tourner comment ton outil de partitionnement, puisque ton 2.6.15 ne tourne pas encore ?
Je dis ça parceque ton truc m’interresse: j’ai une testing/unstable qui refuse de démarrer en 2.6.15, alors qu’elle démarre parfaitement en 2.6.14, et comme c’est effectivement un problême de disque, j’aimerais savoir si c’est parceque les disque sont nommés d’une manière différente, ou quoi…
Bon, ceci etant dit, je n’ai pas eu le temps de me pencher sur le problême plus que ca…[/quote]
Aprés m’être penché sur le problême, il s’agissait d’une meilleure priorisation d’udev au boot qui n’avait pas été bien mise à jour. udev avait une priorité 20/80 comme la majorité des autres services, et ne fournissait pas encore un /dev/ peuplé au moment du montage de /root.
Une reconfiguration en 19/81 a règlé le pb…

#8

Pour information, je suis passé recemment d’un noyau mono proc 2.6 au noyau bi proc 2.6 (smp), version etch, par un aptitude install kernel-2.6-686-smp.

Ce qui m’entrainait systématiquement des erreurs initrd au démarrage puis puis au final un /bin/sh can’t access tty.

J’ai donc testé la solution préconisée ici par Bluenote, en régénérant mon initrd et ca fonctionne impec.

Merci bcp :smiley:

#9

Un lien interessant (en anglais):

[quote]
The switch from initrd to initramfs for newer Debian kernels
*Debian kernels require an initial ramdisk to work
*Comparison of the various replacements for initrd-tools
*Only some kernel versions work
*Comparable hilites beyond simply working
*Hilites not directly comparable[/quote]

wiki.debian.org/InitrdReplacementOptions

#10

Merci bluenote, ca marche niquel.
Il m’a fallu prendre un ancien noyau qui lui avait la liste des bons modules sinon yaird se plantait lors de la detection des modules, il prenait les modules chargés ce qui n’etait pas bon dans mon cas (pas de DMA sur le disque)

#11

Content que ça serve ! (je m’étais tapé pas mal de doc en anglais avant de comprendre ce qui clochait avec ces nouveaux noyaux)

#12

On peut virer les autre initrd j’imagine.
C’est surtout ton post qui m’a sauvé la vie: le coup de booter sur un noyau fonctionnel , plutot que yaird.
L’avantage de yaird c’est qu’il m’a juste mis les drivers disques et pas besoin de tous le reste.