Quand je rédigeais l’article précédent, gcc finissait sa deuxième compilation. Bash est passé sans problème. Cependant, la compilation de coreutils a été plus ardue. En effet, une dépendance était introuvable. Le bug est connu, par ailleurs.
Pour contourner ce problème, j’ai du récupérer – en recopiant le fichier dans /var/spool/lunar/ – le fichier libcap-2.22.tar.gz depuis le miroir irlandais du site kernel.org.
wget -c ftp://ftp.heanet.ie/mirrors/linux/libs/security/linux-privs/libcap2/libcap-2.22.tar.gz
Ensuite, la compilation s’est déroulée sans encombre. Arrive le moment tant redouté, le noyau. Allez, un petit lin linux-2.6 et on attend en croisant les doigts
Et comme pour libcap, obligé de récupérer le patch 2.6.39.4 avec wget… Grrr !
wget -c ftp://ftp.heanet.ie/mirrors/linux/kernel/v2.6/patch-2.6.39.4.bz2
Ensuite, les ennuis continuent… Lilo refuse de m’installer le noyau 2.6.39.4 avec un message sybillin :
Fatal: Setup length exceeds 31 maximum ; kernel setup will overwrite boot loader
Seul le noyau 2.6.35.3 est listé… Le 2.6.39.4 est invisible. Grub2 ? La compilation plante
Quant à SysLinux, c’est pas mieux.
Y a pas à dire, je suis vraiment malchanceux avec les distributions sources… Au moins, pour une fois, le noyau se sera recompilé, mais je ne saurais jamais s’il était démarrable ou pas !




Il y a très, très longtemps, les noyaux étaient bootables par eux-mêmes quand on les «calait» en début de disquette. On faisait ça avec
dd /dev/fd0
Bien sûr, les noyaux ne faisaient pas 2 mega et demi. J’ignore si ça fonctionne avec un clé USB, je n’en ai pas de libre sous la main pour tester.
Il y avait aussi une commande rdev qui permettait de modifier quelques octets dans le noyau pour lui indiquer quelle était la partition racine, quel mode vga, etc.
Le mieux serait quand même que tu utilises un grub 1 sur une live-cd pour configurer le boot-loader. C’est sûrement plus efficace
Grub 1 ne fonctionne pas en version 64 bits sur la lunar-linux. J’avoue que le coup du Lilo (pourtant à jour) ne supportant pas un deuxième noyau ainsi m’a légèrement énervé
Ma commande a été tronquée parcequ’elle comprenait des caractères « plus petit » et « plus grand ». Essayons ceci:
dd < /boot/vmlinuz > /dev/fd0