@george1421 Thank you once again for great support!!!

Since the apache crashes did not correlate with the no directory or file errors I double checked everything attached to our workbench and…

Found out one of my engineers had a test box attached to our workbench that was set for no reply to ICMP so I did not catch it had been static’d to 10.0.0.250 as well. Flipped it over to DHCP and now PXE boot works consistently.

Sorry and thank you for your time!

Some options.

1º Use a snapin pack including the executable.
2º Put it in a ftp server and use a cmd ftp client to download it. (You can use the fog server/node as ftp and the built-in ftp client)

This two solutions works!!!

@Peter365 The only comment I can make is watch the permissions on the /images directory now. If you run into upload issues issue this command (note is a bit loose with the security, but its not too big of a risk) chmod -R 777 /images

@Wayne-Workman a bit late in the day but have just setup Fog Imaging server. Could get Realtek Nics to work. Your post solved the issue.

I have been paying with this for a bit now and was working through a scenario where the OS doesn’t get an IP so trying to statically assign one, at least temporarily. I wasn’t able to get it to work but I think it just needs a little more time to work on this scenario. Otherwise, this works quite well. I did some minor tweaks so that my end user only had to boot to the USB drive and after the cron job runs keep an eye on the screen for the IP of the FOG server which I echo’ed out at the end of the script using: printf “The IP of the FOG server is: $IP \N” > /dev/console

I sent it off to a co-worker in another location and asked them to just plug in the USB drive, boot to it, wait for the message then try another machine to see if he got the FOG menu. He did and was able to register the machine with FOG and pull an image down so I’m marking this:

SOLVED!!!

I may try to go back when I have some time to finish hashing through the statically assign an IP if you don’t get one scenario…

Current Solution set Kernel to 4.19.64 and set global option in Fog Configuration–> FOG Settings --> General Settings --> Kernel ARGS to tsc=unstable

Luckly this is the last year for these machines.

@oliver just so you know the linux user fog or fogproject should never be used for system administration. These accounts are owned by the fog program and will reset their passwords each time you install FOG.

We are glad you have it working now.

@Brad-Schumann From what you wrote so far I am fairly sure this is a different issue than we had before. Please open a new topic and post more details on when this is exactly happening. When there is a task scheduled or if you try to register the host or what?

@darkxeno In the dell firmware switch the disk controller from Raid-on to AHCI mode. Unless you have more than one disk connected in a raid configuration raid-on mode doesn’t help you. There is a document issues between linux and intel controllers in raid-on mode. Once you have imaged with fog you can switch back to raid-on mode or leave it in ahci mode. It doesn’t matter to windows.

@Celena said in I have a problems! I need your help:

he computer reboots before Windows has a chance to set up completely.

This is probably because you didn’t follow the guidance on the wiki about disabling the fog service on your reference image and then enabling it in your setupcomplete.cmd batch file.
https://wiki.fogproject.org/wiki/index.php/FOG_Client#FOG_Client_with_Sysprep (but that’s just a guess)

George,

I have another question, this time about sysprep. Why do we need to go through OOBE for an installation that is all in the same locale? Wouldn’t it be easier to just generalize and be done? And if doing that, do I still need to disable the Fog Client Service before doing it?

Thank you,
Dave

What device is your dhcp server. I’m going to guess it is a soho (home) router? The reason I think this is your gateway is 192.168.0.1 and your next server (from the picture) is also 192.168.0.1. Home (soho) routers will often say they are the pxe boot server and not the fog server.

@Sebastian-Roth if I had to guess it’s lvm setup.

This old topic is solved !
I was setup a new FOG stable server on a debian (on a new disk) and snapins works flawlessly.

Solved ! 😉

@slipke Well if you wanted to do it in the auto reg it will be a bit harder than manual registration, but here is the curl call in the fog.auto.reg program. https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.auto.reg#L73

Before that curl call you will need to collect the serial number of the machine. The trick is the serial number is saved in the smbios in different locations for different manufacturers.

If you look at this post it shows you how to get the serial number for the two chassis types I had to interact with: https://forums.fogproject.org/topic/6304/fog-2-0-request-advanced-host-naming/2 It also shows how to create a complex computer name based on several factors on the fly. So you will need to compute/collect the serial number and pass it along with the other arguments to the php file mentioned in the curl call. And then in the php code read that variable and place it in the hostname variable instead of the mac address.

If you wanted to do this using the manual registration fog.man.reg where it asks for the user to input the host name into $host just use the dmidecode value to copy the serialno value into the host variable. https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg#L161

@aborn

Good day.

Did you get any resolution for this problem?

I have Fog 1.5.7 on CentOS 7 with the specified partition sizes. All other settings as default, firewall and SELinux are disabled. My image name is W10E.

I get the same results as you did, also with the image files appearing in the /images/dev folder, then in /images/W10E and then disappearing again.

I sort of got around it by copying the /W10E folder to /W10E (copy), wait for /W10E to disappear and then rename the copy as /W10E. And I can deploy this image, absolutely no problem.

Many thanks
rarcher2

Would just like to add to this - I recently ran into this same issue again. Racked my brain trying to figure out what I did wrong or what setting could have possibly changed. Here’s what I found out.

I was using the above PC again after cleaning and prepping to capture another image. This PC was already registered in FOG. I deleted the host and attempted to PXE boot again and everything went smooth as butter. Looks like there’s an issue booting if the device is already registered. I’m not sure what the issue is, but deleting the host and re-registering solved it.

I have the same problem here, i have an Ubuntu client with multiple disks and partitions, and when I try to capture the image i have the same errors, I tried a lot of options without success.

Network similarities are as follows
Same network same switch same router

differences are as follows
motherboard
Bios
network adapter
CPU
(everything)
its a uefi bios

the network adapter

I have 4 different PC models scattered about the place and get different results on them all some boot and mount the nfs others time out