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

Hello again, I conducted additional tests. In debug mode on the client, I ran network tests between the client and the fog server using the iperf server. The results do not indicate any network issues:

iperf -c 192.168.25.11 ------------------------------------------------------------ Client connecting to 192.168.25.11, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.25.49 port 35204 connected with 192.168.25.11 port 5001 (icwnd/mss/irtt= 14/1448/924) [ ID] Interval Transfer Bandwidth [ 1] 0.00-10.02 sec 1.09 GBytes 938 Mbits/sec

I also conducted disk write tests, and they also do not indicate any issues with the disk:

bash dd if=/dev/zero of=/tmp/testfile bs=1M count=1000 status=progress 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 0.17635 s, 5.9 GB/s

I also created an uncompressed image, and it also restored slowly, with transfer speeds below 1GB/s, rather around 500-600 MB/s, which results in even lower speeds.

I changed the PXE environment boot file, set it to realtek.efi, and then changed it to snp.efi.The snp.efi visibly improved the FOS loading process, but the image restoration is still slow. Can the FOS system use a different driver during restoration than it does when operating in debug mode?

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

@eliaspereira I’m not fully sure what is wrong or where it’s wrong at and I don’t really have a means to test.

I’m presuming you posted the issue on github which is a good place to start.

If that is the case it sounds like something missed a step during updating the database potentially?

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

I was unable to resolve this issue with pnputil using a cmd.exe script.

I noticed that the problem was also present on another FOG installation managed by other system administrators.

I assume (perhaps wrongly) that the problem is linked to an ANSI/UTF encoding issue. If someone using another language manages to run pnputil.exe in a cmd.exe script, report it here.

I was finally able to resolve this driver deployment issue using powershell. I’m leaving a sample code (install of a driver named usbblstr.inf) in case it helps someone.

New-Item -Path "c:\" -Name "drivers" -ItemType "directory" -Force Copy-Item -Path "usb-blaster" -Destination "C:\drivers" -Recurse Start-Process -FilePath "pnputil.exe" -ArgumentList "/add-driver C:\drivers\usb-blaster\usbblstr.inf /subdirs /install" -RedirectStandardOutput "$env:tmp\usb-blaster-install.txt" -RedirectStandardError "$env:tmp\usb-blaster-err.txt"

Sincerely,

Julien

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

@mashina You may have to make appropriate customizations but here are the basic steps:
https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images