are they all in a clean shutdown state before starting?
do they already have an OS?

Just came across the same issue, did you fix it?

Finally , @Tom-Elliott

Reinstallation of fog solved the problem . I think the issue was linked to the fogproject account. This issue can be closed.

@infotech_22 Generally speaking, if you do setupcomplete.com, you should completely disable the FOGService as re-enable it as the final step of the setupcomplete.com script.

The reason:

FOGService will attempt to start up and perform its actions alongside anything else that’s occurring. Generally, when the system is setup and running just fine, things are okay because there’s no interactions, but when you pair it with the OOBE configuration stuff, where it could be changing ini’s and Registry thigns, then the FOG Client is saying “Hey restart to change the name and join the domain” or “Hey restart because I completed installing this Snapin” or whatever else may be going on, it can leave your machine in an unknown and cause issues.

This isn’t something we’re able to fix in a codified manner unfortunately and we have given instructions many times to allow FOG Client while in OOBE state.

https://wiki.fogproject.org/wiki/index.php/FOG_Client#:~:text=If you plan to use,the image deployment is complete.

I don’t know if this is in the more modern Documentation, but it is in the original documentation as well.

@Mr_____T Well, I have discovered a work around. According to our consultant, the legacy wrapper message in the 1st or 2nd image was kinda the key. the X360 has no wired nic port and the usb nic adabter is recognized as a legacy booting device. But the unit only boots efi. I followed this link for starters:

Kernel runtime parameter:

Next I added the MAC addresses from each usb dongle I have available. Then, from the fog web interface:

list all hosts
Select the host
Basic Tasks tab
Deploy tab
Task (I first checked debug and followed the bread crumbs no issues)
Imaging commenced.

This is quite a bit more work than I was hoping to do just to image one machine. I was hoping someone out there could come out of the fog (pun intended) and provide some feedback.

So this is not solved. But a work around that does. If you got this far Tx

Not sure why I did not just start with trying a pre 6.xx.xx kernel…

Downloaded the the last 5.15.xx Linux kernel slapped it in /var/www/fog/service/ipxe/bzimage-5.15.98 updated the host kernel to bzimage-5.15.98 and BOOM 20GB/min.

Still willing to do some testing if there is anything you need from me to see if this can be fixed in 6.xx.xx.

@JJ-Fullmer We are using FOG 1.5.9 I have tried turning on the Mac passthough. I have tried all of the .efi bootfiles i have. We did get a machine back from Lenovo where they rolled back the biois and that one machine is working fine

@joshua_mchugh George’s mention of using a post install script to do it is more advanced but very worth the effort. Having it domain joined via sysprep specialize simplifies things in the long run.
That being said, you’re probably misunderstooding groups, because they’re a little confusing. Groups in Fog do not dynamically update the OU of the host members, but it can be used to set the OU in bulk on members. There is a plugin to change the behavior of groups if you want, but I’d try it the normal way first.
But if you set the OU on the host, then when it joins the domain via the fog client, it will be in that OU. It will not move a host to a different OU, unless you do something like manually leave the domain and change the computer name and then the fog service will rename the computer back to what it is in fog and then join the domain in the set OU.

I personally use a post install script now that grabs the OU from to host and Injects that into my unattend file. I believe I’ve posted some examples in the past. If I remember tomorrow when I’m at a computer and not a phone, I’ll link them.

@argylega have you restarted the Mariadb and apache services, or the whole server?
I also assume you mean you can’t login to the website. Is there anything in the apache error log?

@AUTH-IT-Center Super, thank you very much! Looks like its working again 🙂

I deleted the private and public SSL certs and reran the installer, seems to have fixed it.

/opt/fog/snapins/ssl/.srvprivate.key
/var/www/html/fog/management/other/ssl/srvpublic.crt

@processor

I’ll reply to myself.
finally I found that image was partially copied to storing folder.
So yes no images was found !!
I just had to re-upload a backup to solve this issue.

sorry for the disturbing.

@Tom-Elliott Hellooooo,
Sooooo, leaving the UUIDs as is I simply decided to use a different machine to create the image. I was using Intel and switched to a SuperMicro and set BIOS booting option to BOTH meaning Legacy + UEFI.

That same image was successfully deployed to that very problem Intel box as well as others. And since it was EXT4, the partition grew and shrunk as needed.

I found a partial solution. If in the file /var/www/fog/lib/reg-task/registration-class.php on the line where $userTest is, I change the values ​​of $username and $password to the real values ​​through which I log in to the FOG server, I get quickreg including deploy image… This is not a system solution and should be fixed by the developer. (Again, this is for version 1.6, on 1.5.10 this works correctly).