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.