PXE Chainloading error after FOG images menu
-
@Redbob In the last topic the FOG server had IP 172.24.3.144. Did you change that again??
-
@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).
-
@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.
-
@Redbob Did you disable firewall and SELinux? Run the following commands as root and post output here:
iptables -L -n -v getenforce
-
@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
-
@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…
-
@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) -
@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?
-
@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.
-
@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. -
@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?
-
@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.
-
@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.
-
@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?
-
@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.
-
@Redbob Do you have some kind of security gateway, IPS thing in your network?
-
@Redbob Any news on this?