Not sure if that is possible, but if a guy is using SVN to download the trunk, then needing to roll back to a previous version of trunk its confusing and you pretty much have to guess the SVN version from the fog version.

Thought it would be convenient to have those versions match the fog version in the cloud.

I am not an expert in SVN/GIT, but I usually use SVN because of the easy downloading of a specific revision.

EDIT: Or list both version numbers in the cloud if it isnt possible.
Fixing the fog/management/index.php?node=about page to list the SVN version would work as well

I am also seeing this issue, however when I look in the fog.log file it says that all modules are disabled on the server, even through i checked both the host and server level settings. I am using the old fog client (I assume this is supposed to work yet).

I also noticed the hostname didnt change when the machine started up, so the early hostname change didnt work, the image is a Windows 7 image. Fog ver 7597

Anything I can provide to assist in fixing this issue?

@Developers

Seems to be a typo on the Database Update page. Server is CentOS 6.5

http://fog/fog/management/index.php?node=schemaupdater

cd ~;mysqldump --allowkeywords -x -v fog > fogbackup.sql

Should be

cd ~;mysqldump --allow-keywords -x -v fog > fogbackup.sql

So for fun or insanity, i downgraded rpcbind.x86_64 0:0.2.0-13.el6_9 to rpcbind.x86_64 0:0.2.0-13.el6 on the CentOS 6 box I am local to and I think that may have fixed the issue. The image is currently uploading in debug mode, going to try pushing it out as soon as its done.

The other thing I haven’t ruled out is having open-vm-tools installed. I dont know why this would break things but I read something somewhere on some forum about it.

I did yum downgrade rpcbind on the CentOS 7 box and the services are still running, but the local tech hasnt tried imaging again yet.

Resolving Dependencies
--> Running transaction check
---> Package rpcbind.x86_64 0:0.2.0-38.el7 will be a downgrade
---> Package rpcbind.x86_64 0:0.2.0-38.el7_3 will be erased
--> Finished Dependency Resolution

EDIT: it appears this process fixed the CentOS 6 box, it was able to deploy the same image after an immediate capture of it.

@george1421 Yep, I have had the best luck with GRUB vs SANBOOT, probably not as fast but works.

Thanks for the info, we can close this case!

I discovered this bug too when updating. My solution was just to create a group of all computers and then update the default AD credentials under Fog Settings. Then I just cleared it and repopulated the fields in Fog Settings. Then used the group of all and modified it for all computers at once. I even used the same password as I was.

My speculation is that the new password encryption measure put in are breaking it, the length when the password is shown is way off of what it should be when its updated correctly.

It appears the github download link is broken on the fogproject.org website? Is this an error or is this because 1.5.1 has a big bug? I realize I can pull it from a github zip, I just always use the tar.gz files in my install script.

Thanks,

@george1421 Yep, I have had the best luck with GRUB vs SANBOOT, probably not as fast but works.

Thanks for the info, we can close this case!

@george1421 Thanks, that is what I did.

So for legacy its set to GRUB and EFI its set to REFIND_EFI

@george1421 Thanks, that worked. I see there is more settings under the system for exit types, so I just changed the whole EFI part of the server to REFIND_EFI. So we will see what that breaks.

Server

• FOG Version: 1.4.4
• OS: CentOS 7

Client

• Service Version: NA
• OS: NA

Description

Fog iPXE screen is having a chain loading issue when trying to boot from the local disk. They get the error and then reboot in 10 seconds and then just keep looping forever.

Computer models with issue are Dell Latitude 5580 and 5289

I am using GRUB as the Exit type in FOG.

Computers are UEFI booting to iPXE.

Here is a shot of the error. Picture

Thanks,

Here is the errors from the FOG client.

7/14/2017 11:44 AM Service Sleeping for 334 seconds
 7/14/2017 11:49 AM Middleware::Communication URL: http://fogserver/fog/management/index.php?sub=requestClientInfo&configure&newService&json
 7/14/2017 11:49 AM Middleware::Response Success
 7/14/2017 11:49 AM Middleware::Communication URL: http://fogserver/fog/management/index.php?sub=requestClientInfo&mac=F8:59:71:B0:43:44|F8:59:71:B0:43:43|F8:59:71:B0:43:47&newService&json
 7/14/2017 11:49 AM Middleware::Response Invalid host
 7/14/2017 11:49 AM Middleware::Communication URL: http://fogserver/fog/service/getversion.php?clientver&newService&json
 7/14/2017 11:49 AM Middleware::Communication URL: http://fogserver/fog/service/getversion.php?newService&json

 7/14/2017 11:49 AM Service Creating user agent cache
 7/14/2017 11:49 AM Middleware::Response Module is disabled globally on the FOG server
 7/14/2017 11:49 AM Middleware::Response No Printers
 7/14/2017 11:49 AM Middleware::Response Module is disabled globally on the FOG server

Hello,

Server version is 1.4.4
Using EFI PXE booting rather than legacy

I am having issue where using a USB-C dock with NIC in it to image. The problem is that when you register and image the computer it uses a4:4c:c8:aa:9e:c5 MAC, which is fine and they image fine.

When its done imaging and windows boots, then the dock uses the ‘correct’ MAC d4:81:d7:8a:44:64 that is actually printed on it and is actually associated with the dock and not the laptop, which is its own problem.

So I thought a solution was to approve the wireless card MAC and let the FOG Client use that MAC to identify and join the domain, the problem is that it doesn’t unless I make it the primary MAC, which then breaks the iPXE part of imaging fog. So I cant have both working.

So my question is what is the point of the additional MACs if FOG cant use them to identify and perform tasks using other MAC than the primary one? I thought that was the point so that we didn’t end up with ‘duplicate’ clients in FOG.

I understand that if the MAC is NOT approved it shouldn’t be able to do any functions, however once approved why cant it?

Thanks,

I heard back from the local tech with the CentOS 7 box and downgrading rpcbind fixed the issue on that server as well. I guess we will have to wait until RedHat/CentOS fixes the rpcbind package

@Sebastian-Roth and @george1421

Yes, the service will start and run, but shortly after a client tries to connect the service will die.

The link you listed sound exactly what is happening, however i didn’t test different versions of NFS protocol, ie v3 vs v4.

On one of the fog servers the tech was able to actually image one computer successfully and then the next computer it failed on, because the rpcbind service had died.