Dopo aver installato Debian Squeeze Ethernet non compare


2

Dopo aver installato Debian stable (squeeze) ho scoperto che eth0 non stava arrivando, quando lo ho mostrato con "ifconfig eth0 up" è configurato solo IPv6. L'installazione è avvenuta in una rete con IPv6 abilitato attraverso un tunnel e un router radvd. Il che mi fa pensare che potrebbe aver deciso di disabilitare IPv4, non so come o perché.

Ho fatto molte installazioni in una rete abilitata per IPv6 come questa e Debian (o Ubuntu) sarebbe sempre in grado di usare IPv4, dato che tutti i driver e le configurazioni sono corretti.

La scheda madre è un mini-ITX VIA e-900. Ethernet è un dispositivo realtek 8168B:

05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06) 

Sono abbastanza sicuro che l'hardware sia riconosciuto, poiché "ifconfig -a" mostra eth0, "ifconfig eth0 up" lo visualizza e IPv6 è disponibile. Mi sono anche assicurato di ottenere il firmware giusto, syslog non segnala problemi durante il caricamento. Durante l'installazione la rete funzionava bene e il programma di installazione stava scaricando felicemente i pacchetti. Ho praticamente fatto tutto ciò che faccio sempre durante l'installazione, quando IPv4 funziona in seguito.

/ etc / network / interfaces è simile al seguente:

auto lo
    iface lo inet loopback

auto eth0
iface eth0 inet static
    address 10.2.2.9
    netmask 255.255.255.0
    broadcast 10.2.2.255
    network 10.2.2.0
    gateway 10.2.2.1

Ho rimosso il gestore della rete (mis). Anche se questo non ha risolto il problema.

Qualche idea di cosa potrebbe essere sbagliato? C'è qualche impostazione speciale che ho ignorato che può risolvere questo problema?

Aggiornamento: per chiarire, in realtà ottiene un IP da un router radvd sulla rete e posso fare un ping6 2001: 500: 88: 200 :: 10 (esempio.com), posso anche ssh nella macchina attraverso il suo indirizzo IPv6 . Quindi è chiaro che qualcosa sta impedendo la creazione di reti all'avvio. Penso che dovrò esaminare se non vengono caricati moduli.

Update2: l'aggiunta manuale della configurazione IPv4 tramite i comandi "ip" funziona e quindi anche IPv4 è attivo.

Risposte:


1

Ho quasi lo stesso problema. L'unica differenza è che funziona alla perfezione con il kernel 2.6 di installazione predefinito di compressione amd 64 e con l'ultimo kernel 2.6 di compressione amd disponibile per l'aggiornamento. Se poi passo a un kernel 3.x, non riesco a ottenere un indirizzo IPV4.

Sembra non avere nulla a che fare con il firmware (funziona con e senza il kernel 2.6 e non funziona mai con o senza un kernel 3.x). Inoltre, ho provato a installare il driver disponibile su realtek, ma senza successo.

Quindi, finirò per pensare che ci sia un bug tra questo modo di lavorare con la scheda realtek e il modo 3.x del kernel linux per gestire la rete.

Proverò a controllare questo fine settimana se riesco a farlo funzionare con IP statico se ho abbastanza tempo per gestire tutta la mia rete per funzionare senza DHCP.

Infine, e un po 'fuori tema, ma non c'è bisogno di dire come il mio punto di vista. Anni fa, quando acquistammo una scheda madre, dovemmo scegliere la nostra scheda audio e la nostra scheda di rete. Oggi TUTTE le schede madri forniscono una scheda audio e una scheda di rete, e spesso abbiamo problemi (nel mondo di Linux), con questo chip fornito. Quindi è stato solo per dire che preferisco davvero scegliere tutti i miei componenti da solo ...


+1 Sono pienamente d'accordo con il tuo ultimo punto. Inoltre sono d'accordo che non è il firmware. Il bug che ho presentato al sistema debian bug è stato chiuso per questo. Anch'io credo che possa (parzialmente) essere il driver realtek. Accetterò la tua risposta poiché accettare la mia in questo caso è un po 'sciocco.
aseq,

1

Penso che il problema sia legato a http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611954, quindi è specifico per il dispositivo ethernet realtek. Devo aggiungere "ifup eth0" a uno script di init (rc.local per ora) per ottenere effettivamente la piena rete all'avvio.

Quindi sembra essere un bug nel pacchetto firmware-realtek, probabilmente anche a monte.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610302 suggerisce di provare una versione del kernel più recente. Questo aiuta un po ', nel senso che caricherà la patch del firmware, ma il problema rimane.

Per illustrare, kernel 2.6.32-5:

r8169 0000:05:00.0: firmware: requesting rtl_nic/rtl8168e-1.fw
r8169 0000:05:00.0: eth0: link down
r8169 0000:05:00.0: eth0: link down
ADDRCONF(NETDEV_UP): eth0: link is not ready
r8169 0000:05:00.0: eth0: link up
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

In questo caso il kernel sta provando a caricare rtl8168e-1.fw e ci riesce. Presumo che non sia riuscito per quanto riguarda initramfs ed è per questo che lo sta caricando in seguito quando è stato eseguito "ifup".

Kernel 3.2.0-0.bpo.2:

r8169 0000:05:00.0: eth0: link down
r8169 0000:05:00.0: eth0: link down
ADDRCONF(NETDEV_UP): eth0: link is not ready
r8169 0000:05:00.0: eth0: link up
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

In questo caso, la patch del firmware rtl8168e-1.fw è stata caricata correttamente durante l'avvio, tuttavia la rete non è stata ancora creata.

Per essere chiari, entrambe le versioni del kernel hanno una connessione di rete funzionante se si esegue qualcosa come "ifup ethX".

Immagino che dovrò convivere con il lavoro fino a quando questo non sarà risolto.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.