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

Hi Sebastian,

Thank you for your answer.
Indeed the problem was some definition I set and forgot in the global settings.

Under “Non-Registered Host Image” I set : /images when I removed it, everything works fine.

Great product with a great community.
Thanks again!

@Basavarajnc said in It takes longer Time (More Than 5 Minutes) Erasing current MBR/GPT tables.:

Now My Question is … Manually Written the file ->“bzImage4183” in the Host Kernel Field… is it Correct Sir?
Thereafter, I updated by using Update Button in the Make Changes? Field… is it Correct Sir?

Yes this is correct. This field allows you to assign a specific kernel to a specific host. That is the design of FOG. No this is not correct. You have hard defined for that host it will only use bzImage4183. The main and updatable kernel is called bzImage. When the next version of FOG is released (1.5.5) it will only update bzImage. The host where you statically defined bzImage4183 will continue to us that kernel forever.

Also Sebastian’s fix also requires you to update the init.xz files to completely eliminate the delay during disk format creation. So both the kernel (bzImage) and the virtual hard drive (init.xz) need to be updated to correct this problem.

@dburk Sorry for digging out this old topic. While trying to figure out some replication hickup I found and fixed a couple of issues within the code. All that will be in the next release. Hopefully coming soon. Let me know if you are keen to test those changes beforehand.

Edit: Issues fixed in 1.5.5.

@Sebastian-Roth

Dear Sir (Sebastian-Roth),

Sir, One Word … You are Real Great Sir…

I am totally frustrated with Error…Till Now.

Now It has got solved. Now running successfully…

Devotedly and Willingly Thankful to You Sir. Real Great…

Sincerely Yours,

Basavaraj From India,

@Sebastian-Roth

Ok. I will change those values to 0 on Monday and let you know if it boots up. Appreciate he help!!!

@iwohl The hack I created (with the help of Tom who converted it into a plugin) for persistent group like function. In this case you will create a template “fake” host, who’s settings will get copied to any host added to the group. That should get you pretty close.

@JimmyJ0516 Definitely an issue of sending Wake On LAN packets across VLANs and all that. We talked on chat. Not sure yet if the switches used (Cisco Meraki MS-350) can do something like “UDP-helper”, directed broadcasts or call it whatever you like. At least I have not found and details yet.

@zpoling DHCP handshake looks good in the latest PCAP but as you said we won’t find out what was going on when it failed. More often than not those kinds of issues keep coming back until you really find and fix them. Make sure to capture the traffic when you see it happening next time.

Marking this as solved for now.

figured it out thanks to this thread.

https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

@Sebastian-Roth I’ve opened another thread about it. I ran a program that scans for DHCP traffic because I’m not too familiar with wireshark, but it does the same thing I imagine. After three hours, the only traffic showing up was our one and only DHCP server.

https://forums.fogproject.org/topic/12615/tftp-only-working-with-certain-vlans/2

@rlindenschmidt Have never seen this error before but doing a little research I think LDM in this case means Windows Logical Disk Managment - see here·. Can you please take a picture of Windows Disk Management console from that client and post here?

@JackWallington Please answer George’s questions first. As well let me add this one. Do you have a D-Link DGS-3620 switch between your HP desktop and the FOG server? If not you still might check to see if some kind of DOS attack prevention is enabled on a switch connecting those two - more information see here.