@george1421, great stuff! How couldn’t I see this before?
lol!!!
Well, I reinstalled it, and already applied what Elliot said. Let’s see if it will take things easy. Thanks!!

Hi, everyone!

I know that whenever FOG Web Interface shows this message when I try to access it:

it’s to time to reinstall it.

The problem is: this situation occurs every 2 months the average.
Is there another way to solve this unless reinstalling it?

@Sebastian-Roth it’s funny but… I decided change the client IP (added 172.24.12.49 into DHCP Exclusion Zone now client received 172.24.12.65), so it worked!

Maybe some lockout from FW or Core rules… but it’s working, as I figured out on other computer with some specification. Could you check PCAP of 172.24.12.65? It’s here: new PCAP, just to understand it, because I know, FW and Core rules are not the target of this forum ;)

@Sebastian-Roth these are the answers, as followed:

1. No, MAC address from client is 10:05:01:9c:7b:24 (that’s from 2nd image); MAC adress from FOG Server is 34:64:19:00:26:86;
2. That’s Core Switch (My network is splitted in subnets - FOG is in default subnet - mask 255.255.252.0, the client is in another subnet - mask 255.255.254.0);
3. As I know, there’s no firewall rules restricting LAN-level access, just WAN-level. See IPTABLES from FOG server:

userutil@moringa:~$ sudo iptables -L
[sudo] password for userutil: 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             multiport dports mdns
ACCEPT     tcp  --  anywhere             anywhere             multiport dports 4000

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

4. Yes, I could access WEB UI from the client normally.

@Sebastian-Roth , I did a capture directly from FOG server (172.24.3.144) by Wireshark, the troubled client is 172.24.12.49. Here you have it: https://drive.google.com/open?id=1oolDaPqrF4gFIzN8gRfIXrnyKC18ahHj

Hi,

I still have the ipxe.efi chainloading tantalizing me… I already posted another issue about it (11240) and it worked when I followed instructions to “connect” to a unmanaged switch over building switch “as a workaround”…

…we have here several types of computer with UEFI boot. Some of them is working properly. That’s its behavior:

on the other side, I have some computers will no work, they gave me this kind of error:

Any ideas? As I see, it’s not properly IPXE issue, because some UEFI are booting from IPXE… Is the second type of BIOS “lazy” to process IPXE Boot request??

I have this problem in FOG every 3 months aproximately. All I just do is to reinstall it and everything turns well, wihout any lose of data or settings.

@Sebastian-Roth, it’s funny. Fog deployed successfully all partitions, simply pressing ENTER after each breakpoint.

@Sebastian-Roth That’s what I did.
Follows Settings you suggested:

After usual messages, these are what I get. Here are the images:

@Sebastian-Roth Follows here:

Below is a variable dump from FOG
osid=9
osname=Windows 10
mbrfile=
type=down
storage=172.24.3.144:/images/
img=PositivoD535Win10A8
imgType=mpa
imgFormat=0
imgPartitionType=All
disks=/dev/sda /dev/sdb
hd=/dev/sda
 * Press [Enter] key to continue

[Tue Sep 11 root@fogclient /]#

Typing fdisk -l, we have:

Disk /dev/sda:119.2 GiB, 128035676160 bytes, 250069680 sectors
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/physical): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start       End   Sectors  Size Id Type
/dev/sda1           1 500118191 500118191 238.5 ee GPT


Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes