gdialog ..

Frédéric Bothamy

08/06/2005 à 10:40

* Rolland T. Chago [2005-06-08 03:13] :

Slut ,
j'ai installé quelques scripts pour nautilus au moment de les exécuter
je me rend compte que ceux ci ont besoin d'1 certain gdialog ..apres
recherche sur le net .. gdialog se trouve paket dans gnome-utils mais
apres l'installation de gnome-utils je me rend compte que gdialog n'est
pas tjrs installé ..
est que quelqu'1 pourrais me dire où je pourrais trouver le fameux gdialog

D'après un "apt-file search gdialog", tu devrais pouvoir le trouver
dans le paquet zenity.

Fred

--
Comment poser les questions de manière intelligente ?
http://www.gnurou.org/documents/smart-questions-fr.html
Comment signaler efficacement un bug ?
http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Nicolas Roudninski

08/06/2005 à 10:50

Rolland T. Chago a écrit :

Slut ,
j'ai installé quelques scripts pour nautilus au moment de les exécuter
je me rend compte que ceux ci ont besoin d'1 certain gdialog ..apres
recherche sur le net .. gdialog se trouve paket dans gnome-utils mais
apres l'installation de gnome-utils je me rend compte que gdialog n'est
pas tjrs installé ..
est que quelqu'1 pourrais me dire où je pourrais trouver le fameux gdialog

Peace

Tu trouveras gdialog dans le paquet zenity

--
Nicolas Roudninski

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Roger Mampey

09/06/2005 à 08:20

Bonjour la liste,

C'est sans doute quelque peu hors sujet. Je cherche à compiler sur un
portable Dell un noyau pour une cible PC104. Les 2 sont actuellement
sous Debian (ex-testing) mais les problemes que je rencontre concernent
en fait la compilation du noyau.

Je ne peux pas compiler sur la cible - disque Flash de 256M plein à 80%
- où je dois ajouter des drivers pour une carte d'acquisition video (à
laquelle je ne peux accéder que depuis un PC104) mais la cible et le
portable sont sur un meme réseau.

Dans un premier temps, je cherche à compiler sur le portable le meme
noyau que celui qui est sur la cible. Echec patent (au reboot sur la
cible). J'ai essayé d'esquiver la redéfinition du fichier initrd quoique
les 2 noyaux - origine et compilé - ne soient pas identiques. Je ne peux
pas entrer dans les détails dans un premier mail, j'aimerai juste savoir
pour le moment si la redéfinition de initrd est incontournable ou alors
comment obtenir exactement le meme noyau (le fichier de configuration
disponible sur la cible passé à travers 'make menuconfig' sans procéder
à aucune modif. est néanmoins modifié à la sortie d'une facon que je ne
m'explique pas) ?

Tout pointeur vers une info précise est le bienvenu. Je dispose de
bouquins sur les systemes Linux embarqués (celui de Ficheux et celui de
Yaghmour) que j'ai lus mais sans doute pas de la facon appropriée.

Roger Mampey

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

tnemeth

09/06/2005 à 11:00

Selon Roger Mampey :

| Bonjour la liste,

Bonjour,

| Dans un premier temps, je cherche à compiler sur le portable le meme
| noyau que celui qui est sur la cible. Echec patent (au reboot sur la
| cible).

C'est-à-dire ?

| J'ai essayé d'esquiver la redéfinition du fichier initrd quoique
| les 2 noyaux - origine et compilé - ne soient pas identiques.

Dans ce cas ce n'est pas une bonne idée (sauf si ce n'est que le
nombre de pilotes qui change entre les 2 noyaux : si c'est carrément
la version du noyau qui change, mieux vaut regénérer initrd).

| Je ne peux
| pas entrer dans les détails dans un premier mail, j'aimerai juste savoir
| pour le moment si la redéfinition de initrd est incontournable ou alors
| comment obtenir exactement le meme noyau.

Cf plus haut : incontournable si tu changes de version de noyau, mais
puisque tu sembles vouloir reconstruire exactement le même alors là,
effectivement, il n'est pas nécessaire de recontruire l'initrd.

