@COE Typically if the permissions on the /images directory get messed up you can reinstall FOG and it will fix the permissions.

If you run the chmod 777 /images that will make the directory world writable but not the existing files / folders under that directory. If you use chmod -R 777 /images it will change everything under that directory to world writable.

But before you do that, the linux user fogproject should have read write access to /images. The password for that user is found in the hidden file /opt/fog/.fogsettings That is the user account fog uses to move files around while imaging.

@CheekiBreekiHelsinki you have some missing information needed in your first post.

What device is your dhcp server? (manufacturer and version) Is it on the same subnet as the FOG server? You mentioned the VM and FOG server was on the same subnet. What hypervisor are you using? I assume when you say “run PXE” you are saying you are trying to pxe boot the VM? Is the VM in bios or uefi mode? What specifically do you have defined for dhcp option 66 and 67?

Lets start with those questions to see what’s next

@luilly23 thanks for the reply. It was a working script before and I had updated it to comment areas and operations recently and added regions within the powershell script. There were no reboot options that I can remember (fairly sure) inline in the script but will double check.

There was a reboot option on the snapin itself.

Is there any log of the fog client to server comms that could say “this caused the reboot” or just more detail. I was thinking of turning the reboot off of the snapin properties to see if it would progress.

@george1421 result!!!

i bought a HP NIC as i have a HP laptop and it works

this one if anyone is inteerested

https://www.amazon.co.uk/HP-N7P47AA-Network-DesignJet-Adapters-Black/dp/B01618WGMY?th=1

as literally star tech, ugreen, tp link, realtek or asix chipsets didnt work

@george1421 I have run all test and first, there were a firewall rule that were blocking TFTP from the FOG server then after running more test, I realised that it’s not link to hardware or sofware on the server.
During test, I just changed the port on the switch next the computer to keep most of the hardware between server and client.
On same vlan I run at 450 Mbits/s (around 50 mo/s) and when I change vlan, I run at 150 Mb/s only.
And under 20 mo/s max with Windows TFTP client so I give up using it to run more tests.
Colleagues says there is not QOS but there is definitly something reducing the speed.

a06abb6b-6197-402f-ba10-c8be4fddc41a-image.png

@davidsontiago If you are using sysprep, include the command line option to tell sysprep to power off the computer. You have this message because when you pick shutdown from the menu, windows doesn’t actually shutdown the computer but put it into a sleep state leaving some files open that FOG sees. Sysprep will power off the computer correctly for cloning or use the following command “shutdown -s -t 0” to properly power off the source computer and close all open files.

@kotson3 I’m seeing connection failed, so I’m unsure what/where the problem is occurring.

In case anyone else is experiencing the same issue, I figured this one out.
routeraddress was missing in .fogsettings

cd /opt/fog vim .fogsettings

enter router/default gateway IP between single quotes

routeraddress='192.168.1.1'

reboot server.

@Jim-Graczyk

The wiki on migration covers migrating a single FOG server using the only workable process, so I’ll leave that alone.

I think my issue with the entire “Server Migration” process is that it requires you take FOG down at the onset of the process - before you attempt to install FOG on the new server. This obviously stops all the PC IT maintenance processes FOG provides IT support, but also FOG’s benefits to the end users of the hosts, until the new server/system is back up and working.

I’ve used FOG on a fairly large scale - some instances have 10+ remote sites, each with its own FOG Storage Node. To say that shutting it down before starting migration is inconvenient to the business is an understatement. Storage node migration didn’t require that the storage node had use the same IP as the old storage node - so that helped.

I hope that my initial post to you comes up when other FOG users search “FOG Migration”, so they don’t waste the time I did trying to build a completely new FOG system, including storage nodes, to cut over to, only to find that you can image PCs and create new hosts, but the exiting host would not talk to the new server system - so all the existing host configuration is lost (a large chunk of work). Ironically, there are numerous FOG wikis that address most issues that I ran into - creating new certs, the ever-present Reset Encryption on the FOG Client, etc., but none mentioned that the CA of the old system HAD to be used in place of the new.

I’m glad there was some way forward without having to reconfigure everything manually, but like many things in FOG wikis, everything in them is true, but context and limitations are not defined at the beginning. Even the migration process link didn’t spell out requirements, nor include remote sites and storage nodes. It needs to spell out that harvesting the CA and certs and using the old server’s IP address are as important as the database, snapins, and images - and this is the ONLY way to migrate.

So - a suggestion to the great minds working on FOG:

Create a way to change the FOG Client CA in one step - delete old and replace new - from within the FOG Client. This could be something issued from the old FOG server, for security reasons. CA deletion should also be built into the FOG Client Installation MSI/EXE. I use FOG to build portable Windows images that are company and FOG server independent. The FOG client is installed at the initial boot and replaced in the image as FOG evolves.

If that capability could be added, migration would be possible such that the new system w database, snapins, images, host configs, could be build out with multi-storage nodes and multi-locations, side-by-side with the old FOG system, gated only by DHCP boot settings at each site (IP broadcast space).

Jim Graczyk

@bwilli78 my dell machine was wrongly identified as 32bit and sent bzimage32. You can: 1) update to dev-branch 1629 I should help. Or 2) send bzimage to 32bit machines. (Because they are wrongly identified).

This could be your issue. I don’t see FOG sending bzimage32 anyway. Just a gut feeling. May be wrong.

@RocksAndRolls So NFS is mounted on the host and used as the place to put the files into a storage point separate of the deployable image point.

After the capture completes, FTP (to the server from the server) is used to move the captured image to the actual image path.

For example you have an existing image called: Windows 10, with a path of /images/Windows10

You create a new “base” image for this and are in the process of capturing it anew. But at the same time another 2 machines are configured to be deployed in the mean time:

You are capturing the new Windows10 in /images/dev/<mac_of_host_capturing> and the 2 other machines that are trying to be deployed can still run at the same time.

The FTP you see called is to move the /images/dev/<mac_of_host_capturing> to /images/Windows10 once it completes.

@fabritrento That’s not how this works. Just saying lol. 6.1.22 works fast for your situation, but that doesn’t mean there’s truly something wrong with the kernel for everybody. So when the next stable release comes out, you should remember to switch back to 6.1.22 and we’ll work to keep trying to update the kernels and hope that you’ll test them to see if it works for your situation so you don’t have to revert it to 6.1.22.