@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.

@george1421 @Sebastian-Roth I just discovered the solution to this issue.

Back a while ago we had HP Z400 workstations that required us to put a global kernel argument of “ahci = off” as they would fail to deploy an image without it. The reason we made this global as it did not have an impact on any other devices and I would not have to specify it specifically on every workstation. The oddness of this all, when the VM was running in BIOS this was not an issue with capturing the image with the SCSI controller. When the VM was UEFI it would fail and would require us using the SATA controller which slowed capturing to be almost a 2 hour process. Removing this kernel argument now allows us to capture an image at full speed again using teh SCSI controller and it fixed a hang issue that occurred in the beginning that was also previously reported with the “can’t find IRQ”.

All in all this is now fixed removing that kernel argument. I am just shocked that it would be affected differently between BIOS and UEFI specifically on a VM.

Thanks for all your help.

@Sebastian-Roth It started working now. I don’t know why it wasnt working yesterday. thank you.

@Mark7807 said in [Help] Can't download FogClient!!:

Hello,

I tried the .MSI network-compatible download, and the smart installer, and I get a timed out error on the site loading the download file.

I have the client download working on another Fog Server host, but the host on my laptop doesn’t load the client download from the “Fog Client” link at the bottom of the website cpanel.

What gives?!

Any help is greatly appreciated!

Sorry to bore you all to death, but it was just an IP conflict 🙂

Have a good day 🙂

Do you have any custom created FOG iPXE menu entries?

What is the output of the following URL keyed into a ms windows browser look like ?
http://192.168.56.10/fog/service/ipxe/boot.php?mac=1c:39:47:d5:c5:3d

what were you doing when this error was thrown?

First time pxe boot Imaging Something else

Next set of questions will be around the “LENOVO B50 IdeaPad”. The main question will be what version of the OS is installed on that device from the factory. Is it Win10 x64 or Win10 x86. (Yes some tablets are still running 32 bit operating systems).

@george1421 The capture was successful.

I do not remember shutting down Windows unsafely (on either install), but it seems likely that I did. I had since shutdown from the start menu.

I did see this error:

0_1541609320335_678a406a-fdfc-41ef-b4cf-ea48b4d19bbb-image.png

I am not sure if it will cause any problems.

I plan on running more tests to ensure that everything is working properly, but it looks like the partclone capture problem has been solved. I am curious, however, as to why dd also failed. Shouldn’t the state of the filesystem(s) be irrelevant for dd?

Thank you for your help.

@george1421
Thx :))

@p4cm4n We have seen issues with this lately and I am wondering if there is a bug pending. But on the other hand I cannot replicate this and I have done a couple of storage node installs lately. Please let us know if you have an idea on how this happened. Marking as solved for now.

@cwells-stpaulsgb Nevermind I will still add those advanced checks so we get better user error messages in the future.

You are more than welcome to join the team and help out with whatever you are good at, be it wiki or client development or … Just give is a shout.