Ce ne sont pas les sources d'un noyau 2.4.7-10 mais la version 10 du paquet des sources du noyau 2.4.7.
J'en suis pas convaincu. De toute façon je confirme après vérification que j'ai les sources des noyaux d'origine sur mes CD de RedHat (6.0,6.2,7.0,7.3,8 et 9). Comme d'un fait exprès on a jamais installé ou utilisé de 7.2 à la boite :-)
Le fichier de config du kernel si c'est celui de la distribution doit pouvoir se trouver.
Oui, mais tu avais dit de faire une configuration minimale. Ce n'est pas du tout la même chose.
On est d'accord, mais ça coute rien de tester un module compilé de cette manière, tout en gardant une porte de sortie évidemment.
-- Floris Dubreuil
Nicolas George a écrit :
Et comme souvent quand on veut faire une remarque de gros bon sens bien
gras, c'est une bêtise.
Ouais, mais chercher uniquement un bon vieux rpm d'époque avec des
œillères c'est une bêtise aussi.
Ce ne sont pas les sources d'un noyau 2.4.7-10 mais la version 10 du paquet
des sources du noyau 2.4.7.
J'en suis pas convaincu. De toute façon je confirme après vérification
que j'ai les sources des noyaux d'origine sur mes CD de RedHat
(6.0,6.2,7.0,7.3,8 et 9).
Comme d'un fait exprès on a jamais installé ou utilisé de 7.2 à la boite :-)
Le fichier de config du kernel si c'est celui de la distribution doit
pouvoir se trouver.
Oui, mais tu avais dit de faire une configuration minimale. Ce n'est pas du
tout la même chose.
On est d'accord, mais ça coute rien de tester un module compilé de cette
manière, tout en gardant une porte de sortie évidemment.
Ce ne sont pas les sources d'un noyau 2.4.7-10 mais la version 10 du paquet des sources du noyau 2.4.7.
J'en suis pas convaincu. De toute façon je confirme après vérification que j'ai les sources des noyaux d'origine sur mes CD de RedHat (6.0,6.2,7.0,7.3,8 et 9). Comme d'un fait exprès on a jamais installé ou utilisé de 7.2 à la boite :-)
Le fichier de config du kernel si c'est celui de la distribution doit pouvoir se trouver.
Oui, mais tu avais dit de faire une configuration minimale. Ce n'est pas du tout la même chose.
On est d'accord, mais ça coute rien de tester un module compilé de cette manière, tout en gardant une porte de sortie évidemment.
-- Floris Dubreuil
Nicolas George
Floris wrote in message <48ea9616$0$11976$:
Ouais, mais chercher uniquement un bon vieux rpm d'époque avec des œillères c'est une bêtise aussi.
Non, au contraire, c'est l'unique solution correcte. Ce fichier qui a été perdu provenait d'un RPM, le seul endroit où le retrouver avec garantie d'avoir la bonne version, c'est ce même RPM.
J'en suis pas convaincu.
N'en sois pas convaincu si tu veux, le fait demeure que 2.4.7-10 n'a jamais été un numéro de version de noyau Linux.
On est d'accord, mais ça coute rien de tester un module compilé de cette manière
Ça peut au contraire faire absolument n'importe quoi, y compris causer des pertes de données.
Floris wrote in message <48ea9616$0$11976$426a74cc@news.free.fr>:
Ouais, mais chercher uniquement un bon vieux rpm d'époque avec des
œillères c'est une bêtise aussi.
Non, au contraire, c'est l'unique solution correcte. Ce fichier qui a été
perdu provenait d'un RPM, le seul endroit où le retrouver avec garantie
d'avoir la bonne version, c'est ce même RPM.
J'en suis pas convaincu.
N'en sois pas convaincu si tu veux, le fait demeure que 2.4.7-10 n'a jamais
été un numéro de version de noyau Linux.
On est d'accord, mais ça coute rien de tester un module compilé de cette
manière
Ça peut au contraire faire absolument n'importe quoi, y compris causer des
pertes de données.
Ouais, mais chercher uniquement un bon vieux rpm d'époque avec des œillères c'est une bêtise aussi.
Non, au contraire, c'est l'unique solution correcte. Ce fichier qui a été perdu provenait d'un RPM, le seul endroit où le retrouver avec garantie d'avoir la bonne version, c'est ce même RPM.
J'en suis pas convaincu.
N'en sois pas convaincu si tu veux, le fait demeure que 2.4.7-10 n'a jamais été un numéro de version de noyau Linux.
On est d'accord, mais ça coute rien de tester un module compilé de cette manière
Ça peut au contraire faire absolument n'importe quoi, y compris causer des pertes de données.
Floris
Nicolas George a écrit :
Non, au contraire, c'est l'unique solution correcte. Ce fichier qui a été perdu provenait d'un RPM, le seul endroit où le retrouver avec garantie d'avoir la bonne version, c'est ce même RPM.
A ton avis, c'est quoi ça ? une brochure publicitaire pour la nouvelle clio ?
N'en sois pas convaincu si tu veux, le fait demeure que 2.4.7-10 n'a jamais été un numéro de version de noyau Linux.
Je n'ai jamais dit ça non plus. Pour moi c'est la 10ème version du noyau 2.4.7 compilé sur/avec/pour redhat 7.2
Ça peut au contraire faire absolument n'importe quoi, y compris causer des pertes de données.
_AVANT_ de faire quoique ce soit de ce style sur un système, il faut évidemment s'assurer d'avoir des sauvegardes et/ou des images, ainsi qu'une procédure fiable de restauration. Ça aurait été le cas, la petite tulipe n'aurait pas disparue.
-- Floris Dubreuil
Nicolas George a écrit :
Non, au contraire, c'est l'unique solution correcte. Ce fichier qui a été
perdu provenait d'un RPM, le seul endroit où le retrouver avec garantie
d'avoir la bonne version, c'est ce même RPM.
A ton avis, c'est quoi ça ? une brochure publicitaire pour la nouvelle
clio ?
N'en sois pas convaincu si tu veux, le fait demeure que 2.4.7-10 n'a jamais
été un numéro de version de noyau Linux.
Je n'ai jamais dit ça non plus. Pour moi c'est la 10ème version du noyau
2.4.7 compilé sur/avec/pour redhat 7.2
Ça peut au contraire faire absolument n'importe quoi, y compris causer des
pertes de données.
_AVANT_ de faire quoique ce soit de ce style sur un système, il faut
évidemment s'assurer d'avoir des sauvegardes et/ou des images, ainsi
qu'une procédure fiable de restauration.
Ça aurait été le cas, la petite tulipe n'aurait pas disparue.
Non, au contraire, c'est l'unique solution correcte. Ce fichier qui a été perdu provenait d'un RPM, le seul endroit où le retrouver avec garantie d'avoir la bonne version, c'est ce même RPM.
A ton avis, c'est quoi ça ? une brochure publicitaire pour la nouvelle clio ?
N'en sois pas convaincu si tu veux, le fait demeure que 2.4.7-10 n'a jamais été un numéro de version de noyau Linux.
Je n'ai jamais dit ça non plus. Pour moi c'est la 10ème version du noyau 2.4.7 compilé sur/avec/pour redhat 7.2
Ça peut au contraire faire absolument n'importe quoi, y compris causer des pertes de données.
_AVANT_ de faire quoique ce soit de ce style sur un système, il faut évidemment s'assurer d'avoir des sauvegardes et/ou des images, ainsi qu'une procédure fiable de restauration. Ça aurait été le cas, la petite tulipe n'aurait pas disparue.
-- Floris Dubreuil
Nicolas George
Floris wrote in message <48eb1805$0$31358$:
A ton avis, c'est quoi ça ?
Tu y vois un fichier dont le nom se termine par .o, toi ?
Je n'ai jamais dit ça non plus.
Si.
_AVANT_ de faire quoique ce soit de ce style sur un système, il faut évidemment s'assurer d'avoir des sauvegardes et/ou des images, ainsi qu'une procédure fiable de restauration. Ça aurait été le cas, la petite tulipe n'aurait pas disparue.
Sans blague ?
Tu ne veux pas arrêter d'accumuler les conneries de plus en plus grosses pour tenter de couvrir les précédentes ?
Floris wrote in message <48eb1805$0$31358$426a34cc@news.free.fr>:
A ton avis, c'est quoi ça ?
Tu y vois un fichier dont le nom se termine par .o, toi ?
Je n'ai jamais dit ça non plus.
Si.
_AVANT_ de faire quoique ce soit de ce style sur un système, il faut
évidemment s'assurer d'avoir des sauvegardes et/ou des images, ainsi
qu'une procédure fiable de restauration.
Ça aurait été le cas, la petite tulipe n'aurait pas disparue.
Sans blague ?
Tu ne veux pas arrêter d'accumuler les conneries de plus en plus grosses
pour tenter de couvrir les précédentes ?
Tu y vois un fichier dont le nom se termine par .o, toi ?
Je n'ai jamais dit ça non plus.
Si.
_AVANT_ de faire quoique ce soit de ce style sur un système, il faut évidemment s'assurer d'avoir des sauvegardes et/ou des images, ainsi qu'une procédure fiable de restauration. Ça aurait été le cas, la petite tulipe n'aurait pas disparue.
Sans blague ?
Tu ne veux pas arrêter d'accumuler les conneries de plus en plus grosses pour tenter de couvrir les précédentes ?
Floris
Floris a écrit :
Nicolas George a écrit :
Non, au contraire, c'est l'unique solution correcte. Ce fichier qui a été perdu provenait d'un RPM, le seul endroit où le retrouver avec garantie d'avoir la bonne version, c'est ce même RPM.
Non, au contraire, c'est l'unique solution correcte. Ce fichier qui a été
perdu provenait d'un RPM, le seul endroit où le retrouver avec garantie
d'avoir la bonne version, c'est ce même RPM.
Non, au contraire, c'est l'unique solution correcte. Ce fichier qui a été perdu provenait d'un RPM, le seul endroit où le retrouver avec garantie d'avoir la bonne version, c'est ce même RPM.
On Mon, 6 Oct 2008 23:55:29 +0200, "Nicolas S." wrote:
Jean Bon (de Parme) a écrit:
L'argument imparable : ne faites pas d'erreur de manip.
Et pourquoi pas un système de régénération automatique à la Windows tant qu'on y est ?
En option a activer manuelement, pourquoi pas...
You are root, you are responsible for your action.
Oui mais l'erreur est humaine meme en root.
Bernard
Le Sun, 05 Oct 2008 23:09:22 +0300, Rakotomandimby (R12y) Mihamina a écrit :
etc...
J'ai recherché dans mes CDs d'installation de RH 7.2 et, effectivement, je n'y ai pas trouvé le fichier tulip-cb.o. tulip-cb.c s'y trouve (et aussi sur mon système), mais cela ne m'avance guère, car je ne sais pas régénérer le module en .o. J'hésite encore à faire une install complète avec le cd d'origine, car je commence à douter du succès de l'opération, par ailleurs risquée : l'installation originelle remonte à plusieurs années, et, depuis lors, j'ai fait des modifs dont je n'ai pas conservé un compte exact, il convient de dire que j'ai depuis lors travaillé sur plusieurs PCs, perso et boulot, avec RH 6.0, RH 7.2, Debian Sarge (d'où j'écris le présent message), et que j'ai, il y a plusieurs années, recompilé plusieurs noyaux d'origine pour leur adjoindre des fonctionalités diverses (par exemple, des zip drives, que je n'utilise absolument plus aujourd'hui, et d'autres choses dont j'ai perdu le souvenir. Sur mon TP600, je crois me rappeler que j'ai encore le noyau d'origine d'install. Ces précisions simplement pour expliquer pourquoi je ne sais plus trop d'où pouvait provenir le fichier tulip_cb.o que j'ai perdu, qu'il s'agisse de l'install d'origine ou d'une intervention ultérieure telle qu'une installation à partir d'un fichier compilable trouvé sur le web.
A ce stade, donc, j'ai tenté d'exploiter les possibilités d'un autre module, lequel se trouve toujours bien sur mon système : xircom_tulip_cb.o. Et désormais il ne m'est plus précisé que tulip_cb.o est introuvable ; le système ne me dit plus que la carte n'est pas reconnue ; le module xircom_tulip_cb apparaît bien dans la liste affichée par /sbin/lsmod (avec la mention "unused"), ce qui n'est déjà pas si mal... mais par la suite j'ai des erreurs que je ne sais convenablement interpréter. Si cela se trouve, cela fonctionne, mais il manque quelque chose derrière :
localhost cardmgr[815]: watching 2 sockets localhost kernel: cs: IO port probe 0x0c00-0x0cff: clean localhost kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x130-0x137 0x3b8-0x3df 0x4d0-0x4d7 localhost kernel: cs: IO port probe 0x0a00-0x0aff: clean localhost pcmcia: done localhost kernel: cs: memory probe 0xa0000000-0xa0ffffff: clean localhost cardmgr[816]: socket 0: IBM 10/100 Etherjet Cardbus Adapter localhost rc: Starting pcmcia: succeeded localhost rc: cardmgr[816]: get dev info on socket 0 failed: Resource temporalily unavailable
Peut-être convient il que j'active quelque chose à ce stade ? Ou que je teste quelque chose ?
Ah, au fait, il va sans dire que, si je place la carte EtherJet dans l'autre slot, j'ai une réponse exactement identique, à ceci près que "socket 1" et "socket 0" sont inversés dans les messages
Merci d'avance pour toute suggestion.
Ah, au fait, ma véritable adresse ne figure pas dans le champ "from", la voici donc : , pour ceux qui préféreraient m'écrire en perso.
Le Sun, 05 Oct 2008 23:09:22 +0300, Rakotomandimby (R12y) Mihamina a
écrit :
etc...
J'ai recherché dans mes CDs d'installation de RH 7.2 et, effectivement,
je n'y ai pas trouvé le fichier tulip-cb.o. tulip-cb.c s'y trouve (et
aussi sur mon système), mais cela ne m'avance guère, car je ne sais pas
régénérer le module en .o. J'hésite encore à faire une install
complète avec le cd d'origine, car je commence à douter du succès de
l'opération, par ailleurs risquée : l'installation originelle remonte
à plusieurs années, et, depuis lors, j'ai fait des modifs dont je n'ai
pas conservé un compte exact, il convient de dire que j'ai depuis lors
travaillé sur plusieurs PCs, perso et boulot, avec RH 6.0, RH 7.2, Debian
Sarge (d'où j'écris le présent message), et que j'ai, il y a plusieurs
années, recompilé plusieurs noyaux d'origine pour leur adjoindre des
fonctionalités diverses (par exemple, des zip drives, que je n'utilise
absolument plus aujourd'hui, et d'autres choses dont j'ai perdu le
souvenir. Sur mon TP600, je crois me rappeler que j'ai encore le noyau
d'origine d'install. Ces précisions simplement pour expliquer pourquoi je
ne sais plus trop d'où pouvait provenir le fichier tulip_cb.o que j'ai
perdu, qu'il s'agisse de l'install d'origine ou d'une intervention
ultérieure telle qu'une installation à partir d'un fichier compilable
trouvé sur le web.
A ce stade, donc, j'ai tenté d'exploiter les possibilités d'un autre
module, lequel se trouve toujours bien sur mon système :
xircom_tulip_cb.o. Et désormais il ne m'est plus précisé que tulip_cb.o
est introuvable ; le système ne me dit plus que la carte n'est pas
reconnue ; le module xircom_tulip_cb apparaît bien dans la liste
affichée par /sbin/lsmod (avec la mention "unused"), ce qui n'est déjà
pas si mal... mais par la suite j'ai des erreurs que je ne sais
convenablement interpréter. Si cela se trouve, cela fonctionne, mais il
manque quelque chose derrière :
localhost cardmgr[815]: watching 2 sockets
localhost kernel: cs: IO port probe 0x0c00-0x0cff: clean
localhost kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x130-0x137
0x3b8-0x3df 0x4d0-0x4d7
localhost kernel: cs: IO port probe 0x0a00-0x0aff: clean
localhost pcmcia: done
localhost kernel: cs: memory probe 0xa0000000-0xa0ffffff: clean
localhost cardmgr[816]: socket 0: IBM 10/100 Etherjet Cardbus Adapter
localhost rc: Starting pcmcia: succeeded
localhost rc: cardmgr[816]: get dev info on socket 0 failed: Resource
temporalily unavailable
Peut-être convient il que j'active quelque chose à ce stade ? Ou que
je teste quelque chose ?
Ah, au fait, il va sans dire que, si je place la carte EtherJet dans
l'autre slot, j'ai une réponse exactement identique, à ceci près que
"socket 1" et "socket 0" sont inversés dans les messages
Merci d'avance pour toute suggestion.
Ah, au fait, ma véritable adresse ne figure pas dans le champ "from", la
voici donc : bdebreil@teaser.fr, pour ceux qui préféreraient m'écrire
en perso.
Le Sun, 05 Oct 2008 23:09:22 +0300, Rakotomandimby (R12y) Mihamina a écrit :
etc...
J'ai recherché dans mes CDs d'installation de RH 7.2 et, effectivement, je n'y ai pas trouvé le fichier tulip-cb.o. tulip-cb.c s'y trouve (et aussi sur mon système), mais cela ne m'avance guère, car je ne sais pas régénérer le module en .o. J'hésite encore à faire une install complète avec le cd d'origine, car je commence à douter du succès de l'opération, par ailleurs risquée : l'installation originelle remonte à plusieurs années, et, depuis lors, j'ai fait des modifs dont je n'ai pas conservé un compte exact, il convient de dire que j'ai depuis lors travaillé sur plusieurs PCs, perso et boulot, avec RH 6.0, RH 7.2, Debian Sarge (d'où j'écris le présent message), et que j'ai, il y a plusieurs années, recompilé plusieurs noyaux d'origine pour leur adjoindre des fonctionalités diverses (par exemple, des zip drives, que je n'utilise absolument plus aujourd'hui, et d'autres choses dont j'ai perdu le souvenir. Sur mon TP600, je crois me rappeler que j'ai encore le noyau d'origine d'install. Ces précisions simplement pour expliquer pourquoi je ne sais plus trop d'où pouvait provenir le fichier tulip_cb.o que j'ai perdu, qu'il s'agisse de l'install d'origine ou d'une intervention ultérieure telle qu'une installation à partir d'un fichier compilable trouvé sur le web.
A ce stade, donc, j'ai tenté d'exploiter les possibilités d'un autre module, lequel se trouve toujours bien sur mon système : xircom_tulip_cb.o. Et désormais il ne m'est plus précisé que tulip_cb.o est introuvable ; le système ne me dit plus que la carte n'est pas reconnue ; le module xircom_tulip_cb apparaît bien dans la liste affichée par /sbin/lsmod (avec la mention "unused"), ce qui n'est déjà pas si mal... mais par la suite j'ai des erreurs que je ne sais convenablement interpréter. Si cela se trouve, cela fonctionne, mais il manque quelque chose derrière :
localhost cardmgr[815]: watching 2 sockets localhost kernel: cs: IO port probe 0x0c00-0x0cff: clean localhost kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x130-0x137 0x3b8-0x3df 0x4d0-0x4d7 localhost kernel: cs: IO port probe 0x0a00-0x0aff: clean localhost pcmcia: done localhost kernel: cs: memory probe 0xa0000000-0xa0ffffff: clean localhost cardmgr[816]: socket 0: IBM 10/100 Etherjet Cardbus Adapter localhost rc: Starting pcmcia: succeeded localhost rc: cardmgr[816]: get dev info on socket 0 failed: Resource temporalily unavailable
Peut-être convient il que j'active quelque chose à ce stade ? Ou que je teste quelque chose ?
Ah, au fait, il va sans dire que, si je place la carte EtherJet dans l'autre slot, j'ai une réponse exactement identique, à ceci près que "socket 1" et "socket 0" sont inversés dans les messages
Merci d'avance pour toute suggestion.
Ah, au fait, ma véritable adresse ne figure pas dans le champ "from", la voici donc : , pour ceux qui préféreraient m'écrire en perso.
Floris
Bernard a écrit : > Merci d'avance pour toute suggestion.
J'ai trouvé le RPM officiel RedHat contenant ton module compilé pour une 7.2 et j'ai fourni tout les liens ici même.
Il y a le kernel, les sources du kernel, les modules compilés de base, et bien entendu le fichier tulip.o
Tu n'as même pas lu ton propre fil de discutions entièrement...
Ton fichier est là: ftp://ftp.sunet.se/pub/Linux/distributions/redhat/redhat-archive/redhat/linux/7.2/fr/os/i386/RedHat/RPMS/kernel-BOOT-2.4.7-10.i386.rpm
A bon entendeur...
-- Floris Dubreuil
Bernard a écrit :
> Merci d'avance pour toute suggestion.
J'ai trouvé le RPM officiel RedHat contenant ton module compilé pour une
7.2 et j'ai fourni tout les liens ici même.
Il y a le kernel, les sources du kernel, les modules compilés de base,
et bien entendu le fichier tulip.o
Tu n'as même pas lu ton propre fil de discutions entièrement...
Ton fichier est là:
ftp://ftp.sunet.se/pub/Linux/distributions/redhat/redhat-archive/redhat/linux/7.2/fr/os/i386/RedHat/RPMS/kernel-BOOT-2.4.7-10.i386.rpm
Bernard a écrit : > Merci d'avance pour toute suggestion.
J'ai trouvé le RPM officiel RedHat contenant ton module compilé pour une 7.2 et j'ai fourni tout les liens ici même.
Il y a le kernel, les sources du kernel, les modules compilés de base, et bien entendu le fichier tulip.o
Tu n'as même pas lu ton propre fil de discutions entièrement...
Ton fichier est là: ftp://ftp.sunet.se/pub/Linux/distributions/redhat/redhat-archive/redhat/linux/7.2/fr/os/i386/RedHat/RPMS/kernel-BOOT-2.4.7-10.i386.rpm
