linux zamrozić przy pomocy pxe, gdy jest więcej niż 1 interfejs sieciowy


2

Mam skonfigurowane 2 maszyny wirtualne z virtualbox:

  1. pierwszy (nazwany później serwerem) działa jako serwer dhcp (isc-dhcp-server) i tftp (atftpd)
  2. drugi (nazwany później „klientem”) jako komputer bezdyskowy.

Proces rozruchu klienta rozpoczyna się od syslinux, który ładuje jądro Linuksa przekazując mu argumenty initrd=ram_test.img nfsroot=10.0.0.1:/srv/nfsroot/stretch,rw ip=dhcp rw.

Komputery są zdefiniowane jako 64-bitowe, serwer uruchamia się na stabilnej wersji Debiana, a klient ma zapewnioną stabilną wersję Debiana, na której można również uruchomić komputer.

Nie ma żadnych problemów, gdy klient ma tylko 1 interfejs sieciowy (sieć wewnętrzna, karta typu „intel pro / 100MT Desktop (8254OEM)”), ale gdy tylko dodam inny tego samego typu, z innym adresem MAC, wszystko działa ok, dopóki Linux nie spróbuje pobrać adresu DHCP.

W tym momencie system zawiesza się na frazie „losowy: szybka inicjacja wykonana”. Inne rzeczy, które widzę wcześniej i są prawdopodobnie bardziej interesujące, to:

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

Po zamrożeniu, 323 sekundy później, pojawia się tylko „random: crng init done”.

Oto 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";
}

Aby wszystko działało (przynajmniej z tylko 1 interfejsem), musiałem zmodyfikować plik, /srv/nfsroot/stretch/etc/initramfs-tools/initramfs.confaby wyglądał tak (usunięto komentarze i puste linie):

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

Myślę, że problem pochodzi z argumentów dostarczonych do jądra w konfiguracji syslinux lub, initramfs.confale nie mogę znaleźć dokładnego punktu, w którym zawodzę, a przeszukiwanie sieci również nie powiodło się.

Pisząc to wszystko, zauważyłem wiersz DEVICE=eth0w initramfs.confi pomyślałem, że może tak być, ale właśnie próbowałem zmienić parametry jądra linux-a, aby je dodać, net.ifnames=0 biosdevname=0aby jądro używało starych nazw eth0 / eth1, ale zachowanie jest identyczne (z wyjątkiem, oczywiście, że nazwy w logach nie są już enpXsY, ale ethZ).

Istotą posiadania 2 interfejsów sieciowych na tej maszynie wirtualnej jest to, że system ten jest przeznaczony do wdrażania systemów (za pomocą cdebootstrap i skryptów ręcznych, już działających) na sprzęcie, który ma 2 interfejsy sieciowe. Nie miałem okazji wypróbować tego w prawdziwej sytuacji, ale jestem przekonany, że problem też tam będzie (dlaczego by tego nie zrobił?), Więc naprawdę chciałbym tu mieć jakieś opinie.

Dzięki i przepraszam za WoT.

Odpowiedzi:


1

po appendlinii w pliku pxelinux cfg dodaj opcję:

ipappend 2

Dzięki temu jądro rozruchowe wykona transakcję DHCP przy użyciu karty rozruchowej PXE


Wracając do tego, miałem inne problemy z różnymi systemami (testy, w których z virtualbox, z kartami płyty głównej MANO842 nadal miałem problemy z uruchamianiem), ale dzięki tym informacjom udało mi się znaleźć informacje, których potrzebowałem na tej stronie . Krótko mówiąc, ipappend wydaje się przestarzałe, zamiast tego użyj sysappend i można użyć BOOTIF = MA: CA: DD: RE: SS: 00, aby określić, który iface ma zostać użyty. Może to pomóc innym, którzy mają ten problem później.
user3459474

ipappend nie jest przestarzałe. The SYSAPPEND option, introduced in Syslinux 5.10, is an enhancement of a previous IPAPPEND option which was only available on PXELINUX.
Pat

0

Oto krótki i krótki opis tego ...

Podczas uruchamiania klienta bezdyskowego PXE, jeśli klient ten ma wiele interfejsów sieciowych, jądro może albo wpaść w panikę jądra, albo zawiesi się konfiguracja IP.

Dzieje się tak dlatego, że w IP-Config występuje błąd i nikt tak naprawdę nie chce go naprawić. Zasadniczo IP-Config zbyt szybko i powtarzalnie uderza w serwer DHCP. Z tego powodu DHCP nie odpowiada po raz drugi (lub trzeci), gdy IP-Config go uderzy. Dlatego IP-Config nie może rozwiązać DHCP i bez adresu IP nie można skonfigurować katalogu głównego, a następnie jądro ulega awarii.

Obejście jest następujące (jeśli używasz 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

Jeśli używasz zwykłego środowiska PXE:

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

Nie oczekuję, że twoje wpisy będą wyglądać dokładnie tak. To tylko przykłady . Edytuj odpowiednio swoje.

1) Musisz ustawić statyczny adres IP bezpośrednio w parametrach jądra (lub w dodatku). Jeśli nie, IP-Config spróbuje uruchomić DHCP i tego nie chcesz .

2) Chcesz zmusić PXE do wysyłania zapytań tylko z jednego interfejsu karty sieciowej, a nie ze wszystkich. Aby zmusić go do używania tylko jednego interfejsu, używasz „sieci ksdevice = bootif BOOTIF = $ {netX / mac}” w iPXE i używasz „IPAPPEND 2” w zwykłym PXE. Napisz dokładnie tak, jak pokazano powyżej.

To jest to! Dwa proste kroki i będziesz na dobrej drodze.

BOOTIF zmusza PXE do korzystania tylko z głównego interfejsu, na którym załadowano PXE. Zignoruje wszystkie pozostałe interfejsy. IPAPPEND robi dokładnie to samo.


Dzięki za najważniejsze informacje. Głosowałem, ale ponieważ nie mam wystarczającej reputacji ... cóż ... W każdym razie wyjaśnia to różne rzeczy i myślę, że pxelinux faktycznie używa jednego z opisanych przez ciebie obejść, a mianowicie drugiego.
user3459474
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.