PXE Chainloading error after FOG images menu

george1421 · Sep 4, 2019, 7:29 PM

Well I guess two questions to start.

Is 172.24.3.71 the IP address of your FOG server? Please confirm with ip addr show If you are unsure post the results of that command here.
Did you change over to using https to access FOG? If you go to a windows computer and key in “http://172.24.3.71/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00” do you get a page of text?
(Bonus question) Can you get to the fog web ui interface and login?

Sebastian Roth · Sep 5, 2019, 5:40 AM

@Redbob In the last topic the FOG server had IP 172.24.3.144. Did you change that again??

***Redbob · Sep 5, 2019, 7:39 PM

@george1421 here are the answers:

Yes, I raised another server. It’s not 172.24.3.144 anymore. It’s based on Fedora 30;
Yes, here’s the output from “http://172.24.3.71/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00”:

#!ipxe
set fog-ip 172.24.3.71
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
cpuid --ext 29 && set arch x86_64 || set arch i386
goto get_console
:console_set
colour --rgb 0x00567a 1 ||
colour --rgb 0x00567a 2 ||
colour --rgb 0x00567a 4 ||
cpair --foreground 7 --background 2 2 ||
goto MENU
:alt_console
cpair --background 0 1 ||
cpair --background 1 2 ||
goto MENU
:get_console
console --picture http://172.24.3.71/fog/service/ipxe/bg.png --left 100 --right 80 && goto console_set || goto alt_console
:MENU
menu
colour --rgb 0xff0000 0 ||
cpair --foreground 1 1 ||
cpair --foreground 0 3 ||
cpair --foreground 4 4 ||
item --gap Host is NOT registered!
item --gap -- -------------------------------------
item fog.local Boot from hard disk
item fog.memtest Run Memtest86+
item fog.reginput Perform Full Host Registration and Inventory
item fog.reg Quick Registration and Inventory
item fog.deployimage Deploy Image
item fog.multijoin Join Multicast Session
item fog.sysinfo Client System Information (Compatibility)
choose --default fog.local --timeout 3000 target && goto ${target}
:fog.local
sanboot --no-describe --drive 0x80 || goto MENU
:fog.memtest
kernel memdisk initrd=memtest.bin iso raw
initrd memtest.bin
boot || goto MENU
:fog.reginput
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://172.24.3.71/fog/ consoleblank=0 rootfstype=ext4 storage=172.24.3.71:/images/ storageip=172.24.3.71 loglevel=4 mode=manreg
imgfetch init_32.xz
boot || goto MENU
:fog.reg
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://172.24.3.71/fog/ consoleblank=0 rootfstype=ext4 storage=172.24.3.71:/images/ storageip=172.24.3.71 loglevel=4 mode=autoreg
imgfetch init_32.xz
boot || goto MENU
:fog.deployimage
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param qihost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
param sysuuid ${uuid}
:fog.multijoin
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param sessionJoin 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
param sysuuid ${uuid}
:fog.sysinfo
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://172.24.3.71/fog/ consoleblank=0 rootfstype=ext4 storage=172.24.3.71:/images/ storageip=172.24.3.71 loglevel=4 mode=sysinfo
imgfetch init_32.xz
boot || goto MENU
:bootme
chain -ar http://172.24.3.71/fog/service/ipxe/boot.php##params ||
goto MENU
autoboot

Yes, I can manage all operations from WEB UI
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).

***Redbob · Sep 5, 2019, 7:42 PM

@Sebastian-Roth, yes I change my server. I installed in another distro (Fedora 30) and set IP 172.24.3.71, because I’m tired to deal with Ubuntu is FOG Enemy.

Sebastian Roth · Sep 5, 2019, 7:54 PM

@Redbob Did you disable firewall and SELinux? Run the following commands as root and post output here:

iptables -L -n -v
getenforce

***Redbob · Sep 5, 2019, 8:25 PM

@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 · Sep 5, 2019, 8:28 PM

@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 · Sep 5, 2019, 8:30 PM

@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 · Sep 5, 2019, 8:31 PM

@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 · Sep 5, 2019, 8:38 PM

@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 · Sep 5, 2019, 2:49 PM

@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 · Sep 5, 2019, 8:50 PM

@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 · Sep 5, 2019, 8:53 PM

@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 · Sep 5, 2019, 3:00 PM

@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 · Sep 6, 2019, 8:31 PM

@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 · Sep 6, 2019, 2:51 PM

@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 · Sep 7, 2019, 6:40 AM

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

Sebastian Roth · Sep 18, 2019, 5:03 PM

@Redbob Any news on this?

PXE Chainloading error after FOG images menu

135

12.1k

17.3k

155.4k