Best posts made by neodawg

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!