Depuração de ethernet antes da inicialização do NFS

Question

Eu estou tentando inicializar o Linux a partir do U-boot em uma placa ARM embarcada usando um sistema de arquivos em uma máquina remota servida via NFS. Parece que a conexão ethernet não está chegando corretamente, o que resulta em uma falha na montagem do compartilhamento NFS. No entanto, sei que o hardware ethernet funciona, porque o U-boot carrega o kernel via TFTP.

Como posso depurar isso? Eu posso tentar mexer no kernel, mas isso significa recompilar o kernel para cada iteração, que é lenta. Existe uma maneira que eu possa fazer o kernel rodar sem poder montar um sistema de arquivos externo?

    

Answer 1

Você pode compilar uma imagem initrd no kernel ( General Setup -> Initial RAM filesystem and RAM disk (initramfs/initrd) support -> Initramfs source file(s) ). Você especifica o arquivo em formato especial como (meu init para x86):

dir /bin                                    0755 0 0
file    /bin/busybox                        /bin/busybox    0755 0 0
file    /bin/lvm                        /sbin/lvm.static0755 0 0
dir /dev                                    0755 0 0
dir /dev/fb                                 0755 0 0
dir /dev/misc                               0755 0 0
dir /dev/vc                                 0755 0 0
nod /dev/console                                0600 0 0    c  5   1
nod /dev/null                               0600 0 0    c  1   3
nod /dev/snapshot                               0600 0 0    c 10 231
nod /dev/tty1                               0600 0 0    c  4   0
dir /etc                                    0755 0 0
dir /etc/splash                             0755 0 0
dir /etc/splash/natural_gentoo                      0755 0 0
dir /etc/splash/natural_gentoo/images                   0755 0 0
file    /etc/splash/natural_gentoo/images/silent-1680x1050.jpg  /etc/splash/natural_gentoo/images/silent-1680x1050.jpg  0644 0 0
file    /etc/splash/natural_gentoo/images/verbose-1680x1050.jpg /etc/splash/natural_gentoo/images/verbose-1680x1050.jpg 0644 0 0
file    /etc/splash/natural_gentoo/1680x1050.cfg        /etc/splash/natural_gentoo/1680x1050.cfg        0644 0 0
slink   /etc/splash/tuxonice                    /etc/splash/natural_gentoo              0755 0 0
file    /etc/splash/luxisri.ttf                 /etc/splash/luxisri.ttf                 0644 0 0
dir /lib64                                  0755 0 0
dir /lib64/splash                               0755 0 0
dir /lib64/splash/proc                          0755 0 0
dir /lib64/splash/sys                           0755 0 0
dir /proc                                   0755 0 0
dir /mnt                                    0755 0 0
dir /root                                   0770 0 0
dir /sbin                                   0755 0 0
file    /sbin/fbcondecor_helper                 /sbin/fbcondecor_helper                 0755 0 0
slink   /sbin/splash_helper                 /sbin/fbcondecor_helper                 0755 0 0
file    /sbin/tuxoniceui_fbsplash               /sbin/tuxoniceui_fbsplash               0755 0 0
file    /sbin/tuxoniceui_text                   /sbin/tuxoniceui_text                   0755 0 0
dir /sys                                    0755 0 0
file    /init                           /usr/src/init   0755 0 0

Eu não usei isso no ARM, mas deve funcionar. /init é o arquivo que você pode colocar comandos de inicialização. Rest são vários arquivos necessários (como o busybox, etc.).

    

Answer 2

Algumas coisas que vêm à mente:

• Use o tcpdump, wireshark ou outro inspetor de pacotes Ethernet para ver se a placa está enviando pacotes para o endereço errado ou não enviando nada.
• O que você tem no console serial (se houver)?
• Tente conectar um depurador de kernel remoto .
• Tente executar dentro de um simulador, se você tiver um simulador em que possa reproduzir seu problema.
• Em vez de apenas buscar um kernel, coloque um sistema de arquivos boot-and-root na memória flash , ou carregue um sistema de arquivos raiz em um disco RAM .

Answer 3

Esta postagem está relacionada aos problemas de rede criados na pergunta, não à depuração do kernel.

Se o seu switch suportar o Spanning Tree Protocol (STP), tenha em mente que o STP pode não ativar a porta Ethernet no switch por 6 segundos ou mais, enquanto o STP faz o trabalho. Esse atraso pode começar de novo toda vez que o host redefine a porta Ethernet no host, o que pode acontecer várias vezes entre a ativação, a solicitação DHCP, quando o Kernel carrega os drivers de rede etc. Isso pode interferir nas inicializações do NFS para sistemas sem disco , DHCP, kickstart, etc. e causou muita dor de cabeça para muitos administradores de sistema. Para alguns exemplos, consulte RedHat Bug 189795 - Tempos limite de DHCP durante o Kickstart e este guia PXE .

A maioria dos switches high-end, como os switches Cisco e os switches HP ProCurve, suportam STP e é ativada para todas as portas prontas para uso.