| (le fichier de configuration
| disponible sur la cible passé à travers 'make menuconfig' sans procéder
| à aucune modif. est néanmoins modifié à la sortie d'une facon que je ne
| m'explique pas) ?

Quelles sont les différences entre les 2 fichiers de config ?

| Tout pointeur vers une info précise est le bienvenu. Je dispose de
| bouquins sur les systemes Linux embarqués (celui de Ficheux et celui de
| Yaghmour) que j'ai lus mais sans doute pas de la facon appropriée.

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).

Thomas.

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Selon Roger Mampey <Roger.Mampey@cert.fr>:

| Bonjour la liste,

Bonjour,

| Dans un premier temps, je cherche à compiler sur le portable le meme
| noyau que celui qui est sur la cible. Echec patent (au reboot sur la
| cible).

C'est-à-dire ?

| J'ai essayé d'esquiver la redéfinition du fichier initrd quoique
| les 2 noyaux - origine et compilé - ne soient pas identiques.

Dans ce cas ce n'est pas une bonne idée (sauf si ce n'est que le
nombre de pilotes qui change entre les 2 noyaux : si c'est carrément
la version du noyau qui change, mieux vaut regénérer initrd).

| Je ne peux
| pas entrer dans les détails dans un premier mail, j'aimerai juste savoir
| pour le moment si la redéfinition de initrd est incontournable ou alors
| comment obtenir exactement le meme noyau.

Cf plus haut : incontournable si tu changes de version de noyau, mais
puisque tu sembles vouloir reconstruire exactement le même alors là,
effectivement, il n'est pas nécessaire de recontruire l'initrd.

| (le fichier de configuration
| disponible sur la cible passé à travers 'make menuconfig' sans procéder
| à aucune modif. est néanmoins modifié à la sortie d'une facon que je ne
| m'explique pas) ?

Quelles sont les différences entre les 2 fichiers de config ?

| Tout pointeur vers une info précise est le bienvenu. Je dispose de
| bouquins sur les systemes Linux embarqués (celui de Ficheux et celui de
| Yaghmour) que j'ai lus mais sans doute pas de la facon appropriée.

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).

Thomas.

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vous avez filtré cet utilisateur ! Consultez son message

Selon Roger Mampey :

| Bonjour la liste,

Bonjour,

| Dans un premier temps, je cherche à compiler sur le portable le meme
| noyau que celui qui est sur la cible. Echec patent (au reboot sur la
| cible).

C'est-à-dire ?

| J'ai essayé d'esquiver la redéfinition du fichier initrd quoique
| les 2 noyaux - origine et compilé - ne soient pas identiques.

Dans ce cas ce n'est pas une bonne idée (sauf si ce n'est que le
nombre de pilotes qui change entre les 2 noyaux : si c'est carrément
la version du noyau qui change, mieux vaut regénérer initrd).

| Je ne peux
| pas entrer dans les détails dans un premier mail, j'aimerai juste savoir
| pour le moment si la redéfinition de initrd est incontournable ou alors
| comment obtenir exactement le meme noyau.

Cf plus haut : incontournable si tu changes de version de noyau, mais
puisque tu sembles vouloir reconstruire exactement le même alors là,
effectivement, il n'est pas nécessaire de recontruire l'initrd.

| (le fichier de configuration
| disponible sur la cible passé à travers 'make menuconfig' sans procéder
| à aucune modif. est néanmoins modifié à la sortie d'une facon que je ne
| m'explique pas) ?

Quelles sont les différences entre les 2 fichiers de config ?

| Tout pointeur vers une info précise est le bienvenu. Je dispose de
| bouquins sur les systemes Linux embarqués (celui de Ficheux et celui de
| Yaghmour) que j'ai lus mais sans doute pas de la facon appropriée.

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).

Thomas.

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

tnemeth

09/06/2005 à 17:00

Selon Roger Mampey :

| 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.

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

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.

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vous avez filtré cet utilisateur ! Consultez son message

Selon Roger Mampey :

| 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.

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Roger Mampey

09/06/2005 à 17:30

Bonjour,

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).

Thomas.

Mon objectif normal est d'installer un noyau aussi compact que possible
sur la cible, donc a priori sans initrd et sans modules. 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.

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.

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".

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.

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).
Au reboot, un peu avant le "Kernel panic", j'obtiens une suite imposante
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

J'ai bien cru voir passer un message concernant initrd juste avant mais
je ne vois pas comment m'en assurer.

[J'ai copié le répertoire /lib/modules/2.4.7 obtenu par 'make modules
modules_install' sur la cible avec les bons droits]

Là, c'est pareil, je voudrais d'abord comprendre pourquoi ca coince
plutôt que tenter de corriger.

Roger Mampey

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Bonjour,

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).

Thomas.

Mon objectif normal est d'installer un noyau aussi compact que possible
sur la cible, donc a priori sans initrd et sans modules. 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.

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.

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".

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.

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).
Au reboot, un peu avant le "Kernel panic", j'obtiens une suite imposante
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

J'ai bien cru voir passer un message concernant initrd juste avant mais
je ne vois pas comment m'en assurer.

[J'ai copié le répertoire /lib/modules/2.4.7 obtenu par 'make modules
modules_install' sur la cible avec les bons droits]

Là, c'est pareil, je voudrais d'abord comprendre pourquoi ca coince
plutôt que tenter de corriger.

Roger Mampey

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,

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).

Thomas.

Mon objectif normal est d'installer un noyau aussi compact que possible
sur la cible, donc a priori sans initrd et sans modules. 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.

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.

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".

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.

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).
Au reboot, un peu avant le "Kernel panic", j'obtiens une suite imposante
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

J'ai bien cru voir passer un message concernant initrd juste avant mais
je ne vois pas comment m'en assurer.

[J'ai copié le répertoire /lib/modules/2.4.7 obtenu par 'make modules
modules_install' sur la cible avec les bons droits]

Là, c'est pareil, je voudrais d'abord comprendre pourquoi ca coince
plutôt que tenter de corriger.

Roger Mampey

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Roger Mampey

09/06/2005 à 22:30

Selon Thomas Nemeth :

Attention : les noyaux debian sont parfois patchés et donc ne
correspondent pas forcément aux noyaux vanilla.

Ah ! Ca doit suffire à expliquer pourquoi il y a une différence. Est-ce
qu'il est possible d'obtenir sur le site de la Debian les sources
correspondant aux images qu'elle propose ?

Tiens donc ? Qu'entends-tu par "disparition" ?
Veux-tu dire que c'est commenté par un # suivi de "is not set" ?

Non, ca n'apparait plus du tout. Attention : CONFIG_EXT2_FS et
CONFIG_EXT3_FS sont toujours là, ce qui disparait, ce sont des
parametres de type CONFIG_EXT?_FS_XATTR* et CONFIG_EXT?_FS_POSIX_ACL A
part ca, il y a d'autres disparitions.

As-tu plutôt tenté de faire un 'make oldconfig' ?

Je connais config, menuconfig et xconfig. Mais pas oldconfig. Ficheux
recommande chaudement d'éviter config, alors oldconfig :-) Je suppose
que oldconfig ne prend aucune initiative alors que ce n'est visiblement
pas le cas de menuconfig. Je vais regarder si j'ai ca.

Il aurait fallu le message exact de ton kernel panic,

"Attempted to kill init !" :-)

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 ?

Correction, c'est 2.4.27. Mais j'ai installé tout le répertoire
/lib/modules/2.4.27 sur la cible. Non vide avec les bons droits et
modules.dep non vide.

| 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.

Je vais faire ca. Mais demain est un autre jour.

A part ca, j'ai essayé une autre manip qui tue :

Je pars toujours du fichier de config de la cible et j'utilise toujours
menuconfig et je supprime le support des modules sans m'occuper de
quoique ce soit d'autre (en vérifiant quand meme que les anciens modules
indispensables - network, ide, ... - sont bien passés de 'm' à 'y'), La
compilation du noyau échoue dans le répertoire .../drivers/isdn/eicon.
Je vais reessayer en supprimant le support isdn, mais ca énerve surtout
quand on ne sait pas exactement de quoi on a absolument besoin.

Peut-etre bien qu'un fichier de config pour noyau amaigri sur PC serait
une meilleure base de départ. Mais quand meme, un échec à la compilation
en remplacant (en laissant make menuconfig le faire) tous les modules
par du code interne noyau. est-ce bien normal ?

Roger Mampey

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Selon Thomas Nemeth :

Attention : les noyaux debian sont parfois patchés et donc ne
correspondent pas forcément aux noyaux vanilla.

Ah ! Ca doit suffire à expliquer pourquoi il y a une différence. Est-ce
qu'il est possible d'obtenir sur le site de la Debian les sources
correspondant aux images qu'elle propose ?

Tiens donc ? Qu'entends-tu par "disparition" ?
Veux-tu dire que c'est commenté par un # suivi de "is not set" ?

Non, ca n'apparait plus du tout. Attention : CONFIG_EXT2_FS et
CONFIG_EXT3_FS sont toujours là, ce qui disparait, ce sont des
parametres de type CONFIG_EXT?_FS_XATTR* et CONFIG_EXT?_FS_POSIX_ACL A
part ca, il y a d'autres disparitions.

As-tu plutôt tenté de faire un 'make oldconfig' ?

Je connais config, menuconfig et xconfig. Mais pas oldconfig. Ficheux
recommande chaudement d'éviter config, alors oldconfig :-) Je suppose
que oldconfig ne prend aucune initiative alors que ce n'est visiblement
pas le cas de menuconfig. Je vais regarder si j'ai ca.

Il aurait fallu le message exact de ton kernel panic,

"Attempted to kill init !" :-)

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 ?

Correction, c'est 2.4.27. Mais j'ai installé tout le répertoire
/lib/modules/2.4.27 sur la cible. Non vide avec les bons droits et
modules.dep non vide.

| 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.

Je vais faire ca. Mais demain est un autre jour.

A part ca, j'ai essayé une autre manip qui tue :

Je pars toujours du fichier de config de la cible et j'utilise toujours
menuconfig et je supprime le support des modules sans m'occuper de
quoique ce soit d'autre (en vérifiant quand meme que les anciens modules
indispensables - network, ide, ... - sont bien passés de 'm' à 'y'), La
compilation du noyau échoue dans le répertoire .../drivers/isdn/eicon.
Je vais reessayer en supprimant le support isdn, mais ca énerve surtout
quand on ne sait pas exactement de quoi on a absolument besoin.

Peut-etre bien qu'un fichier de config pour noyau amaigri sur PC serait
une meilleure base de départ. Mais quand meme, un échec à la compilation
en remplacant (en laissant make menuconfig le faire) tous les modules
par du code interne noyau. est-ce bien normal ?

Roger Mampey

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vous avez filtré cet utilisateur ! Consultez son message

Selon Thomas Nemeth :

Attention : les noyaux debian sont parfois patchés et donc ne
correspondent pas forcément aux noyaux vanilla.

Ah ! Ca doit suffire à expliquer pourquoi il y a une différence. Est-ce
qu'il est possible d'obtenir sur le site de la Debian les sources
correspondant aux images qu'elle propose ?

Tiens donc ? Qu'entends-tu par "disparition" ?
Veux-tu dire que c'est commenté par un # suivi de "is not set" ?

Non, ca n'apparait plus du tout. Attention : CONFIG_EXT2_FS et
CONFIG_EXT3_FS sont toujours là, ce qui disparait, ce sont des
parametres de type CONFIG_EXT?_FS_XATTR* et CONFIG_EXT?_FS_POSIX_ACL A
part ca, il y a d'autres disparitions.

As-tu plutôt tenté de faire un 'make oldconfig' ?

Je connais config, menuconfig et xconfig. Mais pas oldconfig. Ficheux
recommande chaudement d'éviter config, alors oldconfig :-) Je suppose
que oldconfig ne prend aucune initiative alors que ce n'est visiblement
pas le cas de menuconfig. Je vais regarder si j'ai ca.

Il aurait fallu le message exact de ton kernel panic,

"Attempted to kill init !" :-)

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 ?

Correction, c'est 2.4.27. Mais j'ai installé tout le répertoire
/lib/modules/2.4.27 sur la cible. Non vide avec les bons droits et
modules.dep non vide.

| 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.

Je vais faire ca. Mais demain est un autre jour.

A part ca, j'ai essayé une autre manip qui tue :

Je pars toujours du fichier de config de la cible et j'utilise toujours
menuconfig et je supprime le support des modules sans m'occuper de
quoique ce soit d'autre (en vérifiant quand meme que les anciens modules
indispensables - network, ide, ... - sont bien passés de 'm' à 'y'), La
compilation du noyau échoue dans le répertoire .../drivers/isdn/eicon.
Je vais reessayer en supprimant le support isdn, mais ca énerve surtout
quand on ne sait pas exactement de quoi on a absolument besoin.

Peut-etre bien qu'un fichier de config pour noyau amaigri sur PC serait
une meilleure base de départ. Mais quand meme, un échec à la compilation
en remplacant (en laissant make menuconfig le faire) tous les modules
par du code interne noyau. est-ce bien normal ?

Roger Mampey

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Thomas Labourdette

10/06/2005 à 08:20

Le Jeudi 09 Juin 2005 19:24, Roger Mampey a écrit :

Selon Thomas Nemeth :
> Attention : les noyaux debian sont parfois patchés et donc ne
> correspondent pas forcément aux noyaux vanilla.

Ah ! Ca doit suffire à expliquer pourquoi il y a une différence. Est-ce
qu'il est possible d'obtenir sur le site de la Debian les sources
correspondant aux images qu'elle propose ?

kernel-source-2.4.27, c'est le paquet contenant les sources patchées
kernel-patch-debian-2.4.27 contient uniquement les patches

Autrement en faisant un
apt-get source kernel-source-2.4.27

tu auras, entre autre
kernel-source-2.4.27_2.4.27.orig.tar.gz qui sont les sources d'origines
et
kernel-source-2.4.27_2.4.27-10.diff.gz qui contient tous ce qui faut pour
avoir un noyau à la sauce debian

@+
--
Juste POURVOIR (signature aléatoire)
Quelle est la femme idéale ?
- Une jolie blonde, nymphomane, muette, sourde, qui a perdu sa mère
et dont le père tient un sex-shop.
(Desproges)

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

tnemeth

10/06/2005 à 09:20

Selon Roger Mampey :

| Selon Thomas Nemeth :
|
| > Attention : les noyaux debian sont parfois patchés et donc ne
| > correspondent pas forcément aux noyaux vanilla.
| >
| Ah ! Ca doit suffire à expliquer pourquoi il y a une différence. Est-ce
| qu'il est possible d'obtenir sur le site de la Debian les sources
| correspondant aux images qu'elle propose ?

Pour les paquets habituels c'est le cas : il suffit d'aller sur la
page concernant le paquet et tu as le .tar.orig et le patch.
Maintenant je ne sais pas ce qu'il en est du noyau mais je ne vois
pas pourquoi il en serait autrement.

| > Tiens donc ? Qu'entends-tu par "disparition" ?
| > Veux-tu dire que c'est commenté par un # suivi de "is not set" ?
| >
| Non, ca n'apparait plus du tout. Attention : CONFIG_EXT2_FS et
| CONFIG_EXT3_FS sont toujours là, ce qui disparait, ce sont des
| parametres de type CONFIG_EXT?_FS_XATTR* et CONFIG_EXT?_FS_POSIX_ACL A
| part ca, il y a d'autres disparitions.

Ça doit être dû aux patches qui sont différents.

| > As-tu plutôt tenté de faire un 'make oldconfig' ?
| >
| Je connais config, menuconfig et xconfig. Mais pas oldconfig. Ficheux
| recommande chaudement d'éviter config, alors oldconfig :-)

S'il recommande d'éviter config c'est que depuis les débuts du noyau
de nombreuses options et un support matériel immense ont été rajoutés
alors que 'make config' passe toutes les options une par une... Tu
imagines le souk si tu devais te taper toutes les options à la suite
:) ?

| Je suppose
| que oldconfig ne prend aucune initiative alors que ce n'est visiblement
| pas le cas de menuconfig. Je vais regarder si j'ai ca.

oldconfig ne te pose de question que sur les nouvelles options par
rapport à ton ancien noyau.

| > Il aurait fallu le message exact de ton kernel panic,
| >
| "Attempted to kill init !" :-)

Ouch !

| > 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 ?
| >
| Correction, c'est 2.4.27. Mais j'ai installé tout le répertoire
| /lib/modules/2.4.27 sur la cible. Non vide avec les bons droits et
| modules.dep non vide.

Et il y a quoi en module ?
Pour un noyau minimal bien réduit il ne devrait pas y en avoir
beaucoup (voire aucun).

| A part ca, j'ai essayé une autre manip qui tue :
|
| Je pars toujours du fichier de config de la cible et j'utilise toujours
| menuconfig et je supprime le support des modules sans m'occuper de
| quoique ce soit d'autre (en vérifiant quand meme que les anciens modules
| indispensables - network, ide, ... - sont bien passés de 'm' à 'y'), La
| compilation du noyau échoue dans le répertoire .../drivers/isdn/eicon.
| Je vais reessayer en supprimant le support isdn, mais ca énerve surtout
| quand on ne sait pas exactement de quoi on a absolument besoin.

Tu ne sais pas de quoi tu vas avoir besoin ?
Généralement, lorsque tu fais de l'embarqué, tu sais exactement sur
quelle cible tu va mettre ton noyau. À ce titre, j'enlève tout ce qui
n'est pas directement en rapport avec le matos que je veux faire
marcher (et généralement le matos est peu complexe, dans l'embarqué).

En l'occurence nous avons développé dans ma boite une carte CPU ARM
avec plein de ressources mais seulement certaines sont utilisées par
les cartes "métier" utilisant cette carte CPU : à chaque nouvelle
carte j'adapte le noyau en virant les ressources non utilisées par la
carte métier... Mais cela implique de connaître parfaitement le matos.

Avant de faire un noyau essaye de te renseigner sur le matériel que
tu dois supporter. Si c'est pour faire un test sur ton propre pécé,
alors prend la doc de ta carte mère, de tes périfs etc. et ne prend
les pilotes que de ce que tu veux supporter. Peu importe si tout
n'est pas présent, il te suffit de tester et rajouter ce qui te manque
au fur et à mesure que tu t'en rends compte (pense alors à tout noter
à chaque modif).

| Peut-etre bien qu'un fichier de config pour noyau amaigri sur PC serait
| une meilleure base de départ. Mais quand meme, un échec à la compilation
| en remplacant (en laissant make menuconfig le faire) tous les modules
| par du code interne noyau. est-ce bien normal ?

Oui même si c'est rare : il y a du matériel incompatible avec
certaines options.

Thomas.

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Selon Roger Mampey <Roger.Mampey@cert.fr>:

| Selon Thomas Nemeth :
|
| > Attention : les noyaux debian sont parfois patchés et donc ne
| > correspondent pas forcément aux noyaux vanilla.
| >
| Ah ! Ca doit suffire à expliquer pourquoi il y a une différence. Est-ce
| qu'il est possible d'obtenir sur le site de la Debian les sources
| correspondant aux images qu'elle propose ?

Pour les paquets habituels c'est le cas : il suffit d'aller sur la
page concernant le paquet et tu as le .tar.orig et le patch.
Maintenant je ne sais pas ce qu'il en est du noyau mais je ne vois
pas pourquoi il en serait autrement.

| > Tiens donc ? Qu'entends-tu par "disparition" ?
| > Veux-tu dire que c'est commenté par un # suivi de "is not set" ?
| >
| Non, ca n'apparait plus du tout. Attention : CONFIG_EXT2_FS et
| CONFIG_EXT3_FS sont toujours là, ce qui disparait, ce sont des
| parametres de type CONFIG_EXT?_FS_XATTR* et CONFIG_EXT?_FS_POSIX_ACL A
| part ca, il y a d'autres disparitions.

Ça doit être dû aux patches qui sont différents.

| > As-tu plutôt tenté de faire un 'make oldconfig' ?
| >
| Je connais config, menuconfig et xconfig. Mais pas oldconfig. Ficheux
| recommande chaudement d'éviter config, alors oldconfig :-)

S'il recommande d'éviter config c'est que depuis les débuts du noyau
de nombreuses options et un support matériel immense ont été rajoutés
alors que 'make config' passe toutes les options une par une... Tu
imagines le souk si tu devais te taper toutes les options à la suite
:) ?

| Je suppose
| que oldconfig ne prend aucune initiative alors que ce n'est visiblement
| pas le cas de menuconfig. Je vais regarder si j'ai ca.

oldconfig ne te pose de question que sur les nouvelles options par
rapport à ton ancien noyau.

| > Il aurait fallu le message exact de ton kernel panic,
| >
| "Attempted to kill init !" :-)

Ouch !

| > 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 ?
| >
| Correction, c'est 2.4.27. Mais j'ai installé tout le répertoire
| /lib/modules/2.4.27 sur la cible. Non vide avec les bons droits et
| modules.dep non vide.

Et il y a quoi en module ?
Pour un noyau minimal bien réduit il ne devrait pas y en avoir
beaucoup (voire aucun).

| A part ca, j'ai essayé une autre manip qui tue :
|
| Je pars toujours du fichier de config de la cible et j'utilise toujours
| menuconfig et je supprime le support des modules sans m'occuper de
| quoique ce soit d'autre (en vérifiant quand meme que les anciens modules
| indispensables - network, ide, ... - sont bien passés de 'm' à 'y'), La
| compilation du noyau échoue dans le répertoire .../drivers/isdn/eicon.
| Je vais reessayer en supprimant le support isdn, mais ca énerve surtout
| quand on ne sait pas exactement de quoi on a absolument besoin.

Tu ne sais pas de quoi tu vas avoir besoin ?
Généralement, lorsque tu fais de l'embarqué, tu sais exactement sur
quelle cible tu va mettre ton noyau. À ce titre, j'enlève tout ce qui
n'est pas directement en rapport avec le matos que je veux faire
marcher (et généralement le matos est peu complexe, dans l'embarqué).

En l'occurence nous avons développé dans ma boite une carte CPU ARM
avec plein de ressources mais seulement certaines sont utilisées par
les cartes "métier" utilisant cette carte CPU : à chaque nouvelle
carte j'adapte le noyau en virant les ressources non utilisées par la
carte métier... Mais cela implique de connaître parfaitement le matos.

Avant de faire un noyau essaye de te renseigner sur le matériel que
tu dois supporter. Si c'est pour faire un test sur ton propre pécé,
alors prend la doc de ta carte mère, de tes périfs etc. et ne prend
les pilotes que de ce que tu veux supporter. Peu importe si tout
n'est pas présent, il te suffit de tester et rajouter ce qui te manque
au fur et à mesure que tu t'en rends compte (pense alors à tout noter
à chaque modif).

| Peut-etre bien qu'un fichier de config pour noyau amaigri sur PC serait
| une meilleure base de départ. Mais quand meme, un échec à la compilation
| en remplacant (en laissant make menuconfig le faire) tous les modules
| par du code interne noyau. est-ce bien normal ?

Oui même si c'est rare : il y a du matériel incompatible avec
certaines options.

Thomas.

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vous avez filtré cet utilisateur ! Consultez son message

Selon Roger Mampey :

| Selon Thomas Nemeth :
|
| > Attention : les noyaux debian sont parfois patchés et donc ne
| > correspondent pas forcément aux noyaux vanilla.
| >
| Ah ! Ca doit suffire à expliquer pourquoi il y a une différence. Est-ce
| qu'il est possible d'obtenir sur le site de la Debian les sources
| correspondant aux images qu'elle propose ?

Pour les paquets habituels c'est le cas : il suffit d'aller sur la
page concernant le paquet et tu as le .tar.orig et le patch.
Maintenant je ne sais pas ce qu'il en est du noyau mais je ne vois
pas pourquoi il en serait autrement.

| > Tiens donc ? Qu'entends-tu par "disparition" ?
| > Veux-tu dire que c'est commenté par un # suivi de "is not set" ?
| >
| Non, ca n'apparait plus du tout. Attention : CONFIG_EXT2_FS et
| CONFIG_EXT3_FS sont toujours là, ce qui disparait, ce sont des
| parametres de type CONFIG_EXT?_FS_XATTR* et CONFIG_EXT?_FS_POSIX_ACL A
| part ca, il y a d'autres disparitions.

Ça doit être dû aux patches qui sont différents.

| > As-tu plutôt tenté de faire un 'make oldconfig' ?
| >
| Je connais config, menuconfig et xconfig. Mais pas oldconfig. Ficheux
| recommande chaudement d'éviter config, alors oldconfig :-)

S'il recommande d'éviter config c'est que depuis les débuts du noyau
de nombreuses options et un support matériel immense ont été rajoutés
alors que 'make config' passe toutes les options une par une... Tu
imagines le souk si tu devais te taper toutes les options à la suite
:) ?

| Je suppose
| que oldconfig ne prend aucune initiative alors que ce n'est visiblement
| pas le cas de menuconfig. Je vais regarder si j'ai ca.

oldconfig ne te pose de question que sur les nouvelles options par
rapport à ton ancien noyau.

| > Il aurait fallu le message exact de ton kernel panic,
| >
| "Attempted to kill init !" :-)

Ouch !

| > 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 ?
| >
| Correction, c'est 2.4.27. Mais j'ai installé tout le répertoire
| /lib/modules/2.4.27 sur la cible. Non vide avec les bons droits et
| modules.dep non vide.

Et il y a quoi en module ?
Pour un noyau minimal bien réduit il ne devrait pas y en avoir
beaucoup (voire aucun).

| A part ca, j'ai essayé une autre manip qui tue :
|
| Je pars toujours du fichier de config de la cible et j'utilise toujours
| menuconfig et je supprime le support des modules sans m'occuper de
| quoique ce soit d'autre (en vérifiant quand meme que les anciens modules
| indispensables - network, ide, ... - sont bien passés de 'm' à 'y'), La
| compilation du noyau échoue dans le répertoire .../drivers/isdn/eicon.
| Je vais reessayer en supprimant le support isdn, mais ca énerve surtout
| quand on ne sait pas exactement de quoi on a absolument besoin.

Tu ne sais pas de quoi tu vas avoir besoin ?
Généralement, lorsque tu fais de l'embarqué, tu sais exactement sur
quelle cible tu va mettre ton noyau. À ce titre, j'enlève tout ce qui
n'est pas directement en rapport avec le matos que je veux faire
marcher (et généralement le matos est peu complexe, dans l'embarqué).

En l'occurence nous avons développé dans ma boite une carte CPU ARM
avec plein de ressources mais seulement certaines sont utilisées par
les cartes "métier" utilisant cette carte CPU : à chaque nouvelle
carte j'adapte le noyau en virant les ressources non utilisées par la
carte métier... Mais cela implique de connaître parfaitement le matos.

Avant de faire un noyau essaye de te renseigner sur le matériel que
tu dois supporter. Si c'est pour faire un test sur ton propre pécé,
alors prend la doc de ta carte mère, de tes périfs etc. et ne prend
les pilotes que de ce que tu veux supporter. Peu importe si tout
n'est pas présent, il te suffit de tester et rajouter ce qui te manque
au fur et à mesure que tu t'en rends compte (pense alors à tout noter
à chaque modif).

| Peut-etre bien qu'un fichier de config pour noyau amaigri sur PC serait
| une meilleure base de départ. Mais quand meme, un échec à la compilation
| en remplacant (en laissant make menuconfig le faire) tous les modules
| par du code interne noyau. est-ce bien normal ?

Oui même si c'est rare : il y a du matériel incompatible avec
certaines options.

Thomas.

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Thomas Labourdette

10/06/2005 à 16:10

Le Vendredi 10 Juin 2005 15:34, Roger Mampey a écrit :

Selon Thomas Labourdette :
>Autrement en faisant un
>apt-get source kernel-source-2.4.27

J'ai fait ca, j'obtiens 3 fichiers (les 2 dont tu parles + un *.dsc) et
un répertoire nommé kernel-source-2.4.27-2.4.27/

Il contient les sources du noyau debian.

J'en conclus que le-dit répertoire est celui d'origine. Tu ne parles pas
de ce répertoire qui pour moi devrait résulter de tar xzvf
kernel-source-....orig.tar.gz ?

Lui il contient les sources originaux sans les patches

Questions annexes : Ya t'il un moyen de récupérer sur le site Debian
simplement le tgz des sources patchées sans passer par un paquet Debian
? Sinon, je l'extrais comment de l'archive *.deb (j'aimerais m'épargner
le temps nécessaire à devenir un empaqueteur-dépaqueteur confirmé si
c'est possible; un coup d'oeil à 'man deb' ne m'a pas suffit) ?

Bon je résume :
si tu veux les sources d'un noyau à la sauce debian,
apt-get install kernel-source-la.version.que.tu.veux
et tu décompresses le fichier kernel-source-etc.bz2 qui se trouvera
dans /usr/src

si tu veux les sources originaux qu'a utilisé debian pour faire un noyau à sa
sauce,
apt-get source kernel-source-la.version.que.tu.veux
et la tout est dans le orig.tar.gz

J'espère avoir été clair

@+

PS : ne pas me mettre en copie merci
--
Côme TOULMONDE (signature aléatoire)
AUTOBUS : Véhicule qui roule deux fois plus vite quand on court après
que lorsqu'on est dedans.

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

gdialog ..

10 réponses

Veuillez sélectionner un problème