Installe un noyau récent. Les cartes realtek sont bien reconnues. Tu as essayé avec le CD de CefAgreg ou ClefOffi?
Mmmm si c’est la distro dont tu me parlais plus tôt : pas encore, à l’heure ou j’écris ces lignes (j’étais pas là ce soir), mais je regarde tout ça demain soir. Promis… yeah, faut que ça marche… ca marchera…
Chris
yo,
Donc voilà. Quand je passe par le mii-tools, j’ai seulement:
SIOCGMIIPHY on eth0failed
SIOCGMIIPHY on eth1failed
Quand je passe par iostat, j’ai :
avg-cpu: %user %nice %system %iowait %steal %idle
0,18 0,00 0,43 2,01 0,00 97,38
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 17,93 389,11 80,36 108516 22412
sdf 0,20 2,83 0,02 788 5
au niveau de syslog j’ai dû merder qq part car il ne m’a pas copier le résultat sur le fichier c’t’endouille… mais je vois un eth0 et un eth1 link down. Zut… je vais renvoyer ça demain (il est tard).
J’ai gravé ton image (cleoffi), il démarre en “live” sans pb, en soi, mais… il semble qu’il ne monte pas le système de fichier. Donc viandage.
j’ai des “rm : not found”, “mkdir : not found” etc… et surtout un "kernel panic - not syncing:VFS:unable to mount fs or unknow-block(3,5).
Mais j’ai peut-être mal gravé mon truc. Chai-pas. A voir.
Thx,
Chris.
Hello,
Voilà le résultat de ce soir…
Tout d’abord, chose étrange et bien relou : tout comme au début, pour une raison indéterminée, quand le poste est éteint ou sous linux, de nouveau, sur le switch, je n’ai plus qu’un led d’allumé (celui qui correspond à la connexion de la liveBox, je dirai). L’autre, qui correspond à la connexion de la carte est au noir. Si je change de prise RJ45, c’est la même chose ailleurs. Si j’intervertis les câbles, idem. Par contre, dès que je met Windows, pof, tout s’allume et fonctionne correctement.
Ca l’avait fait au début, puis, sans raison, même sous linux ou même quand le poste était éteint, tout s’était allumé (ce qui est le comportement normal de mon switch, comme je peux le voir avec les autres pc ou mon ancien serveur), puis… Ca a recommencé.
A l’évidence, si c’était douteux avant, il était clair que je n’aurais pas de liaison dans ces conditions…
Les messages que me renvoie Syslog :
Jul 17 00:00:07 Monstre kernel: eth1394: eth0: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Jul 17 00:00:07 Monstre kernel: r8169: eth1: link up
Jul 17 00:01:30 Monstre kernel: NETDEV WATCHDOG: eth1: transmit timed out
Jul 18 00:32:03 Monstre kernel: eth1394: eth0: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Jul 18 00:32:03 Monstre kernel: r8169: eth1: link up
Jul 18 00:33:56 Monstre kernel: NETDEV WATCHDOG: eth1: transmit timed out
Jul 21 22:00:21 Monstre kernel: eth1394: eth0: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Jul 21 22:00:21 Monstre kernel: r8169: eth1: link down
Jul 21 22:09:11 Monstre kernel: eth1394: eth0: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Jul 21 22:09:11 Monstre kernel: r8169: eth1: link down
Jul 21 22:16:38 Monstre kernel: eth1394: eth0: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Jul 21 22:16:38 Monstre kernel: r8169: eth1: link down
Jul 21 22:57:52 Monstre kernel: eth1394: eth0: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Jul 21 22:57:52 Monstre kernel: r8169: eth1: link up
Jul 21 22:59:45 Monstre kernel: NETDEV WATCHDOG: eth1: transmit timed out
Jul 21 23:08:10 Monstre kernel: eth1: RTL8100e at 0xffffc20000032000, ff:ff:ff:ff:ff:ff, IRQ 185
Jul 21 23:08:11 Monstre kernel: Modules linked in: r8169 nls_iso8859_1 nls_cp437 vfat fat nfs nfsd exportfs lockd nfs_acl sunrpc ppdev parport_pc lp parport button ac battery dm_snapshot dm_mirror dm_mod sbp2 loop tsdev sg psmouse i2c_i801 sr_mod serio_raw i2c_core pcspkr cdrom eth1394 evdev ext3 jbd mbcache sd_mod usb_storage ide_core ohci1394 ahci ieee1394 libata scsi_mod ehci_hcd uhci_hcd thermal processor fan
Jul 21 23:11:45 Monstre kernel: eth1394: eth0: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Jul 21 23:11:45 Monstre kernel: r8169: eth1: link down
Jul 21 23:13:08 Monstre kernel: r8169: eth1: link down
Jul 21 23:13:33 Monstre kernel: r8169: eth1: link down
Jul 21 23:16:45 Monstre kernel: eth1: RTL8168b/8111b at 0xffffc20000078000, 00:1e:8c:c5:4d:44, IRQ 185
Jul 21 23:16:45 Monstre kernel: r8169: eth1: link down
Jul 24 00:05:53 Monstre kernel: eth1394: eth0: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Jul 24 00:05:53 Monstre kernel: r8169: eth1: link up
Jul 24 21:56:13 Monstre kernel: eth1394: eth0: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Jul 24 21:56:13 Monstre kernel: r8169: eth1: link down
Jul 24 22:13:40 Monstre kernel: eth1394: eth0: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Jul 24 22:13:40 Monstre kernel: r8169: eth1: link down
Avec un dmesg :
eth0: RTL8168b/8111b at 0xffffc2000004a000, 00:1e:8c:c5:4d:44, IRQ 185
eth1394: eth0: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
r8169: eth1: link down
Les mii-tools me renvoient :
SIOCGMIIPHY on eth0failed: Operation not supported
SIOCGMIIPHY on eth1failed: Operation not supported
Not Mii interfaces found
Et du reste, au démarrage, j’entrevois :
"SADC Not enabled in /etc/default/sysstat, not starting
J’ai aussi une copie de la configuration du Kernel (le “config” dans /boot), tel qu’il est compilé actuellement (par défaut, pour le moment). Je le dis au cas où, si ça t’intéresse. J’y ai jeté un oeil : tout me parait honnête, à priori.
J’ai jeté un oeil dans le bios : la carte est enabled.
J’ai aussi rééssayé de lancer ton live, mais le résultat est le même. Toutefois, c’est peut-être de ma faute : il semble que j’ai utilisé un DVD-R Philips. Pas le plus adapté… J’ai été un peu vite, hier. Vu l’heure je ne vais pas remener l’opération, mais… demain ou samedi au plus tard (j’aurais du temps), je vais :
1.Choper du CD+RW et rééssayer de booter sur le live.
2.Voir ce qui se passe avec NDISWRAPPER, si je l’utilise (sauf si tu as une meilleure idée).
3.Voir, si j’ai le temps, choper une nouvelle clé et copier le live dessus, en suivant ton lien (qui me sera utile. C’est justement un truc que je voulais apprendre à faire. Ca tombe bien).
4.J’ai bien envie de voir ce que ça donne avec une Debian 32bits. La machine, en principe, vu sa configuration physique, prends les 64, mais peut - logiquement - prendre aussi les 32, right? (l’inverse n’étant pas possible sur des machines non optimisées pour les 64, évidemment).
Si j’ai le temps de tout faire, bien sûr…
Faudra ensuite que je tente l’installation d’un autre noyau, plus récent.
Juste un truc qui peut être utile à savoir : comment sont gérées les cartes réseau, lorsque les machines sont éteintes? Sur tout mes postes, y compris celui-ci jusque hier, même quand les postes sont éteints, les leds sont tous allumés sur la façade avant du switch (il y a deux leds par ports physiques), indiquant ainsi, malgré tout, les connexions “up” des cartes. Ici, ce n’est plus le cas pour le pc à pb (un sur deux, donc, comme expliqué plus haut). Sauf une fois que Windows est démarré… Ce qui n’est certes pas le résultat escompté.
Eh beh… Tu vois, c’est pas évident. A priori, ce n’est pas la carte qui est déffectueuse. Par contre… est-il possible que HP ait fait en sorte que ça délire pour nous empêcher d’installer correctement Linux? Via le Bios? (je pose la question, au passage).
Thx,
Chris
Yo,
Juste histoire de te donner des nouvelle. Vu que l’installation par le réseau ne pouvait que partir en sucette, j’ai récupéré le CD de la lenny, afin de tester avec une distro munie d’un noyau plus récent (voire pour récupérer le noyau et tester la Etch avec). Je vois au passage que l’interface d’installation a évolué. Sympa.
Je voulais déjà tester tel quel, puis compiler le noyau, qui à réinstaller celui-ci sur la Etch (qu’importe… après tout).
Ce n’est pas possible :
En dehors du fait qu’au démarrage je vois ceci :
Erreur constatée:
PCI:Bios Bug :MCFG area at e0000000 E820 is not reserved
PCI: MCFG - not using MMConfig
(qui n’a peut-être rien à voir avec le problème. J’ai récupéré quelques informations ici : forums.fedora-fr.org/viewtopic.php?id=14929. Comme il était minuit passé, j’ai pas poussé plus loin la recherche).
L’installation se bloque sur “détection du matériel réseau” (0%).
Il a passé cette étape à une reprise, tout de même (!!), puis comme la mise en place des partitions à planté, j’ai recommencé et là, plus rien : de nouveau bloqué au même endroit. En fait j’ai même eu du mal à réinstaller la Etch et j’ai fini par passer un coup de gparted pour faire sauter les partitions (qu’au passage j’ai réinstallé au propre).
J’envisageais, un moment, de faire ceci : installer la Lenny sur mon portable, recompiler et copier le noyau que j’installerai sur la Etch, sur le PC. Mais… mon portable serait en 32 bits, la Etch non. Zut… à moins d’installer une 32 sur la machine, ce sera pas possible (soit dit en passant, c’est un test que j’ai aussi effectué. Là encore, en vain - tjs pas de réseau).
Dis-moi… je pense à ça au moment ou j’écris ces humbles lignes : En dehors de l’hypothèse du noyau ou d’un module deffectueux, il est possible qu’une configuration de la carte, effectuée (par défaut : je n’y ai pas touché) sous Windows, puisse bloquer le redémarrage de la carte sous linux? Je vais fouiner un peu ce soir, mais je crois bien avoir vu, hier, quelques références à ce type de problèmes, sur la toile.
Thx
Chris
Bonjour,
jamais entendu parler de windows ou de BIOS qui bloquent une cate ethernet, mais les fabriquants comme HP ne savent plus quoi inveter parfois …
Tant qu’a essayé un live CD, essaie SIDUX, c’est une debian.
Hello Piratebab
Non, j’ai pas tenté cette live là. A voir.
Je vais rééssayer ce soir, pour l’install de la débian Lenny… quoique… il parait que la Etch est sorti avec le noyau 2.6.24. Ce serait la pure occasion d’essayer ça. Qq sait s’il y a une version pour l’amd64?
Thx,
Chris
Essaie la méthode préférée du grand chef: un chroot depuis un live CD.
?
Dans quel sens? Le chroot te permet d’isoler une application ou un user dans une racine que l’on a choisie pour lui.
Je suis prêt à essayer ton truc, bien sûr, surtout si j’apprends quelque chose de nouveau au passage, mais… si tu pouvais être plus explicite…
Thx,
Chris
Voir la doc officielle:
http://www.debian.org/releases/stable/i386/apds03.html.fr
Mat est l’expert dans ce domaine.
Salut, j’ai eu aussi un souci avec une debian recente et ce type de carte, problème que je n’ai pas pu résoudre, c’est apparement un souci de drivers :
ubuntuforums.org/archive/index.php/t-582453.html
Si tu trouves la solution ca m’interesse.
Bonne chance
yo,
Ben, en fait j’ai l’impression que pas mal de monde a connu ce problème sur des configurations assez variées, mais tjs avec les realtek 8168 ou 9.
Mais regarde… je viens de faire une trouvaille (totalement par hasard, en plus, en reniflant via google) :
viewtopic.php?f=3&t=14863&st=0&sk=t&sd=a&start=0
“Papy” a connu le même problème et… dispose presque du même matériel que moi! (à par mes 4 go de Ram, il a le même processeur, le même kernel et la même carte réseau)
Muarf!!!
Je lis ceci:
“Le module e1000 sert à piloter des contrôleurs ethernet Intel, pas Realtek ! Le contrôleur Realtek 8168/8111 est piloté par le module r8169. L’ennui, c’est que le module r8169 du noyau 2.6.18 ne supporte pas encore ce contrôleur. Sa prise en charge n’apparaît que dans le noyau 2.6.19, à moins que le noyau Debian ait été patché. Et encore, il y a des bugs parfois graves touchant l’initialisation (il y aurait des interactions avec la mise en veille et le pilote Windows sur les systèmes en dual boot) qui sont corrigés dans les versions ultérieures.”
Merci, PascalHambourg… lol. Si tu savais ça, pourquoi, damn’it, tu ne me l’as pas expliqué ici (ou du moins comme ça)? J’ai quasiment la même configuration et l’origine de mon pb me parait potentiellement liée à cette explication, non? (encore que papy ne parle pas de paquets droppés). En tout cas, truc utile : le lien vers l’image du noyau. CA, c’est utile… Un noyau 2.6.24, en plus!
Je vais tester tout ça ce soir…
Croisons les doigts.
Thx,
Chris
Cela dit, Pascal (si tu lis ce post), tkt, c’est pas un drame… tu m’as aidé, je ne l’ai pas oublié.
Thx,
Chris
Depuis la semaine dernière il y a eu une mise à jour d’Etch du coup ils ont rendu disponible le noyau 2.6.24 (Debian GNU/Linux 4.0 – Notes de publication d’etch-et-demi).
Une simple mise à jour avec apt-get install linux-image-2.6.24-etchnhalf.1-486 devrait peut être te faire avancer
Désolé là je suis Etch/lenny/sid# apt-cache search linux-image-2.6.24
linux-headers-2.6.24-etchnhalf.1-486 - Header files for Linux 2.6.24 on x86
linux-headers-2.6.24-etchnhalf.1-686 - Header files for Linux 2.6.24 on PPro/Celeron/PII/PIII/P4
linux-headers-2.6.24-etchnhalf.1-686-bigmem - Header files for Linux 2.6.24 on PPro/Celeron/PII/PIII/P4
linux-headers-2.6.24-etchnhalf.1-amd64 - Header files for Linux 2.6.24 on AMD64
linux-image-2.6.24-etchnhalf.1-486 - Linux 2.6.24 image on x86
linux-image-2.6.24-etchnhalf.1-686 - Linux 2.6.24 image on PPro/Celeron/PII/PIII/P4
linux-image-2.6.24-etchnhalf.1-686-bigmem - Linux 2.6.24 image on PPro/Celeron/PII/PIII/P4
linux-image-2.6.24-etchnhalf.1-amd64 - Linux 2.6.24 image on AMD64
linux-image-2.6.24-1-486 - Linux 2.6.24 image on x86
linux-image-2.6.24-1-amd64 - Linux 2.6.24 image on AMD64
Mais ici on peut contstater que le noyau linux-image-2.6.24-etchnhalf.1-486 fait partie d’etch.[code]
apt-cache policy linux-image-2.6.24-etchnhalf.1-486
linux-image-2.6.24-etchnhalf.1-486:
Installé : (aucun)
Candidat : 2.6.24-6~etchnhalf.4
Table de version :
2.6.24-6~etchnhalf.4 0
500 http://ftp2.fr.debian.org etch/main Packages[/code]
hi dmon,
En fait, si tu remontes plus loin, tu verras que j’ai vu l’information. A propos du nouveau noyau.
Simplement, c’est l’explication de “pourquoi” ca délirait que j’ai découvert tout à l’heure qui m’a surpris. Mais je ne m’en plains pas : j’ai appris quelques trucs utiles en parlant avec Pascal et Fran.c.
Je ne peux pas utiliser apt-get… lol. Puisque je n’ai pas le réseau (à moins que, entre temps,le noyau n’ai été installé sur la version CD de la 64bits téléchargeable sur le site?).
En fait, je vais voir pour le récupérer sur le site - j’ai vu un lien quelque part - et l’installer avec ce bon vieux dpkg -i.
Par contre, j’ai quand même reçu le pilote linux de Realtek r8168 (quoiqu’on dise sur Realtek, ils font des pilotes pour linux, eux, au moins!). A tout hasard. Pour l’instant je ne vais pas l’utiliser, histoire de voir si ça fonctionne direct… Ce qui dépendra de la façon dont le nouveau noyau a été compilé, à la base (avec la même version de gcc, notamment). Sur ce point, je serai heureux d’avoir un avis, effectivement. Ca pourrait me faire gagner du temps (c’est que j’ai envie de faire joujou avec ma machine, moi!).
Thx,
Chris
Yo,
Par contre, en dehors de ma question précédente, il y a une chose que j’aimerais beaucoup savoir :
“Le contrôleur Realtek 8168/8111 est piloté par le module r8169. L’ennui, c’est que le module r8169 du noyau 2.6.18 ne supporte pas encore ce contrôleur. Sa prise en charge n’apparaît que dans le noyau 2.6.19, à moins que le noyau Debian ait été patché. Et encore, il y a des bugs parfois graves touchant l’initialisation (il y aurait des interactions avec la mise en veille et le pilote Windows sur les systèmes en dual boot) qui sont corrigés dans les versions ultérieures.”
Ce genre d’information… Où est-ce qu’on peut trouver ça?
Thx,
Chris
[quote=“sonador”]Je ne peux pas utiliser apt-get… lol. Puisque je n’ai pas le réseau (à moins que, entre temps,le noyau n’ai été installé sur la version CD de la 64bits téléchargeable sur le site?).
En fait, je vais voir pour le récupérer sur le site - j’ai vu un lien quelque part - et l’installer avec ce bon vieux dpkg -i.
[/quote]À mon avis les CD et DVD sont à jours aussi.
Yeah,
Effectivement, Je confirme :
debian.org/releases/stable/d … ex.en.html
J’ai pas encore fait l’install, mais je l’ai récupéré. En fait, il y a même une verison “update” :
debian-40r4-amd64-CD-1.iso 27-Jul-2008 02:39 647M
debian-update-4.0r4-amd64-CD-1.iso 28-Jul-2008 01:21 611M
(un correctif?)
Thx,
Chris
Yo,
Tout est ok. J’ai installé le noyau 2.6.24 et désormais, j’ai le réseau. J’ai même réinstallé VSFTPD, entre temps.
Merci pour votre aide à tous!
Chris