PXE-Boot funktioniert nicht (OPSI 4.0.7, CentOS 7)

[T.Thiemann]

Hallo!

In folgendem Beitrag war ein, aus meiner Sicht, identisches Problem beschrieben. Leider ist die "Lösung" bei mir wohl nicht passend.
https://forum.uib.de/viewtopic.php?f=7& ... dd69d0a3bc

OPSI 4.0.7 läuft bei uns auf CentOS 7, das ist wiederum in einer HyperV-VM Gen2 gesteckt, welcher unter Server2016 läuft.
Windows Server 2016 Domäne
Clients, die installiert werden sollen: Windows 10 pro

Bei der installation bin ich als OPSI-Neuling brav nach Handbuch vorgegangen.


Alles, was man beim Versuch eines PXE-Boots auf dem Monitor des Clients sieht ist:

Code: Alles auswählen

CLIENT MAC ADDR: [MAC]
CLIENT IP: 10.x.y.23 MASK: 255.255.255.0 DHCP IP: 10.x.y.254
GATEWAY IP: 10.x.y.254
TFTP.
PXE-M0F Exiting Intel Boot Agent

Keine sonstigen Fehlermeldungen. Der Rechner bootet dann gewöhnlich weiter (in das vorinstallierte Windows) und hat wunderbaren Zugriff auf Netzwerk und Internet. Secure-Boot/UEFI ist deaktiviert, da das Modul UEFI Boot laut opsi:4447/configed.jnlp nicht aktiviert ist.
IP-Adressverteilung funktioniert einwandfrei, wie man auch an der Meldung sieht, IPs und Subnetz passen.


Ein tcpdump port tftp -v auf dem OPSI-Server liefert beim Bootversuch des Clients NICHTS.

Von einem Rechner im Netz tftp -i OPSI get linux/pxelinux.0:
Nach einiger Zeit am Client: "Verbindungsaufforderung fehlgeschlagen"

Im tcpdump gibt es mehrfach diese Zeilen:

Code: Alles auswählen

19:06:05... IP (tos 0x0, ttl 127, id 279, offset 0, flags [none], proto UDP (17), length 53)
	10.x.y.z.50838 > opsi.unsere.domain.com.tftp:   25 RRQ "linux/pxelinux.0" octet

und schließlich:

Code: Alles auswählen

19:11:44.123456 IP (tos 0x0, ttl 127, id 21954, offset 0, flags [none] proto UDF (17), length 51)
 	10.x.y.z.50838 > opsi.unsere.domain.com.tftp: 23 ERROR EUNDEF "timeout on receive"

Die Fehlermeldung finde ich etwas nichtssagend. Hat da jemand eine Idee?

Die Datei pxelinux.0 ist vorhanden:

Code: Alles auswählen

ll /tftpboot/linux/pxelinux.0
-rw-rw-r--. 1 opsiconfd pcpatch 15710  6. Jun 14:27 /tftpboot/linux/pxelinux.0

In der tftpd-Datei scheint auch alles zu passen:

Code: Alles auswählen

# cat /etc/xinetd.d/tftpd
service tftpd
{
	disable		= no
	socket_type	= dgram
	protocol		= udp
	wait			= yes
	user			= root
	server		= /usr/sbin/in.tftpd
	server_args	= /tftpboot
	per_source	= 11
	cps			= 100 2
	flags			= IPv4
}

opsi-set-rights mehrfach durchlaufen gelassen.
Versucht (wegen dem oben verlinkten Beitrag) mal ein chmod -R 777 /tftpboot/linux auszuprobieren: Keine Verbesserung, also per opsi-set-rights alles wieder gerade gezogen.

Es wurde in mehreren Forenbeiträgen geraten in /var/log/syslog zu schauen: Die Datei gibt es nicht.



Der Switch (3810M) ist DHCP-Server und hat als TFTP-Server IP und DNS-Namen den OPSI-Server eingetragen. als bootfile ist linux/pxelinux.0 eingetragen
Da ich erstmal die VLANs und unterschiedliche Subnetze als Fehlerquelle ausschließen wollte, ist dieser Test-Client-PC im gleichen VLAN / IP-Bereich wie der OPSI-Server: 10.x.y.0/24


Hat von euch einer eine Idee, warum ich nicht von PXE-Booten / nicht auf den tftp zugreifen kann? Ich sehe es einfach nicht und könnte ein paar gute Tipps gebrauchen!

[wolfbardo]

Geht

Code: Alles auswählen

tftp localhost
get linux/pxelinux.0

?

Gruss
Bardo Wolf

[T.Thiemann]

Geht

Code: Alles auswählen

tftp localhost
get linux/pxelinux.0

?
Gruss
Bardo Wolf

Gute Idee, Bardo!

... yum install tftp...
Rest wie oben von Dir vorgeschlagen: Transfer klappt wunderbar, Datei wird gespeichert.

Also funktioniert tftp prinzipiell.


SELINUX habe ich DISABLED, da ich sonst die Dateien in smb-Freigaben nicht gesehen habe. Irgendwo stand wohl, dass man anstelle von disabled auf permissive gehen müsse. Das probiere ich mal aus.
So, ausprobiert: Nope, das war es nicht.
SELINUX=permissive, dafür dann setenforce 0 (was letztendlich jeden Schutz deaktiviert und nur loggt).
smb-Freigaben funktionieren noch, tftp: wie vorher.

Weitere Ideen?

[ueluekmen]

Mal ein Schuss ins Blaue, kann man an der Hyper-V Netzwerkeinstellung fummeln? Ich habe ein ähnliches Phänomen gehabt mit einer virtuellen Bridge und Virtualbox. Wenn ich das richtig verstanden habe geht der tftp auf dem Server selbst. Das bedeutet, dass TFTP, xinetd und die Pfade alle korrekt arbeiten. Das der Server nach außen nicht reagiert ist entweder eine Blockade von SELinux oder FW, oder zwischen Hyper-V Server und Client stimmt was nicht. Loggt der hyper-V in irgendeiner Form? Sorry, aber hyper-V ist jetzt bei uns zumindest nicht weit verbreitet

[uncle_scrooge]

Am Switch per Wireshark/tcpdump den broadcast traffic beim Boot Deiner VM mitschneiden.
Ist im DHCP offer alles drin, was der Mensch so braucht?
Wie sieht der ARP traffic aus?
(Es gibt Gerüchte, daß MS in aktuellen Hyper-V Versionen mal wieder den ein oder anderen Bock geschossen hat. Btw. welchen Build setzt ihr ein?).

Alternativ/zusätzlich einen physikalischen Client in diesem Netz per PXE booten. Wie weit kommt er? Timeout? Oder kurze Anzeige eines Menüs?

[SisterOfMercy]

SELINUX habe ich DISABLED, da ich sonst die Dateien in smb-Freigaben nicht gesehen habe. Irgendwo stand wohl, dass man anstelle von disabled auf permissive gehen müsse. Das probiere ich mal aus.
So, ausprobiert: Nope, das war es nicht.
SELINUX=permissive, dafür dann setenforce 0 (was letztendlich jeden Schutz deaktiviert und nur loggt).
smb-Freigaben funktionieren noch, tftp: wie vorher.

Never disable selinux, this will mess things up if you ever want to enable it again. Setting it to permissive is the thing you would want in the first place. When everything is working, and you have everything under control, then you might set some selinux booleans and make a policy from the things that are logged.

Anyway, have you looked at your firewall settings? Are you using that network manager thing?

[T.Thiemann]

Am Switch per Wireshark/tcpdump den broadcast traffic beim Boot Deiner VM mitschneiden.
Ist im DHCP offer alles drin, was der Mensch so braucht?
Wie sieht der ARP traffic aus?
(Es gibt Gerüchte, daß MS in aktuellen Hyper-V Versionen mal wieder den ein oder anderen Bock geschossen hat. Btw. welchen Build setzt ihr ein?).

Alternativ/zusätzlich einen physikalischen Client in diesem Netz per PXE booten. Wie weit kommt er? Timeout? Oder kurze Anzeige eines Menüs?

Haaaaalt! Das ist KEINE VM, das ist ein physikalischer Client! (Lenovo ThinkCentre M910q)
HyperV nutze ich für den Server.

[T.Thiemann]

Never disable selinux, this will mess things up if you ever want to enable it again. Setting it to permissive is the thing you would want in the first place. When everything is working, and you have everything under control, then you might set some selinux booleans and make a policy from the things that are logged.

Anyway, have you looked at your firewall settings? Are you using that network manager thing?

Hi SisterOfMercy,
SELINUX is back to permissive - that doesn't change anything.

Firewall is disabled.

[uncle_scrooge]

Vorausgesetzt, daß Deine Informationen (richtige VLAN, richtige Netzmasken, etc.) korrekt sind, muß das funktionieren.
Ich würde jetzt wirklich am Switch einen mirror port einrichten, und wireshark anwerfen.
Vorher vielleicht noch am DHCP-Server mal den bootfile name von linux/pxelinux.0 auf /linux/pxelinux.0 ändern.
(Ja, ich habe zur Kenntnis genommen, daß lokal auf dem OPSI-Server ein tftp gegen linux/pxelinux.0 funktioniert. Ist aber eine ganz andere Baustelle.)

[T.Thiemann]

Das mit dem Pfad glaube ich erstmal nicht, da der Zugriff auf die tftp-Freigabe von einem anderen Rechner aus schon nicht funktioniert.
Und beim Bootversucht loggt tcpdump überhaupt keinen Zugriff. Da geht nichts...

Werde wohl oder übel einen Mirrorport aufmachen müssen und mich dann mal mit wireshark versuchen. Musste ich bisher noch nie, wird also was neues. :-/ Blöd - zur Zeit ist viel los und das sollte doch "ganz einfach" funktionieren! So war zumindest der Plan...