Ah!
Ok… J’ai bien envie de mettre un noyau plus récent (ça ne peut pas faire de mal). Effectivement, c’est une 2.6.18. Je vais y réfléchir. Je vous dirai ce que je vous répondrai d’ici demain soir. Je vais lire le lien qu’a laissé Piratelab.
Thx,
Chris
hi,
Voilà,
J’ai donc fait quelques tests supplémentaires, avant d’envisager la solution de ndiswrapper ou de l’évolution du kernel.
Si je fais un lspci, j’ai :
00:00.0 Host bridge: Intel Corporation Unknown device 29c0 (rev 02)
00:01.0 PCI bridge: Intel Corporation Unknown device 29c1 (rev 02)
00:1a.0 USB Controller: Intel Corporation Unknown device 2937 (rev 02)
00:1a.1 USB Controller: Intel Corporation Unknown device 2938 (rev 02)
00:1a.7 USB Controller: Intel Corporation Unknown device 293c (rev 02)
00:1b.0 Audio device: Intel Corporation Unknown device 293e (rev 02)
00:1c.0 PCI bridge: Intel Corporation Unknown device 2940 (rev 02)
00:1c.2 PCI bridge: Intel Corporation Unknown device 2944 (rev 02)
00:1d.0 USB Controller: Intel Corporation Unknown device 2934 (rev 02)
00:1d.1 USB Controller: Intel Corporation Unknown device 2935 (rev 02)
00:1d.2 USB Controller: Intel Corporation Unknown device 2936 (rev 02)
00:1d.3 USB Controller: Intel Corporation Unknown device 2939 (rev 02)
00:1d.7 USB Controller: Intel Corporation Unknown device 293a (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation Unknown device 2916 (rev 02)
00:1f.2 RAID bus controller: Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH) SATA RAID Controller (rev 02)
00:1f.3 SMBus: Intel Corporation Unknown device 2930 (rev 02)
01:05.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 70)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
04:00.0 VGA compatible controller: nVidia Corporation Unknown device 0402 (rev a1)
Si je fais un lsmod, pour connaitre les modules montés, j’ai :
Module Size Used by
nls_iso8859_1 9856 1
nls_cp437 11520 1
vfat 18048 1
fat 57264 1 vfat
nfs 236216 0
nfsd 256200 17
exportfs 10368 1 nfsd
lockd 67600 3 nfs,nfsd
nfs_acl 8320 2 nfs,nfsd
sunrpc 166984 13 nfs,nfsd,lockd,nfs_acl
ppdev 14088 0
parport_pc 41640 0
lp 17736 0
parport 44684 3 ppdev,parport_pc,lp
button 12192 0
ac 10376 0
battery 15496 0
dm_snapshot 20664 0
dm_mirror 25216 0
dm_mod 62800 2 dm_snapshot,dm_mirror
sbp2 28680 0
loop 20112 0
tsdev 13056 0
sg 40744 0
psmouse 44432 0
i2c_i801 13076 0
sr_mod 22436 0
serio_raw 12036 0
i2c_core 27776 1 i2c_i801
pcspkr 7808 0
cdrom 40488 1 sr_mod
eth1394 24840 0
evdev 15360 1
ext3 138512 5
jbd 65392 1 ext3
mbcache 14216 1 ext3
sd_mod 25856 9
usb_storage 87872 1
ide_core 147584 1 usb_storage
ohci1394 38216 0
ahci 25092 6
ieee1394 361976 3 sbp2,eth1394,ohci1394
r8169 36872 0
libata 106784 1 ahci
scsi_mod 153008 7 sbp2,sg,sr_mod,sd_mod,usb_storage,ahci,libata
ehci_hcd 36104 0
uhci_hcd 28696 0
thermal 20240 0
processor 38248 1 thermal
fan 9864 0
filename: /lib/modules/2.6.18-6-amd64/kernel/drivers/net/r8169.ko
author: Realtek and the Linux r8169 crew netdev@vger.kernel.org
description: RealTek RTL-8169 Gigabit Ethernet driver
license: GPL
version: 2.2LK-NAPI
vermagic: 2.6.18-6-amd64 SMP mod_unload gcc-4.1
Et si je mate dans le détail les infos relatives à la carte, via un modinfo r8169 :
depends:
alias: pci:v000010ECd00008129svsdbcsci*
alias: pci:v000010ECd00008136svsdbcsci*
alias: pci:v000010ECd00008167svsdbcsci*
alias: pci:v000010ECd00008168svsdbcsci*
alias: pci:v000010ECd00008169svsdbcsci*
alias: pci:v00001186d00004300svsdbcsci*
alias: pci:v00001259d0000C107svsdbcsci*
alias: pci:v000016ECd00000116svsdbcsci*
alias: pci:v00001737d00001032svsd00000024bcsci
srcversion: 64EBAEB8E2D2228C72B9EB9
parm: debug:Debug verbosity level (0=none, …, 16=all) (int)
parm: use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm: rx_copybreak:Copy breakpoint for copy-only-tiny-frames (int)
parm: media:force phy operation. Deprecated by ethtool (8). (array of int)
si je fais un modprobe -r suivi un -a, le module descent et monte (du moins la seconde fois que je l’ai fait… la première fois, ca n’a pas marché).
lsmod|grep r8169
r8169 36872 0
Ca ne change rien. J’ai aussi essayé avec une Mandriva, mais le noyau était un 2.6.17. Toujours est-il que c’est la même chose.
Si je teste avec un liveCD, avec un System Rescue CD et en mettant une autre adresse IP:
system rescue cd.
address : 192.168.1.150. netmask 255.255.255.0
test :
ping 192.168.1.1
connect : Network is unreachable
Je vérifie le noyau:
uname -r
2.6.20.11-fd06
Donc un kernel plus réçent que le 2.6.18…
C’est dingue…
J’ai aussi changé les câbles. Même résultat. Je n’ai pas changé le switch (je peux le refaire, si besoin est, mais quand je l’ai fait la première fois, ca n’a pas changé grand-chose. Snif).
Je sèche… Si le problème vient d’un mauvais fonctionnement du module, on pourrait penser qu’avec le system Rescue CD, cela ourrait marcher, n’est ce pas? (à moins que le problème ne se répète au même niveau, ce qui parait improbable). Idem pour l’âge du kernel, puisque celui du System Rescue CD est plus récent. So What? Ca peut être un problème de firmware? Il y a un test qui pourrait me permettre de voir ça?
Je précise aussi que je n’ai pas fait le changement dans le fichier /etc/udev/rules.d/z25_persistent-net.rules, mais bon… le problème ne se situe pas là.
Je me pose une autre question. Quand je fais mon lpci, je vois :
Semiconductor Co., Ltd. RTL8111/8168B PCI
Tandis que via un lsmod, j’ai :
r8169 36872 0
(et non pas r8168b, par exemple).
Tu en penses quoi?
Thx,
Chris
Hi, j’ai regardé ton lien : le problème du gars était lié à la configuration “carte wifi”. J’ai une carte ethernet.
Par contre, qu’il me faille “n’diswrapper”, on va voir. C’est possible… C’est quand même spatial, tout ça… Apparemment la R8168/9 est courante sous Nunux. Pourtant je galère.
En tout cas, merci pour la suggestion.
Thx,
Chris
Bonjour,
Es-tu sur de ta config Livebox aussi ? je sais que les Freebox par exemple ne sont pde en mode routeur d’origine. Si tu te mets ta machine en config DHCP ca donne quoi ?
@+
En fait, je suis déjà en dhcp, oui. Mais tu peux être en dhcp et prendre une adresse qui ne soit pas dans l’étendue dhcp de façon à avoir une ip fixe. C’est courant.
Cela dit, je vais quand même regarder. Sache toutefois que j’ai fait un dhclient quand j’ai fait le test avec le live-cd. Et en retour du dhcpdiscover, j’ai eu un z’olie dhcpoffer qui m’a renvoyé dans le barbelé. En gros, un truc type “no dhcpoffer”. C’est logique, dans la mesure où je ne peux même pas pinguer la box (ce que je peux faire avec les autres machines - je le ferai plus tard mais pour le moment, j’ai gardé une configuration qui permet le ping).
Quand à la livebox… En principe, tel quel, y a rien qui empêche la machine de pinguer. Je n’ai pas interdit la machine au niveau du FW. Quand au mode routeur, je suppose que j’aurais des difficultés à faire communiquer mes deux autres bécanes ensemble s’il y avait un pb de ce côté-là.
Mais là aussi, bien sûr, je peux (re)voir. Ca coûte rien, tu as raison.
chris
Cela dit, avec le même nom de machine et la même IP (ou une autre), même machine, sous Win, ca marche impec’. A partir de là, s’il y avait une configuration intempestive, je suppose que ce serait pareil sous win, n’est ce pas? 
chris
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]
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]