It is now working. I think I found the issue. I was using the Smartinstaller my old server generated. It used the same IP address and hardware, so I didn’t think it’d be a problem.

Hi again,

Only for give more information about this in a huge scenario. In our case the FOGPingHosts service give 4 hours and 30 minutes, more or less, to do ping to all clients.

Capture of the traffic in one client:

18:10:43.216290 IP fog7.lgp.ehu.es.39006 > u032668.lgp.ehu.es.microsoft-ds: Flags [S], seq 3515736006, win 29200, options [mss 1460,sackOK,TS val 2691861063 ecr 0,nop,wscale 7], length 0 18:10:44.216894 IP fog7.lgp.ehu.es.39006 > u032668.lgp.ehu.es.microsoft-ds: Flags [S], seq 3515736006, win 29200, options [mss 1460,sackOK,TS val 2691862064 ecr 0,nop,wscale 7], length 0 22:46:19.552188 IP fog7.lgp.ehu.es.47968 > u032668.lgp.ehu.es.microsoft-ds: Flags [S], seq 14809462, win 29200, options [mss 1460,sackOK,TS val 2708397399 ecr 0,nop,wscale 7], length 0 22:46:20.552909 IP fog7.lgp.ehu.es.47968 > u032668.lgp.ehu.es.microsoft-ds: Flags [S], seq 14809462, win 29200, options [mss 1460,sackOK,TS val 2708398400 ecr 0,nop,wscale 7], length 0 03:19:37.718318 IP fog7.lgp.ehu.es.51734 > u032668.lgp.ehu.es.microsoft-ds: Flags [S], seq 3380421067, win 29200, options [mss 1460,sackOK,TS val 2724795565 ecr 0,nop,wscale 7], length 0 03:19:38.720889 IP fog7.lgp.ehu.es.51734 > u032668.lgp.ehu.es.microsoft-ds: Flags [S], seq 3380421067, win 29200, options [mss 1460,sackOK,TS val 2724796568 ecr 0,nop,wscale 7], length 0 07:52:47.623417 IP fog7.lgp.ehu.es.57902 > u032668.lgp.ehu.es.microsoft-ds: Flags [S], seq 1502300674, win 29200, options [mss 1460,sackOK,TS val 2741185470 ecr 0,nop,wscale 7], length 0 07:52:48.624903 IP fog7.lgp.ehu.es.57902 > u032668.lgp.ehu.es.microsoft-ds: Flags [S], seq 1502300674, win 29200, options [mss 1460,sackOK,TS val 2741186472 ecr 0,nop,wscale 7], length 0

@bmick10 So now that you have it configured to not restart when the system is that’s good. Now just make sure the settings are correct in your .fogsettings file so that the dhcp server isn’t reenabled when you update FOG.

@msi Just to let you know, we have worked on the replication code and fixed a couple of issues. The new release is on the door step and should work fairly well.

We’ll put that into the release notes as well but just to let you know beforehand:
Nodes being on different versions (1.5.4 vs. 1.5.5) will replicate images over and over again as some of the hashing code needed to be changed. Therefore we advise you to update all nodes in one go! Please make sure you stop replication on the master first (systemctl stop FOGImageReplicator), then update the storage node(s) and then update master node as a last step.

@Scott-Adams Thanks Scott. That seemed to work with my initial test. I will test it again later this afternoon. I’m surprised that the service in the base image would impact the deployed host.

Thanks

@Baessens Ahhh, I just had one more idea. Please run fdisk -l /dev/sda and post a picture as well. Possibly this is a sector size issue.

I got it figured out. As I was staring at the error message, it occurred to me I was blaming the computer and not really giving thought to the server itself. Anyway, upon digging I found the .mntcheck file was missing from it was supposed to be, so a couple of touch commands later and we are off an running.

Thanks for the help.

This was weird but I think it’s solved now. It didn’t matter which method I chose it would always give me the SAN error. I decided to reboot the server after current images finished. Then the error messages started to change. This now works with the REFINED_EFI method. I’m not sure why it didn’t want to update the method I chose but updating the server seemed to have kick what was stuck in it’s settings.

@fognerval It really depends on what this means “after several changes to have the tftpd and http boot I am stuck” What was changed from the fog default install.

Also please answer the other questions I asked. We need to get the full picture of what you are tying to pxe boot and what might have changed by you from the default fog installation.

Did you touch/change the FOG/FOS kernels or inits? I’m not talking about Ubuntu but the FOG supplied target boot kernels.

@george1421 Thank you thank you!!! that worked you are a legend mate ! Its all running!

@Sebastian-Roth said in Replication Issue:

max_per_ip=200

Changes in the conf done, will let the rep job running 2 full rounds and edit this post with the results.

“Seems like the default of 50 is not enough for the amount of images you have” yeah, as I said in the chat, here we use fog A LOT, bout 7 diferent images in frequent use and others 4 used from time to time. F* good tool indeed. hahaha

Edit: Hell yeah! running like a charm! 3 rounds of rep job so far, no mismatch, no max conn reach… beautiful

tks dude! Appreciate ur suport!

Are you saying you have the same error and it was fixed by disabling dhcp-snooping on the switch? I’m just trying to understand the context here.

@Sebastian-Roth

Dear Sir,

Thank you for your kind reply.

Basavaraj, From India.

@Sebastian-Roth

Dear Sir(Sebastian-Roth),

I understood (Not Everything) what you explained about My Questions…

You explained that not to define DNS Address in My Network Scenario…
But I already defined it with this Address10.10.1.2

Now Whether it is possible to remove it OR let it be as it is…?

Kind Hardheartedly Thank you For In Time Help…

Kind Regards,

Basavaraj, From India.

In nas server:

root@nasmad00:/# cat /etc/exports /images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0) /images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1) root@nasmad00:/# df -h S.ficheros Tamaño Usados Disp Uso% Montado en /dev/mapper/centos_centos-root 8,0G 1,6G 6,5G 20% / devtmpfs 905M 0 905M 0% /dev tmpfs 915M 0 915M 0% /dev/shm tmpfs 915M 8,4M 907M 1% /run tmpfs 915M 0 915M 0% /sys/fs/cgroup /dev/xvda1 1014M 235M 780M 24% /boot /dev/mapper/centos_centos-images 90G 33M 90G 1% /images tmpfs 183M 0 183M 0% /run/user/0

in fogstorage:

root@fogstor01:/# df -h S.ficheros Tamaño Usados Disp Uso% Montado en /dev/mapper/centos_centos-root 8,0G 3,1G 5,0G 39% / devtmpfs 905M 0 905M 0% /dev tmpfs 915M 8,4M 907M 1% /run tmpfs 915M 0 915M 0% /sys/fs/cgroup 172.30.0.4:/images/ 90G 33M 90G 1% /images

@Sebastian-Roth Yes your fix does indeed resolve the issue for me – thank you sir !!!

@iekozz I’ve marked this topic as solved now. Please feel free to open new threads if you have further questions. Trying to not mix up too many topics in one so this will also be helpful for others if they have a similar issue and search the forums. 🙂

@Sebastian-Roth I can boot with USB C (dodocool).
I’ve only had to update the kernel to the latest version and touch the bios parameter
The model was XPS dell, and already solved! thanks!!

@Jimbohello This is fixed in the latest init files. See here on how to manually download the latest init and kernel files: https://forums.fogproject.org/topic/12169/erasing-current-mbr-gpt-table-issue

@parkcitygolfer Maybe replace cables and you might even look into spanning tree, although I have to admit that I have never seen this error in combination with a spanning tree issue.