PXE Chainloading error after FOG images menu

[***Redbob]

@Sebastian-Roth here you are:

[root@srvfog-mt ~]# iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
[root@srvfog-mt ~]# getenforce
Permissive
[root@srvfog-mt ~]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether a2:02:9d:1b:e5:0a brd ff:ff:ff:ff:ff:ff
    inet 172.24.3.71/22 brd 172.24.3.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::6d9c:8567:1786:2562/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

[george1421]

@Redbob So are you getting the error in the original message still? If you can call that url from a web browser you should be able to get there from pxe client.

Is the pxe booting client on the same subnet as the FOG server? There is something missing here…

[Sebastian Roth]

@Redbob Can you please take a picture of the iPXE error (connection reset) on screen and post that here?

As well I’d ask you to get the boot menu listing again and post here - but this time use the MAC address of the client having this issue: http://172.24.3.71/fog/service/ipxe/boot.php?mac=aa:bb:cc:dd:ee:ff (instead of aa:bb:cc:dd:ee:ff put in the correct client MAC)

[Sebastian Roth]

@Redbob said in PXE Chainloading error after FOG images menu:

I could access LEGACY Boot interface and I’m doing a deploy right now . But UEFI messages remain. Strange, because the interface of FOG menu changes color to red on black (The colors I set on server are blue on white).

Re-reading the things you posted I stumbled upon this and really wonder what that might mean. Do you mean PCs set to legacy boot are doing fine but all UEFI machines fail?

[***Redbob]

@george1421, PXE boot client is not in the same subnet. Boot Client is at VLAN 12 (172.24.12.0/23) and FOG server is at Default VLAN (172.24.0.0/22). As I told before, I could do a Deploy over Legacy Boot, but errors in UEFI boot remain.

[***Redbob]

@Sebastian-Roth these are two images:

this image is from a computer I didn’t registered on Server, chosing Deploy Image from FOG PXE Menu

This other image is from the same computer, but here I registered on Server and attached a Deploy Basic Task.

[george1421]

@Redbob OK just so we are clear. Everything works when in bios (legacy) mode, but the same computer when you switch to uefi mode fails with the error in your first post?

[***Redbob]

@george1421 Yes. What I don’t understand is why it could boot on PXE, but goes to error other there? Before this, PXE error occurred at boot time, not after certain operation. It’s like PXE wants to re-register Client at the middle of the operation.

[george1421]

@Redbob This reminds me of a communication problem. You should not get a connection reset…

It kind of makes me think its a spanning tree issue or a faulty cable. But if everything is the same other than bios/uefi switch on the same computer it really can’t be communications. If it is a communication issue, can you confirm the switch that the pxe booting client is on is using one of the fast spanning tree protocol like Fast-STP, RSTP, MSTP, port fast, etc? Another test would be to put a dumb unmanaged switch between the pxe booting computer and the building switch as a test. If it works with the dumb switch then its a spanning tree issue with the building switch.

If the firmware up to date on this target computer?

The other thing to test is to put the pxe booting computer on the same subnet, same switch as the FOG server. This would rule out any devices in between the two causing this issue. It still makes me think of a communication trouble because its failing at random different steps in the booting process.

[***Redbob]

@george1421, it’s funny again. I scheduled a Deploy Task for the device. So it entered in a loop:

• Boot UEFI ipv4;
• Error after the message “BzImage…” (I post an image with this error)
• Restart and Boot UEFI ipv4.

Suddenly, the computer began to deploy the image!!!

It’s sure I have connectivity issues, no?

[george1421]

@Redbob It sounds like connectivity issues, at the very end of imaging, the target computer tells FOG “I’m done” if the fog server doesn’t see that on the next reboot FOS Linux will start imaging all over again. So I can explain that part of it.

Have you gone through and tried to eliminate components between the fog server and target computer? Like plug the fog server and target computer into the same switch for testing? Replace the network cables? Try a different target computer? What you have is surely very rare in that I haven’t see it before.

[Sebastian Roth]

@Redbob Do you have some kind of security gateway, IPS thing in your network?

[Sebastian Roth]

@Redbob Any news on this?