Depois de instalar o Debian, o squeeze ethernet não aparece

Question

Depois de instalar o Debian stable (squeeze), descobri que o eth0 não está chegando, quando eu o mostro com o "ifconfig eth0 up" apenas o IPv6 está configurado. A instalação aconteceu em uma rede com o IPv6 ativado por meio de um túnel e um roteador radvd. O que me faz pensar que pode ter decidido desabilitar o IPv4, não sei como nem por quê.

Eu fiz muitas instalações em uma rede IPv6 como esta e o Debian (ou Ubuntu) sempre poderia usar o IPv4, dado que todos os drivers e configurações estão corretos.

A placa-mãe é uma VIA e-900 mini-ITX. Ethernet é um dispositivo realtek 8168B:

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

Tenho certeza que o hardware é reconhecido, já que "ifconfig -a" mostra eth0, "ifconfig eth0 up" o traz e o IPv6 está disponível. Eu também fiz questão de obter o firmware correto, o syslog não reporta problemas ao carregá-lo. Durante a instalação, a rede estava funcionando bem e o instalador estava felizmente baixando os pacotes. Eu praticamente fiz tudo que sempre faço ao instalar, quando o IPv4 está funcionando depois.

/ etc / network / interfaces é assim:

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

Eu removi o administrador da rede (mal). Embora isso não tenha resolvido isso.

Alguma ideia do que pode estar errado? Existe algum cenário especial que eu negligenciei e que pode consertar isso?

Atualização: Para deixar claro, ele realmente obtém um IP de um roteador radvd na rede e eu posso ping6 2001: 500: 88: 200 :: 10 (example.com), eu também posso ssh na máquina através de seu endereço IPv6. Então está claro que algo está impedindo a criação de redes na inicialização. Acho que vou ter que investigar se algum dos módulos não está sendo carregado.

Update2: A adição manual da configuração do IPv4 usando os comandos "ip" funciona e, em seguida, o IPv4 também está ativo.

    

Answer 1

Eu tenho quase o mesmo problema. A única diferença é que funciona bem com o squeeze padrão do kernel 64 do kernel de instalação do CD 2.6, e com o kernel 2.6 do kernel squeeze e 64 mais recente disponível para atualização. Se então eu passar para um kernel 3.x, não consigo obter um endereço IPV4.

Parece não ter nada a ver com o firmware (funciona com e sem o kernel 2.6 e nunca funciona com ou sem um kernel 3.x). Além disso, tentei instalar o driver disponível no realtek, mas sem sucesso também.

Então, eu vou acabar pensando que há um bug entre essa maneira de cartão realtek de trabalhar e a maneira do kernel linux 3.x de gerenciar a rede.

Tentarei verificar este fim de semana se conseguir fazê-lo funcionar com IP estático, se tiver tempo suficiente para gerenciar toda a minha rede para funcionar sem DHCP.

Finalmente, e um pouco fora de tópico, mas não é desnecessário dizer como meu ponto de vista. Anos atrás, quando compramos uma placa-mãe, tivemos que escolher nossa placa de som e nossa placa de rede. Hoje em dia TODAS as placas-mãe fornecem uma placa de som e uma placa de rede, e muitas vezes temos problemas (no mundo linux), com esses chips providenciais. Então foi só para dizer que eu realmente prefiro escolher todos os meus componentes por conta própria ...

    

Answer 2

Acho que o problema está relacionado ao link , por isso é específico para o ethernet realtek dispositivo. Eu tenho que adicionar "ifup eth0" a um script de inicialização (rc.local por enquanto) para realmente colocar a rede totalmente em funcionamento na inicialização.

Portanto, parece ser um bug no pacote firmware-realtek, provavelmente até no upstream.

O

link sugere que você experimente uma nova versão do kernel. Isso ajuda um pouco, no sentido de que vai carregar o patch de firmware, mas o problema continua.

Para ilustrar, o 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

Neste caso, o kernel está tentando carregar o rtl8168e-1.fw e obtendo sucesso. Eu suponho que não tenha sucesso com relação ao initramfs e é por isso que ele está sendo carregado mais tarde quando o "ifup" foi executado.

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

Nesse caso, o patch de firmware rtl8168e-1.fw foi carregado com sucesso durante a inicialização, embora a rede ainda não tenha surgido.

Para deixar claro, ambas as versões do kernel têm uma conexão de rede funcional se você executar algo como "ifup ethX".

Acho que vou ter que conviver com o trabalho até que isso seja resolvido.