linux congelar com pxe quando há mais de uma interface de rede


2

Eu configurei 2 máquinas virtuais com o virtualbox:

  1. o primeiro (servidor nomeado depois disso) um atua como servidor dhcp (isc-dhcp-server) e tftp (atftpd)
  2. o outro (chamado "cliente" depois disso) como um computador sem disco.

O processo de boot para o cliente começa com o syslinux, que carrega um kernel do Linux passando os argumentos initrd=ram_test.img nfsroot=10.0.0.1:/srv/nfsroot/stretch,rw ip=dhcp rw.

Os computadores são definidos como os de 64 bits, o servidor é inicializado em um Debian estável e o cliente tem um Debian estável para inicializar também.

Não há problemas quando o cliente tem apenas 1 interface de rede (rede interna, tipo de cartão "intel pro / 100MT Desktop (8254OEM)"), mas assim que eu adiciono outro do mesmo tipo, com um endereço MAC diferente, as coisas vão ok até que o linux tente buscar o endereço DHCP.

Nesse ponto, o sistema congela a frase "random: fast init done". As outras coisas que posso ver antes disso e provavelmente mais interessantes são:

e1000: enp0s8 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
IPv6: ADDRCONF(NETDEV_CHANGE): enp0s8: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): enp0s3: link becomes ready
IP-Config: no response after 2 secs - giving up
IP-Config: enp0s3 hardware address 08:00:27:2a:1a:3b mtu 1500 DHCP
IP-Config: enp0s8 hardware address 08:00:27:5f:de:30 mtu 1500 DHCP

Após o congelamento, 323 segundos depois, há apenas "random: crng init done".

Aqui está o dhcpd.conf:

allow booting;
allow bootp;
subnet 10.0.0.0 netmask 255.255.255.0 {
  #range: 10.0.0.0xC0/26
  range 10.0.0.192 10.0.0.250;
  option broadcast-address 10.0.0.255;
  option routers 10.0.0.1;
  filename "tftp://10.0.0.1/pxelinux.0";
}

Para fazer as coisas funcionarem (pelo menos, com apenas 1 interface), eu tive que modificar o arquivo /srv/nfsroot/stretch/etc/initramfs-tools/initramfs.conf para ficar assim (comentários e linhas vazias removidas):

MODULES=netboot
BUSYBOX=auto
KEYMAP=fr
COMPRESS=gzip
DEVICE=eth0
NFSROOT=auto
BOOT=nfs

Eu acho que o problema vem dos argumentos fornecidos ao kernel na configuração do syslinux, ou o initramfs.conf mas não consigo encontrar o ponto exato em que estou falhando, e pesquisar na Web também não foi bem-sucedido.

Enquanto escrevia tudo isso, notei a linha DEVICE=eth0 no initramfs.conf, e pensei que pode ser isso, mas eu apenas tentei alterar os parâmetros do kernel linux para adicioná-lo net.ifnames=0 biosdevname=0 para que o kernel use os nomes antigos eth0 / eth1, mas o comportamento é idêntico (exceto, é claro, que os nomes nos logs não são mais enpXsY mas ethZ).

O ponto de ter duas interfaces de rede nessa VM é porque esse sistema destina-se a implantar sistemas (por meio de scripts cdebootstrap e manuais, já funcionando) em hardware que possui duas interfaces de rede. Eu não tive a oportunidade de tentar isso em situação real, mas estou convencido de que o problema também estará lá (por que não?), Então eu realmente gostaria de ter algumas opiniões aqui.

Obrigado, e desculpe pelo WoT.

Respostas:


1

depois de append linha no seu arquivo pxelinux cfg adicione a opção:

ipappend 2

Isso fará com que o kernel de inicialização execute a transação DHCP usando o NIC de inicialização PXE.


Voltando atrás, eu tive alguns outros problemas com sistemas diferentes (os testes em que com o virtualbox, com placas de placas-mãe MANO842 eu ainda estava tendo problemas de inicialização), mas graças a essa informação, consegui encontrar as informações necessárias esta página . Em suma, o ipappend parece obsoleto, use o sysappend, e é possível usar o BOOTIF = MA: CA: DD: RE: SS: 00 para especificar qual iface deve ser usado. Isso pode ajudar outros a ter esse problema mais tarde.
user3459474

ipappend não é reprovado. The SYSAPPEND option, introduced in Syslinux 5.10, is an enhancement of a previous IPAPPEND option which was only available on PXELINUX.
Pat

0

Então, aqui está o longo e curto dele ...

Ao inicializar um cliente sem disco PXE, se esse cliente tiver várias interfaces de rede, o kernel pode travar em um kernel panic ou o IP-Config irá travar.

A razão pela qual isso acontece é porque há um bug no IP-Config e ninguém realmente se importa em consertá-lo. Essencialmente, o IP-Config está atingindo o servidor DHCP muito rapidamente e repetidamente. Por causa disso, o DHCP não responde a segunda (ou terceira) vez que o IP-Config o atinge. Portanto, o IP-Config não consegue resolver um DHCP e sem um IP, o diretório raiz não pode ser configurado e, em seguida, o kernel falha.

O trabalho é o seguinte (se você estiver usando o iPXE):

kernel ${base-url}vmlinuz-4.4.0-43-generic boot=nfs netboot=nfs quiet splash panic=30 nfsroot=10.0.0.1/root network ksdevice=bootif BOOTIF=${netX/mac} ip=${ip}:192.168.1.1:192.168.1.1:255.255.255.0:::none
initrd ${base-url}initrd.img-4.4.0-43-generic

Se você estiver usando o PXE regular:

KERNEL vmlinuz-4.4.0-43-generic 
IPAPPEND 2 
APPEND vga=794 boot=nfs root=/dev/nfs initrd=initrd.img-4.4.0-43-generic quiet splash panic=30 -- nfsroot=192.168.1.1:/root ip=192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0:::none

Não espero que suas entradas sejam exatamente assim. Estes são apenas exemplos . Então, edite o seu de acordo.

1) Você precisa definir um endereço IP estático diretamente nos parâmetros do kernel (ou no append). Se você não fizer isso, o IP-Config tentará executar o DHCP e você não quer isso .

2) Você quer forçar o PXE a consultar somente a partir de uma interface NIC e não de todas elas. Para forçá-lo a usar apenas uma interface, use "ksdevice = bootif BOOTIF = $ {netX / mac}" no iPXE e use "IPAPPEND 2" no PXE normal. Escreva exatamente como mostrado acima.

É isso aí! Dois passos fáceis e você estará a caminho.

O BOOTIF força o PXE a usar somente a interface principal na qual o PXE foi carregado. Isso vai ignorar todas as outras interfaces. IPAPPEND faz exatamente a mesma coisa.


Obrigado pelos destaques. Eu tenho upvoted, mas, desde que eu não tenho reputação suficiente ... bem ... Enfim, isso explica várias coisas, e eu acho que o pxelinux realmente usa uma das soluções alternativas que você descreveu, ou seja, o segundo.
user3459474
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.