Re: Debian embarquée
Selon Roger Mampey <Roger.Mampey@cert.fr>:
| Bonjour,
Re.
Je remet la liste en Cc: afin que si d'autres ont des idées sur le
sujet ils nous en fassent profiter.
| Selon Thomas Nemeth
|
| > Bin en fait tout dépend du problème exact lors de ton reboot avec le
| > nouveau noyau. Ici je fais la manip tous les jours (et même
| plusieurs
| > fois par jour lors des tests) sur cibles ARM ou PC à partir d'hôtes
| > PC et ça ne pose aucun pb (sauf que comme c'est de l'embarqué très
| > léger, il n'y a pas d'initrd).
| >
| > Faut voir aussi comment tu réinstalles ton nouveau noyau, puisqu'en
| > plus ta cible semble être un PC, voir comment tu fais avec LILO ou
| > grub (que je n'utilise pas).
| >
| Mon objectif normal est d'installer un noyau aussi compact que possible
| sur la cible, donc a priori sans initrd et sans modules.
$ ll /var/lib/tftpboot/
total 8272
-rw-r--r-- 1 thomas users 6291456 jun 9 16:21 jffs2fs.img
-rw-r--r-- 1 thomas users 1616738 jun 9 16:21 ramdisk.gz
-rwxr-xr-x 1 thomas users 537840 jun 9 16:21 zImage*
Le noyau fait 537Ko (mais je pourrais encore virer quelques trucs),
le ramdisk (qui n'est pas un initrd) fait 1,6Mo avec quelques applis
réseau et des applis spécifiques à la cible et enfin une partition
JFFS2 de 6Mo quasiment vide pour sauvegarder des données de
fonctionnement.
Dans le ramdisk j'ai aussi 2 modules noyau perso pour contrôler du
matos spécifique. Mais bon, faut dire que c'est pour de l'ARM aussi,
là.
| Mais, meme si
| j'ai déjà compilé des noyaux - pour passer de 2.4 à 2.6 sur la Woody -
| je suis loin de maitriser parfaitement la question. Ce que j'ai tenté
| dans un premier temps, c'est d'éviter la définition du noyau de la cible
| à partir de scratch.
Effectivement il vaut mieux partir sur une base connue et qui marche :)
| Donc je pars du noyau installé sur la cible (install ex-testing par
| disquettes) et d'un source qui vient de ww.kernel.org pour le meme noyau
| 2.4.27.
Attention : les noyaux debian sont parfois patchés et donc ne
correspondent pas forcément aux noyaux vanilla.
| Parmi les différences entre les 2 fichiers de config (d'abord celui
| provenant de la cible puis celui construit par make menuconfig), il y a
| essentiellement disparition des parametres CONFIG_EXT3_FS* et
| CONFIG_EXT2_FS* dans la rubrique "File systems" et remplacement de
| modules par du codage dans le noyau dans la rubrique "Cryptographic
| options".
Tiens donc ? Qu'entends-tu par "disparition" ?
Veux-tu dire que c'est commenté par un # suivi de "is not set" ?
| Je peux sans doute corriger ca en changeant les choix par défaut de make
| menuconfig, mais je voudrais d'abord comprendre d'où proviennent ces
| différences.
As-tu plutôt tenté de faire un 'make oldconfig' ?
| Sur la cible, j'utilise grub et j'ai juste ajouté une entrée vers le
| nouveau noyau (d'apres la doc grub, rien d'autre à faire mais mes
| expériences antérieures ont eu lieu avec Lilo).
Hum. Je ne sais pas trop : je n'utilise pas grub. Lilo me suffit
amplement même s'il peut poser quelques problèmes parfois (mais
de toutes façons on arrive toujours à retomber sur ses pattes).
| Au reboot, un peu avant le "Kernel panic", j'obtiens une suite imposante
Ah, carrément !
| de messages identiques concernant modprobe. Trop longue pour que le
| début se soit conservé.
|
| modprobe : modprobe : Can't open dependencies file
| /lib/modules/2.4.7/modules.dep
Hum. Il te manque donc modules.dep. Il suffit de le créer vide si
tu n'as pas de modules. D'autre part, si modprobe fait son bordel
c'est qu'il cherche à charger des modules. Ce n'est pas bon si tu
n'as pas de modules : vérifie ta config. Je pense que ça doit se
faire dans l'initrd à ce niveau, sinon ça ne génèrerait pas de
kernel panic. Et il doit te manquer un support matériel important.
Il aurait fallu le message exact de ton kernel panic, mais il est
plus que probable que, n'ayant plus ext2 ni ext3, tu ne puisses pas
monter / :)
Autre pb : plus haut tu me parles de 2.4.27 et là c'est 2.4.7...
Est-ce une erreur de frappe ? Quel est le bon numéro ?
| J'ai bien cru voir passer un message concernant initrd juste avant mais
| je ne vois pas comment m'en assurer.
La solution est de booter en disant à ton noyau d'utiliser le port
série comme console. Pour cela il te faut avoir intégré au noyau le
driver de ton port série, puis, dans la ligne de commande du noyau,
rajouter console=/dev/ttySX (et quelques paramètres dont je ne me
souviens plus mais que je dois avoir chez moi et que tu dois pouvoir
trouver sur Internet) avec X = 0 en général.
Ensuite tu bootes ta machine en ayant relié par null-modem port série
sur le port série d'une autre machine faisant tourner minicom.
Une fois le boot fini (ou planté) tu peux sauvegarder les messages
dans un fichiers et les poster sur la liste ou à l'endroit qui te
chante dans le respect des règles de la netiquette bien entendu.
| [J'ai copié le répertoire /lib/modules/2.4.7 obtenu par 'make modules
| modules_install' sur la cible avec les bons droits]
Hum. Y a-t-il quelquechose dedans ?
Thomas.
Reply to: