démarrer sans image initramfs

Support Debian
#21

Cette référence au kernel 2.6.13 était juste un prétexte minable pour ramener ma petite science
Wiki, grand wiki , ma source

en.wikipedia.org/wiki/Initrd

  • If the image is a gzip-compressed cpio archive, it will be unpacked by the kernel in an intermediate step into an initramfs (a special instance of a tmpfs available in Linux 2.6.13 onwards), which then becomes the initial root file system. It has the advantage of not requiring an intermediate file system to be compiled into the kernel.

Au passage cette citation montre que valider tmpfs dans le noyau serait également une bonne idée

Reformulation pour ce qui nous concerne :
Aucun noyau linux antérieur à 2.6.13 ne peut démarrer avec initramfs c’est à dire que tous les noyaux antérieurs sans exception démarraient ainsi.
Ce que relax cherche à faire est paradoxalement un retour au comportement par défaut antérieur à linux 2.6.13.
Rien d’irréalisable en somme .

#22

Bonjour^^

Alors j’ai testé tout ça, comme prévu, et devinez quoi ------> ça ne marche toujours pas :stuck_out_tongue:

Je n’ai pas créé d’initrd (mkinitramfs -o initrd.img-NoInitramfs), sachant que “NoInitramfs” est un noyau que j’utilise pour faire les tests de démarrage sans initramfs…
Et voila ce que j’obtiens à l’écran lors du démarrage :

Booting debian GNU/linux, kernel 2.6.30.4-NoInitramfs

root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/vmlinuz-2.6.30.4-NoInitramfs root=/dev/hda1 ro quiet
[Linux-bzImage, setup=0x2e00, size=0x2c6640]

[ 1.343633] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Je vous explique exatement la démarche que j’ai suivi pour la compilation de mon noyau:

  1. je vais dans /home/siraga/linux-2.6.30.4 (après avoir décompressé “linux-2.6.30.4.tar.bz2”)
  2. je fais “make mrproper”
  3. make menuconfig
  4. je configure mon noyau (je vous ai déja montré ma config précédemment), en décochant “Initial RAM filesystem and RAM disk (initramfs/initrd) support”, en mettant en dure tout ce qui se trouve dans “File Systems”, “USB support”, “SCSI device support”, et en définissant une LOCALVERSION personnelle (dans General setup > Local version) pour différencier le noyau de celui fourni par défaut, que j’ai nommé “-NoInitramfs” :slightly_smiling:
  5. je quitte en sauvegardant bien sûr!
  6. make bzImage
  7. make modules && make modules_install
    8) cp arch/x86/boot/bzImage /boot/vmlinuz-NoInitramfs
  8. update-grub
  9. reboot
  10. ça marche pas -----> affichage de l’erreur que j’ai énoncé au début!

Remarques:
–> mon noyau de base est le 2.6.26-2-686.
–> en allant dans le menu.lst, il n’y a en effet pas d’initrd créé pour le nouveau noyau compilé “2.6.30.4-NoInitramfs”, donc ça confirme que je n’ai pas utilisé de “mkinitramfs”…
–> voici ce que j’ai dans /boot:
config-2.6.26-2-686
config-2.6.30.4-NoInitramfs
config-2.6.30.4-NoInitramfs.old
grub
initrd.img-2.6.26-2-686
System.map-2.6.26-2-686
System.map-2.6.30.4-NoInitramfs
System.map-2.6.30.4-NoInitramfs.old
vmlinuz-2.6.26-2-686
vmlinuz-2.6.30.4-NoInitramfs
vmlinuz-2.6.30.4-NoInitramfs.old

–> dernière remarque: je commence à désespérer ^^

#23

Erreur déclarée

[ 1.343633] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Si le fs de ton installation est bien dans le noyau, il se pourrait que l’origine de l’erreur soit extérieure au noyau.
Si tu as validé l’émulation SCSI /dev/hda est devenu /dev/sda
Pour tester change /dev/hda en /dev/sda dans la définition de la racine en grub et /etc/fstab.

#24

Pour relax, “valider l’émulation SCSI” signifie utiliser les nouveaux pilotes PATA/SATA de libata qui nomment les disques sdX au lieu des anciens pilotes IDE/ATA qui nomment les disques hdX.

Je vois “ATA/ATAPI/MFM/RLL support [M]”, donc tu as compilé les pilotes IDE en modules qui ne sont pas disponibles avant que la racine soit montée et forcément, tu ne peux pas définir un disque hdX comme racine.

Soit tu compiles les pilotes IDE en dur et ta racine sera hdX, soit tu compiles les pilotes PATA/SATA en dur et ta racine sera sdX.

#25

AFFAIRE RESOLUE!!!

Il fallait en effet mettre en dur “ATA/ATAPI/MFM/RLL support” et tout ce qui se trouve dedans!
Sinon, j’ai oublié de signaler qu’il faut mettre “make install” après “make modules && make modules_install”

Donc merci bcp PascalHambourg pour ton aide!!

Sinon, je n’ai pas touché à /dev/hda, donc le problème ne venait pas de là, mais merci quand même pour ton aide Etxeberrizahar!

A la prochaine!

#26

Par contre, petit problème:
lors du redémarrage, le clavier est en qwerty :s

Comment je fais pour me remettre en azerty? Je sais que ça vient dans la configuration du noyau, mais je ne sais pas à quelle option il faut toucher…

#27

J’ai essayé “dpkg-reconfigure console-data”, je configure ce qu’il faut, ça marche, je me remets en azerty, mais quand je redémarre ça se remet en qwerty, donc le problème vient bien du noyau…

#28

On peut aussi taper “loadkeys fr” et ça se remet en azerty, mais quand on reboot, ça se met automatiquement en qwerty, c’est chiant!

#29

C’est bon, j’ai réglé le problème:

  1. une fois loggé, taper “loadkeys fr” pour pouvoir bénéficier d’un clavier azerty pour le moment.
  2. pour que le mode azerty reste valable au reboot, taper la commande “set xkbmap -model 105 -layout fr”

et voila le tour est joué :slightly_smiling: -----> j’en ai mis du temps pour trouver cette solution!

#30

l’astuce serai a garder je trouve :slightly_smiling: un petit topic dans truc et astuce avec un referance dans celui de fran.b :smt006

#31

Ce ne serait pas plutôt setxkbmap en un seul mot ?

Ce progamme est pour X11 alors que console-data et loadkeys sont pour la console, tu avais le problème où ?
Nota : Pour ma part je n’ai jamais rencontré ce problème avec mes noyaux maison sans initrd.

#32

Ce ne serait pas plutôt setxkbmap en un seul mot ?

Ce progamme est pour X11 alors que console-data et loadkeys sont pour la console, tu avais le problème où ?
Nota : Pour ma part je n’ai jamais rencontré ce problème avec mes noyaux maison sans initrd.[/quote]

Oui, PascalHambourg, apparemment ce programme est pour X11, mais ça a quand même marché pour moi… je n’ai pas tapé “set xkbmap” en un seul mot et ça a quand même fonctionné, sinon je pense que l’erreur venait de la configuration du noyau, dans File systems -> Native language support, j’avais mis en dur tout ce qui concernait le clavier qwerty en fait (langue USA), j’ai donc décoché ces options et recoché celles qui concernaient le clavier azerty (codepage 850, latin 1 et 9 si je me souviens bien) voila :slightly_smiling:

#33

Tu me laisses perplexe.
“set” est une commande intégrée au shell (man builtins) qui permet de manipuler les variables du shell. La syntaxe et les paramètres qui suivent “set xkbmap” correspondent à ceux du programme setxkbmap. D’autre part, à ma connaissance les options NLS (native language support) correspondent à des jeux de caractères utilisés pour les noms des fichiers dans certains systèmes de fichiers, et n’ont rien à voir avec la disposition du clavier.

#34

Je m’excuse pour cette réponse tardive. J’étais en trin d’essayer de résoudre ce problème de changement de clavier…

Finalement, je pense que tout vient du rcconf. Quand je décoche l’option ‘console-setup’, le clavier se met automatiquement en qwerty. Dès que je la recoche, il se remet en azerty (à condition d’avoir activé les options concernant le clavier azerty lors de la configuration du noyau).

#35

Au final, tu boot en combien de temps ? :slightly_smiling:

#36

En ce moment, le bootchart m’affiche 4s :slightly_smiling:

#37

Quand tu auras fini, tu pourrais faire un résumé de ce que tu as fait ?

#38

juste car on y voit plus rien :slightly_smiling:

#39

Ok je feré une explication complète, mais pas maintenant, en début de semaine prochaine :slightly_smiling:

Bon weekend